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.
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;