Sites de comércio B2B têm um perfil de observabilidade peculiar. O tráfego é baixo em comparação com as lojas para consumidores, algumas centenas de sessões por dia, muitas vezes menos. Mas cada requisição é de alto risco: uma cotação que não carrega, um checkout que falha em silêncio, um preço que por um instante fica errado. O cliente é uma empresa conhecida com quem há um relacionamento, e "quebrou para mim" chega relatado pelo contato de contas a receber, não como uma avaliação anônima.
Essa combinação muda o que a observabilidade precisa fazer. Aqui está o que usamos em projetos de comércio B2B, indo de "uma implantação pequena de ASP.NET Core no IIS" até "Sana Commerce hospedado em várias regiões".
As três coisas de que você realmente precisa
- Logs estruturados que você consiga pesquisar. Quando um cliente relata um problema, você precisa encontrar em segundos cada linha de log relacionada à sessão dele, e não vasculhando arquivos manualmente.
- Traces distribuídos atravessando o limite da integração. A maioria dos erros de comércio B2B está na emenda entre a loja e o ERP. Um trace que abrange os dois lados é a diferença entre uma resposta e uma longa sessão de depuração.
- Dashboards que sua equipe de operações de vendas consiga ler. Não só os engenheiros. Quando o VP de Operações pergunta "estamos perdendo pedidos esta semana?", a resposta não deveria exigir um engenheiro.
O que de fato usamos em projetos de ASP.NET Core
Logging: Serilog com propriedades estruturadas
O ILogger padrão via Microsoft.Extensions.Logging funciona bem, mas o Serilog oferece um logging estruturado melhor com menos cerimônia. A configuração que usamos:
- Sink de console (visível no terminal do Kestrel durante o desenvolvimento e no stdout do IIS em produção)
- Sink de arquivo rotativo em App_Data/logs (com retenção, em geral 14 dias localmente, mais um job que envia os arquivos mais antigos para armazenamento durável)
- Enriquecedores para ClientIP, UserAgent, RequestId e (quando autenticado) o identificador da conta corporativa
O enriquecedor não tão óbvio: o ID de cliente/empresa. Quando você está investigando "por que o checkout da Acme Manufacturing quebrou", você quer filtrar pelo ID deles, não por IDs de sessão que primeiro precisam ser localizados.
Tracing: OpenTelemetry
OpenTelemetry é a resposta certa para tracing distribuído em 2026. O ASP.NET Core tem suporte de primeira classe ao OTel; a configuração são algumas chamadas de AddOpenTelemetry() mais um exportador (normalmente usamos OTLP para um coletor e, de lá, para Honeycomb / Jaeger / Application Insights / etc., conforme o que o cliente já roda).
Os spans de maior valor:
- Servidor HTTP (cada requisição)
- Chamadas de HttpClient ao BuiltWith, ao provedor de IA, ao ERP, ao serviço de e-mail
- Spans de consultas ao SQLite / SQL Server
- Spans personalizados em torno do trabalho crítico para o negócio, como “avaliar o preço para o cliente X, SKU Y” ou “sincronizar o cliente N com o ERP”
Health checks
O ASP.NET Core tem uma API de health checks limpa. Expomos /healthz com verificações de: acesso de escrita ao sistema de arquivos (App_Data gravável), alcançabilidade do SMTP e, o mais importante, a conexão com o ERP ou as APIs de fornecedores das quais a loja depende.
O pipeline de implantação consulta /healthz após cada implantação com novas tentativas; se ficar degradado depois do rollout, o pipeline falha de forma barulhenta.
Os dashboards que importam
O número certo de dashboards é pequeno. Em geral construímos três:
- "O site está funcionando agora?" Uma visão de painel único: taxa de erros HTTP (última hora), latência p99, contagem de erros de sincronização com o ERP e o carimbo de tempo da última sincronização bem-sucedida. Atualiza a cada 30s. Fica em uma tela na sala ou fixado em um canal do Slack.
- "Os pedidos estão fluindo?" Contagem por hora de pedidos feitos, valor em dólares, por canal. Operações de vendas se importa com isso. Contas a receber também. E o CEO durante o mês do lançamento.
- "Investigação: nome do cliente" Um dashboard parametrizado que você abre digitando um ID de cliente. Mostra cada ação que os usuários daquele cliente fizeram nos últimos 30 dias, cada erro que tocou a conta dele, cada sincronização com o ERP que envolveu o registro dele. Este é o dashboard que você vai desejar ter na primeira vez que um cliente disser “ontem aconteceu uma coisa”.
Alertas que não causam fadiga de alertas
Em sites B2B de baixo tráfego, alertas a cada erro disparam o tempo todo porque os erros individuais parecem estatisticamente significativos. Em vez disso, ajustamos para estes padrões:
- Taxa sustentada de HTTP 5xx > 2% ao longo de 10 minutos (não requisições isoladas)
- Qualquer health check com falha que dure > 1 minuto
- A sincronização com o ERP não teve sucesso em > 30 minutos (o assassino silencioso)
- Mais de 30 minutos sem nenhum pedido passando durante uma janela em que deveria haver, medido contra uma linha de base de 30 dias
Todo o resto: registre, coloque em um dashboard, mas não dispare alerta por isso.
E quanto a Application Insights / Datadog / etc.?
Use o que o cliente já roda. Application Insights é ótimo se eles forem fortemente baseados em Azure. Datadog é ótimo se forem multinuvem. Honeycomb é excelente para traces. A plataforma importa menos do que se comprometer com uma só e manter logs e traces correlacionados dentro dela. O pior padrão é "temos logs no IIS, traces no App Insights, erros no Sentry e consultas SQL em lugar nenhum", três ferramentas entre as quais você alterna para investigar um único bug.
A conclusão
A observabilidade B2B é pouco glamourosa e de alta alavancagem. O trabalho de fato é pequeno: algumas horas de configuração do Serilog, mais algumas para o OTel, um dia para o dashboard de investigação de clientes. O retorno é a diferença entre “ontem um cliente nos ligou sobre um problema e não sabemos o que aconteceu” e “aqui está o trace, aqui está a causa, aqui vai a correção saindo hoje”.
Se sua plataforma B2B está em produção e sua estratégia de depuração é “olhar o log do IIS”, fale com a gente. Teremos os dashboards prontos na primeira semana.