Propagação de Contexto Entre Serviços

O serviço A chama o serviço B via HTTP. Como B sabe que a requisição pertence a um trace já existente? O que realmente trafega na rede?

Perguntas de Pleno

Observabilityintermediate

// pergunta de entrevista

O serviço A chama o serviço B via HTTP. Como B sabe que a requisição pertence a um trace já existente? O que realmente trafega na rede?

Resposta de exemplo

Um único header HTTP chamado traceparent, definido pela especificação W3C Trace Context. Ele se parece com 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01: versão, o trace ID de 128 bits, o span ID do pai e flags como o bit de sampled. No lado de quem envia, o propagator do SDK do OpenTelemetry injeta esse header na requisição de saída. No lado de quem recebe, a instrumentação de B o extrai, então o span de servidor que B cria usa o mesmo trace ID e aponta para o span de A como seu pai. Também existe um header opcional de baggage para passar seus próprios pares chave-valor entre serviços, como um tenant ID. Os lugares onde isso quebra são a parte interessante: trabalho assíncrono que dispara uma thread ou goroutine sem carregar o contexto junto, filas de mensagens onde você precisa injetar o contexto nos headers da mensagem manualmente, e proxies ou serviços legados que removem ou descartam headers desconhecidos. Ambientes mistos são outra armadilha: sistemas mais antigos usam os headers B3 do Zipkin, então durante uma migração você roda um propagator composto que lê e escreve nos dois formatos. O sintoma de uma propagação quebrada é sempre o mesmo: traces que cortam numa fronteira de serviço, com o trabalho downstream aparecendo como spans raiz órfãos.

Por que isso importa

A propagação é onde a teoria de tracing encontra a realidade. Qualquer um pode dizer 'o trace ID flui entre os serviços', mas candidatos que já rodaram tracing em produção conhecem o header traceparent pelo nome e já depuraram traces quebrados causados por um proxy que removeu headers ou um consumidor de fila que começou traces do zero. Preste atenção nos modos de falha: fronteiras assíncronas, filas de mensagens, B3 versus W3C. Um candidato que só descreve o caminho feliz provavelmente nunca precisou consertar um trace que apagou pela metade.

Exemplos de código

Como o header traceparent aparece na rede

bash

GET /api/orders/42 HTTP/1.1
Host: service-b.internal
traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
baggage: tenant.id=acme,deployment.canary=true

# Format: version-traceId-parentSpanId-flags
# The last byte (01) means this trace was sampled upstream

Injetando contexto manualmente numa mensagem de fila

python

from opentelemetry.propagate import inject, extract
from opentelemetry import trace

# Producer: HTTP auto-instrumentation will not help here,
# you have to carry the context inside the message yourself
headers = {}
inject(headers)
queue.publish(body=payload, headers=headers)

# Consumer: restore the context so the span joins the trace
ctx = extract(message.headers)
tracer = trace.get_tracer("order-consumer")
with tracer.start_as_current_span("process_message", context=ctx):
    handle(message)

Propagator composto para uma migração de B3 para W3C

python

from opentelemetry import propagate
from opentelemetry.propagators.composite import CompositePropagator
from opentelemetry.propagators.b3 import B3MultiFormat
from opentelemetry.trace.propagation.tracecontext import (
    TraceContextTextMapPropagator,
)

# Accept and emit both header formats while old Zipkin-era
# services are still in the call path
propagate.set_global_textmap(
    CompositePropagator([TraceContextTextMapPropagator(), B3MultiFormat()])
)

Erros comuns a evitar

Acreditar que o backend costura os traces por timestamps ou endereços IP em vez de um header explícito carregado junto com a requisição
Esquecer que filas, handoffs por cron e jobs em background precisam de injeção manual de contexto porque não existe requisição HTTP para carregar o header
Colocar dados sensíveis ou volumosos no baggage sem perceber que eles são encaminhados para todos os serviços downstream em cada chamada

Prováveis perguntas de acompanhamento

Um trace sempre termina em um serviço específico e os spans downstream aparecem como traces raiz separados. Como você depuraria isso?
Como você propagaria contexto através do Kafka, onde não existe uma requisição HTTP entre produtor e consumidor?
Para que serve o baggage, e qual é o risco de colocar dados demais nele?

Responda em voz alta primeiro e depois confira com a resposta modelo.

Praticar todas as perguntas de Pleno Mais perguntas de Observability

#opentelemetry#distributed-tracing#context-propagation#w3c-trace-context

Mais perguntas de entrevista de Observability

Also worth your time on this topic

Checklist

Distributed Tracing com OpenTelemetry: da Instrumentação à Visualização

Um checklist prático para adicionar tracing com OpenTelemetry aos seus serviços, enviar spans através do Collector e transformar esses dados em algo que você realmente consegue usar para debugar.

90-150 minutos

Interview

Traces e Spans Explicados

Uma requisição chega ao seu API gateway, que chama dois serviços de backend, e um desses serviços consulta um banco de dados. Me explique como isso fica representado como um trace distribuído. O que é um span, e como os spans se conectam entre si?

junior

Exercise

Observabilidade de Microsserviços com OpenTelemetry

Implemente uma observabilidade abrangente para microsserviços usando o OpenTelemetry para tracing distribuído, métricas e logging em múltiplos serviços.

140 minutos