Telemetria sem mistério: Prometheus, Loki, Tempo e Grafana, e por que OpenTelemetry

É segunda-feira, nove da manhã, e as transferências de um banco levam o triplo do tempo normal. Chegam as reclamações, abre-se um incidente e cinco equipes se sentam na mesma chamada: canais digitais, o sistema central, antifraude, redes e infraestrutura. Cada uma examina a própria tela e cada uma chega à mesma conclusão: «do nosso lado está tudo bem». Passam-se duas horas até que alguém perceba que a lentidão estava na consulta de um único serviço.

Esse cenário, ilustrativo e sem cliente por trás, não fala de uma equipe ruim. Fala de um sistema do qual ninguém consegue ver o percurso completo de uma operação. A telemetria é a resposta a esse problema: os dados que um sistema emite sobre si mesmo enquanto trabalha, para que possa ser entendido de fora, sem abri-lo e sem adivinhar. Este artigo é para quem responde por esses sistemas em um banco, uma fintech, uma seguradora, uma rede de varejo ou uma empresa regulada, e também para o diretor de negócio que quer entender o que lhe estão pedindo quando a equipe técnica diz «precisamos de observabilidade».

Falaremos de quatro ferramentas abertas muito usadas —Prometheus, Loki, Tempo e Grafana— e de um padrão, OpenTelemetry, que as une. Explicaremos o que cada uma responde, como se cruzam entre si, por que convém um padrão comum, como são montadas em contêineres e em Kubernetes, quando basta ler os logs e quando é preciso instrumentar o software por dentro, e o que tudo isso custa e que riscos traz.

Três sinais para três perguntas diferentes

Um sistema em produção pode contar a própria história de três maneiras, e cada uma responde a uma pergunta diferente. Este artigo se concentra nos três sinais operacionais mais comuns, que o OpenTelemetry chama de sinais [2]: métricas, traces e logs.

• Métricas: o que está acontecendo, e quanto? Uma métrica é uma medição capturada enquanto o sistema roda: quantas transferências por minuto, quanto levaram 95 % delas, quantas falharam. É um número no tempo, barato de guardar e excelente para ver uma tendência ou disparar um alerta. Não diz qual operação falhou.
• Traces: por onde passou esta operação e onde ela parou? Um trace é o percurso completo de uma requisição por todos os serviços que tocou, com o tempo que passou em cada um [2]. É o mapa de uma única operação. Cada trecho desse mapa se chama span.
• Logs: o que o sistema disse naquele momento? Um log é o registro de um evento: uma linha de texto ou de dados com a data, a gravidade e a mensagem. É o detalhe fino: «esgotou-se o tempo de espera do pool de conexões».

Nenhum dos três basta sozinho. A métrica avisa, mas não localiza; o trace localiza, mas não explica; o log explica, mas, sem contexto, é uma agulha no palheiro. A boa prática, e o fio condutor deste artigo, é usá-los em cadeia. Em uma instrumentação bem desenhada, a métrica costuma avisar, o trace costuma delimitar o percurso e os logs podem trazer o detalhe; a qualidade da resposta depende do que foi emitido e conservado.

O que cada ferramenta responde

Cada sinal tem uma ferramenta aberta pensada para guardá-lo e consultá-lo. Antes da tabela, um esclarecimento útil para um comitê: nenhuma destas ferramentas é intercambiável com outra. São armazenamentos especializados.

Duas precisões que poupam mal-entendidos. A primeira: o Prometheus não é uma caixa registradora. A própria documentação dele adverte que, se for preciso exatidão total, como no faturamento por requisição, ele não é uma boa opção [9]. Serve para operar —saber se o sistema está saudável—, não para conciliar. Em um banco ou em uma fintech essa fronteira importa: a conciliação vive nos registros contábeis, não em um painel de latência.

A segunda: o Loki é barato justamente porque não indexa o conteúdo dos logs, somente alguns poucos rótulos por fluxo (de qual serviço e de qual ambiente vem). Os dados são comprimidos em blocos e guardados em armazenamento de objetos [15]. A contrapartida é que buscar texto dentro dos logs é feito no momento da consulta, não com um índice prévio, e que os rótulos precisam ser escolhidos com cuidado. Voltaremos a isso nos custos.

O papel do Grafana

O Grafana é a janela. Segundo a documentação, permite consultar, visualizar, alertar e explorar métricas, logs e traces, não importa onde estejam armazenados [19]. Cada armazenamento é conectado como uma fonte de dados: Prometheus, Loki e Tempo são três fontes, e o Grafana pode ter outras ao lado, como bancos de dados SQL [20].

O valor dele não está no painel bonito, e sim em que cruza as fontes. De um mesmo lugar é possível ir de um gráfico a um trace e de um trace aos logs correspondentes. Para um diretor, isso se traduz em algo concreto: o Grafana pode concentrar a investigação em uma só visão se fontes, permissões e links forem configurados, em vez de cinco telas e uma chamada.

Como a informação se cruza

Que os três sinais existam não significa que estejam conectados. A conexão não aparece por instalar o Grafana: é projetada a partir do momento em que o software é instrumentado e testada de ponta a ponta. O fio condutor é um identificador, o trace_id, que viaja com cada operação. O padrão de propagação que o OpenTelemetry usa por padrão, o W3C Trace Context, leva esse identificador em um cabeçalho chamado traceparent de um serviço ao seguinte [2].

Imagine o trace_id como o código de rastreio de uma encomenda. Se cada serviço o carimba no que produz, depois é possível pedir «tudo o que aconteceu com o código 4F2A…».

Da métrica ao trace: os exemplars

Um exemplar é uma amostra concreta colada a uma métrica agregada. Pense em um gráfico de latência: cada ponto resume milhares de operações. Um exemplar é, nesse ponto, o exemplo de uma operação real —com o trace_id dela— que contribuiu para essa medição. No Grafana aparece como uma estrela sobre o gráfico; ao clicar, abre-se no Tempo o trace dessa operação [20].

Para que o clique do gráfico ao trace funcione, quatro peças precisam estar ativadas; se faltar uma, o clique não leva a lugar nenhum. A documentação do Grafana resume assim: as métricas dão a visão agregada e os traces, a visão fina de uma requisição [20]. Convém conhecer as condições antes de prometer isso a alguém:

1. A aplicação precisa emitir o trace_id junto com a medição, dentro de um trace que esteja sendo conservado.
2. O Prometheus precisa armazenar os exemplars. Hoje essa capacidade é ativada por uma flag marcada como experimental e vem desativada por padrão [12].
3. No Grafana é preciso configurar a fonte Prometheus para que o link aponte para o Tempo e diga qual campo traz o trace_id [20].
4. O trace referido precisa ainda existir: se a amostragem ou a retenção já o descartaram, o clique não leva a lugar nenhum.

Um caminho alternativo é o Tempo calcular métricas a partir dos traces —taxa de requisições, erros e duração, o conhecido trio RED (Rate, Errors, Duration), as três medidas padrão com que se vigia um serviço— e enviá-las a um banco de dados compatível com o Prometheus, com os exemplars correspondentes [17]. Esse caminho deve ser testado contra os limites de séries ativas, tema que se retoma nos custos.

Do trace ao log: o `trace_id` em cada linha

A partir de um trace no Tempo, o Grafana pode abrir os logs desse serviço nessa janela de tempo, consultando o Loki. Isso se configura na fonte de dados do Tempo (trace to logs), e existe um link equivalente para as métricas (trace to metrics) [21]. Para correlacionar um log com o trace, inclua o trace_id; acrescente o span_id quando for preciso restringir a busca ao span que emitiu o log. O modelo de dados de logs do OpenTelemetry os prevê como campos próprios [40], e para formatos que não são OTLP recomenda chamá-los trace_id, span_id e trace_flags [41].

Do log ao trace

O caminho inverso é configurado no Loki com campos derivados (derived fields): uma regra que extrai o trace_id da linha e o converte em um link para o Tempo [47]. Os dois lados são necessários: configurar somente o Tempo não torna um log navegável até o trace correspondente.

Uma regra de ouro deste cruzamento: o trace_id, e em geral qualquer identificador de cliente, pedido, conta ou apólice, não deve ser um rótulo do Loki. Deve viajar dentro do conteúdo do log, ou como metadado estruturado. Mais adiante se explica por quê [14].

Por que OpenTelemetry e não cada tecnologia diretamente

As quatro ferramentas anteriores têm formas próprias de receber dados. Seria possível programar cada aplicação para falar diretamente com cada uma: uma biblioteca para métricas do Prometheus, outra para logs para o Loki e outra para traces para o Tempo. Funciona, mas prende o código de cada serviço a três modelos distintos, três estratégias de nova tentativa e três rotas de migração.

O OpenTelemetry (abrevia-se OTel) é um projeto da CNCF, a fundação que abriga o Kubernetes e o Prometheus. Define-se como um framework para gerar, exportar e coletar telemetria; é neutro em relação a fornecedores e, importante, não é um backend: não guarda nem desenha nada [1]. Traz quatro peças:

• APIs e SDK: bibliotecas por linguagem com as quais o software emite métricas, traces e logs com um modelo comum.
• OTLP: o protocolo comum para transportar os três sinais, sobre gRPC (porta 4317 por padrão) ou HTTP (4318) [4].
• Convenções semânticas: nomes padrão para o que se mede, de modo que «o serviço» ou «o pod» tenham o mesmo nome nos três sinais [46]. Sem esse acordo, o cruzamento entre ferramentas se rompe.
• Collector: um programa intermediário que recebe a telemetria, a enriquece, a filtra e a reenvia a um ou vários destinos [6].

A consequência prática: a aplicação emite uma só vez, em um idioma padrão, e as decisões sobre para onde vai, o que é filtrado e o que é ocultado vivem em uma configuração controlada, não espalhadas pelo código de cada equipe. Os próprios armazenamentos já falam esse idioma: Loki, Tempo e Alloy podem receber OTLP, e o Prometheus pode receber métricas OTLP quando --web.enable-otlp-receiver é habilitado explicitamente [13][16][18][26].

Para um diretor, o argumento é de portabilidade e controle. A documentação do OpenTelemetry o apresenta como não ficar preso a um fornecedor e aprender um único conjunto de convenções [1]. O OpenTelemetry reduz a dependência do código em relação ao destino, embora uma migração ainda possa exigir validar convenções, exportadores, amostragem, painéis, alertas e retenção; o destino muda no Collector.

Duas ressalvas de honestidade, porque esse tipo de promessa se infla facilmente:

• Portabilidade não é gratuita. Mesmo com o OpenTelemetry, os painéis, os alertas e as consultas escritas em PromQL, LogQL e TraceQL são reescritos se se troca de armazenamento. O que se economiza é a reinstrumentação do software, que costuma ser a parte mais cara.
• A maturidade varia por sinal e por linguagem. Segundo a especificação, traces, métricas e logs têm protocolo estável, mas o SDK de métricas consta como «misto» e os perfis seguem em desenvolvimento [3]. Por linguagem, Java tem os três sinais estáveis; Go, Python e JavaScript têm traces e métricas estáveis, enquanto os logs estão em candidato a versão final em Go e em desenvolvimento em Python e JavaScript [5]. Quem programa em Java parte de um terreno mais sólido; quem programa em outras linguagens deve verificar o estado dos logs antes de apostar neles.

Como referência de adoção, na pesquisa anual da CNCF de 2024, na pergunta sobre projetos incubados (n=689), 39 % relataram o OpenTelemetry em produção e 23 % em avaliação; é uma amostra da comunidade da CNCF, não uma participação de mercado [44].

Como se monta: contêineres e Kubernetes

A telemetria precisa de três coisas no caminho: quem a gere (o software), quem a colete e processe (o Collector ou um agente) e quem a guarde e mostre (Prometheus, Loki, Tempo, Grafana). Muda onde se coloca o coletor conforme a plataforma.

No Docker e no Docker Compose

O Compose declara vários serviços, redes e volumes em um único arquivo, e por isso é usado para desenvolvimento, testes integrados e ambientes pequenos [28]. A montagem típica é: as aplicações enviam OTLP a um contêiner com o Collector (ou Alloy); o Collector distribui os traces ao Tempo, os logs ao Loki e as métricas ao Prometheus; e o Grafana consulta os três. O Collector é executado como uma imagem oficial com o arquivo de configuração montado; sem esse arquivo, não inicia [28].

Há dois detalhes dos logs no Docker que costumam surpreender:

• O Docker captura por padrão a saída padrão e a saída de erro padrão. Se a aplicação escreve apenas em arquivos, o docker logs não mostrará essas linhas. Por isso as imagens oficiais de servidores web redirecionam os arquivos para a saída padrão [28].
• O driver padrão não rotaciona os logs. O driver json-file não tem limite de tamanho por padrão, e o Docker recomenda o driver local, que rotaciona por padrão (segundo o Docker, arquivos de 20 MB, até cinco) [28]. Um disco cheio por causa de logs é um incidente de operação real.

Além disso, o modo de entrega importa: no modo bloqueante, que é o padrão, um driver lento pode frear a aplicação; no modo não bloqueante usa-se um buffer e, se ele enche, mensagens são descartadas [28]. E com o driver do Fluentd em modo síncrono, se não há conexão o contêiner para [29]. É preciso escolher com intenção entre não perder logs e não frear o serviço.

No Kubernetes

O Kubernetes recomenda que as aplicações escrevam na saída padrão e que o armazenamento de logs seja externo, com ciclo de vida separado do pod; não traz armazenamento de logs próprio [27]. A rotação é feita pelo kubelet (valor padrão do Kubernetes: arquivos de 10 MiB e cinco por contêiner) e o kubectl logs vê somente o arquivo mais recente [27]. Ou seja, sem um coletor, os logs de um pod que reiniciou ou rotacionou podem se perder.

A documentação do Kubernetes descreve três padrões para coletar em nível de cluster: um agente por nó, um agente em cada pod, ou a aplicação enviar direto ao destino [27]. O OpenTelemetry os traduz nestas montagens:

Quatro cuidados que a documentação aponta e que, quando ignorados, se pagam em retrabalho durante a implantação:

1. Etiquetar cada log com o dono dele. Um log lido de um arquivo não sabe de qual pod vem. O processador k8sattributes cola o pod, o namespace, o deployment e o nó em cada registro, e é estável para os três sinais [33]. A leitura de arquivos (filelog) está em beta para logs [32] e, por padrão, lê somente o que chega depois de iniciar; sem guardar a posição de leitura, um reinício pode duplicar ou perder linhas [32].
2. Uma métrica, um único escritor. Dois coletores reportando a mesma série produzem dados fora de ordem no Prometheus [8].
3. O coletor também falha. Com fila de envio, novas tentativas e armazenamento persistente configurados, pode resistir a falhas transitórias; ainda assim, disco cheio, queda prolongada ou limites de nova tentativa podem causar perda [35]. É dimensionado e vigiado como mais um serviço.
4. Com o Operator, a ordem importa. A instrumentação automática exige que o recurso de configuração exista antes do pod, a anotação no lugar correto e um reinício; além disso, sobrescreve variáveis como JAVA_TOOL_OPTIONS [34].

Um aviso sobre o Promtail. É o agente de logs que muitas equipes instalaram anos atrás para o Loki. A Grafana declarou o fim de vida dele em 2 de março de 2026: já não recebe atualizações nem suporte comercial, e recomenda-se migrar para o Alloy, com uma ferramenta de conversão [22]. Quem ainda o tem em produção opera sem respaldo do fabricante.

Um agente que lê o log, ou instrumentar a aplicação?

É a decisão mais prática de todo o tema, e é mal formulada quando apresentada como «o velho contra o moderno». São dois caminhos com vantagens distintas.

• Um agente que lê é um programa que pega o que o software já escreve —na saída padrão ou em um arquivo— e o leva ao armazenamento. Não requer alterar o software. Em troca, exige interpretar (fazer o parsing de) linhas de formatos diversos, e não pode inventar um trace_id que a aplicação não escreveu [32][40]. O OpenTelemetry descreve as duas vias —ler arquivos ou saída padrão, ou enviar direto por OTLP— e resume o compromisso assim: a primeira não requer mudanças, mas exige um parsing robusto; a segunda evita a complexidade dos arquivos, mas requer configuração na aplicação [39].
• Instrumentar por dentro é usar o SDK do OpenTelemetry ou um appender —um adaptador que conecta o sistema de logs que o framework já usa, como Logback ou Log4j em Java, ao OpenTelemetry— para que cada registro saia com o contexto de trace e com dados estruturados [38]. O OpenTelemetry não substitui essas bibliotecas de logs: faz a ponte com elas [38]. Em troca, é preciso modificar e implantar código.

A resposta madura costuma ser híbrida, com uma condição: não duplicar. Se a aplicação exporta um evento pelo appender e, além disso, esse mesmo evento é lido de novo do arquivo, o armazenamento recebe duas cópias. Cada fluxo é declarado para um caminho ou para o outro.

Uma nota sobre a «instrumentação automática». Em Java, o agente do OpenTelemetry é anexado na inicialização (-javaagent) e injeta código em tempo de execução para capturar telemetria das bibliotecas comuns: as chamadas HTTP que entram e saem, o banco de dados [37]. Dá visibilidade rápida sem alterar o código-fonte. Mas cobre as bordas técnicas, não a lógica do negócio: a documentação é explícita ao dizer que o código próprio da aplicação normalmente não é instrumentado sozinho [36]. Uma decisão como «aprovação de crédito» ou «alocação de estoque» só aparece no trace se alguém a marcou no código. O que a instrumentação automática traz é um bom ponto de partida, não o fim do trabalho.

O que observar em cada setor

Estes são cenários ilustrativos, sem clientes nem cifras medidas. Cada um percorre a mesma cadeia: métrica que avisa, trace que delimita o percurso, log que traz o detalhe.

Bancos: transferências e autorizações. Vigia-se, em métricas, o tempo em que respondem 95 % das transferências e a taxa de erros de autorização. Quando sobe, o exemplar abre o trace de uma transferência lenta; o trace mostra que o tempo foi gasto na consulta ao sistema central, e o log do mesmo trace_id diz que o tempo de espera do pool de conexões se esgotou. Com essa cadeia montada e testada, saber onde e por quê deixa de depender de reunir cinco equipes; o tempo que isso leve depende de o cruzamento estar configurado como descrito acima. Aviso: essas métricas servem para operar, não para conciliar [9].

Fintech: APIs abertas. Um parceiro que consome as APIs da empresa reporta que «às vezes» os pagamentos falham. Sem telemetria é uma anedota. Com traces é possível buscar somente as operações com falha dessa rota e ver se coincidem com a demora de uma consulta antifraude externa. Também se vigiam a taxa de erros por parceiro, as rejeições por limite de requisições e a latência das notificações (webhooks). Separa-se assim «falhou o nosso sistema» de «um terceiro se degradou», com evidência.

Seguros: cotação e emissão. Uma cotação leva 40 segundos no horário de pico. O trace revela que cada cotação consulta em série três sistemas de tarifas, e a métrica de erros mostra que um deles se degrada ao meio-dia. Decide-se paralelizar ou colocar um cache, não «comprar mais servidores». Na emissão, mede-se o tempo de ponta a ponta e onde se acumulam as filas.

Varejo: checkout e estoque. Em uma promoção, o carrinho «fica pensando». As métricas mostram saturação do serviço de estoque; o trace revela que cada visita a um produto o consulta doze vezes. Corrige-se a causa, não o sintoma. E aqui aparece um custo concreto: se as métricas são rotuladas por produto ou por cliente, a cardinalidade dispara (mais adiante).

Empresa regulada: faturamento. Um auditor pergunta o que aconteceu com uma solicitação de faturamento na terça-feira. Com o identificador de trace reconstrói-se o percurso por todos os sistemas, e nos logs associados vê-se o que foi feito e quando. Com uma ressalva: a telemetria ajuda a entender o comportamento técnico, mas não substitui um registro de auditoria formal, íntegro e com a retenção aprovada. Os traces são amostrados e conservados por pouco tempo; isso é decidido com Risco, Privacidade e Jurídico, não com uma configuração técnica.

Custos e riscos: o que pouco se diz

Em muitos casos, o custo relevante vem do volume, da cardinalidade, da retenção, da computação de consulta e da operação; o peso de cada item depende da plataforma e do contrato. Três decisões pesam em especial.

Cardinalidade: cada rótulo novo é uma fatura

A cardinalidade é o número de combinações distintas de rótulos. No Prometheus, cada combinação nova é uma série nova que consome memória, disco e computação. O guia do projeto recomenda manter a cardinalidade de cada métrica abaixo de 10 e, se passa de perto de 100 ou pode crescer sem limite, buscar outra solução; o exemplo dele é claro: 10.000 nós com dezenas de sistemas de arquivos dão cerca de 100.000 séries, aceitável, mas acrescentar uma cota por usuário produz milhões [10]. Tampouco se usam rótulos para identificadores de usuário ou e-mails [11]. Essas cifras são um guia de práticas do projeto, não um limite técnico rígido.

O Loki tem uma versão própria: rótulos de valores ilimitados obrigam a construir um índice enorme e milhares de blocos minúsculos, e o sistema rende muito mal. O guia da Grafana —cifra de fornecedor— sugere não passar de 10 a 15 rótulos e mover os identificadores para o conteúdo ou para os metadados estruturados [14].

Traduzido para o negócio: na promoção de fim de ano do cenário de varejo, se cada cliente é um rótulo, a fatura e a lentidão crescem justamente quando mais se precisa do sistema.

Dados pessoais: o que não se emite, não vaza

Logs e traces têm o péssimo hábito de capturar demais. Um serviço que, por engano, escreve o nome completo e o documento de identidade de quem envia um arquivo deixa esse texto no armazenamento, com a retenção correspondente, à disposição de quem tiver acesso ao painel. O OpenTelemetry é claro: não pode saber o que é sensível no contexto de cada um, a responsabilidade regulatória é de quem implementa, e evitar emitir o dado é melhor do que remediar depois; chega a advertir que aplicar um hash a um identificador pode não dar anonimato quando o universo de valores é pequeno [42].

O Collector oferece processadores para remover ou transformar atributos, mas convém medir a maturidade deles: para logs, redaction e filter constam em alfa e transform em beta [43]. Apoiar toda a proteção em uma peça alfa é frágil. A prática prudente são duas barreiras: não emitir o dado a partir da aplicação e, como segunda linha, filtrar no Collector. No México, a Ley Federal de Protección de Datos Personales en Posesión de los Particulares vigente (publicada no Diario Oficial em 20 de março de 2025, que revogou a de 2010) tem por objeto regular um tratamento legítimo, controlado e informado, e obriga o responsável a manter medidas de segurança administrativas, técnicas e físicas [45]; o que se conserva e por quanto tempo é validado com Privacidade e Jurídico.

Retenção e disco: ninguém decide isso pela empresa

O Kubernetes não retém logs a longo prazo, e o Docker, por padrão, pode encher o disco [27][28]. A retenção de longo prazo é uma decisão do armazenamento e do negócio, e deve distinguir entre métricas, logs, traces e evidência regulatória. Não incluímos cifras de retenção nem preços porque dependem do fornecedor e do contrato; qualquer uma que se cite sem esses dados é uma suposição.

Quem vê o quê, e quem opera. Os painéis do Grafana mostram o que os logs e os traces contêm, então o acesso é projetado por área: cada equipe vê os painéis e as fontes que lhe cabem, e quem consulta logs com dados pessoais é um grupo mais reduzido do que quem olha um gráfico de latência. E operar este conjunto de ferramentas requer pelo menos uma pessoa que entenda as consultas (PromQL, LogQL, TraceQL) e o Collector; é um custo humano, não só de infraestrutura, que convém contar desde o início.

A isso se soma a amostragem: conservar todos os traces é caro, e conservar somente alguns obriga a decidir quais, por exemplo todos os que falham e uma fração dos saudáveis. Com uma amostragem feita no gateway, o roteamento precisa mandar todos os spans de um mesmo trace ao mesmo coletor [8]. E uma nota de entrega do protocolo: diante de falhas transitórias, uma implementação pode tentar o envio de novo; sem confirmação de recebimento, isso pode produzir duplicatas. Por isso, o armazenamento e as consultas devem tolerá-las, sem presumir entrega garantida [4].

Como começar sem querer fazer tudo

1. Escolha um fluxo de negócio crítico, não «o sistema todo». Uma transferência, uma cotação, um checkout, uma fatura. Se falha, dói; por isso é instrumentado primeiro.
2. Defina de antemão as três ou quatro perguntas que se quer poder responder e o sinal que as responde: o que mede a métrica, o que marca o trace, o que deve dizer o log?
3. Combine os nomes desde o princípio. Um nome de serviço e um ambiente consistentes nos três sinais valem mais do que qualquer painel [46].
4. Comece pelo que não requer tocar no software. Um agente que lê a saída padrão e, em Java, a instrumentação automática dão uma primeira visão em pouco tempo [36][37].
5. Instrumente por dentro o que importa ao negócio: os passos desse fluxo, com o trace_id em cada linha de log.
6. Fixe regras de cardinalidade e de dados pessoais antes de abrir a torneira: lista de atributos permitidos, quais dados não são emitidos e quem decide a retenção.
7. Teste o cruzamento de ponta a ponta: do clique no gráfico ao trace e do trace ao log. Se algum salto falha, é nesse momento que se aprende o que faltava, não em um incidente real.
8. Retire o que já não tem suporte. Se há Promtail, planeje a migração [22].

Antes de começar, convém acordar por escrito, para o primeiro fluxo: qual fluxo entra, quem é o responsável, a linha de base e a meta de latência e de erro, a cobertura mínima de traces, os atributos proibidos, a retenção, o orçamento mensal e o teste de correlação da métrica ao trace e ao log.

Saber que ferramenta existe é a parte fácil. O difícil é saber qual parte da plataforma já emite o que é preciso, o que se pode observar sem tocar no software e o que requer instrumentação, onde hoje estão vazando dados pessoais para os logs e que custo cada decisão traz. É isso que revisamos em um diagnóstico: a empresa recebe um mapa de sinais dos fluxos críticos, a tabela do que se cobre com um agente e do que requer instrumentar, o inventário de dados pessoais que hoje chegam aos logs, os fatores de custo que mais pesam no caso dela e a ordem recomendada para adotá-lo, para que TI, segurança, risco e negócio decidam com a mesma informação.