Logger: diseño para diagnósticos en producción

# Diseño de Logger: Priorizando Diagnósticos y Control en Producción

En sistemas en producción, los loggers no se evalúan por la velocidad de su API, sino por lo rápido que ayudan a diagnosticar incidentes sin añadir carga extra. El registro genera sobrecarga, por lo que se minimiza en operaciones normales. Pero cuando surgen problemas, detalles escasos o logs caóticos hacen imposible la resolución de fallos. Un buen logger garantiza la diagnosticabilidad sin sacrificar el rendimiento.

El problema surge cuando la estructura de los logs refleja el código en lugar de los procesos de negocio. En sistemas multihilo, los mensajes de distintas tareas se entremezclan, complicando el seguimiento de una solicitud específica.

Vinculando Contexto a Tareas

La solución es asociar los logs a las tareas, no a los puntos de llamada. Pasar contexto mediante parámetros ensucia las firmas de funciones. Mejor vincularlo al hilo de ejecución.

En logme, esto se hace mediante canales de hilo:

auto requestCh = Logme::Instance->CreateChannel(Logme::ID("req-42"));
LogmeThreadChannel(requestCh);
HandleRequest();

El código interno registra en el canal automáticamente:

void ParseHeaders() {
    LogmeW("invalid header");
}

Los logs ahora se agrupan por operación. En spdlog y Quill, el contexto gira en torno al logger, lo que es más simple pero menos ideal para tareas.

Otro problema es el ruido de mensajes repetidos. Los errores de reintento inundan los logs con duplicados. Límites a nivel de evento lo solucionan:

LogmeW(LOGME_ONCE4THIS, "disk is full");

El mensaje aparece una vez por instancia de clase, manteniendo los logs legibles.

Enrutamiento Flexible de Mensajes

La configuración global no basta. En HTTP/2, hay que separar logs de conexión y solicitud. El canal de solicitud se enlaza al de protocolo, pero los detalles de la solicitud no deben saturar el log principal.

Logme::Override ovr;
ovr.Add.DisableLink = true;
LogmeI(ovr, "request-specific detail");

Esto aísla el mensaje en el canal local. Eventos generales se ven en todas partes; los privados quedan locales.

Sub sistemas para Detalles Precisos

Una dimensión (canal) no es suficiente. Las tareas tienen subsistemas: caché, red, análisis. Registra selectivamente:

LOGME_SUBSYSTEM(cacheSid, "cache");
LOGME_SUBSYSTEM(parserSid, "parser");

LogmeD(cacheSid, "cache miss");
LogmeD(parserSid, "header parsed");

En tiempo de ejecución, activa solo el subsistema necesario, como caché. Los demás callan, manteniendo logs compactos.

Integración con Bibliotecas

Las bibliotecas de terceros tienen su propio registro. Lo interceptamos e integramos:

void FfmpegLogCallback(void* ptr, int level, const char* fmt, va_list args) {
    char buffer[2048];
    vsnprintf(buffer, sizeof(buffer), fmt, args);

    Logme::Override ovr;
    ovr.Add.DisableLink = true;

    LogmeW(ovr, "[ffmpeg] %s", buffer);
}

Los mensajes siguen las mismas reglas: canales, subsistemas, desduplicación.

El soporte de formatos facilita la migración:

LogmeI("value=%i", value);
fLogmeI("value={}", value);
LogmeI() << "value=" << value;

logme combina estilos fmt y stream, a diferencia de spdlog (solo fmt) y Quill (fmt asíncrono).

Control en Producción sin Reinicios

En sistemas siempre activos, los logs son mínimos en condiciones normales. Durante incidentes:

• ¿Sospecha del caché? Activa su subsistema.
• Aísla la tarea vía canal.
• Limita repeticiones.

El control es dinámico mediante logmectl: niveles, subsistemas, sin reinicios.

Tras la solución, reduce detalles. De lo contrario, elevar logs globales causa sobrecarga.

spdlog prioriza velocidad, Quill asincronía, logme control de flujo de mensajes manteniendo rendimiento.

Lecciones clave:

• Los loggers deben agrupar por tareas vía canales, no loggers.
• Desduplicación a nivel de evento reduce ruido.
• Subsistemas permiten detalles dirigidos en runtime.
• Integración de bibliotecas unifica salida.
• Control dinámico sin reinicios es esencial en producción.

— Editorial Team