Quais métricas de sua implantação do PostgreSQL você deve monitorar? Esta série de postagens do 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.
Esta é a segunda parte de uma série de blogs e abrange parâmetros de nível de banco de dados. O primeiro abrange parâmetros de nível de cluster.
Parte 2:Nível do banco de dados
Nesta parte, analisamos métricas e informações que devem ser monitoradas para cada banco de dados importante que você usa.
A maioria das consultas SQL listadas abaixo deve ser executada enquanto estiver conectado ao banco de dados em questão.
1. Clientes conectados
Os clientes conectados ocupam os recursos do sistema operacional e do sistema. O Postgres tem uma arquitetura de processo por cliente, e muitos clientes podem diminuir os tempos de resposta de consulta para todos. Considere usar o PgBouncer ou o pgpool para reduzir o número de conexões que o servidor Postgres terá que atender.
Fique de olho nas mudanças na linha de base após atualizações de aplicativos e picos de conexões devido ao aumento do tráfego.
Ação:monitore o número máximo de clientes conectados em cada dia/semana, investigue as mudanças na tendência.
Como:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Tamanho
O tamanho real do disco usado pelo banco de dados deve ser monitorado. Na maioria dos casos, o tamanho do banco de dados continua crescendo, então é a taxa de crescimento que é mais interessante. Novamente, tenha cuidado com o aumento da taxa de crescimento após novos lançamentos de aplicativos.
Ação:monitore o crescimento do tamanho do banco de dados em cada semana/mês, investigue tendências, reprovisione.
Como:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Aumento da tabela em todas as tabelas
Por causa da arquitetura MVCC do Postgres, versões mais antigas de linhas ficam nos arquivos de dados físicos de cada tabela e são chamadas de bloat . A operação para limpar as versões de linha obsoletas é chamada de vácuo . O Postgres executa um processo em segundo plano chamado autovacuum , que pega tabelas candidatas (com base em parâmetros configuráveis) e as limpa para você.
Bloat torna as operações de tabela mais lentas e desperdiça espaço em disco, e pode fugir mesmo com autovacuum. O monitoramento do bloat, como um número absoluto de bytes, bem como uma porcentagem (de dados mortos para dados totais), é necessário. Isso pode ser feito no nível do banco de dados como um total em todas as tabelas, com a possibilidade de detalhar as “tabelas mais inchadas”.
Ação:monitore continuamente o inchaço total como bytes e porcentagem, alerte se os valores excederem um limite definido.
Como:
Use check_postgres orpgmetrics para obter estimativas de inchaço. Veja a wiki para mais informações.
4. Aumento do índice em todos os índices
Índices inchados podem retardar as inserções e reduzir o desempenho da pesquisa. Monitore o inchaço dos índices tanto como um valor absoluto (número de bytes) quanto como uma porcentagem. Os índices terão que ser reconstruídos quando ficarem muito inchados.
Ação:monitore continuamente o inchaço total como bytes e porcentagem, alerte se os valores excederem um limite definido.
Como:
Use check_postgres orpgmetrics para obter estimativas de inchaço. Veja a wiki para mais informações.
5. Transações de longa duração
Transações abertas por muito tempo não são boas notícias para o PostgreSQL. Transações de longa duração podem causar retenção de arquivos WAL, podem travar e evitar vácuo. Os aplicativos devem ser projetados para manter a duração das transações o mais baixa possível.
Um back-end executando uma transação de longa duração pode ser eliminado com pg_cancel_backend() e pg_terminate_backend() funções.
Ação:monitore continuamente a contagem de transações que estão em execução por mais de um período de tempo definido, alerte se os valores excederem um limite definido.
Como:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Impasses
No PostgreSQL, os backends colocam bloqueios em linhas e tabelas implicitamente enquanto executam consultas que modificam linhas. As consultas também podem colocar bloqueios explícitos (como SELECT .. FOR UPDATE ). Assim como na programação multithread, duas transações que colocam bloqueios, implícita ou explicitamente, em ordem oposta podem resultar em um impasse.
O PostgreSQL detectará deadlocks e reverterá uma das transações envolvidas (todos os bloqueios mantidos por uma transação são liberados quando ela é confirmada ou revertida). Os detalhes serão registrados no destino de log do PostgreSQL.
Os aplicativos devem ser projetados para evitar a possibilidade de impasse. Eles também podem optar por tentar novamente uma transação em caso de deadlock.
Ação:monitore as contagens de impasses a cada dia/semana, redesenhe o aplicativo para reduzir a contagem, investigue as alterações.
Como:
As ocorrências de deadlocks, juntamente com informações adicionais, são registradas no arquivo de log do PostgreSQL. Use pgmetrics, pgbadger ou outras ferramentas de processamento de log específicas do PostgreSQL para extrair essas informações.
7. Vácuo mais antigo
A aspiração regular de tabelas, seja com autovacuum ou com tarefas agendadas, ou manualmente, é essencial para manter as operações de tabela rápidas. Os vácuos podem falhar por vários motivos, incluindo transações de longa duração, slots de replicação inativos, etc.
Como a limpeza regular de tabelas é muito importante no mundo Postgres, é melhor verificar regularmente se todas as tabelas foram limpas pelo menos uma vez em um intervalo definido.
E embora tendam a ficar fora da vista e da mente, as tabelas de catalogação do sistema também devem ser aspiradas.
Ação:verifique continuamente se alguma mesa não foi esvaziada no último número de horas/dias definido, alerta se houver.
Como:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Análise mais antiga
Para executar suas consultas SELECT, o planejador de consultas prepara umplano de execução que descreve quais índices e tabelas devem ser lidos e como. Para chegar a um plano de execução eficiente, o planejador precisa ter estatísticas sobre a distribuição de valores, tamanhos de tuplas e assim por diante. Essas informações estatísticas sobre os dados em uma tabela são coletadas e mantidas por analisar operações. Tabelas com estatísticas atualizadas resultam em consultas mais rápidas e menos E/S.
O processo de autovacuum mencionado acima normalmente também executa ANALYZE na mesa aspira manter esta informação atualizada. No entanto, isso por si só pode não fornecer cobertura de análise suficiente para suas tabelas. Você desejará complementar executando ANALYZE como tarefas agendadas ou após alterações significativas de tabela.
No interesse do desempenho da consulta, é melhor verificar continuamente se todas as tabelas foram analisadas pelo menos uma vez em um intervalo definido.
Ação:Verifique continuamente se alguma tabela não foi analisada no último número de horas/dias definido, alerta se houver.
Como:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;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
A próxima parte desta série abordará métricas em nível de tabela, nível de índice e nível de sistema. Fique atento!
