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

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado mar/2026Atualizado set/2026

Threshold significa limiar. Em monitoramento, é o valor que separa a rotina do alerta. Ou seja, quando a métrica passa desse ponto, a ferramenta deixa de apenas registrar e avisa alguém. Definir esse número é o que decide se o time responde ao incidente ou aprende a ignorar o painel.

Na prática, porém, o número quase sempre sai de estimativa e só é revisado depois que alguém reclama. Limiar baixo gera fadiga de alertas: o analista passa a fechar notificação sem ler. Limiar alto entrega silêncio até o usuário abrir chamado.

Este texto trata do meio-termo com método. Ele cobre a tradução, os dois tipos, como levantar a linha de base e como derivar o limiar dela. Além disso, mostra num laboratório quantos alertas cada configuração dispara sobre a mesma série.

O que são thresholds em monitoramento

Threshold é a palavra inglesa para limiar, ou limite. Em monitoramento, ela nomeia o valor numérico que dispara notificação quando a métrica o ultrapassa, ou fica abaixo dele. Esse corte traduz telemetria contínua em evento discreto. Sem ele, portanto, o painel mostra tudo e não avisa nada, porque ninguém observa gráfico 24 horas por dia.

A grafia tropeça com frequência: são dois h, em threshold. Formas como treshold, threshould e trashold aparecem muito na busca em português, porém nenhuma existe em inglês.

Existem dois tipos. O threshold estático é fixo e independe do contexto, como CPU > 90%. Por outro lado, 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. Por exemplo, 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. Em contrapartida, o 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. Ambas, no final das contas, 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, por exemplo, 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. Como resultado, 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. Assim, 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. Consequentemente, 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, ou seja, não ajuste de número.

Como definir thresholds com base estatística

O método abaixo troca estimativa por evidência. Ele funciona da mesma forma 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, principalmente, 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, portanto, é um perfil e não um número único.

 
O laboratório deste artigo rodou em 3 de setembro de 2026, com Prometheus 3.7.3 e node-exporter 1.10.2 em Docker. A métrica é a CPU do próprio container de carga, preso a quatro núcleos. Assim, o que roda ao lado na mesma máquina não entra na conta.

# janela da linha de base, coletada de 5 em 5 segundos
node mede-base.cjs 2026-09-03T12:37:20Z 2026-09-03T12:52:05Z

{
  "amostras": 178,
  "media": 29.92,
  "desvio_padrao": 18.62,
  "p50": 23.12,
  "p95": 85.46,
  "p99": 89.24,
  "maximo": 92.62,
  "limiar_media_mais_2dp": 67.16
}

Trinta dias de produção viraram 15 minutos aqui, porque a intenção é mostrar a conta e não substituir a coleta. Mesmo assim o perfil já aparece. A média ficou em 29,9% e o pico da janela em 92,6%, ou seja, nenhum valor único descreve as duas coisas.

Passo 2: aplique desvio padrão sobre a base

Com o perfil em mãos, derive o limiar da própria distribuição. Dessa forma, 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. Além disso, métrica com tendência de crescimento exige recalcular a base periodicamente, senão o limiar envelhece junto com o ambiente.

 
A conta não pede planilha nem exportação. Ela cabe, inclusive, numa consulta só, rodada contra a série que já está guardada:

# o mesmo cálculo dentro do Prometheus, sem exportar nada
avg_over_time(cpu[15m:5s])
  + 2 * stddev_over_time(cpu[15m:5s])

# devolveu 67.07; o script, lendo amostra por amostra, deu 67.16

Para a base medida acima o limiar defensável ficou em 67,2%, bem abaixo dos 80% que a intuição costuma chutar. Guarde essa distância, porque ela reaparece no passo 4 com um resultado que contraria a expectativa.

 
Sobre a série real, as duas linhas ficam assim: a vermelha é o limiar derivado, a azul é o chute de 80%.

O caso da latência ilustra bem a diferença. A média esconde a cauda: p50 estável convive com p99 degradado. Vale dizer que 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, dessa forma, separa o que vira registro do que acorda alguém:

Repare que o tempo diminui conforme a severidade sobe. Adicionalmente, 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.

Por fim, 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, portanto, 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. Vale destacar que a prática aparece na documentação oficial de boas práticas de alerta.

 
Em arquivo, a regra ocupa seis linhas. A que muda o resultado, no entanto, é a última:

groups:
  - name: limiar-derivado-da-base
    rules:
      - alert: CPUAcimaDaBase
        expr: cpu > 67.2
        for: 5m   # sem esta linha, pico de 40 segundos vira alerta

 
Enquanto a janela corre, o alerta existe mas não aciona ninguém. O Prometheus chama esse estado de PENDING e mostra há quanto tempo a condição dura:

 
Convém medir esse efeito em vez de supor. No laboratório, quatro variantes da mesma regra ficaram ativas ao mesmo tempo, sobre a mesma série de CPU:

# 23 minutos: 3 picos rotineiros de 35 a 50s e 1 incidente de 8 min
# as quatro regras rodaram ao mesmo tempo, sobre a mesma série

  > 80%    sem duração   ->   4 alertas
  > 80%    for: 5m       ->   1 alerta 
  > 67.2%  sem duração   ->   4 alertas
  > 67.2%  for: 5m       ->   1 alerta 

No meio do incidente, a diferença aparece de uma vez: as duas regras sem duração já disparadas, as duas com janela ainda esperando.

 
Trocar 80% por 67,2% mudou pouco. Essa é a parte contraintuitiva. Os picos rotineiros passam dos dois limiares, portanto o número sozinho não separa nada. Quem cortou o ruído foi a janela de sustentação: ela derrubou os picos de 40 segundos e deixou passar o incidente de oito minutos.

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%, todavia, resolve o pingue-pongue sem perder cobertura.

 
Essa parte também sai medida. Nos 6 minutos finais o laboratório manteve a métrica oscilando em torno de 80%. A regra que abre e fecha no mesmo valor registrou 8 episódios de alerta nesse intervalo, sem que o ambiente mudasse uma única vez.

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, logo o limiar muda com ela.

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. Nesse sentido, o sinal relevante muda. Ele 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. Portanto, 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. Antes de tudo define-se o SLO, em seguida o alerta que protege o orçamento de erro. Esse raciocínio aparece 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. Por isso, um ciclo de revisão mantém a cobertura viva.

Além disso, 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 sobretudo 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. Ou seja, ele já provou que não muda decisão nenhuma.

Thresholds como termômetro de maturidade

Em síntese, 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. Por fim, a 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. Em resumo, 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.