La Marta escriu a les 09:12: «Ahir a la nit, cap a les tres, el web estava donant errors. Què va passar?». Aquesta pregunta té resposta exacta o no en té, i la diferència la marca el que haguessis fet abans que passés. Un servidor no recorda res: l'única cosa que queda de la matinada és el que es va escriure en algun lloc, amb la marca de temps correcta, sense que s'hagi rotat, truncat ni perdut en el reinici. Aquesta lliçó va d'això. I salda de passada el primer deute que vaig anunciar en tancar el Mòdul 4: /var/log/tramontana/acces.log porta 412 línies creixent sense que ningú el roti, i el dia que ompli /var s'endurà per davant l'aplicació sencera.

1. Les dues capes de registre que conviuen a Ubuntu
2. Facilities i severities de syslog
3. journalctl a fons
4. Persistència del journal
5. /etc/systemd/journald.conf i el control de la mida
6. Els fitxers clàssics de /var/log
7. Escriure al registre des dels teus scripts amb logger
8. logrotate: per què i com
9. El problema del fitxer obert després de rotar
10. Centralització de registres
11. Què NO ha d'acabar MAI en un registre
12. Cas Tramontana: rotació i la resposta per a la Marta

En una Ubuntu 24.04 acabada d'instal·lar hi ha dos sistemes de registre funcionant alhora, i entendre el repartiment evita molta confusió:

El flux real: tot el que un servei gestionat per systemd escriu a stdout i stderr ho captura journald, juntament amb el que arriba pel sòcol /dev/log i els missatges del nucli. Journald ho guarda amb les seves metadades i, a més, ho reenvia a rsyslog (ForwardToSyslog=yes), que ho escriu als fitxers de text de sempre. Per això el mateix missatge apareix a journalctl i a /var/log/syslog.

Per què conservar les dues? El journal és incomparablement millor per consultar —filtra per unitat, per prioritat, per arrencada, per camp— i els fitxers de text són millors per al que ja saps fer amb grep, awk i sed, per a eines de tercers i per a l'enviament remot. En un servidor real hi convius amb tots dos.

Aquest vocabulari ve dels anys 80 i continua viu perquè tota la indústria l'entén. Cada missatge porta una facility (d'on ve) i una severity (quant importa).

Facilities habituals: auth i authpriv (autenticació: sudo, sshd), cron, daemon (serveis), kern (nucli), mail, syslog, i local0–local7, reservades per a les teves aplicacions. Aquesta última és la clau pràctica: quan copia_tramontana.sh escrigui al registre, ho farà amb una facility local0 i una severity concordant, i així podràs filtrar els teus missatges sense arrossegar els del sistema.

És l'eina del dia a dia i val la pena aprendre-la bé, perquè substitueix mitja dotzena de grep.

Les expressions de temps accepten yesterday, today, tomorrow, now, -30min, "2 days ago" i dates absolutes. És una de les raons de pes per fer servir el journal: contestar «què va passar entre les 3:00 i les 3:30» amb fitxers de text exigeix un awk amb rangs; aquí són dues opcions.

journalctl -b -1 respon a «el servidor s'ha reiniciat sol aquesta nit, per què?», i requereix journal persistent: justament el de l'apartat següent.

Cada entrada del journal no és una línia: és un conjunt de camps. Descobreix-los amb:

Els camps que comencen per _ els afegeix journald, i per això són de fiar: una aplicació no els pot falsificar. Es fan servir com a filtre:

Combinar filtres és l'essència de l'eina: unitat + finestra temporal + prioritat + format reproduïble, en una sola línia.

Aquest és el detall que sorprèn tothom la primera vegada: per defecte, en moltes instal·lacions el journal és volàtil. Viu a /run/log/journal, que és un tmpfs a la RAM, i es perd sencer en reiniciar. Si el servidor va caure de matinada i el vas reiniciar, acabes de destruir l'única prova de per què va caure.

Si journalctl --list-boots només mostra una línia, aquell és el senyal d'alarma. Activar la persistència és trivial i és de les primeres coses que cal fer en un servidor nou:

Els permisos del directori (2755 root:systemd-journal) els posa systemd-tmpfiles; aquell SGID de 05-02 és el que permet al grup systemd-journal —i a adm— llegir els fitxers que es creïn a dins.

Un journal persistent sense límits és un /var ple esperant el seu torn. Els límits es fixen aquí:

Aquest últim parell mereix un avís seriós: amb els valors per defecte, un servei que emeti més de 10.000 missatges en 30 segons veurà com journald en descarta la resta en silenci, deixant només una nota de quants n'ha suprimit. Justament en una tempesta d'errors, que és quan més els necessites. Si la teva aplicació pot ser sorollosa en un incident, apuja RateLimitBurst o desactiva'l (RateLimitIntervalSec=0) assumint-ne el cost en disc.

Els tres últims són binaris: un cat sobre ells escup brossa i pot desconfigurar-te el terminal. Es llegeixen amb les seves eines:

Una tirallonga de lastb contra root des d'una IP estrangera és exactament el tipus de senyal que a 06-03 aprendràs a tallar amb fail2ban.

Els teus scripts del Mòdul 4 escriuen a /var/log/tramontana/cron-copia.log perquè no sabies fer una altra cosa. logger envia el missatge al mateix lloc que la resta del sistema, amb la seva prioritat i la seva etiqueta:

Ara modifiquem log() i error() de lib/comuns.sh perquè, a més del seu fitxer, escriguin al journal:

El -- abans del missatge evita que un text que comenci per guionet s'interpreti com a opció, seguint la disciplina de 04-03. I com que l'script ara corre dins de tramontana-copia.service (05-05), tot el que escrigui a stdout també acaba al journal d'aquella unitat, amb les seves metadades:

Amb això, la pregunta «es va fer la còpia ahir a la nit?» és una ordre, no una investigació.

Un registre sense rotar creix fins a omplir la seva partició. Quan /var s'omple, l'aplicació no pot escriure, la base de dades no pot confirmar transaccions i el sistema mateix deixa de registrar el desastre. La rotació no és neteja: és disponibilitat.

logrotate s'executa a diari mitjançant logrotate.timer (systemd, ja el saps llegir), llegeix /etc/logrotate.conf i tot el d'/etc/logrotate.d/, i per a cada fitxer decideix si toca rotar.

Provar sempre abans de confiar-hi, seguint la convenció de simular abans d'actuar:

Aquí connecta amb el que vas veure a 05-04 amb lsof +L1. Quan logrotate fa mv acces.log acces.log.1, el procés que el tenia obert continua escrivint al mateix inode: el fitxer nou es queda a zero per sempre i el vell continua creixent, ara invisible. Hi ha dues solucions i cal triar amb criteri:

La regla: si l'aplicació sap reobrir el seu registre, fes servir el senyal; copytruncate és l'últim recurs per a programari que no col·labora.

Amb un servidor, journalctl n'hi ha prou. Amb dos ja no: correlacionar un error del balancejador amb un altre de l'aplicació entrant per SSH a cada màquina és inviable, i a més els registres locals desapareixen quan la màquina es compromet o es perd, que és justament quan més falta fan. Panorama d'opcions, sense muntar-les aquí:

• rsyslog remot: la via clàssica i lleugera, *.* @@servidor:6514 sobre TCP amb TLS. Madura i suficient per a molts casos.
• systemd-journal-remote / -upload: conserva l'estructura del journal entre màquines, amb journalctl -m per consultar-ne diverses.
• Piles d'observabilitat tipus Loki + Promtail + Grafana, o Elasticsearch + Logstash + Kibana: cerca, taulers i alertes, a canvi d'operar una infraestructura que consumeix més recursos que el servei mateix.

Un principi que no canvia: la destinació remota ha de ser append-only per a qui envia. Si un atacant que entra a srv-tramontana pot esborrar els registres del servidor central, la centralització no aporta res forense.

Advertiment de compliment (RGPD). Els registres es copien, s'envien fora de la màquina, es conserven mesos i els llegeix molta més gent que les dades de producció. Mai no han de contenir contrasenyes, tokens, claus d'API, galetes de sessió, números de targeta ni dades personals dels hostes de Tramontana (nom complet, correu, telèfon, document d'identitat). Registrar hoste_id=1017 és correcte; registrar hoste=Ana Pérez, [email protected] converteix el teu fitxer de registre en un fitxer amb dades personals, amb totes les obligacions que això arrossega. La política de retenció —quant de temps es guarda cada tipus de registre— és una decisió legal abans que tècnica i l'ha de validar el responsable de protecció de dades o de compliment, tenint en compte que hi ha registres amb mínims legals de conservació i altres amb màxims.

Mesures concretes i barates: revisa què escriu la teva aplicació en nivell debug abans d'activar-lo en producció; comprova que les URL registrades no porten tokens a la query string; limita /var/log/tramontana al grup adm amb l'ACL de 05-02; i fixa la retenció a logrotate i a journald.conf en lloc de deixar-la a l'atzar.

Cada línia té el seu perquè: rotate 14 amb daily dona dues setmanes d'història, que és el que s'ha acordat amb la Marta; maxsize 100M protegeix del pic —un atac o un bucle d'errors poden generar 100 MiB en una tarda i no volem esperar fins demà—; create 0640 svc-tramontana adm reprodueix exactament els permisos que necessita l'aplicació per escriure i el grup adm per llegir; su root adm és obligatori quan el directori no pertany a root, o logrotate es nega a actuar per seguretat; sharedscripts evita recarregar el servei cinc vegades (una per fitxer); i el postrotate fa servir systemctl reload, que l'aplicació tradueix en reobrir els seus fitxers de registre, evitant copytruncate i la pèrdua de línies.

Verificació obligatòria abans de donar-ho per bo:

Aquella última ordre és la prova que el postrotate va funcionar: si l'aplicació no hagués reobert el fitxer, hi apareixeria un (deleted) amb NLINK 0.

Ara la pregunta de les 03:00 es contesta en tres ordres:

Quinze errors a la franja de matinada, tots el mateix: db_timeout amb connexions_actives=200, que és exactament el valor de max_connexions a /etc/tramontana/app.conf. L'informe per a la Marta, amb l'estructura de sempre —què sabem, què protegeix i què no—: «Entre les 03:00 i les 03:30 hi va haver 15 errors del mateix tipus: l'aplicació va esgotar el seu límit de 200 connexions a la base de dades i les peticions van caducar als 30 s. Nou d'ells van arribar a retornar un 5xx a usuaris. No hi va haver caiguda del servei ni pèrdua de reserves confirmades. Els registres ja roten a diari i es conserven 14 dies, així que la propera vegada tindrem la traça completa. Falta esbrinar per què s'esgoten les connexions a aquella hora, i això ho mesurem a la propera revisió.»

• Donar per fet que el journal és persistent. Si journalctl --list-boots només mostra una arrencada, estàs perdent els registres a cada reinici. Crea /var/log/journal avui.
• Rotar sense avisar el procés. El fitxer nou es queda buit i el vell continua creixent invisible. lsof +L1 el delata; fes servir postrotate amb reload o, en últim cas, copytruncate.
• Oblidar el su en un logrotate.d el directori del qual no és de root: logrotate ho rebutja per seguretat i deixa de rotar en silenci. Comprova-ho amb logrotate -d.
• rotate 0 o una retenció mínima «per estalviar disc»: el dia de l'incident no tindràs res a mirar. Acorda la retenció amb qui la necessitarà.
• Ignorar la limitació de tasa de journald. En una tempesta d'errors pots perdre justament els missatges que busques. Revisa RateLimitBurst si la teva aplicació és sorollosa.
• cat sobre wtmp o btmp. Són binaris: es llegeixen amb last i lastb. I no registris dades personals ni secrets: és una fuita amb format de fitxer de text, replicada a cada còpia de seguretat.
• Consell: qualsevol script que corri sol ha de poder respondre «s'ha executat i amb quin resultat?» amb una ordre. Si no pot, li falta registre.

1. La franja de matinada. Escriu una sola ordre que mostri, de l'arrencada anterior, únicament els missatges de prioritat err o pitjor de tramontana.service produïts entre les 02:00 i les 06:00, en format amb data ISO, i una altra que compti quants n'hi va haver de cada missatge diferent.
2. Rotació per a un registre de tercers. Una eina escriu a /var/log/analitica/esdeveniments.log com l'usuari analitica, no sap reobrir el seu fitxer i genera uns 30 MiB al dia. Escriu el seu fitxer de logrotate.d justificant cada directiva, i explica què perds amb la solució triada.
3. Auditoria d'accessos. Amb el que has vist, respon: quants intents fallits d'accés hi va haver ahir, des de quina IP, i quins usuaris s'hi van intentar? Dona les ordres i digues on viu cada dada.

1.

-o cat deixa només el text del missatge, que és el que permet agrupar amb sort | uniq -c; amb el format normal, la marca de temps faria única cada línia. És el mateix patró de recompte de 03-05, aplicat ara al journal.

2.

daily amb rotate 7 dona una setmana, suficient per a 30 MiB diaris; maxsize 50M cobreix un pic sense esperar fins demà; compress amb delaycompress estalvia disc sense comprimir el fitxer que potser encara s'està escrivint; su analitica analitica és imprescindible perquè el directori no és de root; i copytruncate és l'única opció viable, ja que l'eina no sap reobrir el seu registre i no hi ha cap senyal que enviar-li.

El que es perd: les línies escrites entre la còpia i el truncament, que és una finestra petita però real, i el doble d'espai al disc durant aquell instant. No es fa servir create perquè amb copytruncate el fitxer original mai no es reanomena ni es recrea.

3.

Els intents fallits viuen en dos llocs complementaris: /var/log/btmp (binari, es llegeix amb lastb, guarda usuari, terminal, IP i hora) i el journal d'ssh.service, que a més dona el missatge exacte i permet filtrar per text. Quaranta-set intents des d'una sola IP en una nit no és un usuari despistat: és un atac de força bruta, i bloquejar-lo automàticament és matèria de 06-03.

srv-tramontana ja té memòria. Saps que a Ubuntu conviuen dues capes de registre —journald binari i estructurat, rsyslog en text pla— i per què el journal reenvia a syslog en lloc de substituir-lo; manegues les vuit severities i les facilities de syslog, incloses les local0–local7 reservades per al que és teu; i exprimeixes journalctl de debò: per unitat, en directe amb -f, per finestra temporal amb --since/--until, per prioritat amb -p, per arrencada amb -b -1, per nucli amb -k, per camps estructurats com _PID i _COMM, amb --grep i amb formats short-iso, cat i json-pretty.

Has fet el journal persistent —sense això, el reinici destrueix la prova— i li has posat sostre a journald.conf amb SystemMaxUse i MaxRetentionSec, sabent que la limitació de tasa pot empassar-se missatges justament en una tempesta d'errors. Reconeixes els fitxers clàssics de /var/log i llegeixes wtmp i btmp amb last i lastb. Els teus scripts escriuen al journal a través de logger des de lib/comuns.sh, i tramontana-copia.service respon per si sol a «es va fer la còpia ahir a la nit?».

I el deute del Mòdul 4 està pagat: /etc/logrotate.d/tramontana existeix, està provat en simulació amb logrotate -d, rota a diari conservant catorze dies, comprimeix, recrea el fitxer amb 0640 svc-tramontana adm i recarrega el servei al postrotate perquè cap procés no continuï escrivint en un inode orfe. Saps què mai no ha d'acabar en un registre i que la retenció és una decisió legal abans que tècnica.

Queda l'altra meitat de la pregunta de la Marta. Saps què va passar a les tres de la matinada —quinze db_timeout amb les 200 connexions esgotades—, però no per què, ni si el servidor anava just de CPU, de memòria o de disc en aquell moment, ni amb què comparar el que veus avui. A Monitoratge del Sistema i Optimització del Rendiment aprendràs el mètode USE aplicat als quatre recursos, interpretaràs de debò la càrrega mitjana, vmstat, free -h, iostat -xz i sar, sabràs quan ha actuat l'OOM killer i per què, establiràs una línia base de srv-tramontana, i aplicaràs un procediment numerat de diagnòstic a la queixa de la Marta que «el web va lent al matí» — on descobriràs que la còpia de seguretat i aquelles 200 connexions tenen més a veure del que sembla.