Observabilidade em ASP.NET Core: OpenTelemetry sem virar mil dashboards

OpenTelemetry virou padrão no ecossistema .NET e isso é bom. O efeito colateral é previsível: equipe instala os pacotes de instrumentação, liga AddAspNetCoreInstrumentation, AddHttpClientInstrumentation, AddSqlClientInstrumentation, AddRuntimeInstrumentation, exporta tudo, e seis semanas depois ninguém abre o painel porque ninguém sabe o que olhar. Telemetria sem critério é despesa de armazenamento com aparência de maturidade.

O conjunto mínimo que importa tem três sinais. Latência p95 por endpoint, porque média esconde cauda e cauda é o que o cliente sente. Taxa de erro segmentada por código HTTP e por exceção, porque 500 e 429 contam histórias diferentes. Saturação do recurso crítico do serviço, que quase sempre é pool de conexão de banco ou profundidade de fila quando você usa Service Bus ou Azure Queue. Tudo além disso é diagnóstico, não monitoramento.

Correlation ID end-to-end é a coisa que mais paga juros no longo prazo. ASP.NET Core já propaga traceparent W3C automaticamente, mas a partir do momento que entra fila, worker em background ou chamada pra Azure Function, você precisa garantir manualmente que o Activity.Current viaja junto. Sem isso, trace fica picado e o investigador de incidente passa quarenta minutos costurando log à mão. Com isso, abre Application Insights, filtra pelo operation_Id e a história inteira aparece.

Sampling é onde a conta fecha ou estoura. ParentBasedSampler com TraceIdRatioBased em dez por cento pra tráfego HTTP normal cobre análise de tendência sem pagar ingestão de traço repetido. Em cima disso, AlwaysOnSampler condicional pra request com erro ou latência acima de threshold, implementado num Processor customizado que olha o Activity antes do export. Você fica com cem por cento do que dói e amostra do que está saudável. Custo de Application Insights cai pela metade na primeira semana.

Exportador é decisão de plataforma, não de gosto. OTLP pra Azure Monitor via azure-monitor-opentelemetry-exporter quando o resto da casa vive em Azure, OTLP pra Grafana Cloud ou Honeycomb quando o time já tem ferramenta e processo de incident maduro em cima dela. Misturar dois destinos é receita pra dashboard contraditório e disputa sobre qual número é o verdadeiro. Escolhe um, documenta, segue.

Alerta escasso e dashboard por bounded context, não por serviço. Um painel pra checkout, outro pra catálogo, outro pra billing, cada um agregando os serviços que participam daquela jornada. Alerta dispara em SLO violado, não em métrica oscilando. Quem é acordado às três da manhã merece que o alerta signifique algo. Esse é o teste único que separa observabilidade útil de teatro de monitoração.