Quiz

D — São necessários logs e traces.

O trace mostra qual serviço da cadeia de chamadas causou o erro e quanto tempo cada salto levou, reduzindo a investigação a um único span. Os logs dentro daquele serviço revelam então a classe exata da exceção, a mensagem e o stack trace. Nenhum pilar sozinho dá o quadro completo: traces sem logs dizem onde, mas não por quê; logs sem traces tornam difícil identificar qual serviço, entre muitos, produziu a linha de log correspondente.

C — Histograms são agregáveis; summaries não.

Um Summary calcula os quantis dentro do processo da aplicação — depois de exportados, o valor p99 da instância A e o da instância B não podem ser combinados de forma significativa. Um Histogram exporta as contagens brutas de cada bucket, então histogram_quantile(0.99, sum by (le) (rate(http_server_requests_seconds_bucket[5m]))) calcula corretamente o p99 considerando todas as instâncias e qualquer janela de tempo escolhida. Em um microsserviço escalado horizontalmente, essa distinção é crucial.

B — Taxa média de crescimento por segundo na janela de 5 minutos.

rate() divide o crescimento total do contador na janela pela duração da janela em segundos. Um contador que cresceu 300 em 5 minutos retorna 1.0 (um erro por segundo). Como rate() opera sobre o contador bruto, ele trata corretamente os zeramentos do contador (reinícios do serviço) — o que increase() também faz, mas como contagem absoluta, e não como taxa por segundo.

B — Anexa pares chave-valor a todas as linhas de log da thread corrente.

O MDC guarda um mapa por thread cujos valores o framework de logging (Logback, Log4j2) pode imprimir em todas as linhas de log com um padrão como %X{trace_id}. Com o agente Java do OpenTelemetry, o próprio agente coloca trace_id e span_id no MDC enquanto um span está ativo, então todas as linhas de log da requisição carregam o mesmo ID sem nenhum código na aplicação — o que torna trivial filtrar todo o histórico de logs de uma requisição com uma única consulta. MDC.put continua útil para as suas próprias chaves de negócio (ID do cliente, ID do pedido), que você precisa remover ao final da requisição.

B — O traceId é gerado uma vez e propagado via traceparent.

Quando o primeiro serviço (por exemplo, o API gateway) recebe uma requisição sem cabeçalho traceparent, ele gera um traceId de 128 bits e cria o span raiz. Toda chamada HTTP de saída inclui traceparent: 00-<traceId>-<currentSpanId>-01. Cada serviço downstream lê esse cabeçalho, mantém o traceId inalterado, gera um novo spanId e define parentSpanId como o spanId recebido. O resultado é uma árvore de spans que compartilham o mesmo traceId, que o backend de rastreamento usa para montar a visão completa do trace.

C — Mesmo traceId, novo spanId igual ao ID do span corrente.

O traceId (abc123...) nunca muda ao longo de toda a requisição — essa é a invariante que liga todos os spans. O campo parentSpanId do novo cabeçalho recebe o ID do span corrente (999888...), de modo que o serviço downstream sabe exatamente qual span disparou a chamada. O def456... recebido torna-se o parentSpanId do span corrente (armazenado no registro do span), e não é repassado adiante.

B — O momento da decisão é a diferença central.

O head sampling precisa se comprometer a registrar ou descartar um trace no momento em que o span raiz é criado, sem saber o que acontecerá downstream. Isso é rápido e tem custo quase nulo, mas descarta aleatoriamente alguns traces de erro. O tail sampling mantém os spans em buffer até o trace ficar completo e então aplica regras — por exemplo, manter todos os traces em que algum span tenha status=ERROR. O trade-off é mais memória e mais latência no collector.

C — O OTel Collector.

O Collector é um proxy agnóstico a fornecedores, implantado como sidecar ou como gateway no nível do cluster. Seu pipeline tem três estágios: receivers (aceitam OTLP, Jaeger, Zipkin etc.), processors (filtram, amostram, agrupam em lotes, adicionam atributos) e exporters (enviam para Prometheus, Jaeger, Loki, Datadog etc., simultaneamente). Centralizar o encaminhamento da telemetria no Collector significa que trocar de backend exige apenas uma mudança na configuração do Collector, e não um novo deploy de cada aplicação.

D — Failed Deployment Recovery Time (antes MTTR).

Essa métrica é o tempo entre o início de uma falha (normalmente quando um alerta dispara) e a restauração do serviço à operação normal. Ela captura diretamente a eficácia da resposta a incidentes — incluindo a velocidade de detecção, o tempo de diagnóstico, o deploy da correção e a verificação. Frequência de deploy e lead time medem vazão; a taxa de falha de mudanças mede com que frequência as mudanças quebram algo, não a rapidez da recuperação. Equipes elite se recuperam em menos de uma hora.

B — Instrumentação de bytecode Java via java.lang.instrument.

A API java.lang.instrument da JVM, combinada com um ClassFileTransformer, permite que um JAR -javaagent intercepte cada classe no momento em que ela é carregada e reescreva seu bytecode antes que chegue à aplicação. O agente Java do OTel usa esse mecanismo para injetar criação de spans, propagação de cabeçalhos HTTP e rastreamento de JDBC no Spring MVC, RestTemplate, WebClient, Hibernate e dezenas de outras bibliotecas — tudo sem tocar no código-fonte da aplicação.

B — Cardinalidade de labels ilimitada.

Uma série temporal é identificada pelo nome da métrica mais o conjunto completo de valores de labels, então 200.000 usuários × cada URI × cada status × cada bucket do histogram são milhões de séries. O detalhe por usuário pertence a logs e traces (que são projetados para campos de alta cardinalidade); as métricas devem usar labels limitados, como uri (o template /orders/{id}), method e status.

B — Cerca de 10%.

As decisões de amostragem são aplicadas em sequência: um trace não amostrado no head nunca é registrado nem exportado, então o Collector nunca o vê. Para manter todos os traces de erro, amostre 100% (ou uma proporção alta) no head e deixe a política de tail sampling do Collector manter todos os traces de erro/lentos, mais uma pequena fração dos demais.

A — O label le carrega os limites dos buckets.

Cada bucket do histogram é uma série com um label le ("less than or equal", menor ou igual), como le="0.1". A soma entre instâncias precisa manter o le para que as contagens de cada bucket de todas as instâncias sejam somadas entre si; somar tudo em um único número destrói a distribuição, e o histogram_quantile não devolve nada útil.

C — Alerte sobre um sintoma que os usuários sentem.

Alertas que acionam o plantão devem ser urgentes, acionáveis e ligados ao impacto no usuário: pedidos falhando são exatamente isso. CPU ou uso de heap altos (A, B) podem ser perfeitamente normais enquanto os usuários estão satisfeitos — são causas que merecem um dashboard ou um ticket, não um acionamento. Um deploy (D) é um evento a ser anotado nos dashboards, não um alerta.