portgresql postgres monitoramento

Monitoramento

É importante identificar o propósito do monitoramento e quais objetivos desejamos alcançar com ele. Só depois disso podemos fazer o levantamento das ferramentas que se adequam a esse propósito. E algumas perguntas vão nos ajudar a fazer essa identificação:

As respostas precisam ser correlacionadas com as funcionalidades, vantagens e desvantagens das ferramentas disponíveis.

Como monitorar

Ferramentas locais

Estas são as ferramentas que usaríamos acessando diretamente a máquina do PostgreSQL. A maior parte delas retorna dados instantâneos, sem histórico.

Ferramentas remotas

Estas são as ferramentas que usaríamos remotamente. Muitas envolvem a instalação de um agente, monitor ou exportador de métricas, que são então armazenadas em um local centralizado, permitindo a consulta do histórico e geração de alertas.

O que monitorar

O uso de recursos básicos, como CPU, memória, rede e disco é fundamental para a resolução de problemas. Além deles, alguns pontos extras chamam a atenção:

Espaço ocupado em sistema de arquivos

Todos os dados do PostgreSQL são armazenados em arquivos, diretórios e links simbólicos no sistema de arquivos. Então manter a saúde dos sistemas de arquivos é fundamental para a saúde do PostgreSQL.

Quando o sistema de arquivos fica cheio, o PostgreSQL não consegue tratar mais transações, especialmente se o sistema de arquivos abaixo do pg\_wal estiver cheio. Adicionalmente, sistemas de arquivos são variações complexas de árvores B que, apesar de serem autobalanceadas no caso geral, perdem essa propriedade quando não têm espaço livre. Sem o rebalancecamento, as árvores se tornam degeneradas e têm seus desempenhos degradados em operações como busca e inserção. E essa degradação não é recuperada posteriormente quando o espaço ocupado diminuir. TODO: encontrar e linkar a documentação da Red Hat falando do limiar de 70%.

Portanto, é recomendado monitorar o espaço ocupado em todos os sistemas de arquivos usados pelo PostgreSQL e garantir que esse espaço nunca alcance 70% de ocupação, para garantir a continuidade do serviço e melhor desempenho.

Taxa de cache hit em shared_buffers

O uso de shared_buffers como cache de blocos de disco é um fator importante. Para atender uma consulta um bloco precisa ser lido. Se ele estiver em cache (em memória RAM), então o acesso é rápido e chamamos de cache hit. Caso contrário, é mais lento e chamamos de cache miss (ou read). Em ambientes com memória RAM suficiente, praticamente todos os blocos são encontrados em memória, já que o PostgreSQL mantém automaticamente cópias deles. É possível medir e monitorar a taxa de blocos encontrados vs. não encontrados em cache com as visões pg_stat_database e pg_statio_*.

Se a taxa global, por pg_stat_database, estiver baixa (por exemplo, menor que 90%), é um indicativo de que shared_buffers poderia ser maior. Exemplo de consulta de taxa de cache hit da instância inteira:

SELECT
  round(100.0 * sum(blks_hit) / (sum(blks_read) + sum(blks_hit)), 2) AS ratio
FROM
  pg_stat_database;

Exemplo de consulta da taxa de cache hit em tabelas:

SELECT
  sum(heap_blks_read) AS heap_read,
  sum(heap_blks_hit)  AS heap_hit,
  round(100.0 * sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)), 2) AS ratio
FROM
  pg_statio_user_tables;

Exemplo de consulta da taxa de cache hit em índices:

SELECT
  sum(idx_blks_read) AS idx_read,
  sum(idx_blks_hit)  AS idx_hit,
  round(100.0 * (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit), 2) AS ratio
FROM
  pg_statio_user_indexes;