Como SRE, um dos primeiros passos para garantir a confiabilidade é a instrumentação de tudo. Claro, não é necessariamente monitorar absolutamente tudo, tudo, mas é essencial cobrir todos os aspectos críticos do seu serviço “reliability” e das necessidades dos clientes/business, ser realmente data-diven. Muito essencial, É aqui que entram os conceitos de SLO (Service Level Objectives) e SLI (Service Level Indicators) Error Budget …
Mas por onde começar? É fundamental contar com as ferramentas adequadas para essa tarefa. Um benchmark eficaz deve abranger claramente o problema que você está tentando resolver, focando nas funcionalidades que são realmente importantes para você.
Características como boa interface , dashboards/data querying, integração e alertas, eu acho que são fundamentais para uma boa ferramenta de observabilidade. Tente avaliar esses aspectos cuidadosamente.
Recentemente, interagindo com o Bensley, ele me questionou: “Por que Prometheus, por que uso o Prometheus para monitoramento?” A verdade é que não tenho acesso a soluções como Borgmon/Monarch, e ainda não disponho de recursos para investir em ferramentas de observability líderes de mercado, como Dynatrace, Tanzu Observability, DataDog, etc. Porém, disponho do Prometheus e do Alert Manager, que são open source (OSS).
Neste contexto, o Prometheus/Alert Manager se destaca por uma razão específica: ele permite definir regras de encaminhamento de alertas de forma simples, baseando-se na severidade dos eventos. Mais motivos, deixo no que coloquei no final deste post.
Alert Fatigue
Mas por que essa funcionalidade é tão importante? Meus caros, Alert fatigue é um problema real. Se você recebe notificações para todas as ocorrências, suas regras de alerta provavelmente não estão bem configuradas. Aposto que, quando o pager ou o celular toca, você já tende a ignorar, pensando que pode ser mais um falso positivo ou algo não crítico, pois toca sempre.
Nota: Para manter a organização e a eficiência na gestão de alertas de SRE, é aconselhável separar os dispositivos utilizados para assuntos pessoais dos destinados ao recebimento de alertas críticos de serviços.
Tomemos um exemplo prático: como SRE, não preciso ser notificado por pager ou SMS toda vez que meu cluster realiza um auto scale de recursos (Low Memory or CPU). Esse tipo de evento pode ser classificado com uma severidade menor, como um aviso (warning), e ser comunicado através de um canal do Slack “warnings” por exemplo, o que já seria suficiente. Por outro lado, situações de maior gravidade, como uma node down, DB com alta latência ou down, exigem uma resposta mais imediata e, nesses casos, faz sentido que os alertas sejam enviados diretamente para o nosso pager ou SMS, ou qualquer outro mecanismo de notificação para emergencias. Assim, meu pager/celular (SMS) será reservado apenas para alertas críticos.
Alerta:
Slack:
O processo de tunning de alertas é contínuo, adaptando-se ao longo do lifecycle. À medida que ganhamos mais experiência, começamos a distinguir entre o que constitui apenas ruído e o que realmente necessita de atenção.
Why prometheus?
Prometheus e InfluxDB overview
Virtual Cluster IT 