Analitzar logs amb journalctl i grep eficientment

Qui treballa dia a dia amb sistemes basats en systemd sap que journalctl és una eina útil, però també que es pot tornar un coll d’ampolla si no es fa servir bé. No per falta de funcionalitats, sinó perquè mal utilitzada, retorna volums absurds d’informació, o pitjor, sembla no mostrar res útil quan més ho necessites.

L’error més comú: confiar en grep sense filtrar primer

Un dels hàbits més estesos —i més contraproduents— és llençar un journalctl | grep alguna cosa. Funciona, sí, però en sistemes amb molta càrrega, aquesta canonada pot trigar minuts o retornar milers de línies irrellevants. A més a més, trenca el format de journalctl i perd colors, marques de temps i estructura.

Hi ha una raó per la qual això falla tant: journalctl està pensat per a filtrar abans de generar la sortida, no perquè li passis el resultat complet a una altra eina.

Quan el patró que estàs buscant és prou comú com per aparèixer centenars de vegades, journalctl | grep no t’ajuda a veure el context. I quan és molt estrany, et torna una pantalla buida, i no saps si és perquè no ha passat res o perquè estàs mirant malament.

Solució pràctica: aprofita els filtres interns de journalctl abans de portar-lo a grep. Comença delimitant per unitat (-u), per nivell (-p), per finestra de temps (–since, –until), o per boot (-b). Només quan tens això acotat, si necessites buscar cadenes concretes, ja pots fer servir grep.

Exemple típic:

journalctl -u sshd -p err --since "1 hour ago" | grep 'Failed'

I si realment necessites un context de diverses línies (abans i després), no facis servir grep, fes servir –grep de journalctl, que filtra en origen i manté el format:

journalctl -u sshd --grep=Failed --since "1 hour ago"

Això és especialment útil perquè pots combinar –grep amb múltiples ocurrències (a partir de systemd v239) i conservar el color i els salts d’esdeveniment.

Context temporal: acotar bé els esdeveniments

Quan alguna cosa falla en producció, el temps és or. El log pot tenir milions de línies, i la majoria són soroll. Saber acotar bé el context temporal és més útil que aplicar grep al tuntún.

El truc està en entendre com funcionen –since i –until. Pots passar-li dates en format absolut (2025-07-04 10:30) o relatiu (-30min, “1 hour ago”, “yesterday”). L’important és evitar la temptació d’anar-te’n al log complet.

Per exemple, si algú reporta que alguna cosa va fallar fa 15 minuts:

journalctl --since "-20min" --until "now"

O si saps que un host ha estat reiniciat:

journalctl -b

Això et dona els logs només de l’arrencada actual. Si tens sospites d’esdeveniments previs, fes servir -b -1, -b -2, etc.

Molts obliden aquest detall i tiren de recerques completes. Si fas servir –since bé des del començament, redueixes el volum i millora la llegibilitat.

Filtrar per unitat: el punt de partida bàsic

Sempre que estiguis investigant un problema amb un servei concret, el punt de partida hauria de ser -u. Fer-lo servir consistentment t’evita veure logs que no t’interessen (avahi, cups, dbus, etc.).

journalctl -u nginx.service --since today

O directament:

journalctl -u nginx -b

Si tens un timer associat (per exemple, nginx-reload.timer), recorda que pots afegir múltiples unitats:

journalctl -u nginx -u nginx-reload.timer --since yesterday

Quan es treballa en clusters, convé tenir present que els noms d’unitat no sempre són evidents. Usa systemctl list-units –type=service o systemctl status | less per confirmar els noms exactes.

Un altre truc que estalvia temps: per veure tots els serveis que han fallat recentment:

journalctl -p err -xb

I després investigar cadascú amb -u.

Filtrar per prioritat: útil quan no pots filtrar per unitat

Hi ha sistemes on els serveis no tenen noms coherents, o els logs estan barrejats. Aquí entra en joc el filtre per prioritat (-p). Permet veure errors i advertències sense soroll informatiu.

Prioritats possibles:

• emerg (0)
• alert (1)
• crit (2)
• err (3)
• warning (4)
• notice (5)
• info (6)
• debug (7)

El que més es fa servir a la pràctica: -p err, -p warning, -p err…. alert.

Per exemple:

journalctl -p err --since today

O per a veure tot lo seriós des del darrer boot:

journalctl -p err..alert -b

Un ús molt útil quan fas troubleshooting d’alguna cosa que no saps d’on ve.

Saber quins camps pots filtrar: journalctl entén metadades

Un dels aspectes menys aprofitats de journalctl és la seva capacitat per filtrar per camps estructurats, no només text pla. Pots filtrar per SYSLOG_IDENTIFIER, PID, UID, MESSAGE_ID, etc.

Exemple pràctic: veure tots els missatges d’ un procés específic per PID:

journalctl _PID=1234

O veure tot el que va sortir de sshd com a identificador syslog:

journalctl SYSLOG_IDENTIFIER=sshd

Això et dona precisió que no obtens amb grep, i sobretot, sense trencar l’estructura del log.

Una altra pràctica que ajuda molt en contenidors: si estàs fent servir journald com a backend de logging per a docker o podman, pots filtrar per CONTAINER_NAME o CONTAINER_ID_FULL.

Exportar i treballar offline: journalctl com a font, no com a visor

Quan el sistema està molt carregat, o estàs en una sessió SSH inestable, o has de compartir el log amb un altre equip, pots exportar-lo per revisar-lo amb calma:

journalctl -u nginx --since yesterday > nginx.log

Això exporta a text pla. Si prefereixes conservar l’estructura binària del journal per a analitzar en un altre equip (per exemple, amb systemd-analyze o inspecció avançada), fes servir:

journalctl -u nginx --since yesterday --output=export > nginx.journal

I després pots carregar-lo en una altra màquina amb:

journalctl --file=nginx.journal

Això et permet treballar sense connexió o des d’un entorn local més còmode.

Controlar la mida i la persistència: logs que desapareixen sense avisar

Hi ha situacions on els logs “desapareixen” perquè no està configurats per mantenir logs persistents. Per defecte, en moltes distros (especialment minimalistes), els logs estan en /run/log/journal, que s’esborra en reiniciar.

Per mantenir-los entre boots:

• Crea el directori persistent:

mkdir -p /var/log/journal

• Reinicia systemd-journald:

systemctl reinicia systemd-journald

I després assegura’t de configurar els límits de mida en /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M
SystemKeepFree=100M
SystemMaxFileSize=100M
SystemMaxFiles=10

Això t’evita que un log mal configurat ompli el disc o que el journal s’esborri abans de temps sense que ningú ho noti.

L’ús de less amb journalctl: molt més útil del que sembla

Tot i que sembla trivial, saber navegar amb less fa diferència real. Molts tiren de journalctl -xe i es queden aquí. Però si saps fer servir marques, recerca cap enrere (?), moure’t entre salts d’esdeveniment ({ i }), o marcar línies amb m i tornar amb ‘, pots revisar logs molt més ràpid.

I si vols una sortida menys “formatejada” i més raw, pots canviar la sortida amb –output=short, –output=verbose, –output=json-pretty, o fins i tot cat.

Exemple:

journalctl -u sshd --output=cat --since "1 hour ago"

Això treu els timestamps i mostra només el missatge net, útil quan estàs preparant informes o compartint parts específiques.

Evitar errors comuns quan combines filtres

Una font freqüent de frustració ve de combinar malament els arguments de journalctl. Hi ha operadors que no es barregen com un esperaria. Un exemple clàssic:

journalctl -u sshd -p err

Aquest comandament no filtra com molts pensen. No et dona els errors del servei sshd, sinó tots els errors del sistema, i els logs complets de sshd, en dos blocs separats, depenent de l’ordre en què el journal resolgui els filtres.

Si necessites precisió, fes servir els filtres estructurats. Així:

journalctl _SYSTEMD_UNIT=sshd.service PRIORITY=3

O si la teva versió de systemd ho suporta, pots fer servir –grep al costat dels filtres, i això sí que ho interpreta correctament.

Una altra trampa típica: combinar -b i –since sense tenir en compte que -b acota ja el temps. Per exemple:

journalctl -b --since "2 hours ago"

Això no mostra res si el boot va començar abans d’aquell temps. –since només filtra dins del rang de -b, així que si l’arrencada va ser fa 3 hores, i demanes –since 2 hours ago, el resultat és buit encara que hi hagi esdeveniments.

Solució: o fas servir –since només, o verifiques la hora del boot amb journalctl –list-boots abans.

Com identificar patrons de soroll recurrents

En sistemes grans, un gran problema és el soroll: serveis que escriuen logs constants però irrellevants, com NetworkManager en mode debug, unitats mal configurades o scripts que no silencien sortides.

Quan els logs importants s’ ofeguen en centenars de línies sense valor, convé identificar patrons sorollosos i filtrar-los temporalment durant l’ anàlisi. Exemple:

journalctl --since "-1h" | grep -v "dnsmasq"

Però si fas servir això molt, no és escalable. Una millor pràctica és configurar els serveis sorollosos amb un nivell de log adequat (StandardOutput=null, LogLevel=notice, etc.) o moure la seva sortida a un arxiu separat si no necessites que passin pel journal.

Una altra opció intermitja: ajustar la prioritat a la unitat perquè només entrin missatges a partir de cert nivell.

[Service]
SyslogLevel=warning

Això no ho arregla tot, però ajuda a reduir el volum diari sense perdre esdeveniments crítics.

Combinar amb eines externes

De vegades necessites exportar part del log per processar-lo amb eines externes: awk, jq, set, etc. Si vas per aquest camí, el recomanable és canviar el format de sortida a una cosa més estructurada.

Per exemple, per treballar amb JSON:

journalctl -u nginx --output=json-pretty --des d'ahir > nginx.json

Des d’aquí, pots fer servir jq per extreure claus, agrupar per PID, o veure patrons per PRIORITY.

També pots fer servir journalctl com a input per a eines com fzf, per a navegar logs interactius, o fins i tot construir dashboards mínims amb gawk i gnuplot si estàs monitoritzant alguna cosa puntual.

Això té sentit quan vols graficar errors per minut o entendre pics d’esdeveniments. Però no abusis. Si estàs fent tot això cada setmana, és hora de muntar un stack de logs amb rsyslog, fluentd o journald-forward.

Consideracions finals per a entorns multiusuari o amb suport remot

Si estàs donant suport a usuaris no tècnics o amb privilegis limitats, convé recordar que es pot filtrar per UID:

journalctl _UID=1001

Això permet veure només el que ha generat un usuari específic, útil quan alguna cosa falla amb sessions gràfiques, cron jobs personals o serveis a user.slice.

També pots limitar l’accés als logs. Per defecte, només root o membres del grup systemd-journal poden llegir el journal complet. Això està bé, però en alguns entorns convé delegar accés temporal a logs específics sense donar sudo.

Val la pena bolcar tot a arxius plans?

Un dubte raonable: ¿continua tenint sentit mantenir rsyslog o syslog-ng en paral·lel per tenir /var/log/messages, /var/log/syslog, etc.?

En alguns entorns, sí. Sobretot si hi ha scripts heretats, eines que esperen aquests arxius, o integracions amb backup que busquen en aquesta estructura. Però per a anàlisis en temps real o debugging en calent, journalctl dona molta més flexibilitat, i si es gestiona bé, no hi ha necessitat real de mantenir-los tots dos.

Si decideixes desactivar el syslog tradicional, assegura’t d’ajustar journald.conf per a tenir persistència, rotació controlada i filtres de mida raonables. Sense això, pots acabar perdent esdeveniments valuosos per rotacions agressives o falta de disc.

Conclusió

journalctl té més profunditat de la que molts aprofiten. No cal aprendre tot el seu sistema de camps perquè sigui útil, però sí que convé dominar lo bàsic: filtres per unitat, prioritat, temps i –grep. Combinar-los bé t’estalvia hores.

Fer servir journalctl | grep com a única eina és tirar per la borda el seu disseny. Millor fer servir journalctl com el que és: una interfície pensada per a filtrar abans de mostrar.