Higiene de alertas em monitoramento de hosts: taxa em vez de limiar, units com falha e janelas de duração

O que é

O livro de SRE do Google afirma que "paging a human is a quite expensive use of an employee's time" (acionar uma pessoa por page é um uso bastante caro do tempo de um funcionário) e que um alerta eficaz exige "good signal and very low noise" (bom sinal e muito pouco ruído): cada page que acaba não exigindo ação ensina quem está de plantão a confiar menos nos pages. O capítulo do SRE workbook sobre alertas baseados em SLOs descreve o alerta multijanela, que só dispara quando a taxa de consumo (burn rate) está alta tanto em uma janela longa (para que um pico breve não gere page) quanto em uma curta (para que o alerta se encerre logo após a recuperação).

Aplicadas a um único host, e não ao SLO de um serviço, essas mesmas duas ideias respondem quais dos sinais tratados em outros artigos desta série pertencem ao pager e quais à fila de tickets:

• Espaço em disco: uma porcentagem fixa (por exemplo, "page com 90% de uso") dispara do mesmo jeito, quer a partição esteja parada em 91% há seis meses, quer tenha ido de 60% a 91% na última hora. O que realmente prevê uma interrupção iminente é a taxa de preenchimento, ou seja, o tempo projetado até encher no ritmo atual de crescimento: um 91% lento e estável é um ticket; uma partição a caminho de encher dentro de uma hora é um page.
• Units do systemd com falha / serviços do Windows parados: uma unit que está com falha neste momento e deveria estar em execução se aproxima do caso "já quebrado" que o livro de SRE considera digno de page; uma unit que falhou uma vez e já foi reiniciada pela própria lógica de retry é um ticket, não um page.
• Sincronização de relógio: um host cujo relógio se desviou o bastante para quebrar a validação de TLS ou a correlação de logs merece um page; um timeout momentâneo de consulta NTP que se resolve na próxima verificação, não.
• Saúde SMART/NVMe: um autoteste com falha ou um byte de critical warning diferente de zero merece um page, dado o curto intervalo até a perda de dados; um único setor realocado em um drive que de resto está saudável é um ticket para acompanhar.

Por que importa

Alertar sobre o valor instantâneo bruto de uma métrica, sem exigir duração ou tendência, é o que produz a oscilação (flapping) e o ruído contra os quais o livro de SRE alerta: um limiar que paira perto do seu limite dispara e se encerra repetidamente, e a fadiga de alertas resultante é o mesmo modo de falha, seja a métrica a porcentagem de um disco ou a taxa de erros HTTP.

Como aplicar

• Para cada alerta de host, pergunte se a regra reage a uma taxa/tendência ou a um nível bruto, e se exige que a condição persista ao longo de uma janela em vez de uma amostra instantânea.
• Encaminhe para um page as condições do tipo "já quebrado, ação necessária agora" (disco prestes a encher dentro da janela do plantão, uma unit necessária fora do ar, relógio dessincronizado); encaminhe para um ticket ou dashboard as condições do tipo "vale revisar em breve" (lentas, estáveis ou já recuperadas).
• Reavalie qualquer alerta que gere page mais do que algumas vezes sem uma correção real correspondente: o estudo de caso do Bigtable no livro de SRE descreve a desativação de alertas por e-mail que se tinham tornado numerosos demais para serem diagnosticados.

Armadilhas

• Copiar um limiar de disco baseado em porcentagem de um host para outro com taxa de crescimento muito diferente, onde o mesmo número significa uma margem de tempo distinta.
• Tratar page e ticket como a mesma severidade com canais de entrega diferentes, em vez de classes distintas de urgência.