Guia Completo: Como Montar um Servidor Centralizado de Logs com Rsyslog

Por que centralizar logs é essencial para sua infraestrutura

Em ambientes com múltiplos servidores Linux — sejam eles físicos, virtualizados em Proxmox, ou instâncias em nuvem — um dos maiores desafios operacionais é a visibilidade. Quando um incidente acontece, o tempo perdido logando em cada servidor individualmente para caçar mensagens de erro é tempo que sua equipe não tem, especialmente em ambientes críticos como datacenters de saúde ou infraestrutura industrial.

Um servidor de agregação de logs resolve esse problema centralizando tudo em um único ponto, permitindo:

• Correlação de eventos entre múltiplos servidores durante um incidente

• Retenção e auditoria centralizada, essencial para compliance (LGPD, ISO 27001)

• Sobrevivência dos logs mesmo que o servidor de origem seja comprometido ou destruído

• Alertas centralizados integrando com ferramentas como Zabbix, Grafana ou pipelines de análise via LLM

• Redução de ruído operacional, com um único local para dashboards e buscas

Neste guia vamos construir, do zero, um servidor central de logs usando rsyslog, a ferramenta padrão de sistema de log em praticamente todas as distribuições Linux corporativas (RHEL, Oracle Linux, Ubuntu, Debian).

Arquitetura da solução

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

Cada servidor cliente envia seus logs via rede para o servidor central, que os organiza em diretórios separados por hostname, aplicando rotação e retenção configuráveis.

1. Preparando o servidor central

Recomenda-se uma máquina dedicada (física ou VM) com recursos proporcionais ao volume de logs esperado. Para ambientes pequenos e médios (até ~30 servidores clientes), uma VM com 2 vCPUs, 4 GB de RAM e um disco separado para /var/log (idealmente em um pool ZFS ou LVM com espaço para crescer) já é suficiente.

1.1 Instalação do rsyslog

Na maioria das distribuições baseadas em RHEL/Oracle Linux, o rsyslog já vem instalado por padrão. Para garantir a versão mais recente:

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

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

Verifique a versão instalada (recomenda-se 8.x ou superior para suporte completo a TLS e RELP):

rsyslogd -v

1.2 Habilitando o serviço

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

2. Configurando o servidor central para receber logs

O arquivo principal de configuração é /etc/rsyslog.conf, mas a boa prática é criar arquivos separados em /etc/rsyslog.d/ para manter tudo organizado e facilitar manutenção futura.

2.1 Habilitando os módulos de recepção

Crie o arquivo /etc/rsyslog.d/00-listen.conf:

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

Conteúdo:

# 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 ambientes críticos, priorize sempre TCP em vez de UDP. UDP não garante a entrega dos pacotes — em caso de picos de tráfego ou saturação de rede, você pode perder eventos importantes sem nenhum aviso.

2.2 Organizando os logs por servidor de origem (template dinâmico)

Um dos maiores erros em servidores de log centralizados é jogar tudo em um único arquivo /var/log/messages, misturando eventos de dezenas de servidores diferentes. A prática correta é usar templates dinâmicos para separar por hostname e data.

Crie o arquivo /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
}

Essa regra faz com que:

• Logs do próprio servidor central continuem indo para /var/log/messages normalmente

• Logs recebidos pela rede sejam gravados em /var/log/clients/<hostname>/<data>.log

• O stop evita que a mensagem também seja duplicada nos logs locais do servidor central

Crie o diretório base com as permissões corretas:

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 o serviço

sudo systemctl restart rsyslog
sudo ss -tulpn | grep 514

Você deve ver o rsyslog escutando nas portas 514 (TCP e UDP).

3. Configurando os servidores clientes (envio de logs)

Em cada servidor Linux que deve enviar logs para o servidor central, crie o arquivo /etc/rsyslog.d/90-forward.conf:

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

Conteúdo (substitua pelo IP ou hostname real do seu 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

Note o uso de @@ (duas arrobas), que indica envio via TCP. Um único @ indicaria UDP.

As diretivas de fila (ActionQueue*) garantem que, se a rede cair ou o servidor central ficar indisponível, os logs fiquem armazenados em disco localmente e sejam reenviados automaticamente assim que a conexão for restabelecida — evitando perda de eventos durante manutenções ou instabilidades de rede.

Reinicie o rsyslog no cliente:

sudo systemctl restart rsyslog

3.1 Testando o envio

No cliente, gere uma mensagem de teste:

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

No servidor central, verifique se a mensagem chegou:

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

4. Segurança: criptografando o transporte com TLS

Enviar logs em texto puro pela rede é uma prática arriscada, especialmente se o tráfego passa por segmentos de rede compartilhados ou WAN. Logs frequentemente contêm informações sensíveis (tentativas de login, IPs internos, dados de aplicação).

4.1 Gerando certificados

Para ambientes internos, você pode usar uma CA própria (recomendado) ou reaproveitar sua infraestrutura de PKI existente. Exemplo simplificado com 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

Distribua o ca-cert.pem para todos os clientes que forem enviar logs.

4.2 Configurando TLS no servidor central

Adicione ao /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 no 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 o rsyslog em ambos os lados e valide o tráfego criptografado com tcpdump (o conteúdo deve estar ilegível, ao contrário da porta 514 sem TLS).

5. Firewall e liberação de portas

Não esqueça de liberar as portas no firewall do servidor central. Exemplo com 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

Com ufw (Debian/Ubuntu):

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

Se houver um firewall perimetral (pfSense, Fortinet) entre os servidores, garanta que as regras de liberação sejam feitas apenas entre as redes/VLANs específicas de gerência — nunca exponha as portas de recepção de logs para redes públicas ou não confiáveis.

6. Rotação e retenção de logs

Com múltiplos servidores enviando logs continuamente, o disco do servidor central pode crescer rapidamente. Configure o logrotate para gerenciar isso automaticamente.

Crie /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
}

Esse exemplo mantém 90 dias de histórico com compressão, um equilíbrio razoável entre espaço em disco e necessidade de auditoria. Ajuste o rotate conforme a política de retenção exigida pelo seu setor (hospitais e clínicas, por exemplo, costumam ter exigências de retenção mais longas por conta de auditorias).

7. Indo além: integração com Zabbix e análise inteligente

Depois que os logs estão centralizados, o próximo passo natural é transformar esses dados brutos em inteligência operacional:

• Zabbix pode monitorar arquivos de log via log[] items ou consumir alertas gerados a partir de padrões específicos (falhas de autenticação, erros de aplicação, uso de disco crítico)

• Elasticsearch + Kibana ou Grafana Loki podem ser usados como camada de busca e visualização sobre os logs já centralizados pelo rsyslog, sem sacrificar a simplicidade e confiabilidade do rsyslog como camada de transporte

• Pipelines de análise automatizada (via LLM ou regras) podem consumir esses logs para gerar resumos diários de incidentes, reduzindo o tempo de triagem manual da equipe de infraestrutura

Checklist final de implantação

• Rsyslog instalado e atualizado no servidor central e em todos os clientes
• Recepção via TCP habilitada (preferencialmente com TLS em produção)
• Templates dinâmicos configurados para separar logs por hostname/data
• Fila de retransmissão local configurada nos clientes (`ActionQueue*`)
• Certificados TLS gerados e distribuídos, se aplicável
• Portas liberadas apenas nas redes de gerência, nunca publicamente
• Logrotate configurado com política de retenção adequada ao seu setor
• Teste de failover: desligar a rede do cliente temporariamente e validar que os logs não se perdem

Conclusão

Montar um servidor de agregação de logs com rsyslog é um investimento relativamente simples, usando ferramentas nativas do Linux, que traz um retorno enorme em capacidade de resposta a incidentes, auditoria e conformidade. Para ambientes B2B — especialmente em setores regulados como saúde e indústria — essa centralização não é apenas uma boa prática técnica, é frequentemente um requisito de compliance.

Na Nyverra, ajudamos empresas a estruturar esse tipo de infraestrutura de observabilidade de forma sólida e sob medida, seja em ambientes on-premise, virtualizados em Proxmox, ou híbridos. Se sua empresa ainda não tem uma estratégia de centralização de logs, esse é um ótimo ponto de partida.

Precisa de ajuda para implementar essa arquitetura na sua empresa? Fale com a equipe da Nyverra.