Volumen, costo y pérdida de eventos

El volumen de una regla depende de la frecuencia de lo que vigila, no de su importancia. Vigilar cada apertura de archivo es el ejemplo clásico: el sistema abre archivos todo el tiempo y casi ninguno interesa. Por eso, al medir, se agrupa por clave y se mira cuál concentra la mayor parte de los eventos y de los bytes.

Abre volumen_por_clave.

La política fija un presupuesto de ingesta de auditoría por día, en megabytes. Si lo que se envía lo supera, el exceso o se paga, o se descarta sin decidirlo, o se corta de forma desordenada en el recolector. Hay que medirlo antes de que ocurra, sumando todas las claves.

Suma los megabytes diarios de todas las claves y réstale el presupuesto de politica.

La señal de que la cola de eventos se desbordó es el contador lost del estado de auditoría, que crece mientras el núcleo descarta. Cruzar su historia con los cambios de reglas dice cuándo empezó el problema y qué lo provocó. Lo que ocurrió mientras se perdían eventos no se puede reconstruir después con esta fuente.

Revisa estado_diario y cambios.

Tienes tres salidas posibles a la vez que el servidor pierde eventos: subir el tamaño de la cola, apagar la auditoría o cambiar la regla que genera el ruido. Subir la cola solo retrasa el desbordamiento si el flujo sigue siendo mayor que la capacidad de escritura; apagar la auditoría pierde también lo que sí importa. Lo que ataca la causa es sustituir la regla amplia por reglas dirigidas a los archivos y programas que la política exige vigilar.

Entre el 14 y el 15 de octubre hay un hueco real: eventos que ocurrieron y no se guardaron. Si más adelante alguien pregunta por una de esas fechas, la respuesta honesta no es «no pasó nada», es «no tenemos registro completo de esos días». Esa frase y su causa deben quedar donde las encuentre quien investigue.