Phenquestions
Comprendere i log è importante: se ti capita di cadere su un server che ha un bug o è stato violato, generalmente l'unico modo per capire cosa è successo è tramite i log. L'applicazione principale che useremo è journalctl da cui il nome dell'articolo. Quindi ascolta attentamente come nel giorno giusto, potresti essere felice di sapere come funziona.
Dove sono archiviati i log di sistema?? E in che formato è memorizzato?
Daremo per scontato che tu abbia un sistema normale, perché systemd può essere personalizzato per essere in posti eccezionali. Inoltre, alcune distribuzioni Linux come Ubuntu 16.04 ha disabilitato la registrazione persistente per impostazione predefinita, che impedisce a systemd di svolgere correttamente il proprio lavoro. Se hai tale distribuzione, modifica /etc/systemd/journald.conf, cambia Storage=auto in Storage=persistent e infine riavvia.
Quindi troverai normalmente i file di log di systemd in /var/log/journal. Il sistema di journaling è esso stesso un servizio chiamato system-journald.servizio. Proviamo ad elencare i file in questa directory:
# ls /var/log/journal/ -R/var/log/giornale/:
15e43c1734090ac7fbea6b40fcd99d31
/var/log/journal/15e43c1734090ac7fbea6b40fcd99d31:
[email protected]~
sistema@62ac1299826d036cb043d6c06a9493b7-0000000000000001-00067d6410099a19.rivista
[email protected]~
utente-1000@2123bc076b58569fe1fb13e9dbc1b0e0-0000000000000001-0007fe36ac2810e0.rivista
utente-1000.rivista
[molti altri file come quelli sopra…]
Perché voglio che tu continui a leggere, ho dovuto abbreviare l'output in quanto contiene molti file (nel mio esempio, più di 60 file), mi dispiace per quello! Tentato di aprirne uno forse?
# head --bytes=512 /var/log/journal/15e43c1734090ac7fbea6b40fcd99d31/[email protected]b58569fe1fb13e9dbc1b0e0-0000000000000001-0007fe36ac2810e0.rivista
?s,q?n/FLz???Ulz?io?]????
?_?b???z????o?y1KN ?io?eO??W?tu? ?=?x0?l?d?7??X4n#?e? d3l?
p??o|MFO:?!qs?.tK??R?\??1?|5 ????$?g??#?S??;??B7???????t???sì????mN?q????ZQ
?Yv?e?????BD?C?? wF??d|
?2?? 7???????[??Un?=8????c?2=p?&?" ?0
????*????_?? ???
5?????yk?G? ?6?|??tu??w: #12?sì??
3 TU;???'?jX??2?X'?=??[[email protetta]
[e-mail protetta]?_?>??3S???,lR?.?$?g?l???S?/E??M1??q???
Ehi, vedi, non sembrano i soliti file di registro che vedi, giusto? Non preoccuparti, questo file non è corrotto, hai appena scoperto un aspetto di systemd: systemd memorizza i file in un formato binario. Ecco perché è il più piccolo possibile: i dati strutturati come l'ora o la posizione vengono archiviati direttamente in binario, che generalmente richiede meno byte del testo. Ma non è l'unico motivo.
systemd non memorizza solo le righe di registro. Il suo intento è quello di rendere più facile il monitoraggio e l'esplorazione dei log. Per aiutare in questo compito, i messaggi di registro sono infatti una riga di testo accompagnata da dati come la gravità del registro (avviso, errore, ecc.), o anche campi che sarebbero utili solo alla tua applicazione (URL richiesto ad esempio).
# journalctl --output=verbose --allPRIORITÀ=6
_UID=0
_GID=0
_CAP_EFFECTIVE=3ffffffffff
_BOOT_ID=ee4cc2ce7e8273aaffb5fc59c873ce7b
_ID_MACCHINA=bc422e0feaab64bb7dd218c24e6830e5
_HOSTNAME=linux
SYSLOG_FACILITY=3
SYSLOG_IDENTIFIER=systemd
UNIT=dnf-makecache.servizio
_TRANSPORT=giornale
_PID=1
_COMM=systemd
_EXE=/usr/lib/systemd/systemd
_CMDLINE=/usr/lib/systemd/systemd --switched-root --system --deserialize 76
_SYSTEMD_CGROUP=/init.scopo
_SYSTEMD_UNIT=init.scopo
_SYSTEMD_SLICE=-.fetta
_SELINUX_CONTEXT=system_u:system_r:init_t:s0
CODE_FILE=src/core/lavoro.c
CODE_LINE=795
CODE_FUNCTION=job_log_status_message
MESSAGE_ID=a76e08846f5f0971371dbb11126e62e1
MESSAGE=Avviato dnf makecache.
# journalctl --catalog --lines=3000 --pager-end "_TRANSPORT=kernel" RISULTATO=fatto
_SOURCE_REALTIME_TIMESTAMP=1532886335471422
Ti ho detto che ci sono molti campi (qui ci sono 25 campi o 29 timestamp di conteggio), tutto lo snippet sopra è solo per un singolo messaggio di registro! Il grande vantaggio è che puoi eseguire una ricerca filtrando su qualsiasi campo in questo messaggio di registro. Questo ti consente davvero di filtrare in modo avanzato.
Uno dei filtri più ovvi che vorresti è filtrare in base al servizio. Come puoi vedere sopra, c'è un campo UNIT in modo da poter facilmente filtrare per ottenere solo i messaggi di registro da un servizio. Te ne parlerò più avanti.
Ma questa quantità di dati significa anche qualcos'altro: in quasi tutti i casi, non aprirai mai un file di registro manualmente e non toccherai mai la cartella /var/log/journal. Utilizzerai journalctl per qualsiasi attività relativa alla registrazione. Non esiste una tale rotazione del registro, tutto è gestito dall'ora del messaggio di registro.
Inoltre, il numero di campi dipenderà da quanto è buona l'integrazione di systemd nella tua applicazione. Più campi contiene un messaggio di registro, meglio è. Per i servizi di sistema di base, systemd si è già occupato di fare una buona integrazione ma per altre applicazioni e servizi, la qualità dell'integrazione varia molto. Normalmente, questo dovrebbe migliorare nel tempo man mano che le persone si abituano a systemd.
Ok, ora è il momento di scoprire le funzionalità di journalctl.
Comandi più usati per journalctl
Il primo comando che potresti voler dare un'occhiata è quello che mostra i log del kernel Linux Linux. Sì, systemd gestisce anche l'archiviazione dei registri del kernel, quindi puoi anche ottenere i registri degli avvii precedenti. Ecco il comando:
# journalctl --catalog --lines=3000 --pager-end "_TRANSPORT=kernel"Ti mostra un cercapersone dove puoi vedere gli ultimi messaggi. Puoi scorrere fino alle ultime 3.000 righe usando i tasti freccia (↑ / ↓) o Pagina su / Pagina giù. Il flag -catalog indica a journalctl di mostrare il contesto attorno alle righe di registro, proprio come i riavvii del computer o, in altri contesti, l'arresto/l'avvio di un servizio. Metto sempre questo flag poiché il contesto conta sempre, aiuta a sapere in quale situazione è apparsa la riga di registro, quindi puoi indovinare perché hai questa riga di registro.
Ora, forse vuoi vedere solo le righe di registro dall'avvio corrente:
# journalctl --catalog --lines=35000 --pager-end --boot "_TRANSPORT=kernel"Nota che l'argomento della riga di comando -boot funziona in tutte le situazioni, non solo con i log del kernel. Se preferisci iniziare dall'inizio:
# journalctl --catalog --boot "_TRANSPORT=kernel"Non so se è il tuo caso, ma ne ho abbastanza dei log del kernel! E che ne dici di avere una panoramica generale della tua macchina??
# journalctl --catalog --lines=3000 --pager-endWow, stanno accadendo molte cose sul tuo sistema! Un po' di filtraggio sarebbe utile qui. Uno dei filtri più utilizzati corrisponde a un servizio specifico (come il server SSH o il server HTTP), il nome file dell'unità systemd per il servizio SSH è sshd.servizio, quindi:
# journalctl --catalog --lines=3000 --pager-end --unit=sshd.servizioÈ fantastico, non è vero?? Bene, è utilizzabile solo se conosci il nome del servizio, ma in molti casi non conosci il nome di quel servizio. Se ti trovi in una situazione del genere, potresti volere un elenco dei servizi, le loro descrizioni e il loro stato:
# systemctl list-units --type=serviceOk, questo problema ora è risolto. Ma a volte, ricevi un messaggio di errore da un sistema esterno come il tuo sito Web o da un'applicazione sul desktop. Quindi probabilmente vorrai cercare una parola o una frase specifica nel messaggio di registro. Da systemd v237, ora è possibile.
In journalctl, la ricerca non fa distinzione tra maiuscole e minuscole se la parola che cerchi è tutta in minuscolo. Quindi, se cerchi la parola porta, cercherà anche la parola porta con lettere maiuscole. Un esempio:
# journalctl --catalog --lines=3000 --pager-end --grep="port"Ora, se cerchi una parola come CPU, cercherà solo CPU con tutte le lettere maiuscole, non cercherà cpu.
# journalctl --catalog --lines=3000 --pager-end --grep="CPU"Ricordi il messaggio di errore dal sistema esterno? Generalmente, questi messaggi contengono un timestamp. Per filtrare il messaggio di registro, potresti voler usare quel timestamp. journalctl può elencarti tutti i messaggi di registro da una data e un'ora specifiche con l'argomento -since:
# journalctl --catalog --since="2018-07-30 09:30:00"Se quel sistema esterno è remoto o utilizza i timestamp UTC, ti consigliamo di filtrare in base a una data e ora UTC e visualizzare nel terminale i timestamp UTC in modo che non sia necessario convertirli nella tua testa, che tende ad essere davvero confuso. Per fare ciò, dovrai aggiungere UTC dopo la stringa dell'ora nell'argomento -since. Dovrai quindi aggiungere il flag -utc. Quindi, ad esempio:
# journalctl --catalog --since="2018-07-30 10:45:00 UTC" --utcNota che puoi usare il flag -utc da solo, in questo caso mostrerà fondamentalmente tutte le date e le ore nel fuso orario UTC.
# journalctl --catalog --lines=3000 --pager-end --utcI log sono gestiti meglio con journalctl
Come puoi vedere con tutti i comandi precedenti, il journaling di systemd semplifica il filtraggio e quindi il debug in quanto puoi selezionare tutte le righe di registro utilizzando un singolo comando, journalctl. Alcuni di voi probabilmente conoscevano i tempi antichi in cui era necessario aprire manualmente ogni file in /var/log per avere un'idea generale del problema e di cosa fosse successo. Con tutti i suggerimenti che hai imparato qui, disporrai di solidi strumenti per guardare i tuoi messaggi di registro nel modo in cui vuoi tu.
