Observabilidad en .NET: la diferencia entre saber que falló y saber por qué

Son las 10:15 de la mañana. Tu monitoreo dispara una alerta: «API de pedidos: tiempo de respuesta mayor a 3 segundos». El equipo se conecta, mira el CPU (normal), mira la memoria (normal), reinicia el servicio y todo vuelve a la normalidad. Se cierra el ticket.

Tres días después vuelve a pasar. Y otra vez. Nadie sabe por qué.

Esa es exactamente la frontera entre monitorear y observar. El monitoreo responde a preguntas que ya sabías formular: ¿está arriba?, ¿cuánto CPU usa?, ¿responde el endpoint de salud? La observabilidad responde a la pregunta que no anticipaste: ¿por qué esta petición específica, de este cliente, a esta hora, tardó 3.4 segundos?

Los tres pilares, contados con un pedido real

Imagina una petición POST /api/pedidos que atraviesa tu API, valida inventario, cobra con un proveedor externo y encola un correo. Cada pilar de la observabilidad te cuenta una parte distinta de esa historia.

Ninguno de los tres sustituye a los otros. Las métricas te dicen que algo pasa, las trazas te dicen dónde, y los logs te dicen qué.

Por qué .NET está hoy en un momento ideal

Durante años, instrumentar una aplicación .NET significaba atarse a una herramienta comercial concreta. Eso cambió. OpenTelemetry es hoy un estándar abierto, soportado nativamente en .NET a través de System.Diagnostics.Activity y System.Diagnostics.Metrics, y respaldado prácticamente por toda la industria.

builder.Services.AddOpenTelemetry()
    .ConfigureResource(r => r.AddService("api-pedidos"))
    .WithTracing(t => t
        .AddAspNetCoreInstrumentation()      // peticiones entrantes
        .AddHttpClientInstrumentation()      // llamadas salientes
        .AddSqlClientInstrumentation()       // consultas a base de datos
        .AddOtlpExporter())
    .WithMetrics(m => m
        .AddAspNetCoreInstrumentation()
        .AddRuntimeInstrumentation()         // GC, hilos, memoria
        .AddOtlpExporter());

Ese bloque es, honestamente, el mejor retorno de inversión disponible hoy en un proyecto .NET.

Las cuatro señales que deberías ver desde el primer día

No empieces instrumentando todo. Empieza por lo que responde a la pregunta que hace tu director general: «¿está funcionando bien para el cliente?».

Con estas cuatro, bien graficadas y con alertas sensatas, ya cubres la enorme mayoría de los incidentes que hoy te toman horas.

Una ruta de adopción en cuatro etapas

1. 1Ver Semanas 1 y 2

   Instrumentación automática con OpenTelemetry en tus servicios principales, exportando a un destino único. El objetivo es que exista un solo lugar donde mirar cuando algo pase. Nada más.

2. 2Correlacionar Semanas 3 y 4

   Logging estructurado y propagación del TraceId entre servicios y hacia los logs. El objetivo es que desde un error puedas saltar a la traza completa de esa petición exacta, sin buscar a mano por hora aproximada.

3. 3Alertar con criterio Mes 2

   Definir SLIs y SLOs con el negocio y construir alertas sobre síntomas visibles para el usuario, no sobre causas internas. Menos alertas, y que cada una tenga una acción clara. Un equipo que recibe doscientas alertas al día ya no lee ninguna.

4. 4Medir el negocio Mes 3

   Métricas propias: pedidos procesados, tiempo de cobro, fallas por proveedor de pago. Que el mismo tablero sirva al líder técnico y a la dirección. Aquí la observabilidad deja de ser un gasto de TI y empieza a defenderse sola.

Los tres errores que vemos una y otra vez

Lo que realmente cambia cuando lo tienes

El cambio más visible no es técnico, es de conversación. Se acaban las juntas donde el área de sistemas dice «de nuestro lado todo está bien» y el área comercial insiste en que los clientes se quejan. Con trazas, ambos miran el mismo dato y la discusión se vuelve un diagnóstico.

Y aparece algo que casi nadie anticipa: empiezas a encontrar problemas que llevaban meses ahí y que nadie había reportado.

• ▪Un 3% de checkouts que fallaba en silencio y se contabilizaba como «el cliente se arrepintió».
• ▪Un trabajo nocturno que dejó de correr en marzo y nadie notó hasta el cierre anual.
• ▪Una integración que reintenta cuatro veces cada llamada y triplica el costo del proveedor.

Ese suele ser el momento en que la inversión se paga sola.

Por dónde seguir

Este artículo es la puerta de entrada. Cada etapa de la ruta tiene su propia guía con el código y la configuración concreta:

• —OpenTelemetry en .NET desde cero: tu primera traza distribuida en 30 minutos — el paso a paso de la etapa 1.
• —Logging estructurado en .NET con Serilog — para dejar de escribir logs que nadie puede consultar.
• —TraceId y correlación: cómo seguir una petición a través de 6 microservicios — el corazón de la etapa 2.
• —Los 4 golden signals aplicados a una API .NET real — cómo instrumentar latencia, tráfico, errores y saturación.
• —SLI, SLO y presupuesto de error explicados sin jerga — la base de la etapa 3.
• —Métricas personalizadas en .NET: qué medir de tu negocio — el salto de la etapa 4.
• —Cardinalidad: el error que multiplica tu factura por 40 — para no tropezar con el error 2.

Si tu equipo hoy diagnostica a base de reiniciar servicios y revisar archivos de log por SSH, no es falta de talento: es falta de instrumentos. Y eso, a diferencia de casi todo lo demás, se resuelve en semanas.