Visualizzare e manipolare i log di Systemd con Journalctl

Il logging di sistema e di processo sono solo due dei vantaggi più fondamentali di systemd. Quando i log sono dispersi in tutto il sistema, interessano più applicazioni e sono gestiti da processi e daemon diversi, possono essere difficili da interpretare. Systemd fornisce una soluzione centralizzata per la gestione di tutti i log dei processi del kernel e dello userland in un mezzo di compilazione noto come journal. Puoi saperne di più su systemd nel nostro tutorial su come gestire i servizi e le unità di systemd con systemctl. Tutti i messaggi generati da servizi, initrd, kernel, ecc. in un journal sono gestiti dal daemon del journal. Lo scopo di questa guida è illustrare come accedere e manipolare i dati del journal utilizzando journalctl.

Premessa di base

Indipendentemente da dove possa avere origine un messaggio, uno degli scopi principali di systemd è consentire la centralizzazione della loro gestione. Poiché molti dei processi di avvio e gran parte della gestione dei servizi sono presi in carico dal processo systemd, il modo in cui i log vengono compilati e consultati dovrebbe essere standardizzato. Raccogliendo dati da qualsiasi fonte disponibile in un unico strumento onnicomprensivo, journald li memorizza in un formato binario. Ciò consente ai dati di essere prontamente disponibili per una manipolazione dinamica e semplice.

Questo approccio presenta diversi vantaggi chiave. Disponendo di un luogo centrale per raccogliere tutti i dati, gli amministratori possono filtrare e visualizzare solo i dati di cui hanno bisogno. Ad esempio, è possibile visualizzare i dati di avvio di tre avvii di sistema fa. Potrebbe anche significare la registrazione sequenziale delle voci dei servizi correlati e tracciare in modo più efficace un problema di comunicazione tra di essi.

Grazie all'archiviazione binaria, i dati possono essere visualizzati in una varietà di formati di output a seconda delle esigenze dell'utente in quel momento. Ad esempio, un log giornaliero può essere visualizzato in un formato syslog standard. Ma se hai bisogno di analizzare l'andamento delle interruzioni di servizio sotto forma di grafico, la voce può essere esportata come un JSON oggetto, rendendolo utilizzabile con un servizio di grafici. Quando è necessario modificare i formati in base alle esigenze della situazione, non è necessaria alcuna conversione poiché i dati sono binari e non scritti sul disco in testo normale.

A seconda delle proprie esigenze, è possibile implementare il journal di systemd con un syslog esistente oppure può sostituirne la funzionalità. Systemd può persino integrare i meccanismi di logging esistenti. Ad esempio, più servizi su un singolo sistema possono avere i loro dati compilati intrecciati su un singolo sistema con il journal di systemd.

Impostazione dell'ora del sistema

Systemd, per impostazione predefinita, mostrerà i risultati nell'ora locale, un vantaggio della registrazione binaria del journal nel modo in cui i record di log possono essere visualizzati. In alternativa, possono essere visualizzati in UTC. Pertanto, è importante assicurarsi che il fuso orario sia impostato correttamente prima di iniziare con la registrazione del journal. Per fare ciò, systemd è dotato di uno strumento chiamato timedatectl. Iniziamo vedendo quali fusi orari sono disponibili per l'uso visualizzando un elenco con le opzioni list-timezones:

Dopo aver trovato il fuso orario corrispondente alla posizione del tuo server, il fuso orario può essere impostato utilizzando l'opzione set-timezone:

Per testare e verificare che il fuso orario sia ora visualizzato correttamente, puoi utilizzare il comando timedatectl da solo o aggiungendo 'status':

La prima riga mostra l'ora locale. Questa riga dovrebbe contenere l'ora corretta per la tua regione locale.

Visualizzazione generale dei log

Il comando journalctl ti consentirà di visualizzare i log raccolti dal daemon journald. Quando usi journalctl, ogni voce del journal del sistema verrà visualizzata all'interno della pagina dello schermo, con le voci più vecchie elencate verso l'alto. L'elenco completo dei dati sarà, tuttavia, lungo decine di migliaia di righe.

Coloro che hanno utilizzato la registrazione syslog standard troveranno il formato familiare, ma è importante tenere presente che questa raccolta di dati proviene da molte fonti, a differenza del metodo syslog. I log includeranno la prima fase di avvio, l’initrd e il kernel, oltre agli errori standard delle applicazioni.

Ora che l’ora locale è impostata, tutte le voci inizieranno con timestamp espressi in ora locale, ed è disponibile per ogni log attualmente memorizzato sul sistema, con tutta la logica visualizzata utilizzando queste nuove informazioni. Tuttavia, non sei limitato all’ora locale. Utilizzando il flag –utc, puoi visualizzare i timestamp anche in UTC:

Filtraggio del journal per tempo

Avere così tanti dati a disposizione è fantastico, ma passarli al setaccio ed essere in grado di assimilarli, per non parlare di elaborarli mentalmente, può essere un compito arduo. Con questo in mente, arriviamo alla parte più importante della funzione journalctl: il filtraggio.

Visualizzazione dei log dall’avvio corrente

Se stai cercando i dati nel journal relativi all’ultimo riavvio, puoi utilizzare la funzione journalctl con il flag -b. Questo mostrerà tutte le informazioni di log pertinenti dell’ultimo riavvio del sistema. Questo comando ti consentirà di trovare e gestire le informazioni più pertinenti all’ambiente di lavoro corrente:

Se l’utente sceglie di non valutare ogni singola voce, journalctl mostrerà più di un giorno di avvii che verranno visualizzati in journalctl con comodi separatori ‘Reboot’. Questo aiuta a separare logicamente le informazioni delle diverse sessioni di avvio per la revisione:

Informazioni sugli avvii precedenti

Sebbene la visualizzazione delle informazioni sull’avvio corrente tenda ad essere la più utile, ci sono situazioni in cui le informazioni sugli avvii passati si riveleranno utili. Journal salva le informazioni per più avvii precedenti, quindi journalctl può facilmente visualizzare le informazioni per qualsiasi periodo di tempo.

Alcune distribuzioni disabilitano il salvataggio delle informazioni sugli avvii precedenti, mentre altre lo hanno abilitato per impostazione predefinita. L’abilitazione delle informazioni di avvio persistenti può essere ottenuta creando una directory per la memorizzazione del journal digitando quanto segue:

In alternativa, puoi modificare il file di configurazione del journal nel seguente modo:

Impostando l’opzione Storage= su “persistent” nella sezione [Journal] si abiliterà la registrazione persistente:

Una volta abilitato, journalctl mette a disposizione alcuni comandi che aiutano a designare questi avvii come unità di divisione. Per visualizzare gli avvii che sono stati registrati in journald, puoi utilizzare l’opzione –list-boots tramite journalctl:

Come illustrato, ogni avvio sarà elencato sulla propria riga con la prima colonna che riflette gli avvii precedenti in ordine dal più vecchio al più recente. Se è necessario un riferimento più assoluto, la seconda colonna contiene l’identificazione dell’avvio. Successivamente, sono elencate due specifiche temporali. Le informazioni della prima o della seconda colonna possono essere utilizzate per visualizzare le informazioni del journal relative allo specifico avvio. Ad esempio, puoi utilizzare il flag -b con il puntatore di avvio relativo -1 per visualizzare le informazioni relative al penultimo riavvio:

Allo stesso modo, anche l’ID di avvio della seconda colonna può essere utilizzato in questo modo:

Finestre temporali

Visualizzare i boot tramite ID è un'opzione, ma spesso è più utile poter fare riferimento ai boot precedenti tramite una finestra temporale nel passato che potrebbe non allinearsi necessariamente con boot specifici. Ad esempio, questo è rilevante in una situazione in cui si lavora con server attivi da molto tempo che non vengono riavviati frequentemente. Il filtraggio dei limiti temporali può essere effettuato con limiti di tempo arbitrari. Questo mostrerà solo le informazioni sui riavvii che rientrano in una particolare finestra temporale. I parametri di questa finestra sono designati con le opzioni –since e –until. Sono disponibili diversi formati per le opzioni temporali. Il formato del valore temporale assoluto è il seguente:

Quindi, se si desidera visualizzare tutti i boot a partire dal 10 gennaio 2015 alle 17:15, digitare il seguente comando:

Se uno qualsiasi dei componenti viene omesso, vi sono dei valori predefiniti incorporati. Inoltre, se viene tralasciata una data, viene impostata come predefinita la data corrente. Se il componente dell'ora è assente, il valore predefinito è la mezzanotte (00:00:00). Se si tralasciano i secondi dal componente dell'ora, questi verranno impostati per impostazione predefinita al punto iniziale di quel minuto (00):

Il journal è in grado di comprendere scorciatoie temporali come “today”, “tomorrow”, “yesterday” e “now”. Parole come “ago”, in combinazione con i qualificatori anteposti “-” e “+”, possono essere utilizzate per costruire un comando di tipo frase:

Se si è stati informati di un'interruzione del servizio iniziata alle 9:00 e si desidera controllare i log del journal fino a un'ora fa, è possibile farlo con quanto segue:

Come è evidente, definire una finestra temporale flessibile per visualizzare le voci desiderate è molto semplice.

Filtra per interesse del messaggio

Oltre a filtrare il journal in base a vincoli temporali, i dati possono anche essere filtrati in base al componente di servizio di interesse. Systemd fornisce diversi metodi per farlo.

Per unità

Probabilmente il parametro di filtraggio più utile è quello per unità di interesse. Per filtrare per unità, è possibile sfruttare l'opzione -u. Ad esempio, se si desidera visualizzare tutti i log relativi all'unità Nginx, digitare il seguente comando:

Realisticamente, si vorrà associare questo a un filtro temporale per visualizzare le righe interessanti. Se si desidera controllare il servizio sopra indicato e come si è comportato oggi, è possibile fare quanto segue:

Questo è particolarmente utile quando si sfrutta la capacità del journal di compilare record da più unità, specialmente quelle collaborative. Se il processo Nginx è connesso a un'unità PHP-FPN per l'elaborazione di contenuti dinamici, le voci possono essere unite in ordine cronologico specificando entrambe le unità:

Questo può essere di grande aiuto nel notare l'interazione tra i programmi e facilitare il debug dei sistemi anziché dei singoli processi.

Per ID gruppo, processo o utente

Molti servizi avviano una moltitudine di sottoprocessi (processi figli) per eseguire un lavoro specifico. Se è disponibile l'ID di un particolare processo, è possibile filtrare anche specificando il campo _PID. Se il PID interessante è 8088, è possibile fare quanto segue:

Si potrebbe anche voler visualizzare le voci registrate da un gruppo particolare o da un utente particolare. Questo può essere ottenuto utilizzando i filtri _GID e _UID. Se un server web viene eseguito con l'utente www-data, il comando seguente consente di trovare l'ID necessario:

Utilizzando tale ID, è quindi possibile visualizzare i risultati del journal qualificati:

Systemd rende disponibili molti campi a scopo di filtraggio. Alcuni campi vengono applicati da journald in base alle informazioni raccolte dal sistema al momento della registrazione, mentre altri vengono passati dal processo attualmente registrato.

Un pre-qualificatore di _PID indica che le informazioni sono state raccolte dal sistema al momento della registrazione. Il journal registra e indicizza automaticamente il PID durante il processo di registrazione per rendere disponibile la funzionalità di filtraggio in un secondo momento. Per conoscere i campi del journal disponibili, puoi digitare:

Discuteremo di alcuni di questi più avanti in questa guida, ma per ora accenneremo ad altre opzioni utili relative a questi campi. Se desideri vedere tutti i valori disponibili per un particolare campo del journal, puoi utilizzare l'opzione -F. Se desideri vedere cosa ha il journal di systemd per gli ID di gruppo, puoi fare quanto segue:

Questo può aiutare a costruire filtri fornendo un elenco completo dei valori memorizzati nel campo dell'ID di gruppo del journal.

Per percorso del componente

Il filtraggio può essere eseguito anche fornendo un percorso. Se il percorso porta a un eseguibile, verranno visualizzate le voci in journalctl se riguardano quell'eseguibile. Se l'eseguibile di interesse è 'bash', puoi digitare:

Anche se a volte non è possibile farlo, se l'unità dell'eseguibile è disponibile, può generare un metodo di filtraggio più chiaro e informativo.

Visualizzare i messaggi del kernel

I messaggi del kernel, tipicamente presenti nell'output di dmesg, possono essere recuperati anche dal journal. Per visualizzare solo questi messaggi, utilizziamo i flag -k o -dmesg come parte del nostro comando:

I messaggi dell'avvio corrente verranno visualizzati per impostazione predefinita, ma gli avvii precedenti possono essere specificati utilizzando il flag di selezione menzionato in precedenza. Se stai cercando i messaggi di cinque avvii fa, digitando questo otterrai i risultati necessari:

Per priorità

Gli amministratori di sistema spesso preferiscono filtrare per priorità. I log a bassa priorità, sebbene spesso utili da visualizzare, possono creare confusione e contenere molte distrazioni, rendendoli meno digeribili durante l'analisi. L'uso dell'opzione -p in journalctl mostrerà solo i messaggi di una priorità specificata, filtrando tutte le altre priorità. Se desideri mostrare le voci dal livello di errore in su, inserisci quanto segue:

Questo comando restituirà tutti i messaggi indicati come errori, avvisi, emergenze o critici con il journal che utilizza i livelli di messaggistica syslog standard. I livelli di priorità sono definiti in base a un valore numerico, classificato dal più alto al più basso:

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

Ognuno dei precedenti è utilizzabile in modo intercambiabile con l'opzione -p. La selezione di una qualsiasi delle priorità come descritto sopra filtrerà tutte le priorità a quel livello e superiori.

Modificare la visualizzazione nel Journal

Oltre a utilizzare il filtraggio per la selezione delle voci, abbiamo altri metodi per modificare l'output, adattando la visualizzazione di journalctl alle nostre esigenze.

Troncare/Espandere l'output

Possiamo regolare la visualizzazione del nostro output decidendo se journalctl debba rimpicciolire o espandere i dati. L'impostazione predefinita di journalctl è mostrare la voce completa, facendo scorrere le voci più lunghe verso la destra dello schermo. È possibile visualizzare le voci nella loro interezza scorrendo con il tasto freccia destra. Un utente potrebbe invece voler troncare l'output, con un punto di sospensione indicato sulle righe che altrimenti andrebbero fuori dallo schermo. Per questo, è possibile utilizzare l'opzione –no-full:

In alternativa, puoi anche consentire la visualizzazione di tutto, indipendentemente dalla lunghezza o dall'inclusione di caratteri non stampabili, utilizzando il flag -a:

Output su Standard Out

Journalctl mostra l'output in un pager per impostazione predefinita, ma se desideri manipolare i dati con strumenti di modifica del testo, probabilmente avrai bisogno che l'output sia generato su un'opzione di standard output. Puoi ottenere questo risultato con l'opzione –no-pager:

A seconda delle esigenze dell'utente, questo può essere reindirizzato a un file su disco o a un'utilità di elaborazione.

Formati di output

I dati sono sempre più facili da analizzare quando vengono presentati in un formato più fruibile. Il journal fornisce molteplici opzioni di visualizzazione utilizzando il qualificatore -o seguito da un formato specificamente indicato.

Se desideri esportare le voci del journal in formato JSON, puoi farlo nel seguente modo:

Questa strategia è particolarmente utile con le utilità di analisi. Il formato json-pretty può essere migliore per visualizzare le strutture dati prima di passarle al consumatore JSON:

Ci sono diversi formati che puoi utilizzare per la visualizzazione:

• cat: Mostra solo il campo del messaggio stesso.
• export: Un formato binario adatto al trasferimento o al backup.
• json: JSON standard con una voce per riga.
• json-pretty: JSON formattato per una migliore leggibilità umana
• json-sse: Output formattato in JSON racchiuso per renderlo compatibile con i server-sent events
• short: L'output predefinito in stile syslog
• short-iso: Il formato predefinito integrato per mostrare i timestamp dell'orologio a parete ISO 8601.
• short-monotonic: Il formato predefinito con timestamp monotonici.
• short-precise: Il formato predefinito con precisione al microsecondo
• verbose: Mostra ogni campo del journal disponibile per la voce, inclusi quelli solitamente nascosti internamente.

Le opzioni sopra indicate consentono di visualizzare il journal nel formato preferito.

Monitoraggio dei processi attivi

Il journal consente di accedere alle funzioni di monitoraggio delle attività attive o recenti senza dover ricorrere a un altro strumento. Puoi farlo con il comando journalctl con una funzione 'tail'.

• Visualizzazione dei log recenti

L'utilizzo dell'opzione -n (che funziona proprio come il comando tail -n) consentirà la visualizzazione di una determinata quantità di record:

Il numero di voci che desideri visualizzare può essere specificato con un numero particolare dopo il qualificatore -n:

• Seguire i log

Puoi anche seguire i log attivamente mentre vengono scritti sul sistema con il flag -f. Anche questo funziona allo stesso modo del comando tail -f:

Manutenzione del journal

I log occupano spazio. Vale la pena approfondire questo aspetto, potenzialmente per eliminare alcuni dei log più vecchi per liberare spazio.

Trovare l'utilizzo corrente del disco

Il flag –disk-usage può aiutare a identificare quanto spazio i log stanno attualmente occupando sul disco:

Eliminazione dei vecchi log

Con systemd versione 218 (e versioni successive) puoi ridurre il journal in due modi diversi. Uno è l'opzione –vacuum-size. Questa può ridurre il journal indicandone la dimensione. In altre parole, le voci più vecchie verranno eliminate dal log fino a quando lo spazio occupato non rientrerà nel parametro richiesto:

L'opzione –vacuum-time può ridurre lo spazio occupato dal journal indicando un tempo limite, oltre il quale le voci verranno eliminate, mentre quelle create dopo il tempo specificato verranno conservate. Se desideri conservare solo le voci dell'ultimo anno solare, puoi utilizzare:

Limitare l'espansione del journal

Puoi anche limitare la quantità di spazio che il journal occuperà. Questo si ottiene modificando il file /etc/systemd.journald.conf. La crescita del journal può essere limitata utilizzando uno dei seguenti metodi:

• SystemMaxUse=: Indica lo spazio massimo su disco che il journal è autorizzato a utilizzare nell'archiviazione persistente.
• SystemKeepFree=: Indica quanto spazio deve essere lasciato libero quando le entità del journal vengono aggiunte nell'archiviazione persistente.
• SystemMaxFileSize=: Specifica quanto possono diventare grandi i file del journal prima della rotazione nell'archiviazione persistente.
• RuntimeMaxUse=: Specifica quanto spazio su disco è consentito utilizzare nell'archiviazione volatile (all'interno del filesystem /run).
• RuntimeKeepFree=: Quando si scrivono dati nell'archiviazione volatile, questa funzione indica la quantità di spazio che deve essere dedicata ad altri usi (all'interno del filesystem /run).
• RuntimeMaxFileSize=: Indica quanto spazio un singolo log del journal può occupare nell'archiviazione volatile (all'interno del filesystem /run) prima di dover essere ridimensionato.

Queste opzioni possono tutte aiutare a controllare il consumo di spazio di archiviazione da parte del journal. Un fatto importante da notare è che le opzioni SystemMaxFileSize e RuntimeMaxFileSize prenderanno di mira i file archiviati per raggiungere i limiti stabiliti. Questo è un fatto importante da tenere a mente quando si interpreta il conteggio dei file dopo le operazioni di pulizia (vacuuming).

Conclusione

È evidente che il journal di systemd è uno strumento incredibilmente utile da sfruttare, con la maggior parte dei suoi vantaggi che derivano dalla natura centralizzata dei log’ e dall'ampio volume di metadati registrati. Si può trarre vantaggio dalle ampie funzionalità del journal tramite l'utilizzo del comando journalctl, che favorisce un metodo più semplice per eseguire il debug relazionale dei componenti dell'applicazione, oltre a un'analisi approfondita del sistema.

Buon divertimento con l'informatica!