Configuração de thresholds: baseline, desvio padrão, camadas e janela de sustentação

Toda operação que recebe alerta demais chega no mesmo lugar: o time para de olhar. Não por descuido. A triagem manual de dezenas de notificações por turno não escala. O incidente real chega junto com o ruído, no mesmo canal, com a mesma cor.

A causa raramente é a ferramenta. Está na configuração de thresholds, feita por estimativa e revisada só depois que alguém reclama. Limiar baixo gera fadiga de alertas. Limiar alto entrega silêncio até o usuário abrir chamado.

Este texto trata do meio-termo com método. Ele cobre como levantar a linha de base e como derivar o limiar dela. Depois, quantas camadas de severidade fazem sentido e por que a duração importa tanto quanto o valor.

O que são thresholds em monitoramento

Thresholds são limiares numéricos que disparam notificação quando uma métrica ultrapassa, ou fica abaixo, de um valor definido. Eles traduzem telemetria contínua em evento discreto. Sem esse corte, o painel mostra tudo e não avisa nada, porque ninguém observa gráfico 24 horas por dia.

Existem dois tipos. O threshold estático é fixo e independe do contexto, como CPU > 90%. O threshold dinâmico se ajusta a partir da linha de base histórica, o que absorve sazonalidade de tráfego e ciclo de fechamento.

Escolher o tipo errado para o contexto certo é falha de arquitetura, não de operação. Limiar estático aplicado a uma API com pico previsível às 9h vai alertar todo dia útil no mesmo horário. Sempre com razão numérica, sempre sem valor operacional.

Vale separar dois níveis desde o início. Alerta de causa observa o recurso, como CPU ou memória. Alerta de sintoma observa o que o usuário sente, como taxa de erro e tempo de resposta. Operações maduras acordam gente pelo sintoma e usam a causa para diagnosticar.

Por que o limiar errado custa caro

O prejuízo do threshold mal calibrado aparece nas duas pontas. As duas terminam no mesmo indicador de negócio.

O ruído que esconde o incidente

Limiar apertado demais produz tempestade de alertas. Um único link instável dispara dezenas de notificações por minuto. O incidente que importa entra na fila junto com elas.

O efeito colateral é comportamental e permanente. Depois de algumas semanas recebendo alerta que não exige ação, o analista passa a fechar a notificação antes de ler. A partir daí, a cobertura existe no papel e não existe na prática.

O limiar alto que atrasa a detecção

No outro extremo, o threshold folgado empurra o MTTD para cima. A falha começa a se manifestar, a métrica sobe devagar. O alerta só dispara quando o usuário já sentiu.

Detecção tardia contamina toda a cadeia de resposta. O MTTR herda o atraso, a janela de contorno encurta e a conversa com o negócio deixa de ser sobre prevenção. Por isso o limiar é decisão de risco, não preferência técnica.

O alerta que ninguém sabe tratar

Existe um terceiro modo de falha, menos discutido que os dois anteriores. O limiar está correto, a notificação chega no horário certo. Ainda assim ninguém age, porque o alerta não diz o que fazer.

Um alerta acionável carrega três informações além do valor: o serviço afetado, o impacto provável e o próximo passo. Sem isso, o plantonista abre o painel, olha o gráfico e escala para alguém que saiba. O tempo gasto nessa ponte entra inteiro no MTTR.

Na revisão de limiares, vale contar quantos alertas do último trimestre terminaram em ação concreta. Os que só geraram encaminhamento pedem redesenho, não ajuste de número.

Como definir thresholds com base estatística

O método abaixo troca estimativa por evidência. Ele funciona igual para infraestrutura, aplicação e rede, mudando apenas a métrica de entrada.

Passo 1: colete a linha de base

Capture o comportamento real da métrica por pelo menos 30 dias corridos. Trinta dias cobrem o ciclo mensal inteiro: fechamento contábil, folha e picos de início de mês. São justamente os dias em que o limiar improvisado falha.

Analise média, pico e vale por hora do dia e por dia da semana. Uma plataforma de observabilidade com retenção adequada resolve essa coleta sem instrumentação extra. O resultado é um perfil, não um número único.

Passo 2: aplique desvio padrão sobre a base

Com o perfil em mãos, derive o limiar da própria distribuição. Um corte em média + 2σ captura o que foge do comportamento normal sem disparar nas variações rotineiras. Cerca de 95% das amostras de uma distribuição normal ficam dentro dessa faixa.

Duas ressalvas evitam o uso mecânico da fórmula. Métrica de latência raramente é normal, então use percentil em vez de média. Métrica com tendência de crescimento exige recalcular a base periodicamente, senão o limiar envelhece junto com o ambiente.

O caso da latência ilustra bem a diferença. A média esconde a cauda: p50 estável convive com p99 degradado. Quem sente o p99 é o usuário, então o limiar de latência nasce do percentil e do SLO, nunca da média simples.

Passo 3: monte camadas de severidade

Uma métrica merece mais de um limiar, cada um com destino diferente. A arquitetura em camadas separa o que vira registro do que acorda alguém:

WARNING: CPU > 75% por 15 minutos

CRITICAL: CPU > 90% por 5 minutos

EMERGENCY: CPU > 98% por 1 minuto

Repare que o tempo diminui conforme a severidade sobe. Cada camada aciona um fluxo distinto de escalação de alertas. O warning alimenta relatório e planejamento de capacidade. O critical entra na fila do plantão, o emergency dispara acionamento imediato.

Um teste rápido valida a divisão: se as três camadas terminam no mesmo grupo do mesmo canal, elas não separam nada. Nesse caso, você tem um limiar só, escrito três vezes.

Passo 4: exija duração antes de alertar

Threshold sem janela de sustentação gera flapping. A métrica cruza o limiar por 20 segundos, volta, cruza de novo. Cada travessia vira um alerta novo, embora o ambiente não tenha mudado.

A correção tem duas partes. A primeira é a cláusula de duração, o for do Prometheus e equivalentes, que só dispara quando a condição persiste pela janela definida. A prática aparece na documentação oficial de boas práticas de alerta.

A segunda é a histerese: o limiar de recuperação precisa ser mais baixo que o de disparo. Se o alerta abre em 90% e fecha em 89%, uma métrica oscilando na fronteira abre e fecha o dia inteiro. Fechar em 80% resolve o pingue-pongue sem perder cobertura.

Limiares por tipo de recurso

Aplicar o mesmo modelo para servidor, aplicação e rede é o erro mais comum em ambientes sem maturidade de monitoramento. Cada camada tem métrica dominante e tolerância própria.

Ambiente efêmero muda a pergunta. Em cluster de containers, o pod que estoura memória reinicia antes de qualquer limiar de host fazer sentido. O sinal relevante passa a ser a taxa de reinício, o tempo em estado pendente e a diferença entre o recurso solicitado e o consumido. Alertar por host produz notificação sobre uma máquina que já não existe quando o plantonista abre o painel.

O mesmo raciocínio vale para escala automática. CPU alta pode significar que o dimensionamento está funcionando, não que existe incidente. Alertar pelo sintoma do usuário evita esse falso positivo estrutural.

O limiar de latência merece atenção extra. Ele não sai de referência de mercado, sai do compromisso assumido com o negócio. Primeiro define-se o SLO, depois o alerta que protege o orçamento de erro, raciocínio detalhado no capítulo sobre alerta orientado a nível de serviço.

Automação e revisão contínua

Threshold não é configuração permanente. Ambiente cresce, aplicação muda de padrão de consumo, sazonalidade se desloca. Um ciclo de revisão mantém a cobertura viva.

Plataformas modernas já oferecem detecção de anomalia que ajusta o limiar sozinha a partir do histórico. O arranjo que funciona combina os dois tipos: estático para limite absoluto de segurança, como disco cheio ou certificado vencido, dinâmico para desvio de comportamento.

A detecção automática tem limite conhecido. Ela precisa de histórico para funcionar, então erra nas primeiras semanas de um serviço novo. Também aprende o que estiver rodando, inclusive um comportamento defeituoso que já era rotina quando a coleta começou.

Por isso o limiar absoluto de segurança nunca sai do ar. Disco cheio, certificado vencido e processo parado seguem com corte fixo, porque não existe cenário em que sejam normais.

A revisão ganha disciplina quando entra no post-mortem de cada incidente. Uma pergunta basta: o limiar atual teria detectado isso antes do usuário? Quando a resposta é não, o ajuste vira item de ação com dono e prazo.

Vale o caminho inverso também. Todo alerta que ninguém tratou por três meses seguidos é candidato a corte ou a recalibração, porque ele já provou que não muda decisão nenhuma.

Thresholds como termômetro de maturidade

A configuração de thresholds revela o estágio de uma operação com precisão maior que qualquer autoavaliação. Ambiente com limiar derivado de base, camada de severidade e janela de sustentação responde rápido porque o alerta que chega significa alguma coisa.

O caminho é conhecido e não tem atalho. Instrumente, colete pelo menos um ciclo mensal, derive o limiar da distribuição, separe severidade por destino, exija duração e revise depois de cada incidente. Intuição entra apenas na leitura do resultado, nunca na definição do número.

Se a sua operação convive com ruído de alerta ou descobre incidente pelo chamado do usuário, o problema tem endereço. Costuma estar em três limiares mal calibrados, não em trezentos. Fale com nossos especialistas para revisar a calibragem junto com o time que opera o ambiente.