Pular para o conteúdo principal

Questão de Arquitetura de Software — Sistemas Distribuídos — FGV 2026

Arquitetura de SoftwareSistemas Distribuídos
Código
fg133735
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Gestão de TIC
Uma aplicação baseada em microsserviços, hospedada em uma nuvem privada de um órgão, tem apresentado picos de latência em transações que atravessam vários serviços.Com base no conceito de observabilidade, a correlação correta de itens a ser adotada para acelerar a investigação da causa raiz do problema é:
  1. Athresholds distribuídos + métricas + logs distribuídos;
  2. Btraces distribuídos + métricas + logs correlacionados;
  3. Cthresholds locais + métricas agregadas + logs centralizados;
  4. Dtraces locais + métricas agregadas + thresholds distribuídos;
  5. Etraces locais + thresholds distribuídos + logs correlacionados.
Revelar gabarito e comentário

GabaritoB — traces distribuídos + métricas + logs correlacionados;

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 Microsserviços

Gabarito: letra B. Em sistemas distribuídos, a observabilidade para investigação de causa raiz de latência exige a combinação de traços distribuídos (para rastrear requisições entre serviços), métricas (para indicadores de desempenho) e logs correlacionados (com identificadores únicos que permitem ligar eventos ao traço). As demais alternativas trocam componentes essenciais por conceitos inadequados, como thresholds ou traços locais.

A questão explora os três pilares da observabilidade em microsserviços: métricas, logs e traços. Em transações que atravessam vários serviços, o traço distribuído é indispensável para seguir o caminho completo da requisição, enquanto logs precisam estar correlacionados (ex.: com um trace ID) para que possam ser associados ao traço. Métricas fornecem visão agregada (latência, taxa de erro) que ajudam a localizar o problema.

Alternativa A — ❌ Incorreta

Inclui thresholds distribuídos, que não são um pilar de observabilidade – são limites para alertas. Além disso, logs distribuídos sem correlação não permitem ligar eventos ao traço.

Alternativa B — ✅ Correta ⟵ GABARITO

Combina exatamente os três pilares: traços distribuídos (rastreio ponta a ponta), métricas (visão quantitativa) e logs correlacionados (com identificador de traço). Essa é a receita padrão para debug em microsserviços.

Alternativa C — ❌ Incorreta

Thresholds locais não ajudam a localizar um gargalo distribuído. Métricas agregadas podem esconder picos específicos. Logs centralizados sem correlação não permitem seguir a requisição entre serviços.

Alternativa D — ❌ Incorreta

Traços locais não rastreiam a transação além de um único serviço – inviável para o cenário. Thresholds distribuídos novamente não são um pilar.

Alternativa E — ❌ Incorreta

Traços locais falham em capturar o fluxo entre serviços. Embora tenha logs correlacionados, a ausência de métricas e o uso de thresholds no lugar de traços distribuídos a tornam insuficiente.

PEGA ESSA DICA!

Memorize os três pilares da observabilidade: métricas, logs e traços. Em sistemas distribuídos, os traços devem ser distribuídos e os logs correlacionados (mesmo ID de traço). Thresholds são configurações de alerta, não pilares.

Gabarito: letra B.

Link permanente: /questoes/fg133735