Que Auditd esté activo no significa que todos los registros lleguen a su destino. Para comprobar si hay pérdidas, revisa primero el estado del servicio, después la cola de auditoría del kernel y, por último, los mensajes de Auditd. Cada comprobación responde a una pregunta distinta.
Comprobar que Auditd está activo
systemctl is-active auditd
systemctl status auditdSi el servicio no está activo, revisa sus mensajes con sudo journalctl -u auditd -b. Si figura como active, sigue con el estado del kernel. El servicio puede continuar activo aunque se haya suspendido la escritura en disco.
Leer la cola y el contador de pérdidas
sudo auditctl -spididentifica el proceso de Auditd registrado en el kernel. Si vale0, no hay ninguno registrado.enabledindica el estado de la auditoría del kernel.0significa desactivada,1activada y2activada con la configuración bloqueada hasta el siguiente arranque.backlogindica cuántos registros están pendientes en la cola del kernel en ese instante.backlog_limites el límite configurado para esa cola.lostcuenta los registros de auditoría que el kernel ha descartado desde el arranque o desde el último reinicio del contador. Un evento puede constar de varios registros, así que esta cifra no equivale necesariamente al número de eventos completos perdidos.
Anota la hora y los valores de backlog y lost. Repite la consulta unos minutos después, preferiblemente durante el periodo de carga que quieres investigar. Si lost pasa de 12 a 19, el kernel ha descartado siete registros entre ambas lecturas. Si permanece en 12, confirma pérdidas anteriores, pero no nuevas pérdidas del kernel en ese intervalo.
Una cola que se mantiene cerca de su límite indica presión, pero no demuestra que ya se hayan perdido registros. Del mismo modo, una cola vacía ahora no descarta que se haya llenado antes. Conserva las lecturas en lugar de poner el contador a cero durante el diagnóstico.
Distinguir una pérdida del kernel de un problema de escritura
Si aumenta lost, compara la hora de las lecturas con los mensajes del kernel. Busca avisos sobre la cola de auditoría o el límite de mensajes por segundo. Un incremento del contador confirma la pérdida, pero no identifica por sí solo su causa ni los registros afectados.
sudo journalctl -k --since "15 minutes ago"
sudo journalctl -u auditd --since "15 minutes ago"Si lost no aumenta pero faltan registros en disco, revisa si Auditd notificó falta de espacio, errores de escritura o una suspensión del registro. Si el problema solo aparece en el destino remoto, revisa también el complemento de reenvío. Auditd tiene una cola interna para los complementos distinta de la cola del kernel que muestra auditctl -s.
Un lost=0 solo indica que el kernel no contabiliza descartes en ese periodo del contador. No demuestra que la actividad estuviera cubierta por una regla ni que todo lo recibido se guardara o reenviara. Si necesitas revisar qué actividad registran tus reglas, vuelve a la guía de Auditd en Ubuntu.