Ich möchte die Logs zwischen zwei Sitzungen bzw. Bootphasen vergleichen.
Ein einfacher Texteditor, der Logdateien vergleichen kann, reicht mir
hier aber nicht, denn:
1. kann es vorkommen, dass die Logs von zwei Sitzungen hintereinander in
die gleiche Log Datei geschrieben werden, was man manuell mit extra
Arbeit zwar auftrennen könnte, aber
2. bei modernen Linuxsystemen muss die Initialisierungsreihenfolge der
einzelnen Komponenten nicht mehr sequentiell immer die gleiche sein.
Wenn also der Log Eintrag für Service A vor Service B steht und beim
nächsten Start das genau anders herum ist, dann bringt ein einfacher
Textvergleich nichts, da normale Textvergleichsprogramm so etwas nicht
berücksichtigen.
Deswegen suche ein Vergleichsprogramm, das beides unter einen Hut kriegt
und die Einträge grafisch nebeneinander anzeigen kann.
Gibt es so etwas?
Wie willst Du das automatisieren, wenn ein Dienst seine Einträge nicht
nacheinander ausgibt weil andere dazwischenfunken? Das Programm müßte
erkennen welche Meldung zu welchem Dienst gehört.
Da hilft nur Brain 2.0
Andreas B. schrieb:> Wie willst Du das automatisieren, wenn ein Dienst seine Einträge> nicht> nacheinander ausgibt weil andere dazwischenfunken? Das Programm müßte> erkennen welche Meldung zu welchem Dienst gehört.> Da hilft nur Brain 2.0
Durch einen zeilenweisen Abgleich.
Ich dachte da bspw. an so ne Art Map Datenstruktur gepaart mit
Metainformationen. Die Metainformationen enthalten dann bspw. die
Kernelzeit. die bspw. bei dmesg immer dabei steht.
Dann weiß man z.B. dass Gerät XY sowohl in der erste Sitzung als auch in
der zweiten erkannt wurde.
Anhand der Zeit erkennt man den Start der unterschiedlichen Sessions.
Natürlich gehört da noch etwas mehr dazu, wenn die Log für ein
bestimmtes Gerät oder einen Dienst mehrere Zeilen lang sind. Aber da
gibt's bei dmesg zumindest auch schon ne grobe Gruppierung.
Deswegen ja "intelligentes" Vergleichsprogramm, das ne ungefähre
Vorstellung hat, von dem was es ausgibt.
Bei den Logs von systemd dürfte das schon gut strukturiert sein, da
könnte es einfacher sein.
So in etwa stelle ich mir das grob vor.
Nano schrieb:> Wenn also der Log Eintrag für Service A vor Service B steht und beim> nächsten Start das genau anders herum ist, dann bringt ein einfacher> Textvergleich nichts, da normale Textvergleichsprogramm so etwas nicht> berücksichtigen.
Dann schalte das System doch auf Ausgabe der Log-Informationen als XML
um. Mit Hilfe der Meta-Informationen, die dann mit untergebracht werden
können (z.B. Name des Service), wird für ein Vergleichsprogramm der
Abgleich viel einfacher.
Oder ist das moderne Linuxsystem so modern dann auch wieder nicht?
Frank M. schrieb:> 2. Diff drauf loslassen
So simpel geht es sicher nicht. Allein wegen der Timestamps ist das
sinnlos.
Ich wuerde Perl nehmen und was Spezialisierte stricken.
leo
leo schrieb:> So simpel geht es sicher nicht. Allein wegen der Timestamps ist das> sinnlos.
Beim Separieren der Logs kann man auch den Timestamp filtern. Wenn ich
es richtig verstanden habe, interessiert sich der TO nur für die
Reihenfolge und nicht für die Timestamps.
> Ich wuerde Perl nehmen und was Spezialisierte stricken.
Du hast ein Werkzeug genannt - aber keine Lösung. Natürlich muss man was
stricken, aber dafür reicht auch sh, grep, sed und diff.
Frank M. schrieb:> Beim Separieren der Logs kann man auch den Timestamp filtern. Wenn ich> es richtig verstanden habe, interessiert sich der TO nur für die> Reihenfolge und nicht für die Timestamps.
Ne, eigentlich interessiere ich mich für die Änderungen.
>> Ich wuerde Perl nehmen und was Spezialisierte stricken.>> Du hast ein Werkzeug genannt - aber keine Lösung. Natürlich muss man was> stricken, aber dafür reicht auch sh, grep, sed und diff.
So etwas komplexes schreibt man besser in python.
Aber das hatte ich nicht vor, ich wollte nur wissen, ob es da schon was
in der Richtung gibt.
Das oben genannte systemd-bootchart werde ich mir mal ansehen.
Frank M. schrieb:> leo schrieb:>> So simpel geht es sicher nicht. Allein wegen der Timestamps ist das>> sinnlos.>> Beim Separieren der Logs kann man auch den Timestamp filtern. Wenn ich> es richtig verstanden habe, interessiert sich der TO nur für die> Reihenfolge und nicht für die Timestamps.>>> Ich wuerde Perl nehmen und was Spezialisierte stricken.>> Du hast ein Werkzeug genannt - aber keine Lösung. Natürlich muss man was> stricken, aber dafür reicht auch sh, grep, sed und diff.
journald mit journalctl kann gut filtern. Das systemd journal als
solches wird default meist nicht gespeichert, das lebt im initramfs.
wenn ein Aufruf von journalctl --list-boots nur einen Eintrag, also den
aktuellen Bootverlauf anzeigt /etc/systemd/journald.conf ggf.
Storage=persistent setzen.
Dann läßt sich deutlich einfacher arbeiten
bspw ausgabe von
journalctl -b -p err -t kernel #vergleichen mit
journalctl -b -1 -p err -t kernel #voriger boot
-b (0) aktuell (-1) vorhergehender
-p, --priority= (log level)
-t -t, --identifier=SYSLOG_IDENTIFIER (department)
und viele mehr.
---
da gibts mehr Lesestoff in Bezug zu Usern und Sessions
https://wiki.archlinux.org/index.php/systemd/User#Reading_the_journal
a) gratuliere Kernel hat nichts zu meckern
b) andere interessante Stelle wählen ;)
c) schalte es halt ein
# mkdir /var/log/journal
# systemd-tmpfiles --create --prefix /var/log/journal
# systemctl restart systemd-journald
d)neu anwerfen, zurück zu
journalctl --list-boots
e) die Nummerierung ist ätzend
...
y) installiere slackware
z) have fun
just visiting schrieb:> c) schalte es halt ein
Ja, ich wollte eigentlich Logs aus der Vergangenheit vergleichen.
> # mkdir /var/log/journal> # systemd-tmpfiles --create --prefix /var/log/journal> # systemctl restart systemd-journald>> d)neu anwerfen, zurück zu>> journalctl --list-boots
Ich werde mal gucken, ob das bei Debian nicht etwas anders geht oder ob
ich da wirklich nen Ordner in /var/log erstellen muss.
> y) installiere slackware
Hatte ich früher, aber das System aktuell zu halten ist mir bei
Slackware dann doch zu aufwendig geworden. Außerdem muss man zu viel aus
den sourcen compilieren.
Und dann ist das bei Slackware mit Patrick Volkerding offiziell nur ein
Mann.
Aber ansonsten ist Slackware eine klasse Distribution, ich habe nur gute
Erfahrungen damit gemacht. Dennoch nutze ich heute lieber Debian.
Nano schrieb:> Erfahrungen damit gemacht. Dennoch nutze ich heute lieber Debian.
Dat hat kein systemD...
Ich mach grad Coronaurlaub auf slax, debian+trinity :)
dort residiert das temporär als binärer blobb unter /run/log/journal/
bislang werd ich damit nicht warm, das Ding journald ist die Ausnahme.
>> ich da wirklich nen Ordner in /var/log erstellen muss.
Ist doch dort gut aufgehoben,
kann aber sicher dahin wo immer du es haben willst.
#Computer --tea Earl-Grey hot
just visiting schrieb:> Nano schrieb:>>> Erfahrungen damit gemacht. Dennoch nutze ich heute lieber Debian.>> Dat hat kein systemD...
Ähm doch.
1
systemctl status
2
● ########
3
State: running
4
Jobs: 0 queued
5
Failed: 0 units
6
Since: Thu 2021-02-04 11:39:51 CET; 8h ago
7
CGroup: /
8
├─user.slice
9
│ └─user-1000.slice
Der Debian Fork, der kein systemd verwendet, heißt Devuan.
Aber den nutze ich nicht.
Ich finde systemd eigentlich ganz praktisch und auch sinnvoll.
>>> ich da wirklich nen Ordner in /var/log erstellen muss.>> Ist doch dort gut aufgehoben,> kann aber sicher dahin wo immer du es haben willst.
Ja, aber eventuell gibt's da nen offiziellen Weg, den man mit
dpkg-reconfigure oder ähnlichem vielleicht nur aktivieren muss.
> #Computer --tea Earl-Grey hot
Jean Luc Picard
Nano schrieb:> Ähm doch.
slackware hat keines.
u. slax heute Debian einen seltsamen mix systemD/sysV
>> Ja, aber eventuell gibt's da nen offiziellen Weg, den man mit> dpkg-reconfigure oder ähnlichem vielleicht nur aktivieren muss.>
?
systemd-tmpfiles --remove --create
just visiting schrieb:> Nano schrieb:>>> Ähm doch.>> slackware hat keines.
Ich weiß. Slackware hatte auch eher bsd style Initscripte.
> u. slax heute Debian einen seltsamen mix systemD/sysV
Das hängt auch davon ab wie alt deine Debian Installation ist bzw. wie
viele upgrades auf die nächste Majorversionen die schon hinter sich hat.
>> Ja, aber eventuell gibt's da nen offiziellen Weg, den man mit>> dpkg-reconfigure oder ähnlichem vielleicht nur aktivieren muss.>>>> ?
Wenn du deine Java Run Time Umgebung ändern willst, dann kannst du die
symbolischen links java und javac manuell umbiegen, oder es unter Debian
gleich richtig machen und einfach dafür
update-alternatives --config java
verwenden.
Gleiches gilt für den Browser, dein VNC Programm und viele andere.
Eine Liste kriegst du mit:
update-alternatives --get-selections
Und das manuell zu machen ist halt am System vorbei, ohne dass das
System dies irgendwie richtig mitkriegt und so gemacht wird, wie es
vorgesehen ist.
>> systemd-tmpfiles --remove --create
Hat nichtmal ne --list Option.
Nano schrieb:>> Und das manuell zu machen ist halt am System vorbei, ohne dass das> System dies irgendwie richtig mitkriegt und so gemacht wird, wie es> vorgesehen ist.>
jo, man journald.conf
When packages need to customize the configuration, they can install
configuration snippets in /usr/lib/systemd/*.conf.d/.
Files in etc are reserved for the local administrator, who may use
this logic to override the configuration files installed vendor
packages.
Jetzt ist das aber systemD selber u. eine einzige Örtlichkeit.
....
Storage=
Controls where to store journal data. One of "volatile", "persistent",
"auto" and "none".
If "volatile", journal log data will be stored only in memory, i.e.
below the /run/log/journal hierarchy (which is created if needed). If
"persistent", data will be stored preferably on disk, i.e. below the
/var/log/journal hierarchy (which is created if needed), with a fallback
to /run/log/journal (which is created if needed), during early boot and
if the disk is not writable. "auto" is similar to "persistent" but the
directory /var/log/journal is not created if needed, so that its
existence controls where log data goes. "none" turns off all storage,
all log data received will be dropped. Forwarding to other targets, such
as the console, the kernel log buffer, or a syslog socket will still
work however. Defaults to "auto".
alles grüner Bereich.
---
aber das ist ja auch noch nicht was du suchst.
leo schrieb:> Frank M. schrieb:>> 2. Diff drauf loslassen>> So simpel geht es sicher nicht. Allein wegen der Timestamps ist das> sinnlos.
Nö.
> Ich wuerde Perl nehmen und was Spezialisierte stricken.
Den Timestamp kann man mit einfachsten Shellmitteln wegwerfen und die
Dateien dann mit kdiff3 schick vergleichen. Huch.
Sheeva P. schrieb:> leo schrieb:>> Frank M. schrieb:>>> 2. Diff drauf loslassen>>>> So simpel geht es sicher nicht. Allein wegen der Timestamps ist das>> sinnlos.>> Nö.>>> Ich wuerde Perl nehmen und was Spezialisierte stricken.>> Den Timestamp kann man mit einfachsten Shellmitteln wegwerfen und die> Dateien dann mit kdiff3 schick vergleichen. Huch.
Und dann stellst du fest, dass vieles nicht passt, weil beim ersten Boot
A, B, C, D die Reihenfolge der gebooteten Prozesse war und im zweiten
Boot es nun A, D, C, B ist und kdiff3 findet deswegen außer ein paar
wenige keine Gemeinsamkeiten.
Merke:
Wäre es mit einem diff getan, hätte ich den Thread nicht gestartet.
Nano schrieb:> Und dann stellst du fest, dass vieles nicht passt, weil beim ersten Boot> A, B, C, D die Reihenfolge der gebooteten Prozesse war und im zweiten> Boot es nun A, D, C, B ist
Deswegen schrieb ich ja:
1. Log der Session 1 und Session 2 separieren
Dann ist die Reihenfolge, wie die einzelnen Prozesse gestartet wurden,
egal. Aber Du siehst, was Session 1 anders macht als Session 2.
Frank M. schrieb:> Nano schrieb:>> Und dann stellst du fest, dass vieles nicht passt, weil beim ersten Boot>> A, B, C, D die Reihenfolge der gebooteten Prozesse war und im zweiten>> Boot es nun A, D, C, B ist>> Deswegen schrieb ich ja:>> 1. Log der Session 1 und Session 2 separieren>> Dann ist die Reihenfolge, wie die einzelnen Prozesse gestartet wurden,> egal. Aber Du siehst, was Session 1 anders macht als Session 2.
Das ist aber alles Handarbeit, die ich vermeiden wollte.
Denn dann fragst du dich, wird B gestartet oder nicht, ach da unten am
Ende.
Und D da oben.
Deswegen meine Frage nach einem Programm das gleiches sucht und das dann
kategorisiert und aufbereitet. So dass wirklich nur die Änderungen übrig
bleiben.
Nano schrieb:> Deswegen meine Frage nach einem Programm das gleiches sucht und das dann> kategorisiert und aufbereitet. So dass wirklich nur die Änderungen übrig> bleiben.
Logfiles nehmen, jeweils die Zeitstempel rausschneiden (mit 'cut'),
Dateien sortieren ('sort'), diff machen. Dann hast Du tatsächlich nur
die Unterschiede in den Logs, verlierst aber den zeitlichen Bezug.
Nano schrieb:> Deswegen meine Frage nach einem Programm das gleiches sucht und das dann> kategorisiert und aufbereitet.
Mir nicht bekannt
> So dass wirklich nur die Änderungen übrig> bleiben.
Warum auch immer die (usb)Maus war heute aus
Sheeva P. schrieb:>> Ich wuerde Perl nehmen und was Spezialisierte stricken.>> Den Timestamp kann man mit einfachsten Shellmitteln wegwerfen und die> Dateien dann mit kdiff3 schick vergleichen. Huch.
Ich nutze für sowas "meld", kdiff3 kenne ich nicht.
Wenn in den Logs ständig wechselnde Dinge (z.B. Timestamps oder Pointer)
auftauchen, dann kann ich die per Regex vom Vergleich ausschließen.
Und wenn Zeilen in unterschiedlicher Reihenfolge auftauchen, wird das
auch halbwegs gebrauchbar angezeigt, weil untendrunter ein diff werkelt.
