Muestreo de logs para eventos de alto volumen: conservar todos los errores, muestrear las líneas repetitivas

Qué es

El muestreo de logs registra solo una fracción elegida de eventos que, de otro modo, se repetirían miles de veces con poca variación: líneas de depuración por solicitud, aciertos de caché, solicitudes de comprobación de estado, reintentos dentro de un bucle. El README de zerolog muestra las formas habituales del lado del productor: un muestreador básico que conserva un evento de cada N, un muestreador de ráfagas que deja pasar un número de eventos por período y luego entrega el resto a un muestreador de uno de cada N, y un muestreador por nivel que aplica estas reglas solo a los eventos de depuración, mientras que los demás niveles no se muestrean. Las herramientas del lado del pipeline hacen lo mismo a posteriori; la transformación sample de Vector conserva una tasa configurable (uno de cada N) o una proporción, puede aplicar un hash sobre un key_field para que todos los eventos que comparten un valor se conserven o se descarten en conjunto, registra la tasa aplicada en un campo y admite una condición de exclusión para los eventos que nunca deben muestrearse. La página de muestreo de OpenTelemetry describe el equivalente del lado de las trazas: el muestreo en cabecera (head sampling) decide de forma temprana y económica, mientras que el muestreo en cola (tail sampling) decide después de ver la traza completa y, por ello, puede conservar toda traza con un error, algo que el muestreo en cabecera por sí solo no puede garantizar.

Por qué importa

El volumen de logs se paga tres veces: CPU y E/S en el productor, ancho de banda e indexación en el pipeline, y almacenamiento durante el período de retención. El muestreo reduce los tres, pero solo si lo que sobrevive sigue respondiendo a las preguntas que se plantean durante un incidente.

Cómo aplicarlo

• Nunca muestrear advertencias, errores, eventos de auditoría o eventos de seguridad; aplicar el muestreo solo a los niveles informativo y de depuración.
• Basar el muestreo en el ID de solicitud o de traza, de modo que una solicitud conservada esté completa y una descartada esté ausente, en lugar de que todas las solicitudes queden registradas a medias.
• Escribir la tasa de muestreo en los eventos conservados (sample_rate: 100) para poder reescalar los recuentos y para que quien lea los logs sepa qué está viendo.
• Trasladar primero el conteo a métricas; un contador cuesta una muestra por scrape con independencia de cuántos eventos haya contado, mientras que el logging cuesta una línea por evento.
• Preferir ráfaga seguida de tasa antes que un simple uno de cada N para eventos que importan cuando empiezan a producirse: las primeras apariciones de un nuevo modo de fallo llegan sin muestrear.
• Mantener un interruptor para desactivar el muestreo de un servicio concreto durante una investigación, y recordar volver a activarlo.

Trampas

Aplicar el hash sobre una clave cuyos valores están distribuidos de forma desigual cambia la tasa efectiva, como señala la documentación de Vector. Las alertas o los dashboards que cuentan líneas de log se rompen de forma silenciosa cuando se activa el muestreo. Muestrear en el productor y de nuevo en el pipeline compone las tasas. Los logs de cumplimiento normativo que deben estar completos no son un problema de coste que se resuelva con muestreo.