Hey devs! Hace poco tuve que hacer un refactor en mi trabajo sobre logs y esos temas, y mientras lo realizaba me dije: ¿por qué no hablar de logging? Así que aquí les tengo un artículo cortito y al pie, pero muy práctico, ¡arranquemos!

En producción no debuggeas.

Buscas en logs.

Y la mayoría de proyectos .NET están mal instrumentados.

¿Por qué importa esto en producción?

En producción no buscas texto, buscas respuestas.
Cuando un incidente ocurre, necesitas filtrar por UserId, OrderId, TenantId o cualquier identificador relevante.
Si tus logs no están estructurados, cada investigación se convierte en una búsqueda manual imprecisa.
Los logs estructurados permiten que cada propiedad sea indexable, filtrable y correlacionable.
Eso reduce drásticamente el tiempo de diagnóstico (MTTR).

Error number 1: Interpolación de Strings

Esto es incorrecto:

_logger.LogInformation($"User {userId} created at {DateTime.Now}");

¿Y por qué es incorrecto?

• No es estructurado para comenzar
• Tampoco es indexable en herramientas de terceros como Datadog, etc.
• Pierde perfomance
• Rompe el concepto de telemetría

Otro error común es usar el mismo nivel para todo.
Information no es lo mismo que Warning, y Error no es lo mismo que Critical.
Una mala clasificación provoca ruido innecesario o, peor aún, oculta problemas reales.
En producción, los niveles deben reflejar la severidad real del evento, no el estado emocional del desarrollador, ojito allí.

Forma correcta con logging estructurado

_logger.LogInformation(
    "User {UserId} created at {CreatedAt}",
    userId,
    DateTime.UtcNow);

¿Y en caso de que quieras capturar excepciones? Así lo harías:

_logger.LogError(
    ex,
    "Error creando el User con id {UserId}",
    userId);

¿Y por qué es mejor así?

Te lo explico rapidito:

• UserId es indexable
• Se puede filtrar por propiedad
• Compatible con herramientas como Serilog, Datadog, etc
• Funciona perfecto con Application Insights por ejemplo
• Es más eficiente
• Es un pequeño cambio pero que genera gran impacto

Como te darás cuenta, aquí es donde dejamos de hacer sólo "prints" y pasamos a pensar más en telemetría y observabilidad.

Por supuesto, sólo estos pequeños cambios no son todo lo que hay que saber de telemetría y observabilidad, pero es un gran comienzo.

Buenas prácticas reales

• Nunca uses interpolación en logs ni mucho menos concatenación
• Usa siempre propiedades {Property}
• Usa UtcNow
• Agrega contexto en middleware, no en servicios
• Diseña logs pensando en producción, no en consola

Cómo esto se conecta con observabilidad

El logging es solo una pieza de la observabilidad.

Una aplicación madura en producción debe permitir:

• Rastrear qué ocurrió (logs)
• Medir qué tan saludable está el sistema (métricas)
• Seguir el recorrido completo de una petición (tracing)

Si tus logs no están diseñados correctamente, toda tu estrategia de observabilidad se debilita.

Así que ahora ya lo sabes dev: Logging no es escribir texto.

En desarrollo, los logs ayudan.
En producción, los logs sostienen el sistema.

Diseñar logs correctamente no es un detalle técnico menor.
Es una decisión arquitectónica.

En artículos posteriores te hablaré de Serilog y cómo integrarlo a tus proyectos para que pases al siguiente nivel. Hasta la próxima, estimados.

¡Si este artículo te ha servido, compártelo! 🎉🐿️

Créditos de imagen de portada: Foto de Willian Justen de Vasconcellos en Unsplash