Führen Sie journalctl mit einem Zeitfenster und -o json aus, und Sie erhalten ein JSON-Objekt pro Zeile mit jedem Feld, das das Journal gespeichert hat:
sudo journalctl --since "2026-10-19 00:00" --until "2026-10-20 00:00" -o json --no-pager > web-03_journal.jsonl
Für eine syslog-ähnliche Textdatei verwenden Sie stattdessen -o short-iso. Ohne sudo oder Mitgliedschaft in systemd-journal, adm oder wheel, sehen Sie nur Ihr eigenes Benutzerjournal, nicht das des Systems.
In den meisten modernen Distributionen ist das Journal der Ort, an dem alles zuerst landet: Dienste, der Kernel, sudo, cron, Anmeldungen. In Debian 12 und später, Fedora und Arch ist es oft der einzige Ort, da rsyslog nicht installiert ist. Prime Core hat {N} Erkennungsregeln für Linux-Systemprotokolle, die auf {M} MITRE ATT&CK Techniken abgebildet sind, darunter Cron-Persistenz (T1053.003), bösartige systemd-Dienste (T1543.002) und Sudo-Missbrauch (T1548.003).
Bevor Sie beginnen
Berechtigungen. Gleiche Regeln wie für jedes Systemprotokoll: root oder die oben genannten Gruppen. Unser [Linux-Protokoll-Berechtigungsleitfaden] enthält die Details.
Überdauert das Journal Neustarts? Wenn /var/log/journal nicht existiert, leben Protokolle im Speicher unter /run/log/journal und verschwinden beim Neustart. journalctl –list-boots zeigt, wie viele Starts Sie tatsächlich haben. Wenn es nur den aktuellen auflistet, ist die ältere Historie verschwunden.
Wie viel ist da? journalctl –disk-usage sagt Ihnen, bevor Sie alles in eine Datei dumpen. Standardmäßig kann ein persistentes Journal auf 10 % seines Dateisystems anwachsen, begrenzt auf 4 GB. Das ist weit mehr, als Sie in einem Stück hochladen möchten.
Zeitzonen. Das Journal speichert Zeitstempel in UTC, aber journalctl gibt die lokale Zeit aus, es sei denn, Sie fügen –utc hinzu. JSON-Ausgabe enthält den rohen UTC-Mikrosekunden-Zeitstempel (__REALTIME_TIMESTAMP), egal wie.
Schritt 1: Eingrenzen
Wählen Sie die Filter, die zu Ihrer Frage passen. Sie kombinieren sich:
| Filter | Was er tut |
|---|---|
| –since / –until | Zeitfenster; akzeptiert „2026-10-19 14:00“, gestern oder „vor 2 Stunden“ |
| -b, -b -1 | Aktueller Start, vorheriger Start |
| -u nginx -u ssh | Eine oder mehrere systemd-Einheiten |
| -p warning | Diese Priorität und alles Schlimmere |
| -k | Nur Kernel-Nachrichten |
| _COMM=sudo, _UID=0 | Genau mit einem Journal-Feld übereinstimmen |
Schritt 2: Wählen Sie das Ausgabeformat
- -o json: ein JSON-Objekt pro Zeile, mit jedem Feld. Dies ist die Standardwahl für LogTotal, da nichts verloren geht.
- -o json –output-fields=MESSAGE,_HOSTNAME,_COMM,_PID,SYSLOG_IDENTIFIER,PRIORITY: das gleiche, gekürzt. Einige Felder, wie die Zeitstempel und die Boot-ID, sind immer enthalten. Dies reduziert die Dateigröße erheblich.
- -o short-iso: syslog-ähnlicher Text mit vollständigen ISO-Zeitstempeln. Kleiner und leicht mit den Augen zu lesen. [PROOF: bestätige, dass LogTotal short-iso analysiert]
Verwenden Sie nicht -o export. Trotz des Namens ist es ein Serialisierungsformat zum Versenden von Journalen zwischen systemd-Maschinen, nicht etwas zum Analysieren.
Wir empfehlen Ihnen einen typischen gezielten Export:
sudo journalctl -b -1 -p info -u ssh -u cron
-o json --no-pager > web-03_prevboot.jsonl
Schritt 3 (optional): Lesen Sie Journaldateien von einer anderen Maschine
Bei Vorfallarbeiten haben Sie oft ein Festplatten-Image oder einen kopierten /var/log/journal-Ordner, anstatt ein Live-System. journalctl liest diese direkt:
journalctl -D /mnt/evidence/var/log/journal -o json --no-pager > evidence_journal.jsonl
Verwenden Sie –file, um auf einzelne .journal-Dateien zu verweisen. Ein Journal von einem abgestürzten oder nicht sauber heruntergefahrenen System kann Korruptionswarnungen ausgeben. Die meisten Einträge erscheinen in der Regel trotzdem.
Hochladen, bereinigen und in LogTotal überprüfen
- Hochladen. Öffnen logtotal.com und die .jsonl-Datei hochladen. [PROOF: hochladen Bildschirm, Größenlimit]
- Bereinigen. [PROOF: what gets masked in journal JSON: hostnames, usernames, IPs, machine and boot IDs]. Look it over before you continue.
- Überprüfen. [PROOF: what the results screen shows]
Wie das bei echten Daten aussieht. Wir haben einen Tag Journal von [PROOF: Beispielquelle, z.B. einer Einweg-Test-VM nach dem Hinzufügen eines Cron-Jobs, eines neuen Benutzers und eines verdächtigen systemd-Dienstes] exportiert. LogTotal markierte [PROOF: tatsächliche Funde]. [PROOF: Link zur Beispieldatei]
Wenn es schiefgeht
| Symptom | Wahrscheinliche Ursache | Fix |
|---|---|---|
| Hinweis darauf, dass keine Nachrichten von anderen Benutzern angezeigt werden | Nicht root und nicht in den Journal-Gruppen | sudo, oder fügen Sie das Konto zu systemd-journal hinzu |
| — Keine Einträge — | Zeitfenster oder Einheitenname stimmen nicht überein; lokale vs. UTC-Verwirrung | Erweitern Sie das Fenster; versuchen Sie –utc; prüfen Sie systemctl list-units |
| Nur der aktuelle Start existiert | Flüchtiges Journal | Ältere Protokolle sind weg; überprüfen Sie Ihren Log-Forwarder oder SIEM |
| Ausgabe sieht binär oder verstümmelt aus | -o export wurde verwendet | Verwenden Sie -o json |
| Die Datei ist Gigabytes groß | Keine Filter | Fügen Sie Einheiten, Priorität, –output-fields hinzu |
FAQ
JSON oder Text?
JSON zur Analyse, da es PID, Einheit, Boot-ID und genaue Zeitstempel als separate Felder beibehält. Text, wenn eine Person es liest, oder wenn die Größe eine Rolle spielt.
Ist das Journal dasselbe wie /var/log/syslog?
Nein. Wenn rsyslog installiert ist, kopiert es Nachrichten aus dem Journal in Textdateien, sodass Sie möglicherweise beide haben. Wenn es nicht installiert ist, ist das Journal alles, was es gibt.