Marta escribe a las 09:12: «Anoche, sobre las tres, la web estuvo dando errores. ¿Qué pasó?». Esa pregunta tiene respuesta exacta o no la tiene, y la diferencia la marca lo que hicieras antes de que ocurriera. Un servidor no recuerda nada: lo único que queda de la madrugada es lo que se escribió en algún sitio, con la marca de tiempo correcta, sin que se haya rotado, truncado ni perdido en el reinicio. Esta lección va de eso. Y salda de paso la primera deuda que anuncié al cerrar el Módulo 4: /var/log/tramontana/acceso.log lleva 412 líneas creciendo sin que nadie lo rote, y el día que llene /var se llevará por delante la aplicación entera.

1. Las dos capas de registro que conviven en Ubuntu
2. Facilities y severities de syslog
3. journalctl a fondo
4. Persistencia del journal
5. /etc/systemd/journald.conf y el control del tamaño
6. Los ficheros clásicos de /var/log
7. Escribir en el log desde tus scripts con logger
8. logrotate: por qué y cómo
9. El problema del fichero abierto tras rotar
10. Centralización de logs
11. Qué NUNCA debe acabar en un log
12. Caso Tramontana: rotación y la respuesta para Marta

En una Ubuntu 24.04 recién instalada hay dos sistemas de registro funcionando a la vez, y entender el reparto evita mucha confusión:

El flujo real: todo lo que un servicio gestionado por systemd escribe en stdout y stderr lo captura journald, junto con lo que llega por el socket /dev/log y los mensajes del kernel. Journald lo guarda con sus metadatos y, además, lo reenvía a rsyslog (ForwardToSyslog=yes), que lo escribe en los ficheros de texto de siempre. Por eso el mismo mensaje aparece en journalctl y en /var/log/syslog.

¿Por qué conservar las dos? El journal es incomparablemente mejor para consultar —filtra por unidad, por prioridad, por arranque, por campo— y los ficheros de texto son mejores para lo que ya sabes hacer con grep, awk y sed, para herramientas de terceros y para el envío remoto. En un servidor real convives con ambos.

Ese vocabulario viene de los años 80 y sigue vivo porque toda la industria lo entiende. Cada mensaje lleva una facility (de dónde viene) y una severity (cuánto importa).

Facilities habituales: auth y authpriv (autenticación: sudo, sshd), cron, daemon (servicios), kern (kernel), mail, syslog, y local0–local7, reservadas para tus aplicaciones. Esa última es la clave práctica: cuando respaldo_tramontana.sh escriba en el log, lo hará con una facility local0 y una severity acorde, y así podrás filtrar tus mensajes sin arrastrar los del sistema.

Es la herramienta del día a día y merece la pena aprenderla bien, porque sustituye a media docena de grep.

Las expresiones de tiempo aceptan yesterday, today, tomorrow, now, -30min, "2 days ago" y fechas absolutas. Es una de las razones de peso para usar el journal: contestar «qué pasó entre las 3:00 y las 3:30» con ficheros de texto exige un awk con rangos; aquí son dos opciones.

journalctl -b -1 responde a «el servidor se reinició solo esta noche, ¿por qué?», y requiere journal persistente: justo lo del apartado siguiente.

Cada entrada del journal no es una línea: es un conjunto de campos. Descúbrelos con:

Los campos que empiezan por _ los añade journald, y por eso son de fiar: una aplicación no puede falsificarlos. Se usan como filtro:

Combinar filtros es la esencia de la herramienta: unidad + ventana temporal + prioridad + formato reproducible, en una sola línea.

Este es el detalle que sorprende a todo el mundo la primera vez: por defecto, en muchas instalaciones el journal es volátil. Vive en /run/log/journal, que es un tmpfs en RAM, y se pierde entero al reiniciar. Si el servidor se cayó de madrugada y lo reiniciaste, acabas de destruir la única prueba de por qué se cayó.

Si journalctl --list-boots solo muestra una línea, esa es la señal de alarma. Activar la persistencia es trivial y es de lo primero que hay que hacer en un servidor nuevo:

Los permisos del directorio (2755 root:systemd-journal) los pone systemd-tmpfiles; ese SGID de 05-02 es lo que permite al grupo systemd-journal —y a adm— leer los ficheros que se creen dentro.

Un journal persistente sin límites es un /var lleno esperando su turno. Los límites se fijan aquí:

Ese último par merece un aviso serio: con los valores por defecto, un servicio que emita más de 10 000 mensajes en 30 segundos verá cómo journald descarta el resto en silencio, dejando solo una nota de cuántos ha suprimido. Justo en una tormenta de errores, que es cuando más los necesitas. Si tu aplicación puede ser ruidosa en un incidente, sube RateLimitBurst o desactívalo (RateLimitIntervalSec=0) asumiendo el coste en disco.

Los tres últimos son binarios: un cat sobre ellos escupe basura y puede desconfigurarte el terminal. Se leen con sus herramientas:

Una ristra de lastb contra root desde una IP extranjera es exactamente el tipo de señal que en 06-03 aprenderás a cortar con fail2ban.

Tus scripts del Módulo 4 escriben a /var/log/tramontana/cron-copia.log porque no sabías hacer otra cosa. logger manda el mensaje al mismo sitio que el resto del sistema, con su prioridad y su etiqueta:

Ahora modificamos log() y error() de lib/comunes.sh para que, además de su fichero, escriban en el journal:

El -- antes del mensaje evita que un texto que empiece por guion se interprete como opción, siguiendo la disciplina de 04-03. Y como el script ahora corre dentro de tramontana-respaldo.service (05-05), todo lo que escriba a stdout también acaba en el journal de esa unidad, con sus metadatos:

Con eso, la pregunta «¿se hizo la copia anoche?» es un comando, no una investigación.

Un log sin rotar crece hasta llenar su partición. Cuando /var se llena, la aplicación no puede escribir, la base de datos no puede confirmar transacciones y el propio sistema deja de registrar el desastre. La rotación no es limpieza: es disponibilidad.

logrotate se ejecuta a diario mediante logrotate.timer (systemd, ya sabes leerlo), lee /etc/logrotate.conf y todo lo de /etc/logrotate.d/, y por cada fichero decide si toca rotar.

Probar siempre antes de confiar, siguiendo la convención de simular antes de actuar:

Aquí conecta con lo que viste en 05-04 con lsof +L1. Cuando logrotate hace mv acceso.log acceso.log.1, el proceso que lo tenía abierto sigue escribiendo en el mismo inodo: el fichero nuevo se queda a cero para siempre y el viejo sigue creciendo, ahora invisible. Hay dos soluciones y hay que elegir con criterio:

La regla: si la aplicación sabe reabrir su log, usa la señal; copytruncate es el último recurso para software que no colabora.

Con un servidor, journalctl basta. Con dos ya no: correlacionar un error del balanceador con otro de la aplicación entrando por SSH en cada máquina es inviable, y además los logs locales desaparecen cuando la máquina se compromete o se pierde, que es justo cuando más falta hacen. Panorama de opciones, sin montarlas aquí:

• rsyslog remoto: la vía clásica y ligera, *.* @@servidor:6514 sobre TCP con TLS. Madura y suficiente para muchos casos.
• systemd-journal-remote / -upload: conserva la estructura del journal entre máquinas, con journalctl -m para consultar varias.
• Pilas de observabilidad tipo Loki + Promtail + Grafana, o Elasticsearch + Logstash + Kibana: búsqueda, paneles y alertas, a cambio de operar una infraestructura que consume más recursos que el propio servicio.

Un principio que no cambia: el destino remoto debe ser append-only para quien envía. Si un atacante que entra en srv-tramontana puede borrar los logs del servidor central, la centralización no aporta nada forense.

Advertencia de cumplimiento (RGPD). Los logs se copian, se envían fuera de la máquina, se conservan meses y los lee mucha más gente que los datos de producción. Nunca deben contener contraseñas, tokens, claves de API, cookies de sesión, números de tarjeta ni datos personales de los huéspedes de Tramontana (nombre completo, correo, teléfono, documento de identidad). Registrar huesped_id=1017 es correcto; registrar huesped=Ana Pérez, [email protected] convierte tu fichero de log en un fichero con datos personales, con todas las obligaciones que eso arrastra. La política de retención —cuánto tiempo se guarda cada tipo de registro— es una decisión legal antes que técnica y debe validarla el responsable de protección de datos o de cumplimiento, teniendo en cuenta que hay registros con mínimos legales de conservación y otros con máximos.

Medidas concretas y baratas: revisa qué escribe tu aplicación en nivel debug antes de activarlo en producción; comprueba que las URL registradas no llevan tokens en la query string; limita /var/log/tramontana al grupo adm con la ACL de 05-02; y fija la retención en logrotate y en journald.conf en lugar de dejarla al azar.

Cada línea tiene un porqué: rotate 14 con daily da dos semanas de historia, que es lo acordado con Marta; maxsize 100M protege del pico —un ataque o un bucle de errores pueden generar 100 MiB en una tarde y no queremos esperar a mañana—; create 0640 svc-tramontana adm reproduce exactamente los permisos que necesita la aplicación para escribir y el grupo adm para leer; su root adm es obligatorio cuando el directorio no pertenece a root, o logrotate se niega a actuar por seguridad; sharedscripts evita recargar el servicio cinco veces (una por fichero); y el postrotate usa systemctl reload, que la aplicación traduce en reabrir sus ficheros de log, evitando copytruncate y la pérdida de líneas.

Verificación obligatoria antes de darlo por bueno:

Ese último comando es la prueba de que el postrotate funcionó: si la aplicación no hubiera reabierto el fichero, aparecería un (deleted) con NLINK 0.

Ahora la pregunta de las 03:00 se contesta en tres comandos:

Quince errores en la franja de madrugada, todos el mismo: db_timeout con conexiones_activas=200, que es exactamente el valor de max_conexiones en /etc/tramontana/app.conf. El informe para Marta, con la estructura de siempre —qué sabemos, qué protege y qué no—: «Entre las 03:00 y las 03:30 hubo 15 errores del mismo tipo: la aplicación agotó su límite de 200 conexiones a la base de datos y las peticiones caducaron a los 30 s. Nueve de ellos llegaron a devolver un 5xx a usuarios. No hubo caída del servicio ni pérdida de reservas confirmadas. Los logs ya rotan a diario y se conservan 14 días, así que la próxima vez tendremos la traza completa. Falta averiguar por qué se agotan las conexiones a esa hora, y eso lo medimos en la próxima revisión.»

• Dar por hecho que el journal es persistente. Si journalctl --list-boots solo muestra un arranque, estás perdiendo los logs en cada reinicio. Crea /var/log/journal hoy.
• Rotar sin avisar al proceso. El fichero nuevo se queda vacío y el viejo sigue creciendo invisible. lsof +L1 lo delata; usa postrotate con reload o, en último caso, copytruncate.
• Olvidar su en un logrotate.d cuyo directorio no es de root: logrotate lo rechaza por seguridad y deja de rotar en silencio. Compruébalo con logrotate -d.
• rotate 0 o una retención mínima «para ahorrar disco»: el día del incidente no tendrás nada que mirar. Acuerda la retención con quien la va a necesitar.
• Ignorar el rate limiting de journald. En una tormenta de errores puedes perder justo los mensajes que buscas. Revisa RateLimitBurst si tu aplicación es ruidosa.
• cat sobre wtmp o btmp. Son binarios: se leen con last y lastb. Y no registres datos personales ni secretos: es una fuga con formato de fichero de texto, replicada en cada copia de seguridad.
• Consejo: cualquier script que corra solo debe poder responder «¿se ejecutó y con qué resultado?» con un comando. Si no puede, le falta registro.

1. La franja de madrugada. Escribe un solo comando que muestre, del arranque anterior, únicamente los mensajes de prioridad err o peor de tramontana.service producidos entre las 02:00 y las 06:00, en formato con fecha ISO, y otro que cuente cuántos hubo de cada mensaje distinto.
2. Rotación para un log de terceros. Una herramienta escribe en /var/log/analitica/eventos.log como el usuario analitica, no sabe reabrir su fichero y genera unos 30 MiB al día. Escribe su fichero de logrotate.d justificando cada directiva, y explica qué pierdes con la solución elegida.
3. Auditoría de accesos. Con lo visto, responde: ¿cuántos intentos fallidos de acceso hubo ayer, desde qué IP, y qué usuarios se intentaron? Da los comandos y di dónde vive cada dato.

1.

-o cat deja solo el texto del mensaje, que es lo que permite agrupar con sort | uniq -c; con el formato normal, la marca de tiempo haría única cada línea. Es el mismo patrón de conteo de 03-05, aplicado ahora al journal.

2.

daily con rotate 7 da una semana, suficiente para 30 MiB diarios; maxsize 50M cubre un pico sin esperar a mañana; compress con delaycompress ahorra disco sin comprimir el fichero que quizá aún se esté escribiendo; su analitica analitica es imprescindible porque el directorio no es de root; y copytruncate es la única opción viable, ya que la herramienta no sabe reabrir su log y no hay señal que mandarle.

Lo que se pierde: las líneas escritas entre la copia y el truncado, que es una ventana pequeña pero real, y el doble de espacio en disco durante ese instante. No se usa create porque con copytruncate el fichero original nunca se renombra ni se recrea.

3.

Los intentos fallidos viven en dos sitios complementarios: /var/log/btmp (binario, se lee con lastb, guarda usuario, terminal, IP y hora) y el journal de ssh.service, que además da el mensaje exacto y permite filtrar por texto. Cuarenta y siete intentos desde una sola IP en una noche no es un usuario despistado: es un ataque de fuerza bruta, y bloquearlo automáticamente es materia de 06-03.

srv-tramontana ya tiene memoria. Sabes que en Ubuntu conviven dos capas de registro —journald binario y estructurado, rsyslog en texto plano— y por qué el journal reenvía a syslog en lugar de sustituirlo; manejas las ocho severities y las facilities de syslog, incluidas las local0–local7 reservadas para lo tuyo; y exprimes journalctl de verdad: por unidad, en vivo con -f, por ventana temporal con --since/--until, por prioridad con -p, por arranque con -b -1, por kernel con -k, por campos estructurados como _PID y _COMM, con --grep y con formatos short-iso, cat y json-pretty.

Has hecho el journal persistente —sin eso, el reinicio destruye la prueba— y le has puesto techo en journald.conf con SystemMaxUse y MaxRetentionSec, sabiendo que el rate limiting puede tragarse mensajes justo en una tormenta de errores. Reconoces los ficheros clásicos de /var/log y lees wtmp y btmp con last y lastb. Tus scripts escriben en el journal a través de logger desde lib/comunes.sh, y tramontana-respaldo.service responde por sí solo a «¿se hizo la copia anoche?».

Y la deuda del Módulo 4 está pagada: /etc/logrotate.d/tramontana existe, está probado en simulación con logrotate -d, rota a diario conservando catorce días, comprime, recrea el fichero con 0640 svc-tramontana adm y recarga el servicio en postrotate para que ningún proceso siga escribiendo en un inodo huérfano. Sabes qué nunca debe acabar en un log y que la retención es una decisión legal antes que técnica.

Queda la otra mitad de la pregunta de Marta. Sabes qué pasó a las tres de la mañana —quince db_timeout con las 200 conexiones agotadas—, pero no por qué, ni si el servidor iba justo de CPU, de memoria o de disco en ese momento, ni con qué comparar lo que ves hoy. En Monitoreo del Sistema y Optimización del Rendimiento aprenderás el método USE aplicado a los cuatro recursos, interpretarás de verdad el load average, vmstat, free -h, iostat -xz y sar, sabrás cuándo ha actuado el OOM killer y por qué, establecerás una línea base de srv-tramontana, y aplicarás un procedimiento numerado de diagnóstico a la queja de Marta de que «la web va lenta por las mañanas» — donde descubrirás que la copia de seguridad y esas 200 conexiones tienen más que ver de lo que parece.