Deixe-me discutir um tópico que não é inerentemente específico do PostgreSQL, mas que eu encontro regularmente ao investigar problemas nos sistemas do cliente, avaliar a “suportabilidade” desses sistemas, etc. , e por que
sar ainda é de longe minha ferramenta favorita (pelo menos no Linux). Sobre a importância do monitoramento
Em primeiro lugar, o monitoramento das métricas básicas do sistema (CPU, E/S, memória) é extremamente importante. É um pouco estranho ter que apontar isso em discussões com outros engenheiros, mas eu diria que 1 em cada 10 engenheiros acha que eles realmente não precisam de monitoramento. O raciocínio geralmente segue as seguintes linhas:
É verdade que o monitoramento adiciona sobrecarga, sem dúvida. Mas provavelmente é insignificante em comparação com o que o aplicativo está fazendo. Na verdade,
sar não está realmente adicionando nenhuma instrumentação extra, está apenas lendo contadores do nernel, computando deltas e gravando isso no disco. Pode precisar de algum espaço em disco e E/S (dependendo do número de CPUs e discos), mas é isso. Por exemplo, coletar estatísticas por segundo em uma máquina com 32 núcleos e vários discos produzirá ~ 5 GB de dados brutos por dia, mas compacta muito bem, geralmente para ~ 5 a 10%). E é pouco visível no
top . A resolução por segundo é um pouco extrema, e usar 5 ou 10 segundos reduzirá ainda mais a sobrecarga. Então não, acontece que a sobrecarga na verdade não é um motivo válido para não habilitar o monitoramento.
Custos versus benefícios
Mais importante, porém, "Quanta sobrecarga eu elimino por não habilitar o monitoramento?" é a pergunta errada a fazer. Em vez disso, você deve perguntar “Quais benefícios eu recebo do monitoramento? Os benefícios superam os custos?”
Já sabemos que os custos (overhead) são bastante pequenos ou totalmente insignificantes. Quais são os benefícios? Na minha experiência, ter dados de monitoramento é efetivamente inestimável.
Em primeiro lugar, ele permite que você investigue problemas – olhar para um monte de gráficos e procurar mudanças repentinas é surpreendentemente eficaz e geralmente leva você diretamente ao problema certo. Da mesma forma, comparar os dados atuais (coletados durante o problema) com uma linha de base (coletada quando tudo está bem) é muito útil e impossível se você ativar o monitoramento apenas quando as coisas falharem.
Em segundo lugar, permite avaliar tendências e identificar possíveis problemas antes que eles realmente atinjam você. Quanta CPU você está usando? O uso da CPU está crescendo ao longo do tempo? Existem alguns padrões suspeitos no uso de memória? Você só pode responder a essas perguntas se tiver o monitoramento em vigor.
Por que sar é minha ferramenta favorita
Vamos supor que eu tenha convencido que o monitoramento é importante e você definitivamente deveria fazê-lo. Mas por que
sar nossa ferramenta favorita, quando existem várias alternativas sofisticadas, tanto no local quanto na nuvem? - Está incluído em todas as distribuições, e é fácil de instalar/configurar. Isso torna bastante simples convencer as pessoas a ativá-lo.
- Está na máquina. Portanto, se você usar o SSH para a máquina, também poderá obter os dados de monitoramento.
- Está usando saída de texto simples. Trivial processe os dados - importe-os para um banco de dados, analise-os, anexe-os a um ticket de suporte. Isso é muito difícil com outras ferramentas que geralmente não permitem exportar os dados facilmente, apenas mostram gráficos e/ou restringem significativamente quais análises você pode realizar etc.
Admito que parte disso vem do fato de eu trabalhar para uma empresa que fornece serviços PostgreSQL para outras empresas (seja suporte 24×7 ou DBA remoto. Portanto, geralmente temos apenas um acesso muito limitado aos sistemas do cliente (principalmente apenas servidores de banco de dados e nada mais). Isso significa ter todos os dados importantes no próprio servidor de banco de dados, acessíveis por meio de SSH simples, é extremamente conveniente e elimina viagens de ida e volta desnecessárias apenas para solicitar outro dado de outro sistema. O que economiza tempo e sanidade em ambos os lados.
Se você tiver muitos sistemas para gerenciar, provavelmente preferirá uma solução de monitoramento que colete dados de várias máquinas em um único local. Mas para mim,
sar ainda ganha. Então, como configurá-lo?
Eu mencionei a instalação e ativação do
sar (ou melhor, sysstat , que é o pacote que inclui sar ) é muito simples. Infelizmente, a configuração padrão é um pouco ruim. Depois de instalar o sysstat , você encontrará algo assim em /etc/cron.d/sysstat (ou onde quer que sua distribuição armazene cron configuração):*/10 * * * * root /usr/lib64/sa/sa1 1 1
Isso efetivamente diz que o
sa1 O comando será executado a cada 10 minutos e coletará uma única amostra em 1 segundo. Há duas questões aqui. Em primeiro lugar, 10 minutos é uma resolução bastante baixa. Em segundo lugar, a amostra cobre apenas 1 segundo de 600, então os 9:59 restantes não estão realmente incluídos nela. Isso é bom para tendências de longo prazo, onde a amostragem aleatória de baixa resolução é suficiente. Para outros fins, você provavelmente precisará fazer algo assim:* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Que coleta uma amostra por minuto, e cada amostra cobre um minuto. O
-S XALL significa que todas as estatísticas devem ser coletadas, incluindo interrupções, dispositivos de blocos individuais e partições, etc. Veja man sadc para mais detalhes. Resumo
Então, para resumir este post em alguns pontos simples:
- Você deve ter monitoramento, mesmo se achar que não precisa dele. Quando você tiver problemas, será tarde demais.
- Os custos de monitoramento são provavelmente insignificantes, mas certamente muito menores do que os benefícios de ter os dados de monitoramento.
saré conveniente e muito eficiente. Talvez você use outra coisa no futuro, mas é um bom primeiro passo.- A configuração padrão não é particularmente boa (baixa resolução, amostras de 1 segundo). Considere aumentar a resolução.
Uma coisa que não mencionei é que
sar lida apenas com métricas do sistema – CPU, discos, memória, processos, não com estatísticas do PostgreSQL. Você definitivamente deve monitorar essa parte da pilha também, é claro. 
