[pgbr-geral] Registrando tempo de "downtime" para efeito de SLA

[Alexsander Rosa]

Nosso servidor roda 24x7 porém de tempos em tempos (geralmente num domingo)
o pessoal da operação faz um restart por causa de atualizações do S.O.
(Linux). Eu gostaria de medir este downtime para criar um indicador do SLA
(ex: 99,999% de uptime) separado somente para o PostgreSQL, que é diferente
do downtime dos (micro) serviços.

Existe alguma forma "oficial" de obter os horários de start / stop do
servidor PostgreSQL sem ter que procurar string no log?

Por exemplo, meu desktop aqui tem um PG 9.6 que ao ser reiniciado gera o
seguinte LOG:

2018-03-05 12:02:16.535 -03 [1597] LOG: pedido de desligamento rápido foi
recebido
2018-03-05 12:02:16.535 -03 [1597] LOG: interrompendo quaisquer transações
ativas
2018-03-05 12:02:16.535 -03 [1698] LOG: inicializador do autovacuum está
sendo desligado
2018-03-05 12:02:16.536 -03 [1695] LOG: desligando
2018-03-05 12:02:16.705 -03 [1597] LOG: sistema de banco de dados está
desligado
2018-03-05 12:02:17.737 -03 [6814] LOG: sistema de banco de dados foi
desligado em 2018-03-05 12:02:16 -03
2018-03-05 12:02:17.785 -03 [6814] LOG: MultiXact member wraparound
protections are now enabled
2018-03-05 12:02:17.787 -03 [6813] LOG: sistema de banco de dados está
pronto para aceitar conexões
2018-03-05 12:02:17.787 -03 [6818] LOG: inicializador do autovacuum foi
iniciado

Seria interessante se houvesse algum tipo de gatilho onde eu pudesse gravar
isso de forma controlada.

[Euler Taveira]

Em 5 de março de 2018 12:10, Alexsander Rosa

Existe alguma forma "oficial" de obter os horários de start / stop do
servidor PostgreSQL sem ter que procurar string no log?

pg_isready com versões >= 9.3. Se você usa uma versão mais antiga,
você ainda pode compilar o código do pg_isready na versão antiga ou
fazer um programa em C que use PQpingParams() ou PQping() -- tais
funções estão disponíveis a partir da versão 9.1.

[Alexsander Rosa]

Obrigado pela resposta! Neste caso eu vou ter que fazer um polling, certo?
Eu gostaria de uma precisão abaixo de 1 minuto (ou seja, não dá pra usar o
CRON), porém não quero ficar toda hora chamando o *pg_isready* pois isso
certamente vai influenciar na carga do servidor. Além disso, quando o S.O.
for reiniciado meu programa em C vai cair também.

O ideal seria uma função análoga à *pg_postmaster_start_time()* porém com o
último shutdown.
Talvez seja possível criar uma "*pg_postmaster_last_shutdown()*" para obter
esta informação.

Eu sei que nosso servidor PG foi reiniciado, pela última vez, dia 30 de
janeiro:

SELECT pg_postmaster_start_time();
pg_postmaster_start_time
-------------------------------
2018-01-30 07:33:29.438349-02
(1 row)

No caso eu sei que está no ar desde Janeiro porém eu não sei que horas, no
dia 30/01, o servidor foi parado. Olhando no log temos:
2018-01-30 07:33:07.278 -02 [1212] LOG: autovacuum launcher shutting down
2018-01-30 07:33:07.373 -02 [1209] LOG: shutting down
2018-01-30 07:33:07.440 -02 [1195] LOG: database system is shut down
2018-01-30 07:33:29.439 -02 [1350] LOG: database system was *shut down at
2018-01-30 07:33:07 -02*

Veja que o servidor SABE que o shutdown ocorreu às 2018-01-30 07:33:07 -02
(no caso foi uma alteração no .conf).
Resta saber se esta informação está ficando gravada em algum lugar (além do
texto do log) e como recuperá-la.

Em 5 de março de 2018 12:10, Alexsander Rosa

Post by Alexsander Rosa
Existe alguma forma "oficial" de obter os horários de start / stop do
servidor PostgreSQL sem ter que procurar string no log?

pg_isready com versões >= 9.3. Se você usa uma versão mais antiga,
você ainda pode compilar o código do pg_isready na versão antiga ou
fazer um programa em C que use PQpingParams() ou PQping() -- tais
funções estão disponíveis a partir da versão 9.1.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[Fabrízio de Royes Mello]

Post by Alexsander Rosa
Obrigado pela resposta! Neste caso eu vou ter que fazer um polling,

certo? Eu gostaria de uma precisão abaixo de 1 minuto (ou seja, não dá pra
usar o CRON), porém não quero ficar toda hora chamando o pg_isready pois
isso certamente vai influenciar na carga do servidor. Além disso, quando o
S.O. for reiniciado meu programa em C vai cair também.

Post by Alexsander Rosa
O ideal seria uma função análoga à pg_postmaster_start_time() porém com o

último shutdown.

Post by Alexsander Rosa
Talvez seja possível criar uma "pg_postmaster_last_shutdown()" para obter

esta informação.

Post by Alexsander Rosa
Eu sei que nosso servidor PG foi reiniciado, pela última vez, dia 30 de
SELECT pg_postmaster_start_time();
pg_postmaster_start_time
-------------------------------
2018-01-30 07:33:29.438349-02
(1 row)
No caso eu sei que está no ar desde Janeiro porém eu não sei que horas,
2018-01-30 07:33:07.278 -02 [1212] LOG: autovacuum launcher shutting down
2018-01-30 07:33:07.373 -02 [1209] LOG: shutting down
2018-01-30 07:33:07.440 -02 [1195] LOG: database system is shut down
2018-01-30 07:33:29.439 -02 [1350] LOG: database system was shut down at

2018-01-30 07:33:07 -02

Post by Alexsander Rosa
Veja que o servidor SABE que o shutdown ocorreu às 2018-01-30 07:33:07

-02 (no caso foi uma alteração no .conf).

Post by Alexsander Rosa
Resta saber se esta informação está ficando gravada em algum lugar (além

do texto do log) e como recuperá-la.
Alexsander,

Atualmente o PostgreSQL só persiste essa informação de Startup e Shutdown
nos logs. A função pg_postmaster_start_time() apenas retorna o valor
interno de uma global chamada PgStartTime que ele seta ao iniciar o
postmaster (vide src/backend/postmaster/postmaster.c), mas não persiste em
nenhum lugar.

Talvez até fosse uma idéia adicionar isso ao global/pg_control e obter
atraves do utilitário pg_controldata e termos isso a nível SQL usando a
função pg_control_init() talvez... mas teriamos que discutir isso lá na
-hackers, isso se já não foi e por algum motivo não foi implementado.

Att,


--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

[Fabrízio de Royes Mello]

Em 5 de março de 2018 15:29, Fabrízio de Royes Mello <

[...]

Pensando melhor sobre o seu caso, vc consegue sim obter ambas informações:

1) Se o servidor estiver online vc executa a pg_postmaster_start_time()

2) Se o servidor estiver offline entao vc pode pegar o valor de 'pg_control
last modified:' no pg_controldata, ex:

$ pg_controldata -D ~/.pgvm/clusters/10.1/main | grep -E '(Database cluster
state|pg_control last modified)'
Database cluster state: shut down
pg_control last modified: Seg 05 Mar 2018 15:40:18 -03


Att,

--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

[Alexsander Rosa]

Em 5 de março de 2018 15:43, Fabrízio de Royes Mello <

Post by Fabrízio de Royes Mello
1) Se o servidor estiver online vc executa a pg_postmaster_start_time()
2) Se o servidor estiver offline entao vc pode pegar o valor de
$ pg_controldata -D ~/.pgvm/clusters/10.1/main | grep -E '(Database
cluster state|pg_control last modified)'
Database cluster state: shut down
pg_control last modified: Seg 05 Mar 2018 15:40:18 -03

Estou usando o *pg_postmaster_start_time*(), criei um indicador "Uptime PG"
no dashboard. Para uma parada controlada dá pra usar o *pg_controldata* pra
ver o *last_modified* mas o caso de uso mais comum é a reinicialização do
S.O. para atualizações, geralmente fora do horário comercial.

[Fabrízio de Royes Mello]

Post by Alexsander Rosa
Em 5 de março de 2018 15:43, Fabrízio de Royes Mello <

Post by Fabrízio de Royes Mello
Pensando melhor sobre o seu caso, vc consegue sim obter ambas
1) Se o servidor estiver online vc executa a pg_postmaster_start_time()
2) Se o servidor estiver offline entao vc pode pegar o valor de
$ pg_controldata -D ~/.pgvm/clusters/10.1/main | grep -E '(Database

cluster state|pg_control last modified)'

Post by Alexsander Rosa

Post by Fabrízio de Royes Mello
Database cluster state: shut down
pg_control last modified: Seg 05 Mar 2018 15:40:18 -03

Estou usando o pg_postmaster_start_time(), criei um indicador "Uptime PG"

no dashboard. Para uma parada controlada dá pra usar o pg_controldata pra
ver o last_modified mas o caso de uso mais comum é a reinicialização do
S.O. para atualizações, geralmente fora do horário comercial.
Nesse caso somente olhando os logs mesmo...


--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

[Alexsander Rosa]

Em 5 de março de 2018 17:10, Fabrízio de Royes Mello <

Post by Fabrízio de Royes Mello
Nesse caso somente olhando os logs mesmo...

Bom, copiei manualmente dos logs e fiz o INSERT à mão, estes primeiros
meses de 2018 ficaram assim:

rednaxel-server:rnge4=> SELECT * FROM vw_webservice_level WHERE servico =
'postgresql' ORDER BY ano, mes;
servico | ano | mes | downtime | dias | segundos | svc_lvl
------------+------+-----+----------+------+----------+----------
postgresql | 2018 | 1 | 22.4383 | 31 | 2678400 | 99.9992
postgresql | 2018 | 2 | 0.0000 | 28 | 2419200 | 100.0000
(2 rows)

Em março ainda não houve *downtime* mas já vi que o servidor está pedindo
reboot... Daí eu procuro no log, sem problemas.

[Fabrízio de Royes Mello]

Post by Alexsander Rosa
Em 5 de março de 2018 17:10, Fabrízio de Royes Mello <

Post by Fabrízio de Royes Mello
Nesse caso somente olhando os logs mesmo...

Bom, copiei manualmente dos logs e fiz o INSERT à mão, estes primeiros
rednaxel-server:rnge4=> SELECT * FROM vw_webservice_level WHERE servico =

'postgresql' ORDER BY ano, mes;

Post by Alexsander Rosa
servico | ano | mes | downtime | dias | segundos | svc_lvl
------------+------+-----+----------+------+----------+----------
postgresql | 2018 | 1 | 22.4383 | 31 | 2678400 | 99.9992
postgresql | 2018 | 2 | 0.0000 | 28 | 2419200 | 100.0000
(2 rows)
Em março ainda não houve downtime mas já vi que o servidor está pedindo

reboot... Daí eu procuro no log, sem problemas.
Show de bola... publica a solução lá no github pra contribuir com resto da
galera.

Att,

--
Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

[Alexsander Rosa]

Em 6 de março de 2018 10:01, Fabrízio de Royes Mello <

Post by Fabrízio de Royes Mello
Show de bola... publica a solução lá no github pra contribuir com resto da
galera.

Ainda não automatizei, quando disse que fiz o INSERT à mão eu fiz mesmo...
E quando eu fizer vai ser varrendo o log, que é o temos no momento.

[Euler Taveira]

Em 5 de março de 2018 14:36, Alexsander Rosa

Post by Alexsander Rosa
Obrigado pela resposta! Neste caso eu vou ter que fazer um polling, certo?
Eu gostaria de uma precisão abaixo de 1 minuto (ou seja, não dá pra usar o
CRON), porém não quero ficar toda hora chamando o pg_isready pois isso
certamente vai influenciar na carga do servidor. Além disso, quando o S.O.
for reiniciado meu programa em C vai cair também.

Fazendo polling. Existem soluções bem simples para contornar a falta
de precisão do cron. Quanto ao pg_isready, ele é mais barato do que
uma conexão pois não precisa de autenticação. Eu não preocuparia com
ele estar influenciando a carga a não ser que sua precisão seja de uma
dezena de milisegundos.

Post by Alexsander Rosa
Veja que o servidor SABE que o shutdown ocorreu às 2018-01-30 07:33:07 -02
(no caso foi uma alteração no .conf).
Resta saber se esta informação está ficando gravada em algum lugar (além do
texto do log) e como recuperá-la.

Essa data/hora vem do pg_control (last modified) mas ela vai mudando
com o serviço no ar, ou seja, o tempo de parada do serviço só fica no
log mesmo.