Onde os sistemas operacionais guardam seus logs e como consultar cada um

O que é

"Verificar os logs" significa um armazenamento e um comando diferentes em cada sistema.

Sistema	Onde ficam os logs	Comando de consulta
Linux com systemd	o journal binário, mais eventuais arquivos em /var/log de serviços que o contornam	journalctl -u NAME --since "1 hour ago"
Linux com rsyslog	arquivos de texto em /var/log (syslog no Debian/Ubuntu, messages no RHEL; arquivos por facility definidos em /etc/rsyslog.conf e /etc/rsyslog.d)	grep, less; em hosts com systemd, o rsyslog normalmente recebe as mensagens do journal, então o journalctl também as enxerga
macOS	o unified log, um armazenamento binário que não aparece como arquivos comuns	log show --predicate 'process == "NAME"' --last 1h ou log stream para acompanhar em tempo real
Windows	os canais do serviço Event Log (Application, System, Security, além de canais por aplicação)	Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-1)} (-LogName e -FilterHashtable não podem ser combinados)
AIX	o log de erros binário (erros de hardware e software) e, separadamente, o syslog, se estiver configurado	errpt para o log de erros; para o syslog, tail -f no arquivo indicado em /etc/syslog.conf (o arquivo padrão não tem regras ativas)
FreeBSD	arquivos de texto em /var/log, rotacionados pelo newsyslog e roteados por /etc/syslog.conf	grep, less ou tail -f /var/log/messages

Por que importa

Os armazenamentos binários (o journal do systemd, o unified log do macOS, o Event Log do Windows, o log de erros do AIX) não podem ser lidos com grep; cada um exige sua própria ferramenta de consulta, e cada ferramenta tem a sua sintaxe de filtro: um nome de unit no Linux, uma expressão de predicado no macOS, uma hash table de filtro ou XPath no Windows. O log em arquivos de texto (rsyslog puro, FreeBSD, a maior parte do log de aplicações no AIX) pode ser tratado com qualquer ferramenta de texto, mas perde os campos estruturados que os armazenamentos binários oferecem, como o boot ID do processo ou o par exato de facility/severity.

Como aplicar

• Identifique o armazenamento antes de escrever a consulta: o journalctl -u de uma unit de serviço e o tail de um arquivo simples não são intercambiáveis, e executar o comando errado no sistema errado não gera erro, apenas devolve um resultado vazio sem avisar.
• Limite toda consulta por tempo (--since, --last, -FilterHashtable @{StartTime=...}) antes de limitá-la por conteúdo; ler logs sem limite é a causa mais comum de um script de agente travar ou inundar a própria saída.
• No macOS, log show e log stream precisam ser executados a partir de uma conta de administrador ou com sudo, e os argumentos de mensagem marcados como privados aparecem como <private> em ambos os casos; leve isso em conta em scripts não supervisionados.
• No Windows, use Get-WinEvent e não o antigo Get-EventLog: só o primeiro lê os canais por aplicação, e o Get-EventLog não existe no PowerShell 7.

Armadilhas

• Presumir que o errpt do AIX é um log geral de aplicações; ele é um log de erros de hardware e software, e não o lugar onde a maioria dos daemons de terceiros grava mensagens de rotina.
• Ler apenas /var/log/syslog em um host com systemd: o Debian 12 e posteriores não instalam mais o rsyslog por padrão, então o arquivo pode não existir e o journal ser o único armazenamento.
• Consultar o log Security do Windows a partir de uma sessão sem elevação; a leitura exige direitos de administrador, e o script recebe um erro de acesso negado, não um resultado vazio.