Datadog - introdução ao monitoramento - o que é um bom dado coletado - parte 4

Bons dados, por assim dizer, devem ter pelo menos essas quatro características:

  • Fácil compreensão - deve ser fácil entender como essa métrica foi gerada e o que ela representa. Durante um sinistro você não vai querer perder tempo interpretando sua coleta. Mantenha simples.
  • Granularidade/Histórico - tenha dados, e em quantidade. Coloque um intervalo que seja o suficiente para obter os dados no menor tempo possível, sem impactar seu sistema.
    • Clareando a idéia:
      • Histórico: 1 ano de coleta de tempo de resposta de uma consulta.
      • Granularidade: Quantidade de coletas de tempo de resposta da mesma consulta, dentro de 1 ano. Quanto mais, melhor.
  • Separado por escopo - podem existir múltiplos escopos. Alguns exemplos:
    • Produção, qualidade e desenvolvimento;
    • Banco de dados e web servers;
    • Data center 1 e data center 2;
    • Podemos ser mais granulares, dividindo os bancos de dados em Oracle e SQL Server e os web servers de acordo com sua tecnologia de backend;
    • Ainda podemos reunir um conjunto de items e criar o escopo de uma aplicação (esse load balancer, mais esse web server, mais esse link, mais esse database formam o escopo da aplicação XPTO)
  • Retenção - se você armazenar seus dados por pouco tempo, você pode estar descartando informação importante sobre o que houve no passado. Conhecimento que pode ir fora. Reter seus dados por pelo menos um ano é o mínimo que se pode esperar, especialmente se seus dados podem ter alterações sazonais (um comércio que participa da black friday terá dados de performance diferentes naquele período, por exemplo).

A tabela a seguir demonstra os diferentes tipos de dados descritos no post anterior. De acordo com sua criticidade (acionamento, informativo...) e o que desencadeia o alerta. Em resumo:

  • Registro - baixa prioridade. Apenas registra um evento, pois não impacta o sistema. Porém, numa análise conjunta, pode ser interessante para formar o todo;
  • Notificação - moderada. Notifica alguém, via chat ou e-mail, que possa solucionar o incidente;
  • Acionamento - alta/urgente. Interrompe seu trabalho, seu sono, seus sonhos, seu futebol, seja a hora que for... 🙂
DadosCriticidadeGatilho
Métrica de trabalho: taxa de transferência (throughput)Acionamentovalor é muito maior ou menor do que o habitual, ou há uma taxa de mudança anômala
Métrica de trabalho: sucessoAcionamentoa porcentagem de trabalho processado com êxito cai abaixo de um limite
Métrica de trabalho: errosAcionamentoa taxa de erro excede um limiar
Métrica de trabalho: desempenhoAcionamentoo trabalho demora muito para ser concluído (por exemplo, o desempenho viola o SLA interno)
Métrica de recurso: utilizaçãoNotificaçãoaproximando o limite crítico de recursos (por exemplo, espaço livre em disco cai abaixo de um limite)
Métrica do recurso: saturaçãoRegistronúmero de processos de espera excede um limite
Evento: relacionado ao trabalhoAcionamentotrabalho crítico que deveria ter sido concluído é relatado como incompleto ou falhou

Fechando: colete tudo que for possível. Ou um pouco mais do que você pensa que precisa.

  • Organize tudo e colete o máximo de métricas, sejam elas de carga, recurso, eventos, etc. Observar sistemas complexos requer métricas fáceis de se compreender, e 'casáveis' com outras métricas. O efeito: isso é causa ou consequência?
  • Colete dados com uma granularidade que lhe permita observar desvios.
  • Para otimizar seus dados coletados, tenha eles separados por escopo - podem ser utilizadas tags - e retenha os dados por pelo menos 18 meses.

Fala tchê!

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