DEV Community: Milton Camara

Pare de usar Logs como MULETA. Voce está fazendo ERRADO!!!

Milton Camara — Mon, 11 May 2026 17:27:51 +0000

Se você já abriu um arquivo de log de 2GB no meio da madrugada tentando descobrir por que o pagamento do cliente falhou, esse post é pra você. E não, a culpa não é da ferramenta. A culpa é sua.

A real é dura: a maioria dos devs trata log como se fosse Console.WriteLine com esteroides. Espalha LogInformation em cada método, acha que está "instrumentando" a aplicação, e quando o sistema quebra em produção fica horas "grepando" arquivo atrás de pista.

Logs não foram feitos pra explicar fluxos. Eles servem pra registrar eventos pontuais. Quem te entrega o fluxo completo de uma operação são os traces. E se você ainda não sabe a diferença, esse é o problema que você precisa resolver hoje.

O pecado capital: log como narrador de novela

Olha se você nunca escreveu algo parecido com isso:

logger.LogInformation("Entrou no método ProcessarPagamento");
logger.LogInformation("Validando dados do cliente {ClienteId}", clienteId);
logger.LogInformation("Chamando API de Pagamento com valor {Valor}", valor);
logger.LogInformation("Pagamento retornou sucesso");
logger.LogInformation("Saiu do método ProcessarPagamento");

Parece responsável. Parece "boa prática". Não é.

Esse código tem 4 problemas graves que ninguém te conta:

1. Zero correlação entre as linhas

Em produção, com 500 requests por segundo, essas 5 linhas vão estar embaralhadas com outras 50.000 de outros usuários. Boa sorte tentando montar a sequência de um pedido específico sem um TraceId.

2. Você está pagando caro por lixo

Datadog, New Relic, CloudWatch, Splunk: todos cobram por volume ingerido. Cada LogInformation("Entrou no método X") é dinheiro real saindo da sua conta. Já vi empresa gastar R$ 80k/mês em log que ninguém nunca leu.

3. PII e vazamento de dados (LGPD chegou em todo mundo)

Quando o dev coloca logger.LogInformation("Request: {@Request}", request) achando que está sendo esperto, ele acabou de logar CPF, cartão, token JWT e senha em texto puro. Auditoria vai te encontrar. A LGPD também.

4. Logs não contam história, contam fofoca

Você sabe que algo aconteceu, mas não sabe quando, quanto tempo demorou, o que veio antes nem o que veio depois. É como tentar entender um filme só pelas legendas, fora de ordem.

A virada de chave: traces

Trace é uma árvore. Cada operação (uma chamada HTTP, um query no banco, uma publicação no Kafka) é um span, e os spans se conectam formando o fluxo completo de uma requisição, mesmo quando ela atravessa 8 microsserviços diferentes.

Com trace você responde perguntas que log nunca vai conseguir responder:

"Por que esse pedido demorou 4 segundos?" → você vê exatamente qual span travou.
"O bug está no meu serviço ou no fornecedor?" → o trace mostra a cadeia inteira.
"Quantos % das requests estão lentas por causa do banco?" → métricas derivadas do span do EF Core.

E o melhor: você instrumenta uma vez, com OpenTelemetry, e exporta pra qualquer backend (Jaeger, Tempo, Datadog, Honeycomb, Azure Monitor). Sem vendor lock-in.

Hands-on: o mesmo cenário, agora bem feito (.NET 8 + OpenTelemetry)

Setup mínimo no `Program.cs`

using OpenTelemetry.Resources;
using OpenTelemetry.Trace;

builder.Services.AddOpenTelemetry()
    .ConfigureResource(r => r.AddService("MinhaApp.Pagamento"))
    .WithTracing(tracing => tracing
        .AddSource("MinhaApp.Pagamento")
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddEntityFrameworkCoreInstrumentation()
        .AddOtlpExporter()); // exporta pro coletor que você quiser

Pronto. Toda chamada HTTP de entrada, toda chamada HTTP de saída e toda query no EF Core já estão sendo rastreadas automaticamente. Você nem precisa escrever código pra isso.

Instrumentação manual onde importa

using System.Diagnostics;

public static class Telemetry
{
    public static readonly ActivitySource Source = new("MinhaApp.Pagamento");
}

public class PagamentoService
{
    private readonly HttpClient _http;
    private readonly ILogger<PagamentoService> _logger;

    public PagamentoService(HttpClient http, ILogger<PagamentoService> logger)
    {
        _http = http;
        _logger = logger;
    }

    public async Task<bool> ProcessarAsync(Guid pedidoId, int clienteId, decimal valor)
    {
        using var activity = Telemetry.Source.StartActivity(
            "processar-pagamento", 
            ActivityKind.Internal);

        // tags = metadados consultáveis no backend de observabilidade
        activity?.SetTag("pedido.id", pedidoId);
        activity?.SetTag("cliente.id", clienteId);
        activity?.SetTag("valor.total", valor);
        activity?.SetTag("moeda", "BRL");

        try
        {
            activity?.AddEvent(new ActivityEvent("validando-cliente"));
            await ValidarClienteAsync(clienteId);

            activity?.AddEvent(new ActivityEvent(
                "chamando-gateway",
                tags: new ActivityTagsCollection 
                { 
                    { "gateway", "Stripe" },
                    { "endpoint", "POST /v1/charges" }
                }));

            var response = await _http.PostAsJsonAsync("/v1/charges", new { valor });

            activity?.SetTag("http.status_code", (int)response.StatusCode);
            activity?.SetTag("response.size", response.Content.Headers.ContentLength);

            if (!response.IsSuccessStatusCode)
            {
                activity?.SetStatus(ActivityStatusCode.Error, "Gateway recusou pagamento");
                // log SÓ aqui, no erro, e SEM payload sensível
                _logger.LogWarning("Pagamento recusado para pedido {PedidoId}", pedidoId);
                return false;
            }

            activity?.SetStatus(ActivityStatusCode.Ok);
            return true;
        }
        catch (Exception ex)
        {
            activity?.RecordException(ex);
            activity?.SetStatus(ActivityStatusCode.Error, ex.Message);
            throw; // deixa o ASP.NET Core lidar
        }
    }
}

O que esse código faz que o anterior não fazia

Antes (logs)	Depois (traces)
5 linhas soltas no arquivo	1 span estruturado com início, fim e duração
Nenhuma correlação entre serviços	`TraceId` propaga automaticamente via HTTP headers
Busca textual com `grep`	Query estruturada por `pedido.id`, `cliente.id`, etc.
Sem noção de tempo	Latência precisa de cada etapa, em microssegundos
Logger genérico vazando PII	Tags controladas, sem campos sensíveis
Custo proporcional ao volume bruto	Custo proporcional a operações + sampling configurável

"E os logs, jogo fora?"

Não. Logs continuam sendo úteis. O que muda é quando você os usa:

✅ Use log pra: eventos de negócio importantes ("Pedido X cancelado pelo cliente"), erros inesperados, auditoria de ações sensíveis.
❌ Não use log pra: rastrear fluxo, medir performance, debugar requisição específica, "marcar que passou aqui".

A regra que eu sigo: se a informação faz parte da história de uma requisição, é trace. Se é um fato isolado que importa fora do contexto da requisição, é log.

E quando você precisar dos dois juntos? Correlacione pelo TraceId:

_logger.LogWarning(
    "Pedido {PedidoId} cancelado. TraceId: {TraceId}",
    pedidoId,
    Activity.Current?.TraceId);

Agora, do dashboard de logs, você clica no TraceId e cai direto no trace. Fim do grep eterno.

A pirâmide da observabilidade (decora isso)

        🔺 Logs        ← eventos pontuais, raros, com contexto
       🔺🔺 Métricas    ← agregações, dashboards, alertas
      🔺🔺🔺 Traces      ← a base de tudo, o fluxo das requests

Quem começa pela base debuga em segundos. Quem começa pelo topo debuga em horas.

Conclusão sem rodeios

Se você ainda está enchendo seu código de LogInformation achando que está fazendo observabilidade, você está uma década atrás do estado da arte. Trace não é luxo de Big Tech, é o mínimo pra qualquer aplicação séria em 2026.

Instala o OpenTelemetry hoje. Roda um Jaeger ou Tempo local. Vê seu sistema do jeito que ele realmente é: uma árvore de operações com latências, erros e dependências. Você nunca mais vai voltar pro tail -f.

E aí, vai continuar caçando agulha no palheiro ou vai aprender a usar a ferramenta certa?

💬 Se esse post fez sentido, deixa um comentário com o pior cenário de "debug por log" que você já viveu.

🔍 Como tornei milhões de conversas históricas "invisíveis" buscáveis em tempo real

Milton Camara — Mon, 11 May 2026 14:40:00 +0000

O problema

Trabalhei recentemente em uma solução para um cenário que muita gente que
mexe com sistemas em escala já enfrentou: um sistema gera diariamente
arquivos JSON que vão para um storage ou qualquer outro banco como histórico, seguindo um padrão de nomenclatura previsível. Com o tempo, esses arquivos se acumulam aos milhões.

A dor apareceu quando surgiu a necessidade de consultar esse histórico.

Três problemas surgiram ao mesmo tempo

Parte da informação que identifica cada arquivo nem sempre estava preenchida no nome, porque é um dado mutável e nem sempre estava disponível no momento da geração.

As pessoas precisavam buscar por critérios variados, alguns estruturados, outros por palavra-chave dentro do conteúdo, e nada disso estava exposto no nome do arquivo

Eram milhões de arquivos espalhados em containers diferentes, varrer linearmente era inviável.

Em resumo: tínhamos os dados, mas eram efetivamente invisíveis.

A solução

Construí um pipeline em .NET 9 que varre o storage e indexa todo o conteúdo em um cluster Elasticsearch (rodando em Kubernetes via ECK
Operator), com mapping otimizado para texto em português (analyzer com
stemmer, asciifolding e stopwords em PT-BR). O resultado é busca textual
em milhões de documentos em tempo real, mesmo quando o termo aparece
apenas no meio de uma seção específica do conteúdo.

Os pontos de design que fizeram diferença

Pipeline producer/consumer com System.Threading.Channels
Producer lista arquivos paginado, workers em paralelo baixam e parseiam em streaming, e bulk indexer envia batches pro Elastic. Channels bounded controlam pressão de memória.

Parser tolerante a dados sujos
Os arquivos históricos vinham com toda sorte de inconsistência: HTML entities, campos ausentes, datas inválidas, números como string, ordem de seções variável. Implementei discriminated union ParseResult (Success/Skipped/Failed) com helpers TryGet defensivos.
Política: indexa o que conseguiu, descarta apenas o irrecuperável, nunca derruba o pipeline por um arquivo ruim.

Busca híbrida em duas camadas
Quando o termo digitado tem um padrão estruturado, a API consulta o próprio storage (prefix lookup nativo, extremamente rápido) e o Elastic em paralelo. Resultados unidos: hits do storage no topo, hits textuais abaixo. O melhor de dois mundos sem latência adicional.

Boosts diferenciados por campo no Elastic
Match em campos estruturados tem boost maior. Match em texto solto tem boost menor. Resultado: busca por uma palavra específica sobe primeiro quem tem essa palavra em campo identificador, e só depois quem mencionou em texto livre.

Estratégia de alias para reindexação sem downtime
Cada carga gera um índice físico novo (com timestamp no nome) e o alias é trocado atomicamente no final. Permite reprocessar o histórico inteiro sem afetar produção.

Checkpointing stateless
Cada partição tem seu progresso salvo em storage externo. Se o pod morrer no meio da carga, retoma exatamente de onde parou. Sem volumes persistentes, sem estado local.

Highlights com fragmentos contextuais
Quando a busca casa em texto livre, o Elastic retorna trechos do conteúdo com a palavra encontrada destacada. A interface mostra o contexto direto na lista de resultados, sem precisar abrir cada item para descobrir por que ele apareceu.

🤖 O papel da IA nesse processo

Não vou fingir que cheguei nessa arquitetura sozinho em uma tarde. Usei
LLM como par técnico ao longo de todo o caminho, e a forma como usei
fez toda a diferença no resultado.

Onde a IA ajudou de verdade

Brainstorming de trade-offs arquiteturais
"Mensageria entre processos faz sentido aqui ou é overhead?", "Cursor pagination ou from/size pra infinite scroll?", "Alias com swap ou reindex in-place?".
Em vez de só pedir resposta, debati cada decisão e pesei prós e contras. A IA é excelente como sparring de design.

Análise crítica do código existente
O projeto inicial tinha mais peças do que precisava. Pedi uma análise técnica completa, code smells, dead code, bugs latentes, aderência a boas práticas. Saiu um documento de diagnóstico priorizado por severidade. Decidi simplificar a arquitetura com base nesse diagnóstico.

Modelagem do parser tolerante
Os cenários de dados sujos foram enumerados de forma exaustiva e cada um virou um caso de teste antes da implementação. Test-driven, mas com IA gerando o checklist.

Mapping do Elasticsearch
Definir analyzer correto pra português, decidir entre tipos de campo, projetar nested vs flat, é o tipo de decisão onde experiência prévia conta muito. Conversar com a IA acelerou em horas o que levaria dias de leitura de docs.

Prompts estruturados para agente de codificação
Quebrei a implementação em fases, cada uma com prompt detalhado contendo arquitetura alvo, decisões já tomadas, restrições, e ordem de execução. Resultado: o agente executou sem perder contexto e sem inventar.

Onde a IA NÃO substituiu o engenheiro

Decisões de negócio (volumes reais, padrões de acesso, regras de tratamento de exceções específicas do domínio)
Validar suposições contra a realidade do projeto (rodar build, ler logs, executar queries pra verificar comportamento)
Conhecer a infra real (capacidade dos volumes, classes de storage disponíveis, limites do cluster)
Priorizar segurança (a IA aponta riscos, mas a decisão de parar tudo pra resolver é humana)

A lição mais importante

IA é multiplicador, não substituto. Quem souber fazer perguntas certas, validar respostas e contextualizar com a realidade do projeto extrai muito valor. Quem só pede "me dá a solução" recebe código genérico que não resolve o problema real.

Stack utilizada

.NET 9 (Worker Service + ASP.NET Core)
Azure Blob Storage (origem dos dados)
Elasticsearch 8.x em Kubernetes via ECK Operator
Azure Table Storage (checkpoint stateless)
SDK oficial do Elastic (tipado)
System.Threading.Channels (pipeline assíncrono in-process)
Claude (sparring técnico e análise de código)
Claude Code (execução guiada por prompts estruturados)

Lições que valeram o post

Dados reais são sujos. Investi mais tempo projetando tolerância a inconsistências do que no pipeline em si. E foi o tempo mais bem gasto, em produção, um único arquivo malformado não pode derrubar uma carga em larga escala.

Mensageria nem sempre é a resposta. Para uma carga histórica única + ingestão futura via eventos do próprio storage, removi a camada de filas intermediária e simplifiquei para um indexer mais direto. Menos infra, menos custo, mais simples de testar.

Storage tem capacidades subutilizadas. O prefix lookup nativo do storage é absurdamente rápido e barato. Combinar isso com Elastic para o resto deu uma estratégia híbrida que nenhum dos dois sozinho daria.

Reindexar sem downtime é decisão arquitetural, não otimização. Resolver isso com alias desde o dia 1 me poupou de um problema futuro que apareceria do nada.

IA não pensa por você, mas amplifica quem pensa. O diferencial está em fazer as perguntas certas, contextualizar com seu projeto e validar tudo na prática.