Datadog - introdução ao monitoramento - problemas de performance - parte 6

Investigando problemas de performance

A responsabilidade de monitoramento do sistema não se restringe a detecção de sintomas. Achou que era só isso?

achou errado otario

Assim que você for notificado que um sintoma requer a sua atenção, seus próximos passos serão:

  • dizer que você já tinha avisado sobre isso;
  • diagnosticar a causa raíz, utilizando os dados que você já coleta.

Muitas vezes ficamos no achismo e no palpite. Vamos ver uma abordagem mais estruturada para isso, a seguir.


Tudo é recurso

Quase todo componente da sua infraestrutura para sua aplicação pode ser considerado um recurso. E eles estão ligados. Quer ver?

Leve em consideração um apache web server, dentro de um conjunto LAMP. Seu recurso de apache server, depende de um recurso MySQL, que por sua vez, depende de recursos, como o limite finito de conexões e ainda num nível mais baixo, cpu, memória, disco, etc.

  1. Comece pelas métricas de trabalho - Pergunte-se: Existe um problema? Como posso caracterizá-lo? Em seguida, examine as métricas de nível mais alto do sistema afetado. Elas geralmente irão dar uma idéia de onde começar a rezar trabalhar.
  2. Descendo para os recursos - se você não constatou que é um comportamento normal/esperado, ou não conseguiu colocar a culpa na rede, bora olhar os recursos assim como aplicações que sejam dependências para seu sistema. Se você está 'tagueando' seu monitoramento, é hora de usar, separado por sistemas e identificar o problema.
  3. Algo mudou - a resposta padrão é 'não mexemos em nada'. Mas faça uma investigação sobre deploy de novo código, algum comunicado, ou verifique arquivos alterados - esse, aliás, outro ótimo ponto a ser monitorado.
  4. Conserte - depois de identificar o que houve, conserte. A investigação está ok quando os problemas desaparecerem. Agora vem a parte boa: análisar como evitar isso no futuro e usar essa experiência para incrementar seu sistema de monitoramento.
keep my eyes on you

Tenha seus dashboards prontos antes de precisar deles

O dashboard, é um local com várias métricas, alarmes e eventos juntos, geralmente agrupados dentro de uma tag.

Podemos ter um dashboard para todos os load balancers. Outro para todos os databases. Outro para todos os file servers, etc. Além disso, podemos/devemos criar dashboards por sistema. Isso facilita a identificação e debug do problema.

Um bom ponto de partida:

  • Um dashboard para suas métricas de carga, alto nível, por aplicação e um painel para cada subsistema.

Siga as métricas

Ter um sistema de monitoramento significa que será mais fácil investigar problemas de uma forma sistemática.

  • Tenha um conjunto de métricas (dashboard, painel, agregação...) para cada sistema em sua infraestrutura, exibindo suas principais métricas, com os eventos relevantes relacionados.
  • Investigue iniciando do nível mais alto. Comece pelo sistema que demonstra estar mais afetado, revisando suas métricas de carga e recurso e relacionando eventos.
  • Corrija, nos respectivos recursos, caso identificado, os incidentes e aplique o mesmo padrão aos recursos subsequentes, até que a causa raiz seja identificada e corrigida.
  • No postmortem ou MIR (Major Incident Report), pense em como evitar que isso ocorra novamente.
  • E segue o baile, mais um dia, mais um incidente, mais um dólar... 🙂
another day another dolar

Fala tchê!

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.