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 terceira e última parte de uma série de blogs e abrange métricas em nível de tabela, índice e sistema. A primeira cobriu métricas em nível de cluster e a segunda cobriu métricas em nível de banco de dados.
Nível da tabela
Normalmente, os dados em um banco de dados seguem a regra 80-20. 20% das tabelas contêm a maioria dos dados e são as mais acessadas ou modificadas. A configuração de monitoramento extra apenas para essas tabelas pode fornecer informações importantes, mas de baixo volume.
Aqui estão algumas métricas em nível de tabela que vale a pena analisar:
1. Tamanho da tabela
O tamanho real do disco usado pela tabela deve ser monitorado. Na maioria dos casos, a tabela continua crescendo, então é a taxa de crescimento que é mais interessante.
Muitas vezes, a taxa de crescimento muda após o lançamento de uma nova versão do aplicativo ou uma alteração de linha de base nos padrões de tráfego/carga/entrada do próprio aplicativo. Tais mudanças devem ser investigadas, pelo menos para verificar se a nova taxa é sustentável pelo hardware provisionado.
Ação:monitore o aumento no tamanho da tabela a cada semana/mês, investigue mudanças abruptas.
Como:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Inchaço da tabela
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.
Essa métrica pode ser monitorada no nível de tabela individual ou como um agregado nas tabelas selecionadas ou no nível do banco de dados.
Ação:monitore continuamente o inchaço da tabela como bytes e porcentagem, alerte se os valores excederem um limite definido, VACUUM conforme necessário.
Como:
Use check_postgres orpgmetrics para obter estimativas de inchaço. Veja a wiki para mais informações.
3. Varreduras Sequenciais
Quando são executadas consultas que não usam de maneira otimizada os índices disponíveis, ou se as informações estatísticas associadas a uma tabela estão muito desatualizadas, o Postgres pode acabar tendo que passar por cada linha da tabela. Isso é chamado de varredura sequencial , e não é muito desejável no caso geral. O que seria melhor ter é uma varredura de índice , onde as linhas de uma tabela são acessadas indiretamente por meio de pesquisa de índice.
O PostgreSQL pode dizer quantas vezes uma tabela foi escaneada sequencialmente e quantas vezes um índice foi usado. Você pode usar isso para monitorar o número de verificações sequenciais (se quiser evitá-las totalmente) ou como uma porcentagem do total de verificações.
Ação:Monitorar continuamente as seq. contagem ou porcentagem de varreduras, alerta se o valor exceder um limite definido.
Como:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Nível do índice
1. Tamanho do índice
Os índices podem ocupar um espaço em disco considerável. Cada índice de uma tabela pode potencialmente ter tanto espaço de disco quanto a própria tabela. É útil ficar de olho no tamanho total dos índices em um banco de dados ou nos índices de tabelas importantes, especialmente em implantações em que os índices podem ser criados por meio de processos automáticos.
Índices excessivamente grandes podem ser causados por inchaço ou apenas um índice mal projetado. Em ambos os casos, corrigir a causa (reconstruindo o índice ou refatorando a consulta/índice) pode resultar em tempos de consulta mais rápidos, portanto, vale a pena investigar índices grandes.
Ação:monitore o tamanho total dos índices interessantes em cada semana/mês, investigue quando for excessivamente grande.
Como:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Índice de inchaço
Os índices também podem ficar inchados. Existem muitos fatores, incluindo tableworkload, tipo de índice, versão do Postgres e muito mais, que decidem como um índice fica inchado. Índices inchados podem retardar inserções e reduzir o desempenho de pesquisa. Monitore o inchaço dos índices como um valor absoluto (número de bytes) e como uma porcentagem. Os índices terão que ser reconstruídos quando ficarem muito inchados.
Ação:monitore continuamente o aumento do índice 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.
3. Taxa de acertos de cache
O PostgreSQL armazena em cache regiões de índices (e também tabelas) acessadas com frequência na memória. Se você ajustou suas consultas para não tocar nas tabelas, exceto para recuperar linhas, a próxima etapa é garantir a residência máxima do cache para os índices importantes que realmente estão acelerando suas consultas.
A utilização do cache de um índice pode ser medida pela taxa de acertos do cache, que é a porcentagem de blocos do índice que foram lidos do cache para o número total de blocos lidos.
Ação:Monitore continuamente a porcentagem da taxa de acertos do cache, alerte se o valor cair abaixo de um limite definido. Investigue valores baixos para índices importantes.
Como:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Nível do sistema
Além das métricas do PostgreSQL, é importante acompanhar algumas métricas da máquina ou VM em que você está executando o Postgres. Você pode usar qualquer solução de monitoramento popular para isso, ou até mesmo pegá-los e rastreá-los você mesmo.
1. Memória usada
Os sistemas Linux modernos têm contabilidade de memória complexa. Recomendamos monitorar a “memória usada”, que é a memória restante após contabilizar a memória marcada comolivre , como buffers , como em cache , e como laje . Os buffers e o cache cederão sob pressão, assim como a maioria (normalmente mais de 95%) da laje.
A memória usada, no entanto, deve ser medida durante um período adequadamente longo. Se você tiver trabalhos em lote, relatórios, ETL etc. executados nos fins de semana, o período será de uma semana. A métrica real que você precisará monitorar é a memória máxima usada durante esse período.
Normalmente, à medida que o tamanho do banco de dados aumenta, esse valor tende a aumentar. Você terá que garantir que o uso máximo de memória esteja dentro de um limite confortável de memória disponível, como, digamos, 60-80%. Negligenciar isso faria com que suas cargas de trabalho de análise/OLAP falhem por falta de memória.
Ação:monitore o máximo de memória usada em uma semana/fornight, alerte se exceder um limite definido, reprovisione.
Como :
A memória usada é dada por
MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , onde o Mem* os campos são de /proc/meminfo . Para obter mais informações, consulte este artigo da RedHat. 2. Média de carga
O valor médio de carga simples ainda é a maneira mais fácil e rápida de estimar a carga em um servidor. Isso é especialmente verdadeiro para servidores Postgres, pois cada backend é um processo de SO separado, e ter mais deles em um estado executável aumentará o valor médio de carga.
Para um determinado servidor Postgres, a média de carga deve permanecer dentro de um intervalo razoável durante um ciclo de negócios (como uma semana, incluindo execuções de tarefas em lote).
Ação:monitore a média de carga máxima em cada dia/semana, investigue tendências crescentes.
Como :
As médias de carregamento de 1 minuto, 5 minutos e 15 minutos são os primeiros 3 campos da primeira linha no arquivo
/proc/loadavg . 3. Espaço livre em disco
O último item da nossa lista é o mais óbvio para monitorar:a quantidade de espaço livre em disco em cada sistema de arquivos usado pelo seu servidor PostgreSQL, incluindo tablespaces, diretórios de arquivos WAL, diretórios de backup e arquivos de log do servidor. Nos casos em que muitos arquivos (centenas de milhões) são criados em um único sistema de arquivos, certifique-se de que a contagem de inodes livres também seja monitorada. A falta de inodes também é relatada como pouco espaço em disco.
Ação:monitore continuamente o espaço livre em disco e o uso de inode em todos os sistemas de arquivos relevantes, alerte se os valores ficarem abaixo de um limite definido.
Como :
O espaço livre em disco em um sistema de arquivos não pode ser recuperado diretamente pela leitura de qualquer arquivo em
/proc . Você pode usar stat -f /path/to/mount ou mesmo df para descobrir o espaço em disco usado, livre e reservado para um sistema de arquivos montado específico. Referência rápida
Aqui está uma lista completa de todas as métricas que discutimos até agora nesta série. Lembre-se de que essas são apenas o conjunto mínimo e mais essencial de métricas que você deve monitorar para detectar quando as coisas estão prestes a dar errado com sua implantação do PostgreSQL.
Nível de cluster
- Intervalo de IDs da transação
- Número de back-ends
- Slots de replicação inativos
- Back-ends aguardando bloqueios
- Back-ends inativos na transação
- Atraso de replicação para conexões ativas
- Atraso de replicação para slots de replicação
- Contagem de arquivos WAL
- Contagem de arquivos WAL prontos para arquivar
Nível do banco de dados
- Clientes conectados
- Tamanho
- Tabela inchada em todas as tabelas
- Indexação em todos os índices
- Transações de longa duração
- Impasses
- Aspirador mais antigo
- Análise mais antiga
Nível da tabela
- Tamanho da tabela
- Tabela inchada
- Verificações sequenciais
Nível do índice
- Tamanho do índice
- Inchaço do índice
- Taxa de acertos de cache
Nível do sistema
- Memória usada
- Média de carga
- Espaço livre em disco
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.
