“Um bom sistema de monitoramento paga dividendos.” Monitoramento: Princípios, Por que monitorar, Definições, Alerta sobre SLOs, Características desejáveis ​​de uma estratégia de monitoramento e muita coisa boa.

1. SRE
Site Reliability Engineering
Engenharia de confiabilidade

2. Capítulo 4
Monitoramento
● Princípios
● Por que monitorar?
● Definições
● Alerta sobre SLOs
● Características desejáveis de uma estratégia de monitoramento
“Um bom sistema de monitoramento
paga dividendos.”

3. Princípios
Métricas principais

4. Princípios
● Mantenha a simplicidade , evite criar painéis complexos que você nunca usará ou alertas que podem acionar
notificações de falso positivo
● Mantenha-o consistente , use nomes consistentes e significativos em seus painéis e alertas
● Use logs , métricas e rastreios com sabedoria e em conjunto
● Evite métricas de alta cardinalidade
● Evite consultas complexas e lentas em seus painéis
● O sistema de monitoramento deve responder duas perguntas: O que está errado e por quê?

5. Métricas principais
● 4 sinais dourados
○ Latência (duração) - O tempo que leva para atender a uma solicitação
○ Tráfego (taxa) - Uma medida de quanta demanda está sendo colocada em seu sistema
○ Erros - A taxa de solicitações que falham
○ Saturação - O quão "cheio" o seu serviço esta
● Método RED
○ Taxa - o número de solicitações, por segundo, que seus serviços estão atendendo
○ Erros - o número de solicitações com falha por segundo
○ Duração - distribuições da quantidade de tempo que cada solicitação leva
● Métricas de infraestrutura
○ Muitos serviços dependem de infraestruturas como um cache, um banco de dados ou uma fila, monitorá-los
pode ajudá-lo a identificar a causa raiz de um problema
● Métricas de plataforma
○ Normalmente, as equipes de resposta a incidentes e SRE analisam esses painéis para ter uma visão geral e
obter o Tempo Médio de Detecção (MTTD) e o Tempo Médio de Recuperação (MTTR) mais rápidos

6. Por que monitorar?

7. No nível mais básico, o monitoramento permite que você ganhe visibilidade em
um sistema. Existem vários motivos para monitorar um sistema, incluindo:
● Analisar tendência a longo prazo
● Fazer comparações ao longo do tempo ou com grupos experimentais
● Gerar alertas
● Criar painéis de controle
● Conduzir análise retrospectivas
Por que monitorar?
Quando ocorrem acionamentos com frequência
demais, os funcionários começam a tentar
adivinhar, fazem uma leitura superficial ou até
mesmo deixam de ver alertas.
Monitorar nossas aplicações mais do que permitir a detecção de falhas,
também, quem sabe, pode nos informar o que está prestes a falhar.

8. Definições

9. Nem mesmo dentro do google existe um vocabulário bem definido, mas as
interpretações mais comuns estão listadas a seguir:
● Monitoramento
● Monitoramento caixa branca
● Monitoramento caixa preta
● Painel de controle
● Alerta
● Causa raiz
● Atualização de versão (push)
Definições

10. Dessa lista vale destacar a monitoramento caixa preta e caixa branca
● Monitoramento caixa branca
○ Monitoramento baseada em métricas, incluindo logs, interface ou até mesmo http handler que
gere estatísticas internas
● Monitoramento caixa preta
○ Testes comportamentais visíveis externamente, como um usuário os veria
Definições

11. Definindo expectativas

12. ● Um equipe de SRE do google com 10 a 12 membros geralmente tem um ou
dois membros cuja a atribuição principal é construir e manter os sistemas de
monitoramento
● As equipes de SRE evitam cuidadosamente qualquer situação que exija
alguém que fique "olhando uma tela a fim de observar se há problemas"
Definindo expectativas

13. Alerta sobre SLOs

14. Alerta sobre SLOs
● Aprenda a transformar SLOs em regras de alerta para que você possa responder aos
problemas antes de consumir muito do seu orçamento para erros.
● Para gerar alertas de indicadores de nível de serviço (SLIs) e um orçamento
de erro, você precisa de uma maneira de combinar esses dois elementos em
uma regra específica

15. Considerações de alerta
Considere os seguintes atributos ao avaliar uma estratégia de alerta:
● Precision
○ Precision será de 100% se cada alerta corresponder a um evento significativo
● Recall
○ Recall será de 100% se todos os eventos significativos resultarem em um alerta
● Detection time
○ Quanto tempo leva para enviar notificações em várias condições
● Reset time
○ Por quanto tempo os alertas são disparados depois que um problema é resolvido

16. Maneiras de alertar
Taxa de erro de destino ≥ Limite SLO
Janela de alerta aumentada
Incrementando a duração do alerta

17. Taxa de erro de destino ≥ Limite SLO
Para a solução mais trivial, você pode escolher uma pequena janela de tempo (por exemplo,
10 minutos) e alertar se a taxa de erro nessa janela exceder o SLO.Por exemplo, se o SLO for
99,9% em 30 dias, alerte se a taxa de erro nos 10 minutos anteriores for ≥ 0,1%:
● O tempo de detecção é bom: 0,6 segundos
para uma interrupção total
● Este alerta dispara em qualquer evento que
ameace o SLO, exibindo uma boa
recuperação
● A precisão é baixa: o alerta dispara em
muitos eventos que não ameaçam o SLO.
Uma taxa de erro de 0,1% por 10 minutos
alertava, enquanto consumia apenas 0,02%
do orçamento mensal de erro
● Levando esse exemplo ao extremo, você
poderia receber até 144 alertas por dia
todos os dias, não agir sobre nenhum alerta
e ainda atender ao SLO
Prós Contras

18. Janela de alerta aumentada
Ao aumentar o tamanho da janela, você gasta um valor de orçamento maior antes de
acionar um alerta. Para manter a taxa de alertas gerenciável , você decide ser notificado
apenas se um evento consumir 5% do orçamento de erro de 30 dias - uma janela de 36
horas:
● O tempo de detecção ainda é bom: 2
minutos e 10 segundos para uma
interrupção completa
● Melhor precisão do que o exemplo anterior:
ao garantir que a taxa de erro seja
sustentada por mais tempo, um alerta
provavelmente representará uma ameaça
significativa ao orçamento de erro
● Tempo de reinicialização muito ruim: no
caso de 100% de interrupção, um alerta
será disparado logo após 2 minutos e
continuará a disparar pelas próximas 36
horas
● Calcular taxas em janelas mais longas pode
ser caro em termos de memória ou
operações de E / S, devido ao grande
número de pontos de dados
Prós Contras

19. Incrementando a duração do alerta
A maioria dos sistemas de monitoramento permite que você adicione um parâmetro de
duração aos critérios de alerta para que o alerta não seja disparado, a menos que o valor
permaneça acima do limite por algum tempo
● Os alertas podem ser de maior precisão.
Exigir uma taxa de erro sustentada antes de
disparar significa que os alertas têm mais
probabilidade de corresponder a um evento
significativo
● Rechamada e tempo de detecção insuficientes: como a
duração não é compatível com a gravidade do
incidente, uma interrupção de 100% alerta após uma
hora, o mesmo tempo de detecção de uma interrupção
de 0,2%. A interrupção de 100% consumiria 140% do
orçamento de 30 dias naquela hora
● Se a métrica, mesmo momentaneamente, retornar a
um nível dentro do SLO, o cronômetro de duração é
zerado. Um SLI que oscila entre SLO ausente e SLO
aprovado pode nunca alertar
Prós Contras

20. Estratégia de monitoramento
Características

21. Características
● Velocidade
○ Os dados devem estar disponíveis quando você precisa deles: a atualização afeta
quanto tempo levará seu sistema de monitoramento para avisá-lo quando algo der
errado
○ Dados com mais de quatro a cinco minutos desatualizados podem afetar
significativamente a rapidez com que você pode responder a um incidente
Por exemplo, durante a resposta a incidentes, se o tempo entre a causa (execução de uma ação) e
o efeito (ver essa ação refletida em seu monitoramento) for muito longo, você pode supor que
uma mudança não teve efeito ou deduzir uma correlação falsa entre causa e efeito

22. Características
● Cálculos
○ As métricas que você retém sobre eventos ou consumo de recursos devem ser
contadores incrementando monotonicamente. Usando contadores, seu sistema de
monitoramento pode calcular funções em janela ao longo do tempo
○ O suporte para uma gama mais completa de funções estatísticas pode ser útil porque
operações triviais podem mascarar o mau comportamento
○ Sem uma visão de longo prazo de seus dados, você não pode analisar tendências de
longo prazo, como o crescimento do sistema
○ Um sistema de monitoramento que suporta percentis de computação (ou seja, 50º, 95º,
99º percentis)

23. Características
● Interfaces
○ Um sistema de monitoramento robusto deve permitir que você exiba concisamente
dados de série temporal em gráficos e também estruture dados em tabelas ou uma
variedade de estilos de gráfico
○ Provavelmente, você precisará oferecer visualizações diferentes dos mesmos dados
com base no público
○ Seja específico sobre a criação de painéis que façam sentido para as pessoas que
consomem o conteúdo

24. Características
● Supressão de alertas
○ A funcionalidade de supressão de alertas permite que você evite ruídos desnecessários
que distraiam os engenheiros de plantão.
Por exemplo quando todos os nós estão apresentando a mesma alta taxa de erros, você
pode alertar apenas uma vez para a taxa de erro global, em vez de enviar um alerta
individual para cada nó
○ Quando uma de suas dependências de serviço tem um alerta de disparo (por exemplo,
um back-end lento), você não precisa alertar para as taxas de erro de seu serviço

25. Fontes de dados de monitoramento
Métricas
Logs

26. Métricas
● são medidas numéricas que representam atributos e eventos, normalmente coletados por
meio de muitos pontos de dados em intervalos regulares de tempo.
● Menos granular
● Maior velocidade ao disponibilizar a informação
● Painéis e alertas geralmente usam métricas por sua natureza em tempo real

27. Logs
● São um registro de eventos apenas de acréscimo
● Mais granular
● Maior lentidão ao disponibilizar a informação
● logs são usado para encontrar a causa raiz de um problema

28. Dicas
● Mova informações de registros para métricas
○ Monitore tipos de erros diferentes ( status HTTP)
○ Defina diferentes limites de alerta para erros de cliente e servidor
● Melhore os registros e as métricas
○ Fazer uma triagem, via script, do erro para identificar se houve impacto do SLO sem uma
ferramenta/lib de uso comum pode não ser escalável
● Manter registros como fonte de dados
○ Evitar usar dado de alta cardinalidade para identificar uma métricas
○ Anexar documentos, scripts e etc junto ao Alerta para que seja fácil fazer qualquer
procedimento com o objetivo de diminuir a carga cognitiva

29. Gerenciando Seu Sistema de Monitoramento

30. Gerenciando Seu Sistema de Monitoramento
● Seu sistema de monitoramento é tão importante quanto qualquer outro serviço que você
execute. Como tal, deve ser tratado com o nível adequado de cuidado e atenção.
● Trate sua configuração como código
● Incentive a consistência
● Uma abordagem centralizada fornece consistência, mas, por outro lado, as equipes individuais
podem querer controle total sobre o projeto de sua configuração. Uma única estrutura permite
que os engenheiros atuem mais rapidamente ao trocar de equipe e facilita a colaboração
durante a depuração
● Se possível, torne a cobertura de monitoramento básica sem esforço

31. Gerenciando Seu Sistema de Monitoramento
● Prefira baixo acoplamento
○ Os requisitos de negócios mudam e seu sistema de produção terá uma aparência
diferente daqui a um ano. Da mesma forma, seu sistema de monitoramento precisa
evoluir ao longo do tempo, conforme os serviços que ele monitora evoluem por meio de
diferentes padrões de falha.
Dividir a funcionalidade em componentes individuais está se tornando popular no mundo do código
aberto. Uma década atrás, sistemas de monitoramento como o Zabbix combinavam todas as funções em
um único componente. O design moderno geralmente envolve a separação de coleta e avaliação de regra
(com uma solução como o servidor Prometheus ), armazenamento de série temporal de longo prazo (
InfluxDB ), agregação de alerta ( Alertmanager ) e painel ( Grafana ).

32. Métricas com finalidade
● As métricas SLI são as primeiras que você deseja verificar quando os alertas baseados em
SLO são disparados
● Métricas devem aparecer com destaque no painel de seu serviço, de preferência em sua
página de destino.
● Ao investigar a causa de uma violação de SLO, você provavelmente não obterá informações
suficientes dos painéis de SLO. Esses painéis mostram que você está violando o SLO, mas
não necessariamente por quê.

33. Mudança planejada
Ao diagnosticar um alerta baseado em SLO, você precisa ser capaz de passar das métricas de
alerta que o notificam sobre problemas que afetam o usuário para as métricas que informam o
que está causando esses problemas. Mudanças recentes planejadas em seu serviço podem ser
a falha.
● Monitore a versão do binário.
● Monitore os sinalizadores de linha de comando,
especialmente ao usar esses sinalizadores para habilitar e desabilitar recursos do serviço.
● Se os dados de configuração forem enviados ao seu serviço dinamicamente, monitore a versão dessa
configuração dinâmica.
Quando você está tentando correlacionar uma interrupção com uma implementação, é muito mais fácil
olhar para um gráfico / painel vinculado ao seu alerta do que vasculhar os registros do sistema de CI / CD
(integração contínua / entrega contínua) após o fato.
Adicione monitoramento que
informa sobre quaisquer alterações
na produção.

34. Dependências
Mesmo se seu serviço não mudou, qualquer uma de suas dependências pode mudar ou ter
problemas, portanto, você também deve monitorar as respostas provenientes de dependências
diretas
É razoável exportar o tamanho da solicitação e resposta em bytes, latência e códigos de resposta
para cada dependência

35. Saturação

36. Saturação
● Procure monitorar e rastrear o uso de todos os recursos dos quais o serviço depende
● Alguns recursos têm limites rígidos que você não pode exceder, como RAM, disco ou cota de
CPU alocada para seu aplicativo
● Outros recursos - como descritores de arquivos abertos, threads ativos em qualquer pool de
threads, tempos de espera em filas ou o volume de logs gravados - podem não ter um limite
rígido claro, mas ainda requerem gerenciamento

37. Saturação
Dependendo da linguagem de programação em uso, você deve monitorar recursos adicionais:
● Em Java: o tamanho do heap e do metaspace e métricas mais específicas, dependendo do tipo de coleta de
lixo que você está usando
● Em Go: o número de goroutines
Pode ser preciso configurar um alerta que dispara quando você se aproxima da exaustão de
recursos específicos, como:
● Quando o recurso tem um limite rígido
● Quando cruzar um limite de uso causa degradação de desempenho

38. Status do tráfego servido

39. Status do tráfego servido
É uma boa ideia adicionar métricas ou rótulos de métricas que permitem que os painéis dividam o
tráfego servido por código de status (a menos que as métricas que seu serviço usa para fins de
SLI já incluam essas informações). Aqui estão algumas recomendações:
● Para tráfego HTTP, monitore todos os códigos de resposta, mesmo se eles não fornecerem
sinal suficiente para alertar, porque alguns podem ser acionados por comportamento incorreto
do cliente
● Se você aplicar limites de taxa ou cota a seus usuários, monitore os agregados de quantas
solicitações foram negadas por falta de cota
● Os gráficos desses dados podem ajudá-lo a identificar quando o volume de erros muda
perceptivelmente durante uma mudança de produção

40. Implementando Métricas Objetivas

41. Implementando Métricas Objetivas
● Cada métrica exposta deve servir a um propósito. Resista à tentação de exportar um
punhado de métricas apenas porque são fáceis de gerar
● O ideal é que os valores de métricas usados para alertar mudem drasticamente apenas
quando o sistema entra em um estado de problema e não mudam quando o sistema está
operando normalmente
● Ao escrever uma autópsia, pense em quais métricas adicionais teriam permitido que você
diagnosticou o problema mais rapidamente

42. Lógica de alerta de teste

43. Lógica de alerta de teste
Em um mundo ideal, o código de monitoramento e alerta deve estar sujeito aos mesmos padrões
de teste do desenvolvimento de código (ideias em maturação até mesmo no google)
Se você não pode testar seu monitoramento por meios sintéticos, ou há um estágio do seu
monitoramento que você simplesmente não pode testar, considere a criação de um sistema em
execução que exporte métricas conhecidas, como número de solicitações e erros
É muito provável que suas regras de alerta não sejam acionadas por meses ou anos após sua
configuração, e você precisa ter certeza de que, quando a métrica ultrapassar um determinado
limite, os engenheiros corretos serão alertados com notificações que façam sentido

44. Como a função do SRE é responsável pela confiabilidade dos sistemas em produção, os SREs
geralmente precisam estar intimamente familiarizados com o sistema de monitoramento de um
serviço e seus recursos
Sem esse conhecimento, os SREs podem não saber onde procurar, como identificar um
comportamento anormal ou como encontrar as informações de que precisam durante uma
emergência

45. Next
?

46. https://ichi.pro/pt/criacao-de-paineis-de-monitoramento-34358631784876
https://sre.google/sre-book/monitoring-distributed-systems/#xref_monitoring_golden-signals
https://www.weave.works/blog/the-red-method-key-metrics-for-microservices-architecture/
https://sre.google/workbook/monitoring/
https://sre.google/workbook/monitoring/