Como configurar logs centralizados com rsyslog

O que você vai aprender

Neste guia, você vai montar uma estrutura centralizada de logs usando dois servidores Ubuntu. O servidor logs.infra.local, com o IP privado 10.20.0.10, receberá os eventos enviados pelo cliente client1.infra.local, com o IP 10.20.0.21.

Ao concluir, você saberá:

• Instalar e validar o rsyslog no servidor e no cliente.
• Criar uma autoridade certificadora local para proteger o transporte.
• Receber logs pela porta TCP 6514 usando TLS.
• Separar os eventos em diretórios por hostname e programa.
• Configurar uma fila persistente para suportar indisponibilidades.
• Definir rotação, retenção e permissões dos arquivos centralizados.
• Testar o fluxo completo e diagnosticar falhas comuns.

A arquitetura funciona em VPS, máquinas virtuais e servidores em nuvem. Se você ainda estiver definindo a infraestrutura, consulte a explicação sobre diferenças entre cloud server e VPS. Para ambientes de aplicação, os conteúdos sobre VPS para API e VPS para desenvolvedores ajudam a dimensionar os nós que produzirão os logs.

Pré-requisitos

Você precisa de dois servidores Ubuntu 22.04 ou 24.04 conectados pela mesma rede privada. Os comandos consideram a seguinte topologia:

• Servidor central: logs.infra.local, IP 10.20.0.10.
• Servidor cliente: client1.infra.local, IP 10.20.0.21.
• Rede autorizada: 10.20.0.0/24.
• Porta de recepção TLS: 6514/TCP.

Confirme que você consegue acessar as duas máquinas por SSH e executar comandos com sudo. Se os endereços reais forem diferentes, substitua os IPs apresentados antes de aplicar as configurações. Não exponha a porta 6514 para toda a internet.

Você também precisa conhecer operações básicas de terminal, edição de arquivos e permissões Linux. O guia utiliza nano, openssl, systemctl, ss, logger e journalctl.

Antes de alterar qualquer configuração, confirme o sistema operacional em cada máquina:

cat /etc/os-release | grep -E '^(NAME|VERSION)='

A saída esperada será semelhante a:

NAME="Ubuntu"
VERSION="24.04.1 LTS (Noble Numbat)"

Confirme ainda que os nomes resolvem entre os servidores. Em uma rede sem DNS interno, acrescente estas entradas ao /etc/hosts das duas máquinas:

10.20.0.10 logs.infra.local logs
10.20.0.21 client1.infra.local client1

Teste com getent hosts logs.infra.local. O comando deve retornar o IP 10.20.0.10.

Passo 1: Preparar os servidores e instalar o rsyslog

Comece fazendo uma cópia das configurações atuais. Esse backup permite restaurar o serviço caso uma diretiva seja digitada incorretamente. Execute os comandos tanto no servidor central quanto no cliente:

sudo mkdir -p /root/backup-rsyslog
sudo cp -a /etc/rsyslog.conf /etc/rsyslog.d /root/backup-rsyslog/
sudo ls -la /root/backup-rsyslog

Você deve encontrar o arquivo principal e o diretório de configurações:

-rw-r--r-- 1 root root 3142 Oct 12 10:20 rsyslog.conf
drwxr-xr-x 2 root root 4096 Oct 12 10:20 rsyslog.d

Atualize o índice de pacotes e instale o rsyslog com o módulo GnuTLS. O módulo será usado para criptografar a comunicação entre as máquinas:

sudo apt update
sudo apt install -y rsyslog rsyslog-gnutls openssl

Uma instalação concluída normalmente termina com uma saída parecida com esta:

Setting up rsyslog-gnutls ...
Setting up rsyslog ...
Processing triggers for man-db ...

Agora verifique a versão e o estado do serviço:

rsyslogd -v | head -n 2
sudo systemctl is-enabled rsyslog
sudo systemctl is-active rsyslog

O resultado deve indicar uma versão instalada e os estados enabled e active:

rsyslogd  8.2312.0
Config file: /etc/rsyslog.conf
enabled
active

Se o serviço estiver inativo, habilite-o sem alterar ainda a configuração de rede:

sudo systemctl enable --now rsyslog

Faça uma validação sintática inicial. O parâmetro -N1 analisa os arquivos sem iniciar uma segunda instância do daemon:

sudo rsyslogd -N1

O final da saída deve informar que a validação terminou. Avisos ou mensagens contendo error precisam ser corrigidos antes de continuar.

rsyslogd: End of config validation run. Bye.

Passo 2: Criar a autoridade certificadora e o certificado TLS

Execute esta etapa somente no servidor central 10.20.0.10. Você criará uma autoridade certificadora local e um certificado para logs.infra.local. A chave da autoridade pode assinar outros certificados, então mantenha o arquivo protegido e nunca o copie para os clientes.

Crie o diretório e gere a chave privada da autoridade certificadora:

sudo install -d -m 0700 /etc/rsyslog.d/tls
sudo openssl genrsa -out /etc/rsyslog.d/tls/ca.key 4096
sudo chmod 0600 /etc/rsyslog.d/tls/ca.key

Gere o certificado da autoridade com validade de dez anos:

sudo openssl req -x509 -new -nodes \
  -key /etc/rsyslog.d/tls/ca.key \
  -sha256 -days 3650 \
  -out /etc/rsyslog.d/tls/ca.crt \
  -subj "/C=BR/O=Infra Local/CN=Rsyslog Local CA"

Em seguida, crie a chave e a solicitação do servidor. O campo SAN associa o certificado ao nome usado pelo cliente:

sudo openssl genrsa -out /etc/rsyslog.d/tls/server.key 4096
sudo openssl req -new \
  -key /etc/rsyslog.d/tls/server.key \
  -out /etc/rsyslog.d/tls/server.csr \
  -subj "/C=BR/O=Infra Local/CN=logs.infra.local" \
  -addext "subjectAltName=DNS:logs.infra.local,IP:10.20.0.10"

Assine a solicitação preservando a extensão SAN:

sudo openssl x509 -req \
  -in /etc/rsyslog.d/tls/server.csr \
  -CA /etc/rsyslog.d/tls/ca.crt \
  -CAkey /etc/rsyslog.d/tls/ca.key \
  -CAcreateserial -days 825 -sha256 \
  -copy_extensions copy \
  -out /etc/rsyslog.d/tls/server.crt
sudo chmod 0600 /etc/rsyslog.d/tls/server.key
sudo chmod 0644 /etc/rsyslog.d/tls/server.crt /etc/rsyslog.d/tls/ca.crt

Você deve ver uma confirmação semelhante a:

Certificate request self-signature ok
subject=C = BR, O = Infra Local, CN = logs.infra.local

Verifique emissor, validade e SAN antes de usar o certificado:

sudo openssl x509 -in /etc/rsyslog.d/tls/server.crt \
  -noout -subject -issuer -dates -ext subjectAltName

A saída precisa incluir DNS:logs.infra.local e IP Address:10.20.0.10. Copie agora apenas o certificado da autoridade para o cliente:

sudo scp /etc/rsyslog.d/tls/ca.crt [email protected]:/tmp/rsyslog-ca.crt

Ajuste admin somente se sua conta SSH tiver outro nome. Não transfira ca.key nem server.key.

Passo 3: Configurar o servidor central

No servidor central, crie a configuração que habilita o listener TLS, normaliza nomes usados nos caminhos e grava cada programa em um arquivo separado. O modo x509/anon no lado servidor fornece criptografia, enquanto o cliente validará o nome e a cadeia do servidor. O acesso também ficará limitado pela regra de firewall à rede privada.

Crie /etc/rsyslog.d/10-central-server.conf:

sudo nano /etc/rsyslog.d/10-central-server.conf

Insira o conteúdo abaixo:

global(
  DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.crt"
  DefaultNetstreamDriverCertFile="/etc/rsyslog.d/tls/server.crt"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog.d/tls/server.key"
)

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

template(name="RemoteFile" type="list") {
  constant(value="/var/log/remote/")
  property(name="hostname" securePath="replace")
  constant(value="/")
  property(name="programname" securePath="replace")
  constant(value=".log")
}

ruleset(name="remote_tls") {
  action(
    type="omfile"
    DynaFile="RemoteFile"
    createDirs="on"
    DirCreateMode="0750"
    FileCreateMode="0640"
  )
  stop
}

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

A opção securePath="replace" impede que caracteres perigosos recebidos no hostname ou no nome do programa sejam interpretados como componentes arbitrários de caminho. Crie o diretório de destino e atribua o grupo de leitura:

sudo install -d -o syslog -g adm -m 0750 /var/log/remote
sudo chown -R syslog:adm /var/log/remote

Valide antes de reiniciar. Isso reduz o risco de interromper o processamento dos logs locais:

sudo rsyslogd -N1

O resultado esperado termina assim:

rsyslogd: End of config validation run. Bye.

Libere a porta somente para a rede privada e verifique a regra. Se o UFW ainda não estiver ativo, confirme primeiro que a porta SSH está permitida para evitar perda de acesso:

sudo ufw allow from 10.20.0.0/24 to any port 6514 proto tcp
sudo ufw status numbered

A regra deve aparecer como:

6514/tcp  ALLOW IN  10.20.0.0/24

Reinicie o serviço e confirme o listener:

sudo systemctl restart rsyslog
sudo systemctl is-active rsyslog
sudo ss -lntp | grep ':6514'

Você deve ver active e uma linha LISTEN associada ao rsyslogd.

Passo 4: Configurar o cliente e a fila persistente

No cliente 10.20.0.21, instale o certificado da autoridade que foi enviado para /tmp. O arquivo é público, mas deve continuar protegido contra modificações por usuários comuns:

sudo install -d -m 0755 /etc/rsyslog.d/tls
sudo install -o root -g root -m 0644 \
  /tmp/rsyslog-ca.crt /etc/rsyslog.d/tls/ca.crt
openssl x509 -in /etc/rsyslog.d/tls/ca.crt -noout -subject

A saída esperada identifica a autoridade criada anteriormente:

subject=C = BR, O = Infra Local, CN = Rsyslog Local CA

Crie a configuração de encaminhamento:

sudo nano /etc/rsyslog.d/60-central-forwarding.conf

Adicione estas diretivas:

global(DefaultNetstreamDriverCAFile="/etc/rsyslog.d/tls/ca.crt")

*.* action(
  type="omfwd"
  target="logs.infra.local"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  StreamDriverPermittedPeers="logs.infra.local"
  action.resumeRetryCount="-1"
  action.reportSuspension="on"
  queue.type="LinkedList"
  queue.filename="central_forward"
  queue.spoolDirectory="/var/spool/rsyslog"
  queue.maxDiskSpace="1g"
  queue.saveOnShutdown="on"
)

A fila ligada em disco evita a perda imediata de eventos quando o servidor central estiver indisponível. Com action.resumeRetryCount="-1", o cliente continua tentando reconectar. Monitore o espaço, pois uma indisponibilidade prolongada pode consumir o limite de 1 GB.

Verifique a resolução DNS e a conectividade antes de reiniciar:

getent hosts logs.infra.local
nc -vz logs.infra.local 6514

O resultado esperado é:

10.20.0.10 logs.infra.local logs
Connection to logs.infra.local 6514 port [tcp/*] succeeded!

Valide a sintaxe e reinicie o cliente:

sudo rsyslogd -N1
sudo systemctl restart rsyslog
sudo systemctl is-active rsyslog

Você deve receber active. Gere eventos de serviços diferentes para confirmar que a separação por programa funciona:

logger -t api-pagamentos "teste de envio centralizado id=4821 status=ok"
logger -p auth.notice -t auditoria-ssh "teste de evento de autenticacao"

O comando logger normalmente não produz saída. A confirmação será feita no servidor central durante a etapa de testes.

Passo 5: Configurar retenção e proteção dos arquivos

Sem rotação, o diretório central pode crescer até ocupar todo o disco. Configure o logrotate no servidor para compactar arquivos antigos, manter 30 ciclos diários e sinalizar o rsyslog depois da rotação.

Antes de alterar a retenção, consulte o uso atual do volume:

df -h /var/log
sudo du -sh /var/log/remote

Em um ambiente recém-configurado, a saída pode ser semelhante a:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        78G  6.2G   68G   9% /
16K     /var/log/remote

Crie /etc/logrotate.d/remote-rsyslog:

sudo nano /etc/logrotate.d/remote-rsyslog

Use esta configuração:

/var/log/remote/*/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    dateext
    su syslog adm
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

O padrão cobre os arquivos organizados como /var/log/remote/hostname/programa.log. A opção missingok evita erro quando ainda não existem logs, enquanto notifempty ignora arquivos vazios. delaycompress mantém o ciclo anterior sem compressão, facilitando consultas recentes.

Valide a configuração sem executar a rotação real:

sudo logrotate --debug /etc/logrotate.d/remote-rsyslog

A saída inclui mensagens como:

reading config file /etc/logrotate.d/remote-rsyslog
considering log /var/log/remote/client1.infra.local/api-pagamentos.log

O modo --debug não altera arquivos. Para testar uma rotação forçada, faça primeiro um backup dos logs recebidos, pois os nomes serão modificados:

sudo tar -C /var/log -czf /root/remote-logs-before-rotate.tar.gz remote
sudo logrotate --force /etc/logrotate.d/remote-rsyslog

Verifique permissões e arquivos rotacionados:

sudo find /var/log/remote -maxdepth 3 -type f -printf '%M %u:%g %p\n'

Os arquivos ativos devem pertencer a syslog:adm e usar permissões próximas de -rw-r-----. Restrinja o acesso ao grupo adm, pois logs podem conter endereços IP, usuários, caminhos internos e outros dados operacionais sensíveis.

Verificação e testes

No cliente, envie uma mensagem com um identificador único:

TEST_ID="rsyslog-$(date +%s)"
logger -t teste-central "id=${TEST_ID} origem=client1 resultado=sucesso"
echo "$TEST_ID"

Você verá um identificador semelhante a:

rsyslog-1791799200

No servidor central, localize o evento. Use o identificador exibido no cliente:

sudo grep -R "rsyslog-1791799200" /var/log/remote

A saída esperada contém o hostname, a tag e a mensagem:

/var/log/remote/client1.infra.local/teste-central.log:Oct 12 14:00:00 client1 teste-central: id=rsyslog-1791799200 origem=client1 resultado=sucesso

Teste também a negociação TLS diretamente:

openssl s_client -connect logs.infra.local:6514 \
  -servername logs.infra.local \
  -CAfile /etc/rsyslog.d/tls/ca.crt </dev/null 2>/dev/null \
  | grep 'Verify return code'

O resultado correto é:

Verify return code: 0 (ok)

Confira se não existem erros recentes no cliente e no servidor:

sudo journalctl -u rsyslog --since "10 minutes ago" --no-pager

Para validar a fila persistente, pare temporariamente o rsyslog central, gere uma mensagem no cliente e inicie o servidor novamente. Esse teste causa uma breve interrupção planejada na coleta, então faça-o apenas em uma janela segura:

sudo systemctl stop rsyslog
sudo systemctl start rsyslog

Depois da reconexão, a mensagem acumulada deve aparecer no diretório remoto.

Troubleshooting

O cliente não consegue conectar à porta 6514

No servidor, confirme que o processo está escutando e que o firewall possui a regra correta:

sudo ss -lntp | grep ':6514'
sudo ufw status numbered

Se não houver listener, execute sudo rsyslogd -N1 e consulte sudo journalctl -u rsyslog -n 50. Erros como module name 'imtcp' is unknown indicam pacote ausente ou configuração incorreta. Reinstale rsyslog e rsyslog-gnutls. Se o listener existir, mas nc -vz logs.infra.local 6514 falhar no cliente, revise regras do provedor, security groups e rotas da rede privada.

O rsyslog rejeita o certificado

Mensagens contendo certificate validation failed geralmente indicam nome divergente, CA incorreta ou relógio fora de sincronia. Verifique o certificado pelo cliente:

openssl s_client -connect logs.infra.local:6514 \
  -servername logs.infra.local \
  -CAfile /etc/rsyslog.d/tls/ca.crt </dev/null

Confirme que o retorno é 0 (ok) e que o SAN contém logs.infra.local. Confira também a hora com timedatectl status. Não desative a validação no cliente para contornar o erro. Corrija o DNS ou emita novamente o certificado.

Os logs chegam com hostname incorreto

O rsyslog usa o hostname presente na mensagem. Confira o nome do cliente:

hostnamectl status
hostname -f

Se necessário, configure um nome permanente com sudo hostnamectl set-hostname client1.infra.local e ajuste /etc/hosts. Reinicie o rsyslog depois da mudança. Novos eventos devem ser gravados em /var/log/remote/client1.infra.local/.

A fila persistente não é esvaziada

Procure suspensões no cliente:

sudo journalctl -u rsyslog --since "30 minutes ago" | grep -Ei 'suspend|error|queue|gnutls'
sudo ls -lh /var/spool/rsyslog

Arquivos central_forward.* indicam eventos pendentes. Não apague esses arquivos enquanto o serviço estiver em execução, pois isso pode causar perda de logs. Corrija conectividade ou TLS, reinicie o rsyslog e acompanhe o diretório até a fila diminuir.

Próximos passos

Depois de validar a coleta, configure alertas para uso de disco, expiração do certificado e crescimento das filas. Integre o diretório /var/log/remote a uma ferramenta de busca, como OpenSearch, Loki ou Elasticsearch, sem remover o rsyslog da camada de transporte.

Considere emitir certificados individuais para autenticar cada cliente, limitar a porta 6514 a sub-redes específicas e encaminhar somente facilities necessárias em ambientes de alto volume. Documente a política de retenção conforme os requisitos legais da aplicação. Por fim, teste periodicamente uma indisponibilidade controlada para confirmar que as filas continuam preservando e reenviando os eventos.