Fundamentos / Syslog

Syslog em automação: facility, severity, transporte e correlação

Projete coleta Syslog em redes OT com prioridade, timestamp, hostname, UDP/TCP/TLS, retenção, normalização e diagnóstico de eventos distribuídos.

6 min de leitura Conteúdo técnico autoral Publicado em 08/09/2026
Ilustração técnica autoral para Syslog em automação: facility, severity, transporte e correlação, destacando o fluxo e os elementos centrais do assunto.
Ilustração técnica autoral do Portal da Automação, criada para o foco específico deste artigo.

Critérios de engenharia para Syslog OT

ItemDecisãoTeste
Identidadehostname único + IP observadoconsulta por ativo
TempoUTC/fuso, precisão e ingestãoevento correlacionado
TransporteUDP, TCP ou TLS conforme riscoperda e reconexão
Filabuffer e política de descartecoletor indisponível
Parsercampos normalizados + originalfirmware e mensagem conhecida
Retençãoprazo, acesso e backuprestauração e auditoria

Severity do fabricante precisa ser traduzida para impacto operacional contextual.

Syslog é formato, transporte e cadeia de coleta

Um originator gera mensagem, relays podem encaminhá-la e um collector armazena ou processa. RFC 5424 define cabeçalho com prioridade, versão, timestamp, hostname, aplicação, processo, message ID e dados estruturados. Muitos equipamentos legados usam formatos anteriores ou texto proprietário. O coletor precisa preservar o original e normalizar sem inventar campos.

Em automação, o valor aparece na correlação: link caiu, VRRP mudou, usuário entrou, configuração foi salva e sessão SCADA reconectou. Se cada ativo usa horário, hostname e severidade diferentes, a sequência perde confiabilidade. Engenharia de logs é parte do comissionamento.

Facility e severity não são sinônimos de criticidade operacional

Priority combina facility e severity. Severity vai de Emergency a Debug, mas fabricantes classificam eventos de modos diferentes. Um linkDown pode aparecer como warning em um switch e critical em outro. Facility ajuda a separar subsistemas, porém mapeamentos variam.

O SIEM ou NMS deve traduzir mensagem e contexto para impacto: porta de proteção, uplink, acesso de usuário ou sensor não usado. Não gere incidente apenas pelo número. Documente regra, exceção, ativo, interface e condição de recuperação.

Mapa de DNS, NTP, SNMP, Syslog, SSH e AAA em uma rede OT.
Serviços auxiliares sustentam operação, observabilidade, acesso e sincronismo dos ativos. Fonte: Portal da Automação · Conteúdo autoral do portal.

Timestamp precisa de fonte e timezone claros

Uma mensagem pode carregar horário do originator, do relay ou apenas o horário de recepção. Fuso, UTC, precisão e sincronismo precisam ser conhecidos. Se o equipamento perde relógio após reboot, eventos podem chegar fora de ordem ou com ano incorreto. O coletor deve preservar tanto timestamp da origem quanto de ingestão.

Teste perda de NTP/PTP conforme a arquitetura e observe indicação de qualidade. Não corrija silenciosamente tudo pelo horário do servidor, pois isso apaga atraso de rede e falha do relógio. Para análise de proteção, correlacione Syslog com SOE e oscilografia reconhecendo as precisões diferentes.

UDP, TCP e TLS têm comportamentos distintos

Syslog por UDP é simples, mas não confirma entrega e pode perder, duplicar ou truncar. TCP oferece transporte confiável, embora uma conexão quebrada exija fila e reconexão da aplicação. TLS acrescenta autenticação e proteção em trânsito, com certificados e versões que precisam de gestão. Porta aberta não comprova que mensagens são aceitas.

Em tempestade de eventos, um originator pode descartar logs ou bloquear se a fila enche. Defina buffer local, taxa, prioridade e comportamento quando o coletor falha. Logs nunca devem comprometer a função principal do IED, mas perder justamente os eventos da falha também reduz diagnóstico.

Hostname e endereço de origem devem identificar o ativo

NAT, relay ou concentrador pode fazer milhares de mensagens parecerem vir do mesmo IP. Hostname duplicado ou genérico quebra pesquisa. Use identificação única alinhada ao inventário e preserve endereço observado, hostname declarado e relay. Mudança de IP não deve apagar histórico do ativo.

Campos application e process ajudam a separar subsistemas. Quando o fabricante envia tudo como uma única aplicação, parser pode extrair interface e código, mas o texto original deve permanecer disponível para auditoria e atualização do parser.

Retenção, integridade e acesso

Defina retenção conforme operação, investigação e requisitos regulatórios, considerando volume em contingência. Proteja logs contra alteração, limite acesso e registre consultas administrativas. Backup sem teste de restauração não garante evidência.

TLS protege o caminho, não a veracidade do originator comprometido. Segmente origens, use certificados quando suportados, compare com SNMP e captura e monitore lacunas. Assinatura de mensagens pode oferecer propriedades adicionais em arquiteturas compatíveis, mas não substitui proteção do coletor.

Diagnóstico da cadeia de logs

Gere um evento seguro e conhecido. Verifique se o equipamento criou mensagem, se saiu pela interface, atravessou ACL/relay, chegou ao coletor, foi parseado e gerou alarme. Uma captura no servidor sem registro aponta ingestão ou parser; ausência no servidor com envio local aponta rede; nenhuma geração aponta configuração do originator.

Compare sequência e contadores de descarte. Não reinicie o coletor antes de exportar fila, conexão e erro de certificado. Mensagem recebida com atraso pode ser buffer drenando após recuperação, não novo evento.

Comissionamento normal, tempestade e recuperação

Valide cada classe crítica, severidade, ativo, interface e timestamp. Interrompa coletor ou rota de teste, gere mensagens, restaure e observe fila, ordem, duplicidade e alarmes. Simule rajada dentro de limites e meça perda sem afetar processo.

O aceite deve incluir dashboard ou consulta que conte a história operacional, não só linha bruta. Depois da correção, confirme evento e normalização. Preserve exemplos por firmware para detectar mudança de formato em futuras atualizações.

Referências técnicas e normas

As explicações do Portal são autorais. Normas e fontes oficiais são priorizadas; materiais acadêmicos e documentação pública de fabricantes complementam a implementação e não substituem a edição normativa aplicável ao projeto.

Continue estudando

Os próximos conteúdos foram escolhidos para formar uma sequência técnica, relacionando fundamento, configuração, diagnóstico e aplicação.

Ver todas as trilhas de estudo →