Linux: ¿cómo enviar nuevas líneas en archivos de registro a syslog remoto?

Tenemos varias aplicaciones que están generando sus propios archivos de registro de texto sin formato, que me gustaría reenviar a un servidor remoto de syslog para el registro centralizado. No tengo acceso rooten estas máquinas, ni puedo reconfigurar syslogpara redirigir la salida a una máquina remota.

He encontrado algunas soluciones en línea, pero en su mayoría son scripts de bash caseros de las personas, y estoy buscando algo más robusto que sea adecuado para la implementación en un entorno de producción de alto volumen potencial.

Preferiblemente, algo diseñado con un ojo para una huella pequeña, un demonio de fondo que sigue funcionando, que puede mantenerse al día con muchas líneas, etc. - ¿Qué soluciones están disponibles actualmente?

Ya ha rechazado los "scripts de bash de otras personas", pero esta es una solución bastante común: un uso creativo del loggercomando puede seguir un archivo y enviar su contenido a otra parte.
Sin embargo, personalmente no haría esto en un entorno de producción.

Se está utilizando una mejor opción que requiere menos piratería de secuencias de comandos rsyslogdy el módulo de entrada de archivos de texto como yoonix mencionó : esta es una solución bastante decente, aunque existe la posibilidad de líneas perdidas durante la rotación de un archivo, y si está en un sistema Linux con rsyslogcomo su demonio syslog no se requiere mucho trabajo adicional.

syslog-ngtambién es compatible con una fuente de entrada de archivo con una funcionalidad similar a rsyslogla de.

En mi humilde opinión, la mejor solución, aunque requiera modificar la aplicación que genera estos registros, es iniciar sesión en syslog directamente. No desea pasar por pasos intermedios, archivos, etc., sysloges el SYStem LOGger, y las cosas que escriben registros en una plataforma Unix deberían enviarlos a syslog.
La implementación de esto, desafortunadamente, se deja como un ejercicio para el lector (y el desarrollador de la aplicación) y puede no ser posible si sus desarrolladores son inexistentes, flojos o incompetentes ...

Puede usar logstash con la entrada del archivo y la salida de syslog .

Por ejemplo, cree una configuración con el archivo (o archivos) que desea monitorear y la información de su servidor syslog.

file-to-syslog.conf:

input { file { path => "/var/log/kern.log" } }
output {
    syslog {
        facility => "kernel"
        host => "syslog.example.com"
        port => 514
        severity => "informational"
    }
}

El inicio logstash con

java -jar logstash-1.2.2-flatjar.jar agent -f file-to-syslog.conf

Pirateé juntos tail.cy logger.cen un solo programa compilado de huella pequeña (binario) que es ligero, rápido y estable. Siempre que tenga acceso de lectura a los archivos de registro, funcionará sin necesidad de privilegios de root.

También realicé un par de mejoras en el registrador nativo y agregué una nueva capacidad (opcional) de insertar una cadena de texto al comienzo de cada línea de registro antes de que se envíe al servidor de registro. El resultado es un programa que se puede ejecutar solo, sin necesidad de utilizar tuberías de shell (es decir, no es necesario tail logfile | logger). Se ejecutará para siempre hasta que se elimine explícitamente o encuentre un error al escribir en el zócalo de la red. Incluso continúa ejecutándose si el archivo de registro se gira o incluso desaparece (solo continuará buscando para ver si el archivo vuelve a aparecer).

Es fácil de usar: solo dele uno o más archivos de registro para monitorear, y cada vez que se escriba una nueva línea en el archivo, enviará una copia de esa línea al servidor syslog local o remoto que especifique. Además de la cadena de texto adicional si usa esa opción.

De hecho, terminé el programa en diciembre, pero estaba esperando que Yahoo tomara los derechos de autor y lo pusiera a disposición, lo que ahora han hecho. (Lo escribí como parte de mi trabajo en Yahoo).

información del programa de registro de archivos y enlace de descarga:

• Publicación de blog sobre el registrador de archivos
• Repo de GitHub para el registrador de archivos

Hay varias formas de abordar esto. Pero la misma, muy primero que debe hacer es: transmita los registros mediante syslog en sí .

Syslog (y muchos reemplazos para syslog) tienen funciones integradas para reenviar el registro a otro servidor syslog en una dirección diferente. Puede hacerlo fácilmente cambiando el archivo de configuración y agregando la dirección para reenviar la instalación. Por ejemplo, agregando esta línea a:

*.*    @192.168.1.1

... reenviaría todas las instalaciones a la máquina en 192.168.1.1, que (con suerte) tiene el servicio en ejecución. El ejemplo que doy aquí es para rsyslog, que es el servidor syslog de stock en Debian, aunque debería funcionar para muchos otros. Consulte la documentación para su implementación de syslog man syslogy vea lo que dice sobre "reenvío".

El servidor remoto de syslog puede ser lo que quieras. Incluso hay productos, como Splunk , que felizmente agregan estos registros en una sola vista con un panel web, búsqueda, notificaciones basadas en eventos, etc., etc. Puede ver más aquí: http://www.splunk.com/ Si que no satisface tus necesidades, puedes usar otra cosa. ¡Incluso hay servidores de syslog que se volcarán a una base de datos SQL!

Claro, podrías escribir tu propio script / programa / servicio para hacer esto por ti, pero ¿por qué reinventar la rueda cuando está hecha para ti y ya te la dieron?

Editar: Así que volví y releí la pregunta, y noté varios comentarios. Suena como:

1. desea agregar sus registros de aplicaciones
2. no tienes acceso a root
3. sus aplicaciones simplemente vuelcan el texto en alguna parte
4. sus aplicaciones no saben cómo escribir en el syslog local
5. no tienes control sobre el código fuente de tu aplicación

Entonces abordemos cada uno en secuencia:

1. syslog estaba destinado a agregar registros juntos. Puedes usar lo que quieras, pero hay una razón por la que ha existido durante mucho tiempo. Está bien probado, bien depurado, bien documentado, conocido y para la mayoría de las plataformas * nix casi universalmente compatibles en un sabor u otro.
2. no necesitamos acceso rootpara configurar el registro. Solo necesitamos acceso a la API de syslog. rootno es un requisito para escribir en el syslog; Si este fuera el caso, todos los servicios que pierden privilegios no podrían escribir diagnósticos en los archivos de registro.

3. Re: volcados de texto, esto es normal. sin embargo, debería poder usar un subshell para canalizar la salida de STDERR y STDOUT a un programa que llame a la API syslog. Esto no es ciencia espacial, está lejos de ser frágil y está bien documentado. De hecho, es una de las razones por las que incluso existe la redirección de salida. Un comando simple que podría lanzarse en un solo script de shell sería:

   (my-application 2> & 1 | my-syslog-shunt) &

4. Si tiene la capacidad de alterar el código fuente de su aplicación, debe escribir una derivación en él para volcar la salida de texto en syslog en lugar de un archivo de texto sin formato. Esto no debería ser demasiado difícil; todo lo que debe hacer es tomar las líneas que generaría y envolverlas con una llamada. Sin embargo....

5. es posible que no tenga acceso al código fuente, por lo que no puede hacer esto. Lo que significa que algo como el # 3 anterior funcionaría bien.

Estoy respondiendo mi propia pregunta.

La muestra podría haber funcionado, pero no pude hacer que el módulo Sys :: Syslog de perl funcione en el host, y el / usr / bin / logger que se instaló en el host no admite el registro en el servidor remoto (util-linux-ng- 2.17.2).

Entonces, lo primero que hice fue descargar el código fuente de util-linux-2.20.1 para el cual el programa registrador admite el registro remoto. Tras la prueba, se hizo evidente que hay un límite impuesto en la cantidad de caracteres permitidos en la línea de registro. Al profundizar en el código fuente, encontré un límite de 400 caracteres codificado. (Si no me cree, ejecute "strings / usr / bin / logger | grep 400" en cualquier sistema Linux).

Este límite no es aceptable para el registro de tipo apache (incluidos los nodejs), por lo que modifiqué el código y aumenté el límite a 4096. Mientras lo hacía, también agregué una nueva opción de línea de comandos que permite insertar una opción cadena de texto al comienzo de cada línea de registro. Hice esto porque los registros de nodejs no incluyen el nombre de host como se podría ver en apache.

En este punto, podría ejecutar un script de shell con "tail -F -n 0 [logfile] | ./modified_logger ...." y funcionó. Pero tenía algunas preocupaciones acerca de ejecutar esto desde supervise (daemontools) o incluso en segundo plano, porque si uno u otro lado de la tubería termina, entonces existe el riesgo de que toda la tubería termine. También tenía preocupaciones (aunque no probadas) sobre el rendimiento.

así que decidí combinar la funcionalidad de la cola con la funcionalidad del registrador en un solo binario ejecutable que evitaría la necesidad de usar tuberías Unix o programas externos. Lo hice pirateando tail.c desde gnu coreutils e incorporando lo que necesito en el programa de registro modificado.

El resultado es un nuevo binario (tamaño de 117k) al que llamo "registrador de archivos" y que monitorea continuamente uno o más archivos y registra cada nueva línea en un syslog local o remoto, ya sea a través de UDP o TCP. Funciona a las mil maravillas. Pude hacer un pequeño benchmarking y registra aproximadamente 17,000 líneas (1.8MB) en aproximadamente 3 segundos a través de subredes con un vlan y un par de conmutadores físicos entre ellos, en un servidor remoto que ejecuta syslog-ng.

para ejecutar el programa, debe hacer algo como lo siguiente (ya sea en primer plano, en segundo plano o supervisado con daemontools):

./filelogger -t 'acceso' -d -p local1.info -n [control remoto] -u / tmp / ignorado -a $ (nombre de host) / tmp / myfile1 / tmp / myfile2 ...

/ tmp / myfile1 y / tmp / myfile2 son los archivos que se monitorean.

La "-a" es la nueva opción que agregué. En este caso, inserto el nombre de host local al comienzo de cada línea de registro.

Esta solución era exactamente el tipo de solución que estaba buscando cuando hice la pregunta y, como resultó, no existía hasta que la hice yo mismo. :)