Questão de Arquitetura de Software — Sistemas Distribuídos — FGV 2025
Arquitetura de Software›Sistemas Distribuídos
Código
fg106559
Banca
FGV
Órgão
CGE-SP
Ano
2025
Nível
Superior
Cargo
Auditor Estadual de Controle - Tecnologia da Informação - tarde
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.
ATratar 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.
BA 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.
CA 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.
DO 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.
EO 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.
Revelar gabarito e comentário▾
GabaritoA — 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.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Observabilidade em Kubernetes: latência de cauda, SLO e FinOps
Gabarito: letra A. A alternativa A é a única que trata corretamente a latência de cauda (p99) sem violação do SLO (p95 < 500ms), propõe investigação integrada com traces e logs, e adota ações de FinOps adequadas (tail-based sampling + redução de verbosidade de logs). As demais alternativas confundem SLO, ignoram a causa raiz ou propõem ações desalinhadas com os pilares de observabilidade.
A questão testa a compreensão de observabilidade (métricas, logs, traces), SLO e FinOps em um cenário real de Kubernetes. O aumento do p99 sem impacto na média e sem erros sugere um problema esporádico de latência (ex.: gargalos em banco de dados ou APIs externas). O SLO (p95 < 500ms) não foi violado, mas o p99 elevado merece investigação. O excesso de logs DEBUG gera custo de armazenamento.
Aspecto
Alternativa A (✅ Correta)
Alternativa B (❌ Incorreta)
Alternativa C (❌ Incorreta)
Alternativa D (❌ Incorreta)
Alternativa E (❌ Incorreta)
Diagnóstico do p99 (latência de cauda)
Reconhece como problema a investigar, sem confundir com SLO
Afirma que viola o SLO (falso: SLO é p95 < 500ms)
Propõe alterar SLO para p50 (inadequado)
Considera p99 como outlier não prioritário (ignora investigação)
Atribui a contenção de recursos (CPU/I/O) sem evidência
Relação com o SLO (p95 < 500ms)
SLO não violado (p95 estável)
Afirma violação de SLO (incorreto)
Propõe mudança do SLO para p50 (não recomendado)
SLO saudável, mas ignora p99
Não aborda SLO
Ação de investigação (traces + logs)
Filtrar traces >1s no Jaeger; usar trace_id no Loki para logs DEBUG
Rollback e HPA reativos; investigar rede física com SNMP (desalinhado)
Pausar Jaeger (remove capacidade de investigação)
Aplicar head-based sampling de 1% (perde traces lentos)
Aumentar requests/limits de CPU/Memória (sem análise de causa)
Ação de FinOps (custo de armazenamento)
Tail-based sampling (captura 100% dos traces lentos) + reduzir logs para INFO
Não aborda FinOps
Pausar tracing (não resolve custo de logs)
Head-based sampling de 1% + reduzir ingestão de logs (pode perder dados críticos)
Considera custo secundário (posterga tratamento)
Adequação aos pilares de observabilidade
Integra métricas, logs e traces corretamente
Ações não baseadas em observabilidade
Remove tracing (perde visibilidade)
Amostragem inadequada para latência de cauda
Foco apenas em recursos, sem observabilidade
Alternativa A — ✅ Correta ⟵ GABARITO
Reconhece a latência de cauda como problema a investigar, sem confundir com SLO. Sugere filtrar traces lentos (>1s) no Jaeger para identificar spans específicos (BD/APIs) e correlacionar com logs via trace_id no Loki — prática padrão de observabilidade integrada. Para FinOps, propõe tail-based sampling (captura 100% dos traces lentos, descartando os normais) e redução do nível de log para INFO, atacando diretamente a causa do aumento de custo (logs DEBUG excessivos). Ação equilibrada que mantém a observabilidade dos problemas e reduz custos.
Alternativa B — ❌ Incorreta
Afirma que o p99 alto viola o SLO, o que é falso — o SLO definido é p95 < 500ms, e a média estável sugere que o p95 não foi afetado. Ações de rollback e HPA (aumentar réplicas) são reativas e não baseadas em análise de causa; investigar rede física com SNMP não se relaciona com latência de cauda nem com o excesso de logs.
Alternativa C — ❌ Incorreta
Propõe alterar o SLO para p50, o que não é recomendado (p95 é mais adequado para performance). Pausar o Jaeger (distributed tracing) remove a capacidade de investigar a latência de cauda, perdendo observabilidade essencial. Não endereça corretamente o FinOps — pausar tracing não resolve o custo de logs e elimina a visibilidade.
Alternativa D — ❌ Incorreta
Considera o p99 como outlier não prioritário, mas em sistemas críticos a latência de cauda pode indicar problemas futuros. Ignorá-la é arriscado. Aplicar head-based sampling de 1% reduz a amostragem uniformemente, possivelmente perdendo traces lentos — o que contraria a necessidade de investigar a causa. A redução de logs é positiva, mas a abordagem de sampling inadequada e a priorização exclusiva de custos sem investigação técnica é incompleta.
Alternativa E — ❌ Incorreta
Atribui o p99 alto e logs excessivos a contenção de recursos (CPU/I/O), sem evidência — a latência média estável não sugere contenção generalizada. Aumentar requests/limits e escalar verticalmente o cluster é uma ação custosa e potencialmente desnecessária. Tratar FinOps como secundário após o incidente é inadequado, pois o custo já está impactando.
PEGA ESSA DICA!
Em cenários de observabilidade, sempre correlacione métricas, logs e traces. O p99 alto com média estável é típico de problemas esporádicos (ex.: consultas lentas em BD). Para controle de custos com tracing, prefira tail-based sampling (foca em amostras lentas) em vez de head-based (amostragem uniforme). E ajuste o nível de log para produção (INFO ou WARN) para evitar acúmulo de DEBUG.