Datadog - introdução ao monitoramento - mais do que métricas - conclusão

Os três pilares da observabilidade

Teoria da observabilidade:

Observabilidade, na teoria de controle, é uma medida quão bem podem os estados de um sistema ser inferidos a partir do conhecimento de suas saídas externas. A observabilidade e a controlabilidade de um sistema são conceitos matemáticos duais.

Origem: Wikipédia, a enciclopédia livre.

Os três pilares:

  • métricas
  • logs
  • traces de APM.

Métricas:

  • Geralmente combinadas, ou mesmo agregadas;
  • Úteis para se identificar tendências ou padrões;
  • A partir dos seus indicadores, você irá definir os alarmes;
  • Ajudam a tornar o comportamento desconhecido... bem... conhecido. 🙂

Logs:

  • Baseados em eventos (dirão o que e quando aconteceu);
  • Devem ser simples de ler e com uma mensagem direta. Se não forem, estruture seus logs com alguma ferramenta específica (grep, parse, graylog, datadog, etc...);
  • Úteis para se achar detalhes de um evento (desde que não seja aquele log meia-boca que diz: aconteceu uma exception... MAS QUE EXCEPTION MEU FILHO???);
  • Junto com as métricas, ajudam a tornar o comport... você já leu isso acima.

APM:

  • Baseado em traces;
  • Acompanha o andamento das requisições, através de funções e chamadas de serviço;
  • Perfeito para debugar o código, e responder: Onde isso está ocorrendo? Ou em que parte da aplicação estamos gastando 98 segundos esperando e parece que nada acontece?

Cenário: você cuidando da sua vida, a aplicação de boa, até que não está mais de boa. Você olha os gráficos e vê que houve um aumento significante de consumo de CPU. Você deduz que escalando isso irá resolver o problema.

Mas não resolve. Jeito errado de resolver. 🙂

Baseado nas métricas, mais especificamente nos eventos, você percebe que houve um deploy de uma nova versão da aplicação. Correlacionando os dados. Hora de ir pros logs! \o/

sherlock holmes

Correlacionando o período do aumento de uso de recursos, somado ao timeline do deploy, vamos verificar o que nos dizem os logs.

Veja só você! O container não consegue montar o device, devido a um problema de permissão:

$ devops-tche.com

[vitor@devops-tche.com ~]#

Error: Cannot start container 2bd068f1c297b783ffa596631ba602a4316d47c803df68c57bb4dace1dce3d22: stat /shared/X/Y/Z: permission denied_

[vitor@devops-tche.com ~]# _

Nossa hipótese agora: código ruim. Dessa forma, visto que usamos git OBVIAMENTE, com os poderes de controle de versão, voltamos a versão anterior e tudo deve estar resolvido.

Não. Obviamente algum poder superior nos odeia. Bora.

Utilizando o APM trace, vemos que embora tenhamos esse log, ele não é a causa, e sim uma outra consequênca. Vemos pelos gráficos que um step de montagem do disco do container está demorando muito mais do que o normal. Um desvio de comportamento.

Verificando o outro sistema, responsável por esse step, achamos um disco corrompido. Disco recriado, container restartado... e:

russian dancing

Grave isso:

Você saberá que um incidente ocorreu pelas métricas.

Você saberá o que investigar pelos logs.

Os traces podem ajudar a se aprofundar e ver onde o problema está ocorrendo.

Como eu sempre digo:

Que saudade da cadeia.

Vitor Jr.

Veja aqui todos os post da série de introdução ao monitoramento aqui. 🙂

Fala tchê!

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