Los sitios de comercio B2B tienen un perfil de observabilidad peculiar. El tráfico es bajo comparado con las tiendas para consumidores, unos pocos cientos de sesiones al día, a menudo menos. Pero cada solicitud es de alto riesgo: una cotización que no carga, un checkout que falla en silencio, un precio que por un momento está mal. El cliente es un negocio conocido con el que existe una relación, y "se me rompió" llega reportado a través de su contacto de cuentas por cobrar, no como una reseña anónima.
Esa combinación cambia lo que la observabilidad debe lograr. Esto es lo que usamos en proyectos de comercio B2B, desde "una implementación pequeña de ASP.NET Core en IIS" hasta "Sana Commerce alojado en varias regiones".
Las tres cosas que realmente necesitas
- Logs estructurados que puedas buscar. Cuando un cliente reporta un problema, necesitas encontrar en segundos cada línea de log relacionada con su sesión, no revisando archivos a mano.
- Trazas distribuidas a través del límite de integración. La mayoría de los errores de comercio B2B están en la costura entre la tienda y el ERP. Una traza que abarca ambos lados es la diferencia entre una respuesta y una larga sesión de depuración.
- Dashboards que tu equipo de operaciones de ventas pueda leer. No solo los ingenieros. Cuando el VP de Operaciones pregunta "¿estamos perdiendo pedidos esta semana?", la respuesta no debería requerir a un ingeniero.
Lo que realmente usamos en proyectos de ASP.NET Core
Logging: Serilog con propiedades estructuradas
El ILogger por defecto a través de Microsoft.Extensions.Logging está bien, pero Serilog ofrece mejor logging estructurado con menos ceremonia. La configuración que usamos:
- Sink de consola (visible en la terminal de Kestrel durante el desarrollo y en el stdout de IIS en producción)
- Sink de archivo rotativo en App_Data/logs (con retención, por lo general 14 días en local, más un job que envía los archivos más antiguos a almacenamiento duradero)
- Enriquecedores para ClientIP, UserAgent, RequestId y (cuando hay autenticación) el identificador de la cuenta corporativa
El enriquecedor no tan obvio: el ID de cliente/empresa. Cuando estás investigando "por qué se rompió el checkout de Acme Manufacturing", quieres filtrar por su ID, no por IDs de sesión que primero tienes que buscar.
Trazas: OpenTelemetry
OpenTelemetry es la respuesta correcta para las trazas distribuidas en 2026. ASP.NET Core tiene soporte de primera clase para OTel; la configuración son unas cuantas llamadas a AddOpenTelemetry() más un exportador (solemos usar OTLP hacia un colector y de ahí a Honeycomb / Jaeger / Application Insights / etc., según lo que el cliente ya tenga en marcha).
Los spans de mayor valor:
- Servidor HTTP (cada solicitud)
- Llamadas de HttpClient a BuiltWith, al proveedor de IA, al ERP, al servicio de correo
- Spans de consultas a SQLite / SQL Server
- Spans personalizados en torno al trabajo crítico para el negocio, como “evaluar el precio para el cliente X, SKU Y” o “sincronizar al cliente N con el ERP”
Health checks
ASP.NET Core tiene una API de health checks limpia. Exponemos /healthz con verificaciones de: acceso de escritura al sistema de archivos (que App_Data sea escribible), alcanzabilidad del SMTP y, lo más importante, la conexión al ERP o las APIs de proveedores de las que depende la tienda.
El pipeline de despliegue consulta /healthz tras cada despliegue con reintentos; si queda degradado luego del rollout, el pipeline falla de forma ruidosa.
Los dashboards que importan
El número correcto de dashboards es pequeño. Por lo general construimos tres:
- "¿El sitio funciona ahora mismo?" Una vista de un solo panel: tasa de errores HTTP (última hora), latencia p99, cantidad de errores de sincronización con el ERP y marca de tiempo de la última sincronización exitosa. Se actualiza cada 30 s. Vive en una pantalla de la oficina o fijada en un canal de Slack.
- "¿Están fluyendo los pedidos?" Conteo por hora de pedidos realizados, valor en dólares, por canal. A operaciones de ventas le importa esto. A cuentas por cobrar también. Y al CEO durante el mes del lanzamiento.
- "Investigación: nombre del cliente" Un dashboard parametrizado que abres escribiendo un ID de cliente. Muestra cada acción que los usuarios de ese cliente realizaron en los últimos 30 días, cada error que tocó su cuenta, cada sincronización con el ERP que involucró su registro. Este es el dashboard que desearás tener la primera vez que un cliente diga “ayer pasó algo”.
Alertas que no provocan fatiga de alertas
En los sitios B2B con poco tráfico, las alertas por cada error se disparan constantemente porque los errores individuales parecen estadísticamente significativos. En su lugar, ajustamos para estos patrones:
- Tasa sostenida de HTTP 5xx > 2% durante 10 minutos (no solicitudes aisladas)
- Cualquier health check fallido que dure > 1 minuto
- La sincronización con el ERP no ha tenido éxito en > 30 minutos (el asesino silencioso)
- Más de 30 minutos sin que pase ningún pedido durante una ventana en la que sí debería haberlos, medido contra una línea base de 30 días
Todo lo demás: regístralo, ponlo en un dashboard, pero no generes alertas por ello.
¿Y Application Insights / Datadog / etc.?
Usa lo que el cliente ya tenga. Application Insights es excelente si están muy metidos en Azure. Datadog es excelente si son multinube. Honeycomb es excelente para trazas. La plataforma importa menos que comprometerse con una sola y mantener los logs y las trazas correlacionados dentro de ella. El peor patrón es "tenemos logs en IIS, trazas en App Insights, errores en Sentry y consultas SQL en ninguna parte", tres herramientas entre las que alternas para investigar un solo bug.
La conclusión
La observabilidad B2B es poco glamorosa y de gran apalancamiento. El trabajo real es pequeño: unas pocas horas de configuración de Serilog, unas más para OTel, un día para el dashboard de investigación de clientes. La recompensa es la diferencia entre “ayer un cliente nos llamó por un problema y no sabemos qué pasó” y “aquí está la traza, aquí está la causa, aquí va la corrección hoy mismo”.
Si tu plataforma B2B está en producción y tu estrategia de depuración es “revisar el log de IIS”, habla con nosotros. Tendremos los dashboards listos en la primera semana.