Este artículo nos mostrará cómo usar Rsyslog para configurar Linux como un servicio de registro centralizado. Al administrar registros de varios sistemas, una configuración centralizada de Rsyslog es ventajosa. Todas las entradas de registro de los servidores del cliente se enviarán al servidor host, lo que permitirá monitorearlas y conservarlas en una ubicación. En comparación con ingresar a cada servidor para estudiar sus registros, esta estrategia facilita considerablemente la administración del sistema, especialmente si hay muchos servidores. Comencemos con la configuración del servidor de registro central.
Requisito previo
- Mínimo 2 máquinas Linux (Aquí máquina nos referimos a 2 instancias de Linux. Puede ser una VM o una VM y una Máquina).
- Todos deben estar en la red y accesibles.
- El servicio rsyslog está activo y funcionando en ambas máquinas.
Pasos para configurar el servidor de registro central con Rsyslog en Linux
Paso 1 : Configure la máquina-1 como un servidor de registro central.
Por defecto, rsyslog usa «imjournal» e «imuxsock»módulos para importar mensajes de registro estructurados desde systemd journal y para aceptar mensajes rsyslog de aplicaciones que se ejecutan en el sistema local a través de sockets Unix, respectivamente.
Se pueden utilizar dos protocolos para la recepción de los mensajes de registro en la máquina servidor «TCP» y «UDP» que utiliza el número de puerto «514» de forma predeterminada.
Usar una conexión TCP que sea más lenta pero confiable. Busque y descomente las líneas a continuación
$ModLoad imtcp $InputTCPServerRun 514
Usar una conexión UDP que es más rápida y poco confiable. buscar y descomentar las líneas de abajo
$ModLoad imudp $UDPServerRun 514
Podemos usar un puerto que no sea 514. Necesitamos abrir ese puerto desde iptables y también debemos desactivar la regla de firewall para ese puerto. Vamos a usar TCP para propósitos de prueba si queremos podemos usar UDP o ambos.
Paso 2 : Configure el destino de los registros en la máquina del servidor.
Los mensajes de registro que recibiremos en la máquina del servidor debemos almacenarlos en un archivo de registro específico. Para eso, necesitamos configurar la regla en el archivo rsyslog.conf.
facility.severity_level destination
- Facilidad: es un tipo de generación de procesos/aplicaciones, incluyen auth, cron, daemon, kernel, local0..local7. El uso de «*» significa todas las instalaciones.
- severity_level: es el tipo de mensaje de registro: emerg-0, alert-1, crit-2, err-3, warn-4, Notice-5, info-6, debug-7. El uso de «*» significa todos los niveles de gravedad y ninguno implica ningún nivel de gravedad.
- destino: es un archivo local o un servidor rsyslog remoto (definido en la forma IP: puerto).
Usaremos el siguiente conjunto de reglas para recopilar registros de clientes remotos.
$template DynamicFile,”/var/log/loghost/%fromhost-ip%.log”
si no ($fromhost-ip == ‘127.0.0.1’) entonces {
*.* -?DynamicFile
}
2.1 : Configure la regla para el destino del registro.
Necesitamos poner esta regla antes que todas las reglas en rsyslog.conf
Ahora, reinicie rsyslog.service para cargar la configuración.
[root@vm-dev ~]# systemctl reiniciar rsyslog.service
2.2 : Para abrir el puerto para escuchar, debemos establecer reglas en SELinux o Firewall, cualquiera que sea el que estemos usando.
$sudo firewall-cmd –permanente –añadir-puerto=514/udp
$sudo firewall-cmd –permanente –añadir-puerto=514/tcp
$sudo firewall-cmd –recargar
2.3 : Para comprobar que el puerto está abierto y escuchando el registro mediante la utilidad «netstat» .
[root@vm-dev ~]# netstat -tulpn
Nos mostrará que el puerto 514 está escuchando tanto en ip4 como en ipv6.
Paso 3 : Configure la máquina cliente para enviar registros.
Para configurar la máquina cliente usaremos el método heredado que es simple de entender y que es parte de rsyslog.conf.
Esto obligará al demonio rsyslog a enviar todos los registros al servidor rsyslog remoto. Como este es el método heredado. Si no se puede acceder al sistema remoto, el procesamiento se bloqueará aquí y descartará los mensajes después de un tiempo.
# Método heredado
# host remoto es: nombre/ip:puerto, por ejemplo, 192.168.0.1:514, puerto opcional
#facilidad.prioridad @@host-remoto:puerto-remoto
*.* @@host-remoto:514
# Nuevo método
*.* action(type=”omfwd” target=”remote-host” port=”hots-port” protocol=”tcp”
action.resumeRetryCount=”cuenta de reintentos”
queue.type=”linkedList” queue.size=”mensaje-cola-tamaño”)
Estamos utilizando el método heredado tal como está, por lo que reenviará todos los mensajes al servidor rsyslog remoto. Reemplace el host remoto con la IP de la máquina del servidor. Simplemente descomente la siguiente línea y reinicie el servicio rsyslog en la máquina cliente.
Reinicie el servicio rsyslog.
[root@vm-dev ~]# systemctl reiniciar rsyslog.service
Paso 4 : pruebe la configuración con el comando logger.
Vamos a probar nuestra configuración con el « registrador « que proporciona rsyslog como una interfaz CLI para iniciar sesión.
Cliente-Máquina
[root@centos ~]# logger -t myApp -p local0.emerg “Hola, este es el mensaje de prueba”
Máquina cliente:
Servidor-Máquina:
Como podemos ver, se está creando un nuevo archivo de registro en la máquina del servidor. La máquina servidor puede recibir todos los registros de la máquina cliente. Si tenemos problemas para recibir mensajes del servidor, consulte nuestras reglas de firewall. La mayoría de las veces, los puertos están bloqueados desde el firewall en el servidor y también en la máquina cliente. Además, debemos verificar si la máquina del servidor y la máquina del cliente son accesibles entre sí.
Publicación traducida automáticamente
Artículo escrito por pokharkaromkar y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA