Quais métricas devo observar quando monitora um servidor?

Question

Eu vi muitas ferramentas de monitoramento e principalmente mostro as mesmas coisas. Mas eu estou querendo saber se é realmente necessário assistir a todas essas coisas.

Eu gostaria de saber quais métricas realmente importa, por exemplo, um servidor web que, principalmente, executar um site, com o PHP-FPM, Nginx e MySQL.

E também, eu estou olhando para gráficos, mas como entendê-los e analisá-los para evitar qualquer falha futuro?

    

Answer 1

As métricas importantes são aquelas que:

• Indica um problema com a operação correta e adequada dos serviços que você fornece; ou
• Indique a causa raiz de um problema

Quais métricas são importantes para você depende do que você julga, na sua opinião profissional, como as métricas que melhor atendem a esses dois critérios. Se você não tem o conhecimento necessário para julgar isso com precisão, bem ... sim . Coletar mais dados que você pode nunca precisar é melhor do que não coletar alguns dados que você precisa mais tarde. (A ressalva é que, se o monitoramento estiver começando a interferir na operação eficiente do serviço, talvez seja necessário diminuí-lo um pouco ou otimizar a coleta de estatísticas).

Se você está procurando uma resposta rápida, eu tenho medo de não ter uma - você está em uma curva de aprendizado que fala ao próprio coração do que significa ser um administrador de sistema. Se você está em uma situação em que algum tempo de inatividade não importa, ótimo! você tem uma ótima oportunidade de aprendizado. Se você vai acabar sendo processado ou sair do negócio se este serviço não funcionar perfeitamente, você pode querer encontrar alguém com mais experiência para lhe dar orientação individual e orientação.

    

Answer 2

Acabei de escrever e publiquei um guia sobre exatamente este assunto:

• Zen e a arte do monitoramento do sistema

Permitam-me resumir aqui: Existem três principais objetivos a serem considerados ao monitorar qualquer tipo de sistema de produção:

1. Identifique o maior número possível de problemas;
2. Identifique esses problemas o mais cedo possível; e
3. Gere o mínimo possível de alarmes falsos (isso significa definir alertas adequados)

E você quer fazer isso escolhendo suas métricas no seguinte framework:

1. Monitorar possíveis coisas ruins (coisas que poderiam errar - muitas vezes, na forma de coisas que são preenchidas / esgotadas - ou seja, memória, disco, largura de banda)
2. Monitore coisas ruins reais (coisas que fazem dão errado, apesar de seus melhores esforços)
3. Monitore as coisas boas (ou a falta delas - preste atenção às coisas que você quer que aconteçam e defina um alerta quando elas ocorrem com menos frequência
4. Sintonize e melhore (caso contrário, você corre o risco de "fadiga de alerta", também conhecido como o equivalente DevOps de "lobo chorando")

Toda implantação será um pouco diferente, então YMMV, mas essa é a estrutura que muitos profissionais experientes usam para pensar sobre as coisas (explícitas ou não).

[Editar para divulgação: Sou afiliado à Scalyr, uma empresa envolvida neste espaço, e o link acima é publicado em seu site]

    

Answer 3

O mais básico é manter um olho na quantidade de carga da CPU, memória livre & swap, espaço em disco, E / S de disco e E / S de rede / largura de banda. Isso pode ser feito usando ferramentas como munin ou collectd. Algumas pessoas gostam de monitorar um lote de coisas, mas se você mantiver as coisas simples, pelo menos, você pode obter uma visão geral. Também recomendo que você configure as ferramentas de monitoramento para enviar alertas por e-mail quando as coisas começarem a dar errado (por exemplo, usando "limites" ou semelhantes).

Outra coisa muito útil é ficar de olho nos registros mais importantes do servidor em busca de algo incomum, isto é, mensagens de erro ou talvez até avisos. Mas tais mensagens podem ser muito comuns, dependendo de como os vários softwares são configurados para o registro. Normalmente, os daemons têm um arquivo de configuração onde você pode alterar o "LogLevel" do erro (= log apenas quando algo está quebrado) para depurar (= log de qualquer coisa). Verifique quais demônios você está executando em seu servidor e altere os níveis de log para erro ou aviso. Em seguida, você pode instalar uma ferramenta de análise de arquivos de log, como OSSEC, e treiná-la para ficar em silêncio quando certas coisas forem aceitáveis, enquanto deve alertar quando as coisas forem interrompidas. Esses alertas podem ser enviados por e-mail para você.

Para seus serviços específicos Nginx e Mysql, recomendo que você monitore seu tempo de resposta. Isso é bom por dois motivos: se você não obtiver uma resposta, algo está quebrado. E se você obtiver uma resposta que indique um tempo de resposta extraordinariamente alto - especialmente se não for temporário, mas durante um período de alguns minutos ou horas -, então o serviço está com dificuldades.

    

Answer 4

Eu recomendo que você dê uma olhada no collectd. Pode ser configurado para registrar numerosas medições em arquivos RRD para análise posterior. Requer muito pouca CPU e ajudará você a entender como seu desempenho muda com o carregamento.

Eu não encontrei uma ferramenta realmente incrível para desenhar gráficos a partir dos RRDs gerados, mas a menos que você queira projetá-los em tempo real, basta usar rrdgraph na linha de comando para verificar grandes mudanças periodicamente.

    

Answer 5

Excelente conselho acima. Mas se você realmente só precisa começar, assista ao básico em primeiro lugar: uso da CPU ao longo do tempo, uso de memória ao longo do tempo, uso de largura de banda e uso de espaço em disco (ou espaço livre em disco). Esses quatro são muito comuns porque definem as capacidades de um computador.

Depois de monitorar por um tempo e saber o que é "normal" para um servidor, você poderá detectar quando algo estiver anormal. É quando você está pronto para começar a cavar mais fundo e descobrir o "por quê" - o que exigirá um monitoramento adicional mais específico:)