PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Monitoramento essencial do PostgreSQL - Parte 1


Quais métricas de sua implantação do PostgreSQL você deve monitorar? Esta série de postagens de blog visa fornecer um conjunto mínimo inicial de ações de monitoramento essenciais que você deve implementar para garantir a integridade e a estabilidade de seus servidores Postgres.

A primeira parte abrange os parâmetros em nível de cluster.

Parte 1:nível de cluster


No jargão do Postgres, um cluster é um conjunto de bancos de dados gerenciados por uma instância de servidor singlePostgres. Recursos como replicação e trabalho de arquivamento WAL em nível de cluster.

1. Intervalo de IDs de transação


Da perspectiva de um cliente normal, os arquivos de dados de um cluster PostgreSQL parecerão conter o instantâneo dos dados modificados pela última transação confirmada. No entanto, devido à arquitetura MVCC do Postgres, os arquivos físicos contêm não apenas os dados da transação mais recente, mas de uma série de transações que terminam com a mais recente. (Aspirar regular se livra dos dados das transações mais antigas.)

Cada transação tem um identificador inteiro de 32 bits exclusivo, chamado deID da transação . Por vários motivos, a diferença dos IDs da primeira e da última transação deve ser menor que 2, que é cerca de 2 bilhões. Manter o intervalo bem abaixo desse limite é deve – leia esta história da vida real do que acontece de outra forma.

Ação:monitore continuamente o intervalo de IDs da transação, alerte se o valor exceder um limite definido.

Como:
-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
       regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
  FROM pg_control_checkpoint();

-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
  FROM pg_database;

2. Número de back-ends


Cada back-end representa um cliente conectado ao servidor ou um processo de back-end do sistema (como trabalhador de vácuo automático, gravador de plano de fundo etc). Cada backend também é um processo do SO que consome recursos do SO, como memória, descritores de arquivos abertos, etc. Muitos backends, normalmente devido a muitos clientes ou muitas consultas de longa duração, podem pressionar os recursos do SO e diminuir os tempos de resposta de consulta para cada cliente.

Ação:monitore a contagem máxima de back-end em cada dia/semana, investigue tendências crescentes.

Como:
-- returns the count of currently running backends
SELECT count(*)
  FROM pg_stat_activity;

3. Slots de replicação inativos


Os slots de replicação são marcados como "inativos" quando o cliente de replicação conectado ao slot é desconectado. Slots de replicação inativos fazem com que os arquivos WAL sejam retidos, pois eles terão que ser enviados ao cliente quando ele se reconectar e os slots ficarem ativos. De fato, a primeira coisa a verificar se a contagem de arquivos WAL não diminui é ver se você possui slots de replicação inativos.

Freqüentemente, os slots de replicação inativos são o resultado de um cliente de backup que foi removido, um escravo que foi desativado, promoções, failovers e similares.

Ação:verifique continuamente se há slots de replicação inativos, alerte se houver.

Como:
-- returns the count of inactive replication slots
SELECT count(*)
  FROM pg_replication_slots
 WHERE NOT active;

4. Backends aguardando bloqueios


As instruções SQL podem fazer com que outras instruções SQL aguardem, explícita ou implicitamente. Por exemplo, executar um “SELECT .. FOR UPDATE” declara explicitamente um bloqueio para as linhas selecionadas e executar um “UPDATE” coloca bloqueios exclusivos de linha implícitos. encontrar o bloqueio terá que esperar até que a primeira instrução abandone o bloqueio, antes de continuar sua execução.

Isso pode se manifestar como desempenho lento do aplicativo durante execuções de relatórios semanais, transações esgotadas/páginas da Web e similares.

Embora uma certa quantidade de bloqueio não possa ser evitada, uma tendência crescente de back-ends aguardando bloqueios normalmente exige que as consultas ou a lógica do aplicativo sejam reestruturadas.

Ação:monitore o número máximo de back-ends aguardando bloqueios a cada dia/semana, investigue tendências crescentes.

Como:
-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE wait_event = 'Lock';

5. Back-ends inativos na transação


Transações de longa duração não são muito boas de se ter no mundo PostgreSQL. Elas podem causar o acúmulo de arquivos WAL, evitar o vácuo automático e manual e consumir recursos. Nada muito pode ser feito sobre transações genuínas que levam muito tempo para serem concluídas, mas há casos como aplicativos/scripts com mau comportamento e o cliente psql ocasional que inicia transações, mas não as fecha. Os back-ends que atendem a esses clientes aparecem como “inativos na transação”.

Os back-ends que estão ociosos na transação devem ser detectados e desligados antes que comecem a afetar a estabilidade do sistema.

Ação:monitore continuamente o número de back-ends inativos na transação, revise se algum for encontrado.

Como:
-- returns the count of backends waiting on locks
SELECT count(*)
  FROM pg_stat_activity
 WHERE state = 'idle in transaction';

6. Atraso de replicação para conexões ativas


Quando há clientes de replicação de streaming ativos (como hot standbys) ou clientes de replicação lógica ativos, o Postgres executa um backend de sistema chamadoWAL remetente para cada cliente ativo (conectado). O remetente WAL é responsável por enviar os dados do registro WAL que o cliente necessita.

Os clientes de replicação geralmente tentam acompanhar o máximo que podem com o primário. Às vezes, no entanto, a taxa de geração de WAL no lado primário pode se tornar maior do que a taxa na qual o cliente pode consumi-los. Isso resulta em um atraso de replicação para cada conexão de replicação.

O PostgreSQL fornece um mecanismo de consulta para escrever lag (nº de bytes enviados mas não escritos no disco do cliente), flush lag (nº de bytes gravados mas não liberados no disco do cliente) e replay lag (nº de bytes liberados mas não reproduzidos no disco do cliente) arquivos de banco de dados) para cada remetente WAL ativo.

Ação:monitore continuamente os atrasos de replicação para conexões ativas, alerte se os valores excederem os limites definidos.

Como:
-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
       flush_lsn - write_lsn AS flush_lag,
       replay_lsn - flush_lsn AS replay_lag
  FROM pg_stat_replication;

7. Atraso de replicação para slots de replicação


Os clientes de repicação não apenas podem ficar atrasados, mas também podem desaparecer completamente devido a falhas, alterações de topologia ou erro humano. Também pode ser por design, onde os clientes nem sempre estão online.

Se o cliente for apoiado por um slot de replicação, todos os arquivos WAL necessários para que o cliente continue do ponto em que parou serão retidos pelo PostgreSQL. Os arquivos WAL serão retidos indefinidamente - não há como definir um limite. Quando o cliente se reconecta, todos os dados retidos devem ser transmitidos primeiro para o cliente, o que pode envolver muito tráfego de disco e rede no primário. Por essas razões, você também deve monitorar o atraso no nível do slot.

(Observação:o processo do remetente WAL é executado apenas quando um cliente está conectado e sai quando o cliente se desconecta. O método do remetente WAL para medir a distância de um cliente não funciona quando um cliente está desconectado.)

Ação:monitore continuamente os atrasos de replicação para slots de replicação lógica, alerte se os valores excederem um limite definido.

Como:
-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
  FROM pg_replication_slots;

8. Contagem de arquivos WAL


Gerenciar arquivos WAL pode ser uma tarefa exasperante, especialmente se você tiver clientes de WALarquivamento ou replicação de streaming. As contagens de arquivos WAL podem começar a aumentar sem qualquer motivo aparente, o processo de arquivamento WAL pode não acompanhar a taxa de geração de WAL e o tamanho total do arquivo WAL pode chegar a terabytes.

No mínimo, você precisa monitorar a contagem de arquivos WAL presentes em seu diretório de banco de dados e garantir que o número pareça razoável para sua implantação.

Ação:monitore continuamente a contagem de arquivos WAL, alerte se o valor exceder um limite definido.

Como:
-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
  FROM pg_ls_waldir();

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';

-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'

9. Contagem de arquivos WAL prontos para arquivar


Quando o arquivamento WAL está habilitado, o PostgreSQL invoca um script de usuário toda vez que um novo arquivo WAL é gerado. O script deve “arquivar” o único arquivo WAL para o qual foi invocado (normalmente o copia para outro servidor ou um bucket do S3). ser arquivado se acumula.

Ação:monitore continuamente a contagem de arquivos prontos para arquivamento do WAL, alerte se o valor exceder um limite definido.

Como:
-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
  FROM pg_ls_archive_statusdir()
 WHERE name ~ '^[0-9A-F]{24}.ready$';

-- same, for v10+
SELECT count(*)
  FROM pg_ls_dir('pg_wal/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- same, for v9.x
SELECT count(*)
  FROM pg_ls_dir('pg_xlog/archive_status')
 WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';

-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .ready

Coleta dessas métricas


As seções acima fornecem instruções SQL para extrair as métricas necessárias de um servidor Postgres em execução. Se você preferir não escrever os scripts, confira a ferramenta de código aberto pgmetrics. Ele pode coletar as métricas acima e muito mais e relatá-las em formatos de texto e JSON.

Você pode enviar diretamente os relatórios pgmetrics para nossa oferta comercial, pgDash, que armazena e processa esses relatórios para exibir gráficos e realizar alertas.

Próximo


Outras partes desta série abrangerão métricas em nível de banco de dados, nível de tabela, nível de índice e nível de sistema. Fique atento!