portgresql postgres 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:

• Preciso monitorar disponibilidade, métricas de recursos disponibilizados (volumetria, conexões estabelecidas…) ou métricas de recursos consumidos (CPU, memória…)?
• Preciso consultar o estado atual ou histórico?
• Preciso disponibilizar acesso a esses recursos a outros usuários?
• Preciso gerar alertas ou tomar ações com base em eventos ou métricas (envio de e-mails, chaveamento do proxy…)?

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

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.

• top
• htop
• iostat
• vmstat
• free
• sar
• iftop
• pg\_top
• …

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.

• Zabbix
• Prometheus
• Nagios
• collectd
• Cacti
• Munin
• …

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:

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.

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;