Cómo mantener los mensajes de registro de haproxy fuera de /var/log/syslog

Cómo mantener los mensajes de registro de haproxy fuera de /var/log/syslog

Configuré el registro de haproxy a través de rsyslogd usando los consejos deEste artículo, y todo parece estar funcionando bien. Los archivos de registro reciben los mensajes de registro.

Sin embargo, todos los mensajes de registro de haproxy también aparecen en /var/log/syslog. Esto significa que una vez que el servidor entre en funcionamiento, el syslog será bastante inútil, ya que será sobrecargado con mensajes de registro de haproxy.

Me gustaría filtrar esos mensajes de /var/log/syslog. Después de revisar la documentación de rsyslogd, intenté cambiar el archivo /etc/rsyslog.d/50-default.confde esta manera:

*.*;auth,authpriv.none;haproxy.none     -/var/log/syslog

Simplemente agregué la ;haproxy.noneparte. Después de reiniciar rsyslogd, dejó de funcionar por completo hasta que revertí mis cambios.

¿Qué estoy haciendo mal?

Respuesta1

También puede hacer lo siguiente para que no aparezcan en ningún otro registro:

local0.*                        -/var/log/haproxy.log
& ~

Esto & ~significa no colocar lo que coincida en la línea anterior en ningún otro lugar durante el resto de las reglas.

Respuesta2

El uso de & ~quedó obsoleto en la versión 7 de rsyslogd y se le recomienda utilizarlo & stopen su lugar. Puedes leer más al respecto en esta sección delpágina de compatibilidad v7.

Las acciones omruleset y descartar (~) están en desuso

Ambos siguen funcionando, pero han sido reemplazados por mejores alternativas.

La acción de descartar (tilde) ha sido reemplazada por la directiva "detener" de RainerScript. Se considera más intuitivo y ofrece un rendimiento ligeramente mejor.

El módulo omruleset ha sido reemplazado por la directiva "llamar" RainerScript. Call permite ejecutar un conjunto de reglas como una subrutina y lo hace con un rendimiento mucho mayor que omruleset. Tenga en cuenta que omruleset podría ejecutarse desde una cola asíncrona. Esto fue más un efecto secundario que un efecto deseado y no está respaldado por la declaración de la convocatoria. Si ese efecto fuera necesario, simplemente se puede simular ejecutando las acciones del conjunto de reglas llamadas de forma asincrónica (lo que en cualquier caso es la forma correcta de manejar esto).

Tenga en cuenta que los módulos obsoletos emiten mensajes de advertencia cuando se utilizan. Indican que la construcción está en desuso y qué declaración se utilizará como reemplazo. Esto no afecta las operaciones: ambos módulos aún están en pleno funcionamiento y no se eliminarán en el plazo de la versión 7.

Entonces, para HAProxy, algo como esto:

$ more /etc/rsyslog.d/haproxy.conf
local2.*    /var/log/haproxy.log
& stop

En cuanto a cómo funciona, & stople dice a rsyslogd que descarte cualquier mensaje adicional que coincida con las reglas previamente coincidentes hasta este punto. Para garantizar que esta regla se aplique desde el principio, puede cambiar el nombre del archivo de /etc/rsyslog.d/haproxy.confa /etc/rsyslog.d/00-haproxy.conf.

Respuesta3

Bien, lo descubrí. Así es como /etc/rsyslog.d/20-haproxy.confse ve mi:

$ModLoad imudp
$UDPServerRun 514

local0.* -/var/log/haproxy_0.log
local1.* -/var/log/haproxy_1.log

Cambié la línea 50-default.confa:

*.*;auth,authpriv,local0,local1.none     -/var/log/syslog

Y ahora parece estar haciendo lo que quiero.

Respuesta4

Prefiero no meterme con el orden del archivo, así que agrego un local0.none al.entrada de línea. La configuración se ve así:

*.info;mail.none;authpriv.none;cron.none;local2.none     /var/log/messages

local2.*                                                 /var/log/haproxy.log

(Probado en CentOS 7)

¡Espero que ayude!

información relacionada