Guía Completa: Cómo Montar un Servidor Centralizado de Logs con Rsyslog

Por qué centralizar logs es esencial para su infraestructura

En entornos con múltiples servidores Linux — ya sean físicos, virtualizados en Proxmox o instancias en la nube — uno de los mayores desafíos operativos es la visibilidad. Cuando ocurre un incidente, el tiempo perdido iniciando sesión en cada servidor individualmente para buscar mensajes de error es tiempo que su equipo no tiene, especialmente en entornos críticos como centros de datos de salud o infraestructura industrial.

Un servidor de agregación de logs resuelve este problema centralizando todo en un único punto, permitiendo:

• Correlación de eventos entre múltiples servidores durante un incidente

• Retención y auditoría centralizada, esencial para el cumplimiento (LGPD, ISO 27001)

• Supervivencia de los logs incluso si el servidor de origen se ve comprometido o destruido

• Alertas centralizados integrando con herramientas como Zabbix, Grafana o pipelines de análisis mediante LLM

• Reducción de ruido operativo, con un único lugar para paneles y búsquedas

En esta guía vamos a construir, desde cero, un servidor central de logs usando rsyslog, la herramienta estándar de sistema de registro en prácticamente todas las distribuciones Linux empresariales (RHEL, Oracle Linux, Ubuntu, Debian).

Arquitectura de la solución

┌─────────────────┐     TCP/UDP 514      ┌──────────────────────┐
│  Servidor Web     │ ────────────────►   │                      │
├─────────────────┤                      │                      │
│  Servidor Oracle  │ ────────────────►   │   Servidor Central    │
├─────────────────┤     TLS 6514          │   Rsyslog             │
│  Servidor AD/DC   │ ────────────────►   │   /var/log/clients/   │
├─────────────────┤                      │                      │
│  Firewall/Proxy   │ ────────────────►   │                      │
└─────────────────┘                      └──────────────────────┘

Cada servidor cliente envía sus logs por la red al servidor central, que los organiza en directorios separados por nombre de host, aplicando rotación y retención configurables.

1. Preparando el servidor central

Se recomienda una máquina dedicada (física o VM) con recursos proporcionales al volumen de logs esperado. Para entornos pequeños y medianos (hasta ~30 servidores cliente), una VM con 2 vCPUs, 4 GB de RAM y un disco separado para /var/log (idealmente en un pool ZFS o LVM con espacio para crecer) ya es suficiente.

1.1 Instalación de rsyslog

En la mayoría de las distribuciones basadas en RHEL/Oracle Linux, rsyslog ya viene instalado por defecto. Para garantizar la versión más reciente:

# Oracle Linux / RHEL / CentOS
sudo dnf install -y rsyslog rsyslog-relp

# Debian / Ubuntu
sudo apt update
sudo apt install -y rsyslog rsyslog-relp

Verifique la versión instalada (se recomienda 8.x o superior para soporte completo de TLS y RELP):

rsyslogd -v

1.2 Habilitando el servicio

sudo systemctl enable rsyslog
sudo systemctl start rsyslog
sudo systemctl status rsyslog

2. Configurando el servidor central para recibir logs

El archivo principal de configuración es /etc/rsyslog.conf, pero la buena práctica es crear archivos separados en /etc/rsyslog.d/ para mantener todo organizado y facilitar el mantenimiento futuro.

2.1 Habilitando los módulos de recepción

Cree el archivo /etc/rsyslog.d/00-listen.conf:

sudo nano /etc/rsyslog.d/00-listen.conf

Contenido:

# Módulo para receber via UDP (mais leve, porém sem garantia de entrega)
module(load="imudp")
input(type="imudp" port="514")

# Módulo para receber via TCP (recomendado, com garantia de entrega)
module(load="imtcp")
input(type="imtcp" port="514")

# Aumenta o limite de conexões TCP simultâneas
$MaxOpenFiles 65536
$InputTCPServerMaxSessions 500

Nota técnica: para entornos críticos, priorice siempre TCP en lugar de UDP. UDP no garantiza la entrega de los paquetes — en caso de picos de tráfico o saturación de red, puede perder eventos importantes sin ningún aviso.

2.2 Organizando los logs por servidor de origen (plantilla dinámica)

Uno de los mayores errores en servidores de log centralizados es volcar todo en un único archivo /var/log/messages, mezclando eventos de decenas de servidores diferentes. La práctica correcta es usar plantillas dinámicas para separar por nombre de host y fecha.

Cree el archivo /etc/rsyslog.d/10-templates.conf:

# Template que organiza logs por hostname/ano-mes/dia
template(name="DynamicFile" type="string"
  string="/var/log/clients/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log")

# Aplica o template a tudo que não seja do próprio servidor local
if $fromhost-ip != '127.0.0.1' then {
  action(type="omfile" dynaFile="DynamicFile")
  stop
}

Esta regla hace que:

• Los logs del propio servidor central continúen yendo a /var/log/messages normalmente

• Los logs recibidos por la red se graben en /var/log/clients/<hostname>/<data>.log

• El stop evita que el mensaje también se duplique en los logs locales del servidor central

Cree el directorio base con los permisos correctos:

sudo mkdir -p /var/log/clients
sudo chown syslog:adm /var/log/clients   # Debian/Ubuntu
# ou
sudo chown root:root /var/log/clients    # RHEL/Oracle Linux
sudo chmod 750 /var/log/clients

2.3 Reiniciando el servicio

sudo systemctl restart rsyslog
sudo ss -tulpn | grep 514

Debería ver rsyslog escuchando en los puertos 514 (TCP y UDP).

3. Configurando los servidores cliente (envío de logs)

En cada servidor Linux que debe enviar logs al servidor central, cree el archivo /etc/rsyslog.d/90-forward.conf:

sudo nano /etc/rsyslog.d/90-forward.conf

Contenido (sustituya por la IP o nombre de host real de su servidor central):

# Envio via TCP com buffer em disco em caso de falha de rede (recomendado)
$ActionQueueFileName fwdQueue
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionQueueType LinkedList
$ActionResumeRetryCount -1

*.* @@srv-logs.nyverra.local:514

Observe el uso de @@ (dos arrobas), que indica envío mediante TCP. Un único @ indicaría UDP.

Las directivas de cola (ActionQueue*) garantizan que, si la red se cae o el servidor central queda indisponible, los logs queden almacenados en disco localmente y se reenvíen automáticamente en cuanto se restablezca la conexión — evitando la pérdida de eventos durante mantenimientos o inestabilidades de red.

Reinicie rsyslog en el cliente:

sudo systemctl restart rsyslog

3.1 Probando el envío

En el cliente, genere un mensaje de prueba:

logger "Teste de envio de log centralizado - $(hostname)"

En el servidor central, verifique si el mensaje llegó:

tail -f /var/log/clients/<hostname-do-cliente>/*.log

4. Seguridad: cifrando el transporte con TLS

Enviar logs en texto plano por la red es una práctica arriesgada, especialmente si el tráfico pasa por segmentos de red compartidos o WAN. Los logs frecuentemente contienen información sensible (intentos de inicio de sesión, IPs internas, datos de aplicación).

4.1 Generando certificados

Para entornos internos, puede usar una CA propia (recomendado) o reutilizar su infraestructura de PKI existente. Ejemplo simplificado con OpenSSL:

# No servidor central, gerando uma CA própria para os logs
sudo mkdir -p /etc/rsyslog.d/certs
cd /etc/rsyslog.d/certs

openssl genrsa -out ca-key.pem 4096
openssl req -new -x509 -days 3650 -key ca-key.pem -out ca-cert.pem \
  -subj "/CN=Nyverra-Log-CA"

# Certificado do servidor
openssl genrsa -out server-key.pem 2048
openssl req -new -key server-key.pem -out server.csr \
  -subj "/CN=srv-logs.nyverra.local"
openssl x509 -req -days 365 -in server.csr -CA ca-cert.pem -CAkey ca-key.pem \
  -CAcreateserial -out server-cert.pem

Distribuya el ca-cert.pem a todos los clientes que vayan a enviar logs.

4.2 Configurando TLS en el servidor central

Añada a /etc/rsyslog.d/00-listen.conf:

module(load="imtcp"
  StreamDriver.Name="gtls"
  StreamDriver.Mode="1"
  StreamDriver.AuthMode="anon")

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca-cert.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/certs/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/certs/server-key.pem"
)

input(type="imtcp" port="6514")

4.3 Configurando TLS en el cliente

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/certs/ca-cert.pem"
)

action(type="omfwd"
  target="srv-logs.nyverra.local"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="anon"
)

Reinicie rsyslog en ambos lados y valide el tráfico cifrado con tcpdump (el contenido debe ser ilegible, a diferencia del puerto 514 sin TLS).

5. Firewall y liberación de puertos

No olvide liberar los puertos en el firewall del servidor central. Ejemplo con firewalld (RHEL/Oracle Linux):

sudo firewall-cmd --permanent --add-port=514/tcp
sudo firewall-cmd --permanent --add-port=514/udp
sudo firewall-cmd --permanent --add-port=6514/tcp   # se estiver usando TLS
sudo firewall-cmd --reload

Con ufw (Debian/Ubuntu):

sudo ufw allow 514/tcp
sudo ufw allow 514/udp
sudo ufw allow 6514/tcp

Si hay un firewall perimetral (pfSense, Fortinet) entre los servidores, asegúrese de que las reglas de liberación se realicen solo entre las redes/VLAN específicas de gestión — nunca exponga los puertos de recepción de logs a redes públicas o no confiables.

6. Rotación y retención de logs

Con múltiples servidores enviando logs continuamente, el disco del servidor central puede crecer rápidamente. Configure logrotate para gestionar esto automáticamente.

Cree /etc/logrotate.d/rsyslog-clients:

/var/log/clients/*/*.log {
    daily
    missingok
    rotate 90
    compress
    delaycompress
    notifempty
    create 640 root adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate 2>/dev/null || true
    endscript
}

Este ejemplo mantiene 90 días de historial con compresión, un equilibrio razonable entre espacio en disco y necesidad de auditoría. Ajuste rotate según la política de retención exigida por su sector (hospitales y clínicas, por ejemplo, suelen tener requisitos de retención más largos debido a auditorías).

7. Yendo más allá: integración con Zabbix y análisis inteligente

Una vez que los logs están centralizados, el siguiente paso natural es transformar esos datos brutos en inteligencia operativa:

• Zabbix puede monitorear archivos de log mediante items log[] o consumir alertas generadas a partir de patrones específicos (fallos de autenticación, errores de aplicación, uso crítico de disco)

• Elasticsearch + Kibana o Grafana Loki pueden usarse como capa de búsqueda y visualización sobre los logs ya centralizados por rsyslog, sin sacrificar la simplicidad y confiabilidad de rsyslog como capa de transporte

• Los pipelines de análisis automatizado (mediante LLM o reglas) pueden consumir estos logs para generar resúmenes diarios de incidentes, reduciendo el tiempo de triaje manual del equipo de infraestructura

Checklist final de implementación

• Rsyslog instalado y actualizado en el servidor central y en todos los clientes
• Recepción mediante TCP habilitada (preferiblemente con TLS en producción)
• Plantillas dinámicas configuradas para separar logs por nombre de host/fecha
• Cola de retransmisión local configurada en los clientes (`ActionQueue*`)
• Certificados TLS generados y distribuidos, si procede
• Puertos liberados solo en las redes de gestión, nunca públicamente
• Logrotate configurado con una política de retención adecuada a su sector
• Prueba de conmutación por error: desconectar temporalmente la red del cliente y validar que los logs no se pierden

Conclusión

Montar un servidor de agregación de logs con rsyslog es una inversión relativamente sencilla, usando herramientas nativas de Linux, que aporta un enorme retorno en capacidad de respuesta a incidentes, auditoría y cumplimiento. Para entornos B2B — especialmente en sectores regulados como salud e industria — esta centralización no es solo una buena práctica técnica, es a menudo un requisito de cumplimiento.

En Nyverra, ayudamos a las empresas a estructurar este tipo de infraestructura de observabilidad de forma sólida y a medida, ya sea en entornos on-premise, virtualizados en Proxmox o híbridos. Si su empresa aún no tiene una estrategia de centralización de logs, este es un excelente punto de partida.

¿Necesita ayuda para implementar esta arquitectura en su empresa? Hable con el equipo de Nyverra.