Syslog: Um Guia Completo para Profissionais de Observabilidade

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado jun/2024Atualizado set/2026

Quando um servidor trava, o log que explicaria a falha costuma morrer junto com ele. Por isso a centralização de logs sustenta a operação das infraestruturas de TI: o registro precisa sair da máquina antes que ela pare. Entre os protocolos dessa tarefa, o syslog é o denominador comum entre equipamentos de fabricantes diferentes.

As mensagens de log carregam o que aconteceu no sistema: erro, alerta, mudança de estado. O protocolo separa transporte de conteúdo. Por isso o mesmo fluxo termina num arquivo, num banco ou numa plataforma de correlação, sem que o emissor precise saber o destino.

Neste artigo, você encontra o que é syslog, como ele funciona e o que muda entre UDP e TCP na prática. Além disso, montamos um laboratório com rsyslog para medir a perda de cada transporte. De lá saem também o campo de prioridade lido no fio e o custo em disco do coletor, dentro do escopo da observabilidade.

O que é Syslog?

Syslog, ou System Logging Protocol, é um padrão para a transmissão de mensagens de log em uma rede IP. Eric Allman o criou na década de 1980, para o Unix. Assim, componentes diferentes de uma mesma infraestrutura passaram a mandar suas mensagens para um servidor central, em vez de guardar cada um o seu arquivo.

Além disso, a RFC 5424 descreve o formato atual. Na prática, todo Unix e Linux e quase todo equipamento de rede falam syslog sem software extra.

Importância do Syslog

O syslog resolve um problema de posse: enquanto o log vive apenas no disco da máquina que o gerou, ele desaparece com a máquina. Um servidor comprometido perde o rastro do ataque. Da mesma forma, um disco cheio para de registrar exatamente quando o incidente começa.

Além disso, a centralização é o que torna a correlação possível. Um erro de aplicação só ganha sentido ao lado do descarte de pacotes no switch e do estouro de conexões no banco, no mesmo minuto. Com os três em máquinas separadas, ninguém cruza nada.

Em contrapartida, centralizar concentra volume. Esse volume termina em disco, com um custo que dá para calcular antes de contratar o servidor.

Funcionamento do Syslog

O syslog opera em modelo cliente-servidor. O dispositivo ou a aplicação que gera o log atua como cliente. Em seguida, o coletor recebe a mensagem, grava em arquivo e às vezes encaminha adiante.

Por padrão, o transporte é UDP na porta 514. O protocolo também aceita TCP, em geral na mesma porta, quando a entrega precisa de confirmação. No entanto, essa escolha decide quanta mensagem você perde.

UDP ou TCP: a perda medida em laboratório

Para medir essa diferença, montamos um coletor rsyslog 8.2504.0 sobre Debian 13. Do outro lado, um gerador de carga com o logger 2.41.5, em container separado na mesma rede. Todos os números desta seção saem desse laboratório, executado em 2 de setembro de 2026.

O primeiro resultado contraria a fama do UDP. Com um remetente único, 50.000 mensagens em 1,11 segundo, nada se perdeu. A perda aparece, no entanto, quando vários processos disputam o mesmo socket:

# 1 remetente, 50.000 mensagens por UDP
logger -n 172.31.15.10 -P 514 -d -t lab-udp -f mensagens.txt
wc -l < /var/log/lab-udp.log       # no coletor
50000                               # nada faltou, em 1,11 s

# 6 remetentes simultaneos, 300.000 mensagens por UDP
for i in 1 2 3 4 5 6; do logger -n 172.31.15.10 -P 514 -d -f mensagens.txt & done; wait
wc -l < /var/log/lab-udp.log
298549                              # faltam 1.451

grep -A1 '^Udp:' /proc/net/snmp
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors InCsumErrors IgnoredMulti MemErrors
Udp: 348551 0 1451 2 1451 0 0 0 0
#     as 1.451 do RcvbufErrors sao exatamente as que faltam no arquivo

Essas 1.451 mensagens que faltam batem exatamente com o contador RcvbufErrors do kernel, em /proc/net/snmp. Ou seja, o buffer de recepção estourou enquanto o rsyslog drenava. Vale monitorar esse contador no coletor: ele é a única evidência local de que o UDP está descartando.

O caso que decide, porém, não é a rajada. É o coletor fora do ar:

# Coletor fora do ar. Mil mensagens por UDP:
logger -n 172.31.15.10 -P 514 -d -f mil.txt
echo $?
0                               # sucesso. E nenhuma das mil chegou.

# As mesmas mil por TCP:
logger -n 172.31.15.10 -P 514 -T -f mil.txt
logger: failed to connect to 172.31.15.10 port 514
echo $?
1                               # falhou, e o remetente soube na hora

O UDP mandou mil mensagens para o vazio e devolveu código de saída 0. Nenhuma chegou. O remetente não teve como saber. Já o TCP falhou na conexão e avisou na hora, com código 1. Essa é a diferença que importa: em rede limpa o UDP não perde mais que o TCP, mas perde em silêncio.

Portanto, o critério cabe em três linhas. Use UDP quando o equipamento não oferece outra coisa, caso comum em switch e appliance antigo. Use TCP para servidor e aplicação, onde você controla o cliente. Adote TLS quando a mensagem sai da sua rede, porque syslog em texto claro trafega legível para quem estiver no caminho.

Estrutura das Mensagens de Log

Cada mensagem de log no syslog possui uma estrutura específica composta por diversas partes, incluindo:

• PRI (Priority): Indica a prioridade da mensagem, combinando a severidade e a facilidade do log.
• Timestamp: Registra a data e hora em que o evento ocorreu.
• Hostname: Identifica o dispositivo ou aplicação que gerou a mensagem de log.
• Tag: Um identificador que normalmente corresponde ao nome do programa ou serviço que gerou o log.
• Message: O conteúdo da mensagem de log, descrevendo o evento ou erro ocorrido.

Com essa estrutura, ferramentas de análise e sistemas de gerenciamento de logs leem a mensagem sem precisar de regra própria para cada fabricante.

Níveis de Severidade

O syslog define oito níveis de severidade, que ajudam a categorizar a importância das mensagens de log:

• Emergência (0): O sistema está inutilizável.
• Alerta (1): Ação imediata é necessária.
• Crítico (2): Condições críticas.
• Erro (3): Erros de operação.
• Aviso (4): Condições de aviso.
• Notificação (5): Condições normais mas significativas.
• Informativo (6): Mensagens informativas.
• Depuração (7): Mensagens de debug.

Esses níveis permitem que os administradores filtrem e priorizem as mensagens de log com base na gravidade dos eventos registrados.

Na rede, porém, severidade e facility não viajam separadas. O syslog junta as duas num único campo, o PRI, pela conta facility * 8 + severity. Capturamos três mensagens do laboratório com tcpdump para ver o campo cru:

# tcpdump -i eth0 -A -n udp port 514
IP 172.31.15.20.41956 > 172.31.15.10.514: SYSLOG local0.info, length: 174
<134>1 2026-09-02T04:22:52.609152+00:00 app01 sshd - - [timeQuality tzKnown="1" isSynced="1"] Accepted publickey for deploy from 10.0.4.31 port 49518 ssh2

IP 172.31.15.20.39844 > 172.31.15.10.514: SYSLOG local0.error, length: 188
<131>1 2026-09-02T04:22:52.610733+00:00 app01 sshd - - [timeQuality tzKnown="1" isSynced="1"] error: maximum authentication attempts exceeded for root from 203.0.113.42

IP 172.31.15.20.59320 > 172.31.15.10.514: SYSLOG daemon.critical, length: 156
<26>1 2026-09-02T04:22:52.611875+00:00 app01 kernel - - [timeQuality tzKnown="1" isSynced="1"] EXT4-fs error: unable to read inode block

Portanto, a leitura confirma a conta. O <134> é local0 (facility 16) com severidade info (6), porque 16 vezes 8 mais 6 dá 134. Já o <26> é daemon (facility 3) com severidade crit (2). O próprio tcpdump traduz o número ao lado, em SYSLOG local0.info e SYSLOG daemon.critical.

A armadilha está no filtro. Quem escreve regra comparando o PRI numérico precisa refazer a conta a cada mudança de facility. Um erro aqui silencia o alerta em vez de derrubá-lo. Ninguém percebe até precisar do log. Por isso o rsyslog expõe %syslogfacility-text% e %syslogseverity-text% como campos separados.

Implementação do Syslog

Implementar o syslog em um ambiente de TI envolve configurar tanto os clientes quanto o servidor syslog. Em seguida, vêm as etapas e as boas práticas de cada lado.

Configuração do Cliente Syslog

Cliente syslog é qualquer dispositivo ou aplicativo que gera mensagem de log. A configuração varia conforme o sistema operacional. Em sistemas Unix/Linux, por exemplo, ela vive em /etc/rsyslog.conf ou /etc/syslog.conf. Nesse arquivo você declara o endereço do coletor e quais logs saem da máquina.

Exemplo de configuração em Linux

# Um arroba envia por UDP. Dois arrobas enviam por TCP.
# A diferenca entre as duas linhas e um caractere.
*.* @coletor.exemplo.com.br:514
*.* @@coletor.exemplo.com.br:514

O seletor *.* encaminha todas as facilities em todas as severidades. A parte que engana é o arroba: @ envia por UDP e @@ envia por TCP. No laboratório o tcpdump mostrou a diferença no fio. Com um arroba sai um datagrama solto. Com dois, em contrapartida, o cliente abre conexão TCP antes de mandar o dado.

Configuração do Servidor Syslog

O servidor syslog recebe, armazena e às vezes processa as mensagens que os clientes mandam. Por exemplo, rsyslog, syslog-ng e Graylog cobrem quase todo caso, do coletor de uma unidade ao de um datacenter inteiro.

Exemplo de configuração do rsyslog

# Coletor: escuta nos dois transportes na porta 514
module(load="imudp")
input(type="imudp" port="514" ruleset="coleta")

module(load="imtcp")
input(type="imtcp" port="514" ruleset="coleta")

# Um arquivo por host e por programa, para a rotacao nao virar um monolito
template(name="PorHost" type="string"
  string="/var/log/remoto/%HOSTNAME%/%PROGRAMNAME%.log")

ruleset(name="coleta") {
  action(type="omfile" dynaFile="PorHost"
         template="RSYSLOG_TraditionalFileFormat")
}

Esse arquivo subiu no laboratório sem aviso de parse. Assim, separou as mensagens em /var/log/remoto/app01/sshd.log, nginx.log e kernel.log. Duas escolhas explicam o resultado. A primeira é o ruleset compartilhado pelos dois inputs, que evita duplicar regra por transporte.

A segunda é o dynaFile, que quebra a coleta em um arquivo por host e por programa. Gravar tudo num único all-logs.log funciona até o primeiro incidente. Depois disso, achar a linha de um host dentro de um arquivo de dezenas de gigabytes custa minutos que o plantão não tem.

Fila em disco: o que salva a mensagem quando o coletor cai

A fila em disco é o que transforma TCP em entrega garantida. Sem ela, o cliente que não consegue conectar descarta a mensagem do mesmo jeito que o UDP, só que com erro no console. Com ela, a mensagem espera em arquivo até o coletor voltar.

# No host da aplicacao: entrega por TCP com fila em disco.
# Se o coletor cair, a mensagem espera no disco em vez de sumir.
action(type="omfwd"
       target="172.31.15.10" port="514" protocol="tcp"
       action.resumeRetryCount="-1"       # tenta para sempre
       queue.type="linkedList"
       queue.filename="fila_coletor"    # liga a fila em disco
       queue.saveOnShutdown="on"         # nao perde no restart
       queue.maxDiskSpace="1g")

Testamos os dois cenários com essa configuração. Com o coletor no ar, as 500 mensagens enviadas chegaram inteiras. Em seguida derrubamos o coletor e mandamos mais 1.000: elas foram parar num arquivo fila_coletor.00000001 de 388.682 bytes, no disco do próprio cliente. Quando o coletor voltou, as 1.000 chegaram.

O parâmetro queue.maxDiskSpace é o limite dessa proteção. Ele define quanto tempo de queda o cliente aguenta antes de começar a descartar. Por isso vale dimensioná-lo junto com a taxa de mensagens do host, em vez de deixar no valor de exemplo.

Ferramentas e Aplicações Syslog

Várias ferramentas se integram ao syslog para melhorar a coleta, a análise e a visualização dos logs. Veja as mais usadas:

Graylog

Graylog é uma plataforma de gerenciamento de logs que coleta, indexa e analisa em tempo real. A plataforma ainda traz interface web, alerta próprio e integração com várias fontes de dados.

DataDog

DataDog é uma plataforma de monitoramento e análise que integra a coleta de logs com métricas de performance e dados de monitoramento de infraestrutura. Ao trabalhar com syslog, DataDog permite que os logs sejam enviados para seu agente, que então os transmite para a plataforma para análise centralizada.

Isso facilita a correlação de eventos de log com métricas de desempenho e alertas de monitoramento, proporcionando uma visão unificada do ambiente de TI. Além disso, DataDog oferece recursos avançados de visualização e dashboards personalizáveis, permitindo que os administradores identifiquem rapidamente padrões e anomalias nos dados de log.

ELK Stack

O ELK Stack (Elasticsearch, Logstash, Kibana) é um conjunto open-source para busca, análise e visualização de logs. Em síntese, o Logstash coleta e processa, o Elasticsearch indexa e o Kibana desenha.

Monitoração de Syslog

Monitorar o próprio syslog evita o pior tipo de falha: a que apaga a evidência de todas as outras. Aqui estão as práticas que se pagam:

➡️ Configuração de Alertas: Alerte por ausência, não só por evento crítico. Um host que parou de enviar log é indistinguível de um host silencioso. Assim, o alerta por falta de mensagem numa janela conhecida cobre os dois casos.

➡️ Análise Regular: Releia os logs em janela fixa para achar padrão anômalo e tendência de desempenho. Por exemplo, Graylog e Splunk automatizam boa parte desse trabalho.

➡️ Auditoria e Compliance: Utilize os logs para auditoria e conformidade com regulamentos de segurança e privacidade. A auditoria cobra duas coisas do coletor: retenção pelo prazo declarado e controle de quem lê.

➡️ Escalabilidade: Monitore o RcvbufErrors do coletor e a profundidade da fila do rsyslog. Ambos sobem antes de o disco encher e, portanto, dão o aviso com folga.

Casos de Uso do Syslog

Na operação, o syslog aparece em três cenários que se repetem em quase toda empresa. Vale olhar cada um deles:

Monitoramento de Segurança

O syslog sustenta boa parte do monitoramento de segurança de sistemas e redes. Firewall, IDS e servidor mandam suas mensagens para o mesmo coletor. Dessa forma, a varredura por atividade suspeita roda uma vez só, sobre o conjunto, em vez de máquina a máquina.

Auditoria e Conformidade

Organizações em setores regulamentados usam syslog para coletar e guardar log de auditoria. Assim atendem à LGPD no Brasil e ao GDPR na União Europeia, que cobram registro de quem acessou dado pessoal. Como resultado, a centralização encurta o relatório de conformidade e a própria auditoria.

Diagnóstico e Resolução de Problemas

Administradores de sistemas e redes utilizam syslog para diagnosticar e resolver problemas de desempenho e configuração. Mensagens detalhadas encurtam a busca pela causa raiz, principalmente quando dá para cruzar o horário do erro na aplicação com o do equipamento de rede.

Desafios e Considerações

Ainda assim, a implementação traz três desafios que aparecem sempre:

Volume de Dados

Centralizar concentra volume, que termina em disco. No laboratório, 50.000 mensagens de 81,7 bytes ocuparam 5.435.483 bytes no arquivo do coletor, no formato tradicional do rsyslog. Ou seja, 108,7 bytes por mensagem, já contando o timestamp, o host e a tag que o coletor acrescenta.

Depois de gzip -9, o mesmo arquivo caiu para 841.446 bytes, ou 16,8 bytes por mensagem, numa razão de 6,5 para 1. O número só vale porque as mensagens saíram com IP, usuário, porta e status sorteados. Vale dizer que linha idêntica repetida comprime em taxas que não existem em produção.

Com essas duas constantes, o dimensionamento sai direto da taxa de mensagens por segundo:

Portanto, a coluna da direita é o argumento a favor da rotação diária. A 500 mensagens por segundo, guardar 90 dias sem comprimir pede 423 GB. Girando o arquivo todo dia e comprimindo o que sai do dia quente, os mesmos 90 dias cabem em 69 GB. É o mesmo dado, com um sexto do espaço.

Padronização dos Logs

Padronizar a mensagem decide se a correlação funciona. Cada fabricante escreve o corpo da mensagem do seu jeito, então a normalização acontece no coletor, com regra de parsing por origem.

Segurança

Logs carregam nome de usuário, endereço interno e caminho de arquivo. Um coletor central vira, por construção, o ponto de maior concentração desse material na rede. Por isso, cifrar o transporte com TLS e restringir quem lê o coletor entram junto com a coleta, não depois dela.

Syslog x Observabilidade

O syslog é um padrão de transporte de mensagens de log entre sistemas. A observabilidade é a prática de reunir e analisar esses dados para explicar o comportamento do ambiente.

Nesse sentido, a observabilidade é baseada em três pilares: logs, métricas e rastreamentos. Os logs são registros imutáveis das atividades que ocorrem em um sistema, enquanto as métricas fornecem uma visão geral da integridade do sistema ou ambiente. Os rastreamentos, por outro lado, permitem acompanhar o fluxo e a condição de uma solicitação ou evento em um sistema distribuído.

Portanto, o syslog se encaixa perfeitamente dentro do conceito de observabilidade. Ele permite a coleta e transmissão de logs de sistema, que podem ser usados para entender melhor o comportamento e desempenho do sistema. Além disso, o syslog pode ser integrado com ferramentas de observabilidade para fornecer uma visão mais completa do sistema.

Conclusão

O syslog entrega um transporte simples e um formato que quase todo equipamento fala. As decisões que separam um coletor confiável de um que perde mensagem não estão no protocolo. Estão no transporte, na fila e no disco.

O laboratório fechou os três números. Em rede limpa, o UDP não perdeu nada com um remetente e perdeu 0,48% com seis. Com o coletor fora do ar, perdeu tudo sem avisar. O TCP com fila em disco, porém, entregou as 1.000 mensagens da janela de queda assim que o serviço voltou. Cada mensagem, por fim, custou 108,7 bytes no disco.

Em resumo, comece pelo transporte que você controla, ligue fila em disco no encaminhador e dimensione o coletor pela taxa real, não pelo pico imaginado. Fale com nosso time de especialistas se quiser essa coleta rodando com alerta de ausência e retenção definida.