Multiwindow, Multi-Burn-Rate Alerts

Fabricio Gonçalves
olist
Published in
5 min readJun 10, 2022
imagem extraída do livro “The Site Reliability Workbook: Practical Ways to Implement SRE”

Multiwindow, Multi-Burn-Rate Alerts talvez seja uma das abordagens que mais mudou a forma que eu enxergava o mundo quando entrei para essa vida de SRE, sigla em inglês para Site Reliability Engineering ou “Engenharia de Confiabilidade de Sites”, que representa uma abordagem da engenharia de software utilizada em operações de TI. Além disso, vejo também que é a forma que a pessoa dev mais tem resistência em aderir.

O que é Multiwindow, Multi-Burn-Rate Alerts?

É a maneira de ter alertas suficientemente sensíveis e, ao mesmo tempo, reduzir os falsos positivos. Propondo um mecanismo para notificar quando uma grande mudança repentina no consumo do orçamento de erros ocorrer, ou se uma queima lenta, porém constante, colocar em risco o SLO.

Mas o que isso significa? SLO é a sigla para Service Level Objective, na tradução, Objetivo de Nível de Serviço. Em resumo, é um acordo firmado internamente a fim de garantir que as promessas feitas anteriormente para o cliente sejam cumpridas.

Quem aqui nunca ficou tentado em criar um alerta em alto uso de CPU levanta a mão? o/
ou em algum lag de fila? o/
Melhor ainda… quem aqui já ignorou um alerta por achar que era um falso positivo? o/ o/ o/ o/

Pois é, quando estamos monitorando saturação de algo, por exemplo, ao invés de monitorar a confiabilidade do negócio a tendência é que isso aconteça.

Mas antes, o que é burn rate mesmo?

Error budget burn rate é uma medida de quão rápido, em relação ao seu SLO, seu serviço consome o orçamento de erros. Por exemplo, se um serviço que tem exatamente zero no orçamento de erro no final do período de observação do SLO, teremos uma taxa de queima igual a 1. (para mais, veja Alert on Burn Rate do capítulo 5 do livro)

Bons alertas

Agora, para mudarmos a abordagem, é necessário entender o que faz um alerta ser “bom”. Para isso, podemos considerar os seguintes atributos:

Precision

A proporção de eventos detectados que foram significativos. A precisão é 100% se cada alerta corresponder a um evento significativo. Observe que o alerta pode se tornar particularmente sensível aos eventos não significativos durante períodos de baixo tráfego.

Recall

A proporção de eventos significativos detectados.
O recall é 100% se cada evento significativo resultar em um alerta.

Detection time

Quanto tempo leva para enviar notificações em várias condições.
Longos tempos de detecção podem afetar negativamente o orçamento de erros.

Reset time

Por quanto tempo os alertas são acionados após a resolução de um problema.
Longos tempos de reinicialização podem causar confusão ou ignorar problemas.

Dito isso, agora temos um norte para conseguirmos classificar se o nosso alerta é bom ou não. Porém, seguindo a abordagem “tradicional”, mesmo com um bom alerta só nos restará a reatividade, já que um alerta acontecerá mediante a um problema já ocorrido, não é mesmo? É aí que entra Multiwindow, Multi-Burn-Rate Alerts, pois queremos ser alertados somente ​​sobre eventos significativos.

Aplicando Multiwindow, Multi-Burn-Rate Alerts

Pré-requisito

A notícia boa é: para seguir com essa abordagem, você precisa ter implantando SLO e Error Budget.

Como funciona?

Basicamente, criamos 4 “presets” com um taxa de queima diferente e com múltiplas janelas de observação. O objetivo desse processo é que sejamos acionados com uma determinada prioridade em caso de lentas alterações no nosso “orçamento de erro”. Em caso de rápidas alterações em um período menor de tempo, seremos acionados com uma prioridade mais elevada. Parece complicado, mas não é! Existe uma tabela que ajuda no entendimento:

https://grafana.com/blog/2019/11/27/kubecon-recap-how-to-include-latency-in-slo-based-alerting/

Na tabela temos:

  • 30 dias de janela (rolling window).
  • SLO 99.9%.

Alert

  • Os alarmes podem ter sua criticidade mais elevada (P1/P2/Page) ou podem ser apenas avisos de algo que não anda bem (P3/P4/Ticket).

Long window e short window

  • As janelas de queima múltipla servem para notificar apenas quando ainda estivermos queimando ativamente o orçamento.
  • Uma boa diretriz é fazer com que a janela curta tenha 1/12 da duração da janela longa.

for Duration

  • Um tempo arbitrário que, normalmente, é a metade da janela curta para evitar que um alarme fique sendo acionado com frequência.

Burn rate factor

  • A taxa de erro média é exatamente o fator 1, que significa a taxa de erro que você poderia sustentar sem estourar seu orçamento de erro.
  • Com o orçamento de erro de 0,1% (SLO 99.9%), se sua taxa de queima for em média 14,4% ao longo de uma hora (janela lonja), você obtém um alerta P1 e, no momento em que a obtém , você queimou 2% do seu orçamento mensal de erros em apenas uma hora. Isso é muito rápido. É aqui que alguém tem que acordar e consertar.
  • Formula: burn rate = budget consumed x period / alert window
    Exemplo:
    budget consumed = 2%
    period = 30 dias = 30*24 = 720
    alert window = 1h (janela de longa duração)
    burn rate = 0.02 * 720 / 1 = 14.4

Error budget consumed

  • Orçamento consumido na janela prevista. De acordo com a última linha da tabela, em 3d com taxa de queima igual a 1 iremos consumir 10% do orçamento.

Podemos customizar os valores com essa ferramenta aqui em conjunto com o PromTools pra gerar as regras.

Em forma de gráfico:

Gráfico para a primeira linha da tabela

No gráfico acima, podemos observar o seguinte:

No minuto 10, ocorre uma situação de erro que traz a taxa de erro para 15%. Quase imediatamente, a janela de observação curta (5m) começa a disparar. Nenhum alerta é gerado, já que ambas as janelas precisam ser disparadas.

No minuto 15, também a longa janela de observação (60m) cruza o limiar e começa a disparar. Nesse ponto, um alerta é enviado. O tempo de detecção foi de 5 minutos.

No minuto 20, o SRE de plantão resolve o problema e os erros caem para zero.

Por volta do minuto 23, a janela curta de observação fica abaixo do limite, inibindo o alerta. Isso significa que o tempo de reposição foi de 3 minutos.

A janela de observação longa fica abaixo do limite apenas por volta do minuto 80, cerca de 60 minutos após a condição de erro ter sido corrigida. Sem a janela de observação mais curta, esse teria sido o tempo de reinicialização.

Conclusão

Pense em termos de orçamentos de erro. Quantos erros são aceitáveis? Não acione alertas se o orçamento não estiver em risco. O uso de várias taxas de queima facilita o ajuste dos alertas.

Multiwindow, Multi-Burn-Rate Alerts oferece uma estrutura flexível que permite controlar o tipo de alerta de acordo com a gravidade do incidente e os requisitos da organização. A boa precisão e um ótimo recall.

Referência:

Chapter 5 — Alerting on SLOs

👉Entre para o #teamOlist e trabalhe em uma empresa com cultura ágil. Confira nossas vagas abertas e candidate-se em olist.gupy.io.

--

--

Fabricio Gonçalves
olist
Writer for

Não tenha medo de inovar e nem de desafios, tenha prazer em ajudar, seja autodidata e ....