Segui Esegui journalctl con una finestra temporale e -o json, e ottieni un oggetto JSON per riga con ogni campo memorizzato nel journal:
sudo journalctl --since "2026-10-19 00:00" --until "2026-10-20 00:00" -o json --no-pager > web-03_journal.jsonl
Per un file di testo in stile syslog, invece, usa -o short-iso. Senza sudo, o appartenenza a systemd-journal, adm o wheel, vedi solo il tuo journal utente, non quello del sistema.
Nella maggior parte delle distro moderne, il journal è dove tutto finisce per primo: servizi, il kernel, sudo, cron, accessi. Su Debian 12 e successive, Fedora e Arch, è spesso l’ unico posto, perché rsyslog non è installato. Prime Core ha {N} regole di rilevamento per i log di sistema Linux, mappate a {M} tecniche MITRE ATT&CK, tra cui persistenza cron (T1053.003), servizi systemd malevoli (T1543.002) e abuso di sudo (T1548.003).
Prima di iniziare
Permessi. Stesse regole di qualsiasi log di sistema: root, o i gruppi sopra. La nostra [guida ai permessi dei log Linux] contiene i dettagli.
Il journal sopravvive ai riavvii? Se /var/log/journal non esiste, i log risiedono in memoria sotto /run/log/journal e scompaiono al riavvio. journalctl –list-boots mostra quanti avvii hai effettivamente. Se elenca solo quello attuale, la cronologia più vecchia è scomparsa.
Quanto ce n’è? journalctl –disk-usage te lo dice prima che lo scarichi tutto in un file. Per impostazione predefinita, un journal persistente può crescere fino al 10% del suo filesystem, limitato a 4 GB. È molto più di quanto tu voglia caricare in un solo pezzo.
Fusi orari. Il journal memorizza i timestamp in UTC, ma journalctl stampa l’ora locale a meno che tu non aggiunga –utc. L’output JSON contiene il timestamp con microsecondi UTC grezzi (__REALTIME_TIMESTAMP) in entrambi i modi.
Passo 1: Restringi il campo
Scegli i filtri che corrispondono alla tua domanda. Si combinano:
| Filtro | Cosa fa |
|---|---|
| –since / –until | Finestra temporale; accetta “2026-10-19 14:00”, ieri o “2 ore fa” |
| -b, -b -1 | Avvio corrente, avvio precedente |
| -u nginx -u ssh | Una o più unità systemd |
| -p warning | Quella priorità e tutto ciò che è più grave |
| -k | Solo messaggi del kernel |
| _COMM=sudo,_UID=0 | Confronta esattamente qualsiasi campo del journal |
Passo 2: Scegli il formato di output
- -o json: un oggetto JSON per riga, con ogni campo. Questa è la scelta predefinita per LogTotal, perché nulla va perso.
- -o json –output-fields=MESSAGE,_HOSTNAME,_COMM,_PID,SYSLOG_IDENTIFIER,PRIORITY: lo stesso, ridotto. Alcuni campi, come i timestamp e l’ID di avvio, sono sempre inclusi. Questo riduce notevolmente la dimensione del file.
- -o short-iso: testo in stile syslog con timestamp ISO completi. Più piccolo e facile da leggere ad occhio. [PROVA: conferma che LogTotal analizza short-iso]
Non usare -o export. Nonostante il nome, è un formato di serializzazione per inviare journal tra macchine systemd, non qualcosa da analizzare.
Ti raccomandiamo una tipica esportazione con ambito:
sudo journalctl -b -1 -p info -u ssh -u cron
-o json --no-pager > web-03_prevboot.jsonl
Passo 3 (opzionale): Leggi i file di journal da un’altra macchina
Nel lavoro di incidente, hai spesso un’immagine del disco o una cartella /var/log/journal copiata piuttosto che un sistema vivo. journalctl li legge direttamente:
journalctl -D /mnt/evidence/var/log/journal -o json --no-pager > evidence_journal.jsonl
Usa –file per puntare a file .journal individuali. Un journal da un sistema crashato o spento in modo non pulito può stampare avvisi di corruzione. La maggior parte delle voci di solito esce comunque.
Carica, sanitizza e revisa in LogTotal
- Carica. Apri logtotal.com e trascina il file .jsonl. [PROVA: schermata di caricamento, limite di dimensione]
- Sanifica. [PROOF: what gets masked in journal JSON: hostnames, usernames, IPs, machine and boot IDs]. Look it over before you continue.
- Revisa. [PROOF: what the results screen shows]
Come appare sui dati reali. Abbiamo esportato un giorno di journal da [PROVA: fonte campione, ad esempio una VM di test usa e getta dopo aver aggiunto un job cron, un nuovo utente e un servizio systemd sospetto]. LogTotal ha segnalato [PROVA: riscontri effettivi]. [PROVA: link al file campione]
Quando qualcosa va storto
| Sintomo | Causa probabile | Fix |
|---|---|---|
| Suggerimento su come non vedere i messaggi di altri utenti | Non root, e non nei gruppi journal | sudo, o aggiungi l’account a systemd-journal |
| — Nessuna voce — | La finestra temporale o il nome dell’unità non corrispondono; confusione tra locale e UTC | Amplia la finestra; prova –utc; verifica systemctl list-units |
| Esiste solo l’avvio corrente | Journal volatile | I log più vecchi sono scomparsi; verifica il tuo forwarder di log o SIEM |
| L’output sembra binario o confuso | -o export è stato usato | Usa -o json |
| Il file è di gigabyte | Nessun filtro | Aggiungi unità, priorità, –output-fields |
FAQ
JSON o testo?
JSON per l’analisi, perché mantiene PID, unità, ID di avvio e timestamp esatti come campi separati. Testo quando una persona lo leggerà, o quando le dimensioni contano.
Il journal è lo stesso di /var/log/syslog?
No. Quando rsyslog è installato, copia i messaggi dal journal nei file di testo, quindi potresti avere entrambi. Quando non lo è, il journal è tutto ciò che c’è.
