Observabilidade: Logs, Métricas e Tracing com OpenTelemetry

radio_button_uncheckedshort_textApresentação do capítulo

Os capítulos anteriores mostraram que uma transação de API pode atravessar DNS, balanceadores, gateways, service meshes, serviços, bancos e sistemas de mensageria. Quando algo falha, nenhum componente isolado enxerga toda a jornada. Observabilidade é a disciplina que transforma sinais emitidos por esses componentes em capacidade de compreender o estado interno do sistema, reconstruir causalidade e avaliar impacto para consumidores e processos de negócio.

Logs, métricas e tracing distribuído são frequentemente chamados de pilares da observabilidade. A expressão é útil, mas pode induzir a uma interpretação fragmentada. O valor não está em armazenar três tipos de dados em ferramentas diferentes; está em correlacioná-los por identidade de serviço, ambiente, versão, requisição, trace e contexto de negócio. Uma métrica indica que a latência aumentou, um trace localiza a etapa responsável e um log explica o erro específico.

OpenTelemetry fornece APIs, SDKs, convenções semânticas, protocolos e um Collector agnóstico de fornecedor para produzir, processar e exportar telemetria. Ele não substitui o backend de observabilidade. Seu papel é padronizar instrumentação e transporte, reduzindo dependência de agentes proprietários e permitindo que sinais consistentes sejam enviados a diferentes destinos.

Este capítulo aprofunda a teoria de observabilidade, o desenho de logs e métricas, a anatomia de traces e spans, propagação de contexto, OTLP, Collector, semantic conventions, sampling, exemplars, SLOs, segurança, controle de cardinalidade e troubleshooting. O foco permanece em APIs corporativas, gateways e arquiteturas distribuídas.

Como estudar este capítulo

Escolha uma única jornada de negócio - por exemplo, criar pagamento - e acompanhe como ela aparece nos três sinais. Pergunte qual identidade descreve o serviço, como o contexto atravessa cada salto, quais atributos são estáveis e como o diagnóstico mudaria se um dos sinais estivesse ausente.

Objetivos de aprendizagem

• Diferenciar monitoramento, telemetria, observabilidade, diagnóstico e auditoria.
• Projetar logs estruturados, métricas úteis e traces distribuídos com contexto consistente.
• Explicar trace, span, span context, resource, event, link, status e baggage.
• Compreender W3C Trace Context, traceparent, tracestate e propagação entre protocolos.
• Descrever APIs, SDKs, auto-instrumentação, OTLP e OpenTelemetry Collector.
• Aplicar semantic conventions e controlar atributos de alta cardinalidade.
• Comparar head sampling, parent-based sampling e tail sampling.
• Relacionar exemplars, logs e traces a métricas e SLOs.
• Desenhar pipelines resilientes, seguros e economicamente sustentáveis.
• Diagnosticar falhas de instrumentação e lacunas de correlação em API Gateways e microsserviços.

Estrutura do capítulo

• 32.1 Observabilidade, monitoramento e telemetria
• 32.2 Sinais e correlação
• 32.3 Logs estruturados
• 32.4 Métricas e cardinalidade
• 32.5 Tracing distribuído e spans
• 32.6 Propagação de contexto e baggage
• 32.7 OpenTelemetry: API, SDK e instrumentação
• 32.8 OTLP e OpenTelemetry Collector
• 32.9 Semantic conventions e Resources
• 32.10 Sampling e exemplars
• 32.11 SLI, SLO, alertas e dashboards
• 32.12 Observabilidade em gateways, Kubernetes e mensageria
• 32.13 Segurança, privacidade, custos e troubleshooting
• Resumo, checklist, laboratórios, exercícios, glossário e referências

radio_button_uncheckedshort_text32.1 Observabilidade, monitoramento e telemetria

Telemetria é o conjunto de dados emitidos pelo sistema: registros de eventos, medições, traces, perfis e outros sinais. Monitoramento utiliza parte desses dados para acompanhar condições conhecidas, comparar valores com limites e disparar alertas. Observabilidade é uma propriedade mais ampla: a capacidade de inferir o estado interno e responder perguntas novas a partir dos sinais externos disponíveis.

Um sistema pode estar intensamente monitorado e ainda ser pouco observável. Dezenas de painéis de CPU, memória e disponibilidade não explicam por que somente consumidores de uma região recebem 502 ao consultar um backend específico. A observabilidade exige contexto, correlação, granularidade adequada e uma arquitetura de dados que permita navegar do sintoma agregado até a evidência individual.

Auditoria possui objetivo diferente. Um log de auditoria registra ações relevantes para segurança e conformidade, preservando autoria, integridade e retenção. Ele pode participar de investigações, mas não deve ser confundido com log de diagnóstico. Misturar os dois usos leva a excesso de dados sensíveis em ferramentas operacionais ou a trilhas de auditoria incompletas.

radio_button_uncheckedshort_text32.2 Logs, métricas e traces como sinais correlacionados

Logs registram eventos discretos com contexto detalhado. Métricas representam medições agregadas e são eficientes para tendências, alertas e capacidade. Traces representam o caminho causal de uma operação através de processos e serviços. Cada sinal possui custos, modelos de consulta e granularidades distintas; nenhum deles é suficiente para todos os diagnósticos.

A correlação depende de atributos comuns. Resource identifica a entidade que produziu a telemetria, como serviço, instância, pod, cluster e ambiente. Trace ID e Span ID conectam logs a uma execução específica. Atributos semânticos padronizam conceitos como método HTTP, rota, sistema de mensageria, banco de dados e código de erro. Sem consistência, painéis e consultas viram conjuntos de exceções por equipe.

OpenTelemetry também trata baggage e profiles como sinais ou mecanismos adjacentes. Baggage propaga pares chave-valor pelo contexto distribuído; profiles registram uso de recursos em nível de código e estão evoluindo no ecossistema. Neste capítulo, o foco permanece nos três sinais mais presentes em APIs, sem ignorar que a arquitetura moderna pode correlacioná-los a outros dados.

radio_button_uncheckedshort_text32.3 Logs estruturados e eventos operacionais

Um log estruturado representa o evento como campos tipados ou pares chave-valor, normalmente serializados em JSON ou no formato nativo do agente. Em vez de escrever apenas "falha no pagamento", o registro inclui timestamp, severidade, serviço, ambiente, versão, operação, código de erro, trace_id, span_id e identificadores de negócio permitidos. Essa estrutura melhora filtragem, agregação e correlação automática.

Severidade deve refletir a capacidade de ação. DEBUG e TRACE ajudam em ambientes controlados; INFO registra eventos operacionais relevantes; WARN indica degradação ou condição inesperada que não interrompeu a operação; ERROR registra falha de uma ação; FATAL ou equivalente indica incapacidade de continuar. Registrar toda exceção como ERROR cria ruído e destrói o valor do alerta.

Logs precisam evitar dados pessoais, tokens, cookies, segredos, payloads completos e números financeiros desnecessários. Mascaramento posterior não é defesa suficiente, porque o dado já pode ter sido transportado ou persistido. O desenho correto começa na origem, com allowlist de campos, classificação de dados, retenção proporcional e acesso restrito.

Exemplo de evento estruturado e correlacionável

{
  "timestamp": "2026-07-16T11:42:31.052Z",
  "severity": "ERROR",
  "service.name": "pagamentos-api",
  "deployment.environment.name": "producao",
  "http.route": "/pagamentos/{id}/confirmacao",
  "error.type": "BackendTimeout",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7"
}

radio_button_uncheckedshort_text32.4 Métricas, instrumentos, agregações e cardinalidade

Métricas representam observações numéricas agregadas no tempo. Contadores acumulam eventos, como requests e erros. Histograms distribuem valores, como duração e tamanho de payload, em faixas ou representações adequadas ao backend. Gauges registram um valor atual, como conexões abertas ou profundidade de fila. UpDownCounters representam quantidades que aumentam e diminuem.

A escolha do instrumento define como a medição pode ser agregada. Uma duração de request não deve ser registrada apenas como média, porque a média esconde caudas. Histograms permitem consultar percentis e distribuição. Ainda assim, percentis agregados de forma incorreta podem produzir conclusões erradas; é necessário compreender o modelo do backend e a janela temporal.

Cardinalidade é o número de combinações distintas de atributos. Adicionar user_id, order_id, URL completa ou trace_id como label de métrica cria séries quase ilimitadas, aumenta memória e custo e pode derrubar o pipeline. Métricas devem usar dimensões limitadas e estáveis, como rota normalizada, método, status class, região e versão. A evidência individual permanece em logs ou traces.

Regra de cardinalidade

Atributos de métricas devem responder perguntas agregadas. Identificadores praticamente únicos pertencem a logs e traces. Antes de adicionar uma dimensão, estime quantos valores diferentes ela pode assumir por ambiente, serviço e janela de retenção.

radio_button_uncheckedshort_text32.5 Tracing distribuído, traces e spans

Um trace representa uma operação distribuída, como uma chamada de API que atravessa gateway, serviço, mensageria e banco. Cada etapa é representada por um span, com nome, intervalo de tempo, contexto, atributos, eventos, status e relações com outros spans. A estrutura permite observar latência total, caminho crítico e dependências acionadas.

SpanKind descreve o papel do span, como SERVER, CLIENT, PRODUCER, CONSUMER ou INTERNAL. A classificação ajuda a compreender fronteiras e a calcular métricas a partir de traces. Events registram ocorrências pontuais dentro do span, como uma exceção. Links relacionam spans que não possuem uma única hierarquia pai-filho, situação comum em processamento assíncrono e fan-out.

O nome do span deve possuir baixa cardinalidade e refletir a operação, não o identificador concreto. Em HTTP, uma rota normalizada é preferível à URL completa. Em mensageria, o nome do destino e a operação ajudam a reconstruir produção e consumo. O trace não deve ser transformado em armazenamento indiscriminado de payloads; atributos e eventos obedecem às mesmas regras de privacidade dos logs.

radio_button_uncheckedshort_text32.6 Propagação de contexto, W3C Trace Context e Baggage

Para que spans de processos diferentes pertençam ao mesmo trace, o contexto precisa atravessar a fronteira de rede. O W3C Trace Context padroniza os headers traceparent e tracestate para HTTP. traceparent carrega versão, trace ID, parent ID e flags. tracestate transporta informações específicas de fornecedores de maneira interoperável. Instrumentações devem extrair o contexto recebido e injetá-lo nas chamadas de saída.

Em gRPC, mensageria e protocolos proprietários, o mesmo princípio é aplicado por metadata ou propriedades de mensagem. A propagação deve respeitar fronteiras de confiança: aceitar IDs externos sem validação ou copiar todo baggage para sistemas internos pode introduzir abuso, vazamento e aumento de payload.

Baggage carrega contexto de aplicação em pares chave-valor. Ele não deve transportar segredo, dado pessoal ou informação de alta cardinalidade sem justificativa. Como pode atravessar muitos serviços, um pequeno campo é multiplicado por toda a jornada. Baggage também não substitui autorização; a aplicação não deve confiar em uma claim propagada apenas porque chegou no contexto.

Exemplo conceitual de contexto distribuído

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
tracestate: vendorname=opaque-value
baggage: tenant.tier=premium,region.origin=br-south

radio_button_uncheckedshort_text32.7 OpenTelemetry: API, SDK e instrumentação

OpenTelemetry separa API e SDK. A API é usada por bibliotecas e aplicações para criar instrumentos sem depender de uma implementação específica. O SDK implementa sampling, processamento, agregação e exportação. Essa separação permite que uma biblioteca seja instrumentada sem obrigar o consumidor a enviar dados para um fornecedor determinado.

Instrumentação manual é adequada para operações de negócio e trechos que a instrumentação genérica não compreende. Auto-instrumentação utiliza agentes, bytecode, monkey patching, eBPF ou mecanismos equivalentes para capturar frameworks e bibliotecas com pouca alteração de código. A combinação costuma ser superior: automática para cobertura de infraestrutura e manual para semântica de negócio.

Instrumentar não significa gerar o máximo de dados possível. Cada span, atributo, log e série possui custo. A equipe deve definir uma estratégia de telemetria: quais jornadas são críticas, quais atributos são necessários, quais convenções estão estáveis, quais sinais serão derivados e como a instrumentação será testada junto ao código.

radio_button_uncheckedshort_text32.8 OTLP e OpenTelemetry Collector

OTLP é o protocolo nativo do OpenTelemetry para transportar telemetria. Ele pode operar sobre gRPC ou HTTP e possui modelos para traces, métricas e logs. O protocolo reduz a necessidade de formatos diferentes por fornecedor, mas não elimina decisões de rede, autenticação, compressão, fila, retry e proteção contra perda.

O OpenTelemetry Collector recebe, processa e exporta telemetria. Receivers aceitam OTLP e outros formatos. Processors aplicam batch, filtragem, transformação, enriquecimento, sampling e proteção de memória. Exporters enviam dados a backends. Extensions fornecem capacidades auxiliares, como health checks e autenticação. As pipelines são declaradas por sinal.

O Collector pode ser implantado como agent próximo da aplicação, gateway central por cluster ou região, ou combinação em camadas. O padrão agent reduz saltos e coleta dados locais; o padrão gateway centraliza processamento e credenciais de backend. O desenho deve considerar disponibilidade, filas persistentes, isolamento por tenant, escalabilidade e risco de tornar o Collector um ponto único de falha.

Exemplo resumido de pipeline do Collector

receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}
processors:
  memory_limiter:
    limit_mib: 1024
  batch: {}
exporters:
  otlp/backend:
    endpoint: observabilidade.internal:4317
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/backend]

radio_button_uncheckedshort_text32.9 Semantic conventions, Resource e governança de atributos

Semantic conventions definem nomes, tipos e significados comuns para atributos, span names, métricas e unidades. Sem essas convenções, cada equipe poderia registrar método HTTP como method, httpMethod ou verb, inviabilizando dashboards corporativos. A padronização permite consultar serviços escritos em linguagens diferentes com a mesma lógica.

Resource descreve a entidade que produziu a telemetria. Atributos como service.name, service.version, deployment.environment.name, host, container e Kubernetes ajudam a localizar a origem. Resource não deve ser confundido com atributos da operação: service.name descreve o emissor; http.route descreve o request.

Nem todas as semantic conventions possuem o mesmo nível de estabilidade. A governança deve registrar a versão adotada, acompanhar mudanças experimentais e impedir renomeações silenciosas. OTel Weaver e ferramentas de schema podem ajudar organizações a validar contratos de telemetria, mas a disciplina começa com um catálogo claro de atributos permitidos.

radio_button_uncheckedshort_text32.10 Sampling, perda controlada e preservação de traces úteis

Sampling reduz volume de traces. Head sampling decide no início, usando probabilidade, parent context ou regras locais. É barato e rápido, mas não conhece o resultado final. Um erro raro pode ser descartado antes de acontecer. Parent-based sampling ajuda a manter coerência entre spans filhos e a decisão do trace.

Tail sampling decide após reunir spans suficientes no Collector ou backend. Ele pode preservar traces com erro, alta latência ou atributos específicos. Em contrapartida, exige memória, espera, roteamento consistente de spans do mesmo trace e planejamento de capacidade. Uma implantação distribuída sem afinidade por trace pode tomar decisões incompletas.

A política deve refletir objetivos: manter 100% de erros, traces acima do SLO, amostras representativas por rota e pequena porcentagem do tráfego saudável. Sampling não corrige telemetria mal desenhada. Mesmo traces descartados podem contribuir para métricas derivadas, dependendo do ponto em que a agregação ocorre.

radio_button_uncheckedshort_text32.11 Exemplars e correlação entre métricas, logs e traces

Exemplar associa uma observação de métrica a um trace ou contexto representativo. Ao observar um bucket de alta latência, o operador pode abrir um trace real que contribuiu para aquele valor. Essa navegação reduz o salto entre visão agregada e evidência individual, especialmente em incidentes de cauda de latência.

Logs também podem carregar trace_id e span_id. A correlação ideal permite navegar de um alerta para a série, da série para um exemplar, do exemplar para o trace e do span para logs da mesma execução. Essa experiência depende de instrumentação consistente, sincronização de tempo, retenção compatível e integração entre backends.

A correlação não deve ser usada para copiar todos os dados para todos os sinais. Métricas continuam agregadas; traces continuam seletivos; logs continuam eventos. O objetivo é manter chaves de navegação e semântica comum, preservando as vantagens econômicas e operacionais de cada modelo.

radio_button_uncheckedshort_text32.12 SLI, SLO, orçamento de erro e alertas

SLI é uma medição do comportamento observado, como proporção de requests válidos concluídos com sucesso abaixo de um limite de latência. SLO define o alvo para uma janela, por exemplo 99,9% em 30 dias. O orçamento de erro representa a quantidade de falhas tolerada antes de ultrapassar o objetivo. Essa abordagem conecta telemetria à expectativa do usuário.

Alertas baseados apenas em infraestrutura produzem muitos falsos positivos e falsos negativos. CPU alta pode ser normal; CPU baixa pode coexistir com indisponibilidade completa por erro de DNS. Alertas de burn rate observam quão rapidamente o orçamento de erro é consumido e podem combinar janelas curta e longa para equilibrar velocidade e estabilidade.

Dashboards devem seguir perguntas operacionais. Para APIs, as golden signals - latência, tráfego, erros e saturação - são um bom ponto de partida. Contudo, a rota, o consumidor, a região, a versão e o backend precisam ser dimensões controladas. Painéis sem owner, SLO e ação associada viram decoração.

radio_button_uncheckedshort_text32.13 Observabilidade em API Gateways, Kubernetes e mensageria

O API Gateway deve registrar a visão de borda e a visão de upstream separadamente. Duração total, tempo até o backend, status produzido pelo gateway, status do upstream, política que falhou, rota, consumidor e trace context são evidências diferentes. Um 502 precisa indicar se houve falha de DNS, connect timeout, TLS, reset ou resposta inválida do backend.

Em Kubernetes, Resources e atributos de infraestrutura conectam o serviço lógico a cluster, namespace, workload, pod, container e nó. O Collector pode enriquecer telemetria com metadados do ambiente. O desenho precisa tolerar pods efêmeros, rollouts e mudanças de IP sem tratar a instância como identidade permanente.

Em mensageria, causalidade pode não formar uma árvore simples. Produção, armazenamento, consumo, retries e DLQ ocorrem em tempos diferentes. Links e atributos semânticos ajudam a relacionar mensagens. Métricas de lag, idade da mensagem, taxa de redelivery e profundidade de fila complementam traces, mas precisam ser interpretadas dentro da semântica do broker.

radio_button_uncheckedshort_text32.14 Segurança, privacidade e integridade da telemetria

Telemetria é um ativo sensível. Ela pode revelar topologia interna, nomes de serviços, versões, falhas, identificadores de usuários e decisões de segurança. O pipeline deve usar autenticação, criptografia em trânsito, segregação por tenant, controles de acesso, retenção e trilha de administração. Coletores não devem aceitar dados de qualquer origem sem validação.

A propagação de trace context atravessa fronteiras externas e precisa de política. IDs recebidos podem ser aceitos, regenerados ou relacionados por links conforme o risco e a necessidade de correlação. Baggage deve ser filtrado. Logs de autenticação precisam evitar tokens e credenciais; atributos de SQL ou HTTP não devem registrar valores sensíveis por padrão.

Integridade também importa. Um invasor pode tentar esconder atividade reduzindo telemetria, inundar o pipeline ou injetar campos enganosos. Limites, autenticação mútua, validação de schema, monitoramento do próprio Collector e armazenamento imutável para auditoria reduzem esse risco.

Telemetria não é área livre de LGPD

Dados observacionais continuam sujeitos a finalidade, minimização, retenção, acesso e segurança. Um trace ID pode não identificar uma pessoa sozinho, mas logs e baggage frequentemente carregam contexto que torna a correlação possível.

radio_button_uncheckedshort_text32.15 Custos, retenção, cardinalidade e capacidade do pipeline

Observabilidade possui custo de CPU, memória, rede, armazenamento, indexação e consulta. O custo nasce na instrumentação e se multiplica por volume, cardinalidade e retenção. Uma aplicação que adiciona cinco atributos de alta cardinalidade pode aumentar séries e índices muito mais do que o crescimento de tráfego sugere.

A estratégia deve definir tiers de retenção, sampling, compactação, agregação e roteamento por sinal. Logs de debug podem permanecer poucos dias; métricas agregadas podem ter retenção longa; traces completos podem ser amostrados; auditoria segue política própria. O Collector permite filtrar, transformar e encaminhar dados para destinos diferentes antes de pagar o custo integral no backend.

O pipeline também precisa de SLO. Filas internas, dropped spans, export failures, recusas por memória, tempo de processamento e uso de CPU do Collector devem ser monitorados. Uma plataforma de observabilidade que perde dados silenciosamente pode levar equipes a conclusões incorretas durante incidentes.

radio_button_uncheckedshort_text32.16 Troubleshooting de observabilidade

Quando um trace está quebrado, verifique primeiro a propagação. O cliente injetou traceparent? O gateway preservou ou recriou o contexto? A biblioteca do serviço extraiu o header? Chamadas assíncronas carregaram o contexto correto? Uma falha em qualquer salto cria traces separados, mesmo que todos os componentes estejam instrumentados.

Quando métricas desaparecem, investigue o instrumento, views, temporality, export interval, filtros e cardinalidade. Em logs, verifique parsing, timestamp, multiline, encoding e mapeamento de severity. No Collector, examine health, filas, memory limiter, batch, retries e erros dos exporters. O próprio pipeline precisa emitir telemetria para ser diagnosticado.

Diferenças de horário produzem spans com ordem impossível e logs fora da janela. Sincronização de relógio é requisito básico. Também é comum que nomes de serviço vazios ou inconsistentes agrupem aplicações diferentes no backend. Uma checklist de Resource e semantic conventions deve fazer parte do deploy.

radio_button_uncheckedshort_text32.17 Estudos de caso e laboratórios

Estudo de caso 1: consumidores recebem intermitentemente 504 em uma API bancária. A métrica de latência mostra aumento apenas em uma rota. Um exemplar abre um trace cujo span do gateway consome pouco tempo, mas o span do backend permanece próximo ao timeout. Os logs do mesmo trace indicam pool de conexões esgotado. A correlação evita alterar policies do gateway sem necessidade.

Estudo de caso 2: após um rollout, o custo de métricas aumenta dez vezes. A investigação mostra que uma nova versão adicionou customer_id como atributo de histogram. A correção remove o identificador da métrica e o preserva apenas em spans amostrados e logs autorizados. O incidente demonstra por que telemetria precisa de revisão de contrato.

Estudo de caso 3: mensagens Kafka aparecem como traces separados do request original. O produtor criou spans, mas não injetou contexto nos headers da mensagem. Após corrigir a propagação e usar links no consumidor quando apropriado, a plataforma passa a reconstruir a jornada assíncrona sem forçar uma hierarquia incorreta.

Laboratórios sugeridos

1) Instrumente uma API com auto-instrumentação e um span manual de negócio. 2) Propague traceparent pelo gateway e confirme a continuidade do trace. 3) Configure um Collector com receiver OTLP, memory_limiter, batch e dois exporters. 4) Crie uma métrica com baixa cardinalidade e associe exemplars. 5) Simule erro, timeout e mensagem assíncrona e compare os três sinais.

radio_button_uncheckedshort_textResumo do capítulo

Observabilidade é a capacidade de explicar o comportamento interno de sistemas a partir de sinais externos. Logs, métricas e traces possuem modelos diferentes e devem ser correlacionados por Resource, contexto distribuído e convenções semânticas. A qualidade da correlação é mais importante que a quantidade de dados.

OpenTelemetry separa APIs, SDKs, instrumentações, protocolo OTLP e Collector. Essa arquitetura permite instrumentação agnóstica de fornecedor, processamento centralizado e exportação para múltiplos backends. O Collector, porém, precisa ser projetado como componente crítico, com capacidade, filas, segurança e telemetria própria.

Sampling, exemplars, SLOs e alertas transformam sinais em decisões. Cardinalidade, privacidade e custo precisam ser tratados desde o design. Em gateways, Kubernetes e mensageria, cada camada produz evidências específicas, mas a jornada completa só aparece quando contexto e semântica atravessam todas as fronteiras.

Próximo passo do curso

O próximo capítulo aprofunda Kubernetes para APIs, conectando workloads, Services, Ingress/Gateway API, probes, autoscaling, segurança e operação às práticas de observabilidade apresentadas aqui.

radio_button_uncheckedshort_textChecklist de observabilidade

• Cada serviço define service.name, versão, ambiente e ownership de forma consistente.
• Logs são estruturados, correlacionáveis e não contêm segredos ou dados pessoais desnecessários.
• Métricas usam instrumentos corretos e atributos de baixa cardinalidade.
• Spans descrevem operações estáveis, dependências, erros e tempo sem copiar payloads completos.
• Trace context é propagado em HTTP, gRPC e mensageria, respeitando fronteiras de confiança.
• Semantic conventions e sua estabilidade são governadas como contrato.
• Sampling preserva erros, latência elevada e representatividade do tráfego saudável.
• Collector possui memory limiter, batch, filas, retries, health checks e telemetria interna.
• Dashboards e alertas estão ligados a SLIs, SLOs, owners e ações conhecidas.
• Custos, retenção, cardinalidade e privacidade são revisados antes da produção.

radio_button_uncheckedshort_textExercícios

• Diferencie telemetria, monitoramento, observabilidade e auditoria.
• Explique por que trace_id é inadequado como label de métrica.
• Descreva Resource, span, event, link, status e baggage.
• Explique traceparent e tracestate em uma chamada HTTP distribuída.
• Compare instrumentação manual e auto-instrumentação.
• Desenhe uma pipeline do Collector com receivers, processors e exporters.
• Compare head sampling e tail sampling.
• Explique como exemplars conectam métricas e traces.
• Proponha um SLI de disponibilidade e outro de latência para uma API.
• Liste controles para impedir exposição de tokens e PII na telemetria.
• Descreva como diagnosticar um trace interrompido entre gateway e backend.
• Proponha um laboratório para correlacionar request HTTP, mensagem e processamento assíncrono.

radio_button_uncheckedshort_textGlossário

radio_button_uncheckedshort_textReferências técnicas

• OpenTelemetry. What is OpenTelemetry? e Observability Primer.
• OpenTelemetry. Concepts: Signals, Traces, Metrics, Logs, Baggage e Context Propagation.
• OpenTelemetry Specification. Overview, Tracing, Metrics e Logs.
• OpenTelemetry Semantic Conventions.
• OpenTelemetry Collector: Architecture, Configuration, Deployment Patterns e Scaling.
• W3C. Trace Context Level 2.
• W3C. Baggage.
• Google SRE. Service Level Objectives e Error Budgets.
• CNCF. OpenTelemetry project documentation.

Nota de atualização

OpenTelemetry evolui sinal por sinal, e semantic conventions podem estar estáveis ou experimentais. Antes de padronizar atributos, exporters ou configuração declarativa, valide o status da versão adotada e teste migrações em ambiente controlado.