Imagem de fundo

Uma aplicação crítica em Kubernetes, monitorada com...

Uma aplicação crítica em Kubernetes, monitorada com Prometheus, Grafana, Loki e Jaeger (OpenTelemetry), apresenta um disparo em sua latência de cauda (p99), que saltou de 200 ms para 2000 ms. No entanto, a latência média segue estável em ~300 ms, sem qualquer alteração na taxa de erros. O Service Level Objective (SLO) de performance da aplicação é p95 < 500 ms.

Simultaneamente, a equipe de FinOps alerta para um aumento de 40% nos custos de armazenamento, impulsionado por um volume excessivo de logs de nível DEBUG nas últimas 24 horas.


Considerando a integração dos pilares de observabilidade (métricas, logs, traces), o SLO definido e o impacto financeiro (FinOps), assinale a afirmativa correta.


A

Tratar como latência de cauda. Filtrar traces > 1s no Jaeger para identificar spans lentos (BD/APIs). Usar trace_id no Loki para inspecionar os logs DEBUG associados. Para FinOps, habilitar tail-based sampling (capturar 100% dos traces lentos) e reverter o nível de log da aplicação para INFO.


B

A anomalia no p99 sugere violação do SLO, caracterizando quebra de SLA. A ação imediata é executar rollback via kubectl, aumentar o replicas count (HPA) para absorver a carga e, preventivamente, investigar a rede física com polling SNMP mais agressivo nos switches do datacenter.


C

A estabilidade da média indica que os alertas estão mal configurados. Ajustar o SLO para se basear na latência média (p50), que reflete melhor o usuário comum. Para resolver o FinOps, pausar o distributed tracing (Jaeger) em produção, removendo o overhead de coleta e o custo de amostragem.


D

O SLO (p95) e a média estão saudáveis; o p99 é um outlier não prioritário. Focar no FinOps: aplicar head-based sampling de 1% no OpenTelemetry e reduzir a ingestão de logs no Loki. A economia de custos deve ser a ação principal e imediata para normalizar os gastos do projeto.


E

O p99 alto e o excesso de logs DEBUG indicam contenção de recursos (CPU ou I/O) nos nodes. A ação é alocar mais recursos, aumentando requests/limits de CPU e Memória dos pods e escalando verticalmente o cluster. O custo de FinOps é secundário e deve ser tratado após o incidente.