Reenvío de journald y recolección remota: ForwardToSyslog, systemd-journal-upload/-remote y límites de tasa

Objetivo

Sacar las entradas del journal de un host fuera de ese host, ya sea entregándolas a la pila local de syslog (para reenviarlas después con rsyslog) o enviándolas directamente a un colector remoto de journal, sin perder entradas de forma silenciosa por el limitador de tasa interno de journald.

Requisitos previos

Acceso root; systemd con los paquetes systemd-journal-upload/systemd-journal-remote instalados si se usa el envío directo; un par de certificados si se usa HTTPS (las herramientas también admiten HTTP plano, pero no se recomienda en una red no confiable).

Pasos

1. Para alimentar un pipeline existente de rsyslog/syslog, establezca ForwardToSyslog=yes en /etc/systemd/journald.conf o en un drop-in dentro de /etc/systemd/journald.conf.d/. Según journald.conf(5), con esto journald pasa cada entrada al socket syslog tradicional, y el módulo imuxsock de rsyslog la recoge como cualquier otra fuente de syslog. En el upstream el valor por defecto es no; Debian y Ubuntu lo cambian a yes mediante un parche. El rsyslog de RHEL lee el journal directamente con imjournal, así que allí no hace falta ningún cambio.
2. Para enviar los datos del journal directamente, configure el emisor: en /etc/systemd/journal-upload.conf se define URL=https://collector.example.org:19532 según journal-upload.conf(5). Inicie y habilite systemd-journal-upload.service; su descripción indica que sube las entradas del journal a la URL indicada con --url=/URL=, leyendo de los archivos de journal locales y siguiendo con el envío de las entradas nuevas a medida que aparecen.
3. En el colector, habilite systemd-journal-remote.socket (puerto 19532 por defecto); systemd-journal-remote.service recibe los datos del journal en el formato de exportación del journal descrito en su propia página de manual y los escribe en archivos de journal bajo /var/log/journal/remote/. Configure su clave y certificado TLS en /etc/systemd/journal-remote.conf (ServerKeyFile=, ServerCertificateFile=, TrustedCertificateFile=).
4. Revise el limitador de tasa propio de journald antes de confiar en cualquiera de las dos vías para obtener datos completos. Según journald.conf(5), RateLimitIntervalSec= y RateLimitBurst= establecen que, cuando un servicio registra más de RateLimitBurst= mensajes dentro de RateLimitIntervalSec= (por defecto 10000 mensajes en 30 segundos, valor que se incrementa con un factor que depende del espacio libre en disco del journal), los mensajes siguientes de ese servicio dentro del intervalo se descartan; journald registra entonces una entrada "Suppressed N messages from <unit>". Las entradas descartadas nunca llegan a ninguna vía de reenvío, ni local ni remota. Aumente el valor de ráfaga, póngalo en 0 (desactivado) o sobrescríbalo por unidad con LogRateLimitIntervalSec=/LogRateLimitBurst= para los servicios de los que se espera mucho volumen de logs durante incidentes.
5. Aplique los cambios: systemctl restart systemd-journald para journald.conf y systemctl restart systemd-journal-upload para journal-upload.conf.

Resultado esperado

journalctl -u systemd-journal-upload -f no muestra errores de conexión repetidos; en el colector, journalctl -D /var/log/journal/remote --list-boots muestra entradas de los boot ID del host remoto.

Límites y base de verificación

Basado en journald.conf(5), journal-upload.conf(5), systemd-journal-upload.service(8) y systemd-journal-remote.service(8). Para deshacer los cambios, detenga y deshabilite la unidad y elimine el archivo drop-in. Un servicio ruidoso que alcance el límite de tasa mostrará huecos tanto en el origen como en cualquier colector remoto; cuando parezca que faltan entradas, busque primero "Suppressed" en el journal en lugar de suponer un problema de red.