Dónde guardan sus registros los sistemas operativos, y cómo consultar cada uno

Qué es

«Revisar los registros» significa un almacén distinto y un comando distinto en cada sistema.

Sistema	Dónde viven los registros	Comando de consulta
Linux con systemd	el journal binario, más cualquier archivo bajo /var/log para los servicios que lo eluden	journalctl -u NAME --since "1 hour ago"
Linux con rsyslog	archivos de texto bajo /var/log (syslog en Debian/Ubuntu, messages en RHEL; archivos por facility definidos en /etc/rsyslog.conf y /etc/rsyslog.d)	grep, less; en hosts con systemd, rsyslog suele recibir sus mensajes desde el journal, así que journalctl también los ve
macOS	el registro unificado, un almacén binario no visible como archivos de texto	log show --predicate 'process == "NAME"' --last 1h, o log stream para seguirlo en vivo
Windows	los canales del servicio Registro de eventos (Application, System, Security, más canales por aplicación)	Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-1)} (-LogName y -FilterHashtable no se pueden combinar)
AIX	el registro de errores binario (errores de hardware y software) y, por separado, syslog si está configurado	errpt para el registro de errores; para syslog, tail -f sobre el archivo indicado en /etc/syslog.conf (el archivo predeterminado no tiene reglas activas)
FreeBSD	archivos de texto bajo /var/log, rotados por newsyslog, enrutados por /etc/syslog.conf	grep, less, o tail -f /var/log/messages

Por qué importa

Los almacenes binarios (el journal de systemd, el registro unificado de macOS, el Registro de eventos de Windows, el registro de errores de AIX) no se pueden leer con grep; cada uno necesita su propia herramienta de consulta, y cada herramienta tiene su propia sintaxis de filtro: un nombre de unidad en Linux, una expresión de predicado en macOS, una tabla hash de filtro o XPath en Windows. El registro en archivos de texto (rsyslog simple, FreeBSD, la mayoría del registro de aplicaciones de AIX) es portable a cualquier herramienta de texto, pero pierde los campos estructurados que ofrecen los almacenes binarios, como el boot ID del proceso o el emparejamiento exacto de facility/severidad.

Cómo aplicarlo

• Identificar el almacén antes de escribir una consulta: el journalctl -u de una unidad de servicio y el tail de un archivo simple no son intercambiables, y ejecutar el comando equivocado contra el sistema equivocado devuelve silenciosamente nada, en lugar de un error.
• Acotar cada consulta por tiempo (--since, --last, -FilterHashtable @{StartTime=...}) antes de acotarla por contenido; las lecturas de registros sin límites son la forma más común en que un script de un agente se cuelga o inunda su propia salida.
• En macOS, log show y log stream deben ejecutarse desde una cuenta de administrador o con sudo, y los argumentos de mensaje marcados como privados aparecen como <private> en cualquier caso; conviene tenerlo en cuenta en scripts desatendidos.
• En Windows, usar Get-WinEvent, no el más antiguo Get-EventLog: solo el primero lee los canales por aplicación, y Get-EventLog no existe en PowerShell 7.

Trampas

• Suponer que errpt de AIX es un registro de aplicaciones general; es un registro de errores de hardware/software, no un lugar donde la mayoría de los demonios de terceros escriban mensajes rutinarios.
• Leer solo /var/log/syslog en un host con systemd: Debian 12 y posteriores ya no instalan rsyslog por defecto, así que el archivo puede no existir, y el journal es el único almacén.
• Consultar el registro de seguridad de Windows desde una sesión sin privilegios elevados; leerlo necesita derechos de administrador, y el script recibe un error de acceso denegado, no un resultado vacío.