Grafische Anwendung für Journalctl (Protokoll/Logs angucken)

[suleiman]

Howdy,

ich hab mir Gnome-Logs und Gnome-System-Logs runter geladen um mir das Protokoll bzw die Logs anzeigen zu lassen,
aber die taugen nix, da hack ich lieber auf der Konsole weiter.

Gibt es gute grafische Anwendungen womit man gezielt Logs und aus /var/log/journal lesen kann ?

Nutze Gnome 3.14 auf Jessie

[smutbert]

…da mach ich lieber auf der Konsole weiter.

ich ebenso

[DeletedUserReAsG]

Joa, journalctl ist schon ziemlich mächtig. Auf der anderen Seite ist der Wunsch nach einem grafischen Frontend nun auch nicht so absurd, und es würde mich wundern, wenn sich da noch keiner dran versucht hätte.

[suleiman]

Joa eine konktrete Vorstellung von so einem Programm hätte ich auch schon,
nur ich kann nicht C++

[DeletedUserReAsG]

Dann nimm halt eine Sprache, die du kannst. Ich würd’s z.B. in Python machen, weil ich das halt am besten kann.

[suleiman]

Du hast ja wieder Recht...
man kann grafische Anwendungen mit Python erstellen
und das wird warscheinlich nicht mal schwehr sein.

Würde trozdem warscheinlich etwas dauern bis ich mich da zurecht finde.
Wenn mein Server läuft wie er soll kann ich mir das nochmal überlegen.

[geier22]

Also so schlecht finde ich gnome-logs nun wieder im Ansatz auch nicht.
Hat ein paar Macken (allerdings ziemlich entscheidend )
Den Log speichern funktioniert nicht richtig ----> speichert nur den gerade sichtbaren Bereich
den kompletten Log für eine Boot- Periode durchscrollen dauert eine Ewigkeit, da offensichtlich das nicht sichtbare nicht im RAM bleibt.

Sollt das (noch) ein Bug sein oder kann man das irgendwo einstellen ?

[Colttt]

Sprechen wir hier nur von einem oder mehreren Servern?

[theSplit]

Hallo,

was erwartet ihr denn von einem Log-Viewer?
Sollen dort diverse Logs als Standard vorhanden sein, so das man schnell zu diesen schalten/wechseln kann? Eventuell nach Kategorien?
Und welche sind das? - Oder alles in "var/log" als Standardauswahl, zum einfachen Öffnen per Mausklick verfügbar?

Zweite Frage, was für Funktionen sollte so ein Tool/Werkzeug denn haben?
Zum Beispiel, Suche nach einem Schlagwort, evtl. mit Hervorhebung im scrollbaren Text, Sprungmarken darauf, oder filtern von Zeilen wie Grep es tut so dass man nach bestimmen Wörtern/Nachrichten filtern kann? Wäre so mein erster Gedanke.

Ich habe Gnome-Logs leider noch nicht verwendet und kann daher nichts zu diesem Werkzeug sagen, aber wenn es massive Probleme damit gibt - was kann man besser machen?

Vielleicht kann man sich überlegen eine Alternative zu schaffen, wenn das Sinn macht.

Rein vom Ablauf kann ich mit C und GTK3 aufwarten, in welches ich mich aktuell einarbeite, eingearbeitet habe..

Nur sollte man überlegen was bei Gnome-Logs anders als erwartet läuft und was man dazu noch brauchen würde und ob es nicht doch Sinn machen würde, einen Verbesserungsvorschlag für Gnome-Logs einzureichen, denn die Software gibt es ja nun schon einmal.

Aber da ich immer gerne Lerne, würde ich mich dafür anbieten etwas zu entwickeln oder zu helfen. Auch wenn ich aktuell schon ein anderes Projekt habe das 99% meiner Zeit beansprucht. Wenn es sinnvoll ist, warum nicht?

[suleiman]

Frohes neues Jahr, an alle !

Hui, scheinen ja doch einige interesse zu haben an einem besseren Tool.
Also wenn ich mir aussuchen könnte was ich gern hätte, dann wäre es folgendes ...

Ich mag Gnome, daher bin ich auch voll für Gnome-Logs!
Das erste Problem was mir aufgefallen ist das man nicht alle Protokolleinträge sieht und auch nicht anzeigen lassen kann, oder habe ich was übersehen ?...
Hardware und System sind bei mir immer leer und ich finde auch nicht die Einträge wo man mit den Option -k oder z.B. -p debug sehen würde.
Dann sind alle Dienste zusammengefasst, was den Überblick auch erschwehren kann.
Für mich ist es sinnvoll im Protokoll von nur einem Dienst zu stöbern (von der Suche mit grep mal abgesehen).
Ich hab auch /var/log/journal erstellt und rufe mit -b die verschiedenen Protokolle auf, geht mit Gnome-Logs leider auch nicht.

Wenn es sowas als grafisches Schmankel geben würde, wäre schon geil xD

[geier22]

Das erste Problem was mir aufgefallen ist das man nicht alle Protokolleinträge sieht und auch nicht anzeigen lassen kann, oder habe ich was übersehen ?...

Bist du in der Gruppe systemd-journal ?
Vermutlich liegt es daran.

Hardware und System sind bei mir immer leer und ich finde auch nicht die Einträge wo man mit den Option -k oder z.B. -p debug sehen würde.

damit meinet du die Optionen von journalctl?

Ich kann alle Gruppen einsehen
Wichtig
Alle
Anwendungen
System
Sicherheit
Hardware
Was ich an den gnome-logs bemängele:

Das Durchscrollen (sowohl in Gnome als auch in Xfce -- beides Testing) bis zum Anfang des Protokolls funktioniert nur mit der Maus und endlos langsam, mit den Cursor-tasten geht es gar nicht.
Das Abspeichern des Logs (egal welche Rubrik man anwählt) ergibt immer nur eine Datei die etwas mehr als den gerade sichtbaren Bereich enthält --- ein Suchergebniss wird aber anscheinend komplett abgespeichert.

Ich hab auch /var/log/journal erstellt und rufe mit -b die verschiedenen Protokolle auf, geht mit Gnome-Logs leider auch nicht.

Zumindest die letzten 6 boots werden bei mir angezeigt und sind auswählbar

[theSplit]

Frohes neues Jahr, an alle !

Ebenfalls, frohes Neues! Ein Jahr der Taten...

Hardware und System sind bei mir immer leer und ich finde auch nicht die Einträge wo man mit den Option -k oder z.B. -p debug sehen würde.

Was würden denn diese switches ausmachen, ohne jetzt die Man-Pages zu bemühen?

Dann sind alle Dienste zusammengefasst, was den Überblick auch erschwehren kann.

Ich würde ja hier nach "Logtyp" > "Xorg" > "Xorg.0.log" - "Xorg.1.log" usw. gehen...

Für mich ist es sinnvoll im Protokoll von nur einem Dienst zu stöbern (von der Suche mit grep mal abgesehen).
Ich hab auch /var/log/journal erstellt und rufe mit -b die verschiedenen Protokolle auf, geht mit Gnome-Logs leider auch nicht.

Nun ja, Cat oder bzw. Grep könnten ja als Tools "under the hood" also "Unter der Haube" dienen um Daten zu beschaffen bzw. anzeigen zu lassen. Ich weiß aber immer noch nicht wozu die Switches dienen

Wenn es sowas als grafisches Schmankel geben würde, wäre schon geil xD

Macht Gnome-logs ja auch

Ist die "Übersicht" gut oder eher schlecht, macht diese Sinn? Also alle in "dpkg" > "dpkg.1.log" usw...

Die Darstellung nach Zeit wiederum, finde ich gut an Gnome-logs - habe ich mir angeschaut!

Dass es nur als Root läuft ist natürlich auch ein kleines Problem, aber das lässt sich vermute ich mal, nicht ändern, da Systemzugriff erforderlich ist.

Das Durchscrollen (sowohl in Gnome als auch in Xfce -- beides Testing) bis zum Anfang des Protokolls funktioniert nur mit der Maus und endlos langsam, mit den Cursor-tasten geht es gar nicht.
Das Abspeichern des Logs (egal welche Rubrik man anwählt) ergibt immer nur eine Datei die etwas mehr als den gerade sichtbaren Bereich enthält --- ein Suchergebniss wird aber anscheinend komplett abgespeichert.

Hier könnte man einen Buffer in Optionen einstellen lassen, also beim Speichern die gesamte Datei sichern, oder selektiv den sichtbaren Bereich (alle Grep Einträge).

Als Option sehe ich da einen Buffer, den man einstellen kann, der sagt wieviel "MB" sichtbar sein sollen, 1024 Kilobite, 4096 Kilobyte, 8096 KB, 8 MB, 16 MB, 32 MB, 64 MB oder noch mehr Zeichen, je nachdem wie viel Speicher zu Verfügung steht.

[suleiman]

Dass es nur als Root läuft ist natürlich auch ein kleines Problem, aber das lässt sich vermute ich mal, nicht ändern, da Systemzugriff erforderlich ist.

Man kann einfach User in die Gruppe adm parken und schon sind fast alle Logs verfügbar.

Code: Alles auswählen

sudo usermod -aG adm mario

Ob das auch mit Gnome-Logs funktioniert habe ich nicht probiert.

Bist du in der Gruppe systemd-journal ?
Vermutlich liegt es daran.

ATM bin ich in der Gruppe sudo.
Ich muß auch jedes mal ein Passwort eingeben bevor Gnome-Logs startet.

Was würden denn diese switches ausmachen, ohne jetzt die Man-Pages zu bemühen?

damit meinet du die Optionen von journalctl?

journalctl Optionen ...
-k zeigt nur das Protokoll vom Kernel.
-p [0-7] zeigt nur das Protokoll mit diesem Status oder nidriger (Kritisch, Fehler, Notiz, usw...).
-b [NUMMER] zeigt das Protokoll ab einer bestimmten Sitzung an. Eine Sitzung startet mitm Boot-Prozess und endet mit dem runter fahren des Systems.

Konkret arbeite ich mit den folgenden Befehlen ...

Code: Alles auswählen

ls -ltra /var/log			# Auflisten in welche Datei wann geschrieben wurde - die Datei mit der neuesten Änderung steht unten - um so ggf. herauszufinden, in welcher Datei man aktuelle Meldungen findet
journalctl --disk-usage			# (sudo) Speicherplatz welchen die Journals momentan verbrauchen
journalctl -f				# (sudo) Protokoll verfolgen, um zu sehen, was für neue Meldungen rein kommen
logrotate -d -f /etc/logrotate.conf	# (sudo) Testen ob logrotate läuft wie es soll (nur ein Text, kein Dateien werden erstellt) 

journalctl -k -p err --since today	# (sudo) Heutige Fehlermeldung(en) vom Kernel anzeigen lassen

systemctl list-units | grep service		# alle Services die über journal laufen auflisten
journalctl -u ssh.service -p warning -n 30	# (sudo) die letzten 30 Warn- und Fehlermeldungen von ssh anzeigen lassen
journalctl -u minidlna.service -p err --since="last hour"	# (sudo)  Fehlermeldungen die minidlna in der letzten Stunde erzeugt hat anzeigen lassen
journalctl -b -p debug | grep -i fuse	# (sudo) Von dieses Sitzung Fehler beim Einbinden mit sshfs raus filtern

Dann hänge ich jeh nach Dienst noch ein passendes grep dran.
Btw. in Gnome-Logs gibts eine Suchfunktion, dann brauch man kein grep.

Mein nächster Schritt ist mir passende Scripts zum abfragen der einzellnen Dienste zu erstelllen.
Weil jeder Dienst gibt die Meldungen anders aus und ich will erstmal nur die Fehler raus filtern.

Ist die "Übersicht" gut oder eher schlecht, macht diese Sinn? Also alle in "dpkg" > "dpkg.1.log" usw...

Die Darstellung nach Zeit wiederum, finde ich gut an Gnome-logs - habe ich mir angeschaut!

Protokolle anhand ihrer Rotation auflsten bringt nicht viel, da die Dateien meist nach Größe und oder Wochentag angelegt werden.
Wiederum sortieren nach Zeit und Systemstart finde ich auch wichtig.


Nachtrag:
Gnome sollte "simple to use and straight forward" sein/bleiben.
Eine Möglichkeit (z.B. Dropdown-Menü) um selbst entscheiden zu können welchen Status man alles angezeigt bekommt.
Ein Menü zum auswählen von einzellenen Diensten wäre auch nice ...

Code: Alles auswählen

systemctl list-units | grep service | cut -c 3- | cut -d" " -f1

[suleiman]

Ich muß nochmal meine Aussage revidieren....
Ich habe jetz gnome-logs im Autostart geparkt und hatte durch Zufall das Glück/Pech ein paar kritische Meldungen angezeigt zu bekommen
Für eine Übersicht von Fehlern, kiritsche Meldungen, Alarm und Notfall, ist das Programm super!
Klar fehlen da viele Optionen die ich gerne hätte, aber sowas ist für Gnome nicht nötig.
Dann lieber ein neues Programm schreiben.

[geier22]

ATM bin ich in der Gruppe sudo.
Ich muß auch jedes mal ein Passwort eingeben bevor Gnome-Logs startet.

Ich habe jetz Debiangnome-logs im Autostart geparkt und hatte durch Zufall das Glück/Pech ein paar kritische Meldungen angezeigt zu bekommen

Das du jedes mal ein Passwort eingeben musst, verwundert mich. Brauchte ich noch nie.
Hast du dich denn in die Gruppe systemd-journal eingetragen? Ist meines Wissens notwendig, um alle Logs zu sehen.
sudo ersetzt das nur, weil du dann root bist. Deshalb wird - glaube ich jedenfalls - ein PW gefordert.

[TomL]

…da mach ich lieber auf der Konsole weiter.

ich ebenso

Ich denke auch immer wieder drüber nach... immer, wenn ich hier kurz mitlese.... und trotzdem favorisiere ich momentan auch noch die Konsole. Aber wenn ich mir 'ne ganz einfache grafische Umsetzung vorstelle, dann fände ich das trotzdem klasse.

Eine solche Lösung mit ein paar vorgegebenen Filtern wäre für mich die perfekte Lösung:

Code: Alles auswählen

+-----------------------------------------------+
| Filter manuelle Eingabe Keyword               |
+---------+-------------------------------------+
| Filter  |                                     |
| Boot    |                                     |
| -1      |                                     |
| -2      |     Tabelle                         |
| etc.    |     Logeinträge                     |
+---------+                                     |
| Filter  |                                     |
| err     |                                     |
| warning |                                     |
| etc.    |                                     |
+---------+                                     |
| Filter  |                                     |
| Services|                                     |
|         |                                     |
|         |                                     |
|         |                                     |
|         |                                     |
|         |                                     |
|         |                                     |
+---------+-------------------------------------+

[geier22]

Ich weiß nicht was Ihr eigentlich wollt:
Das, was gewünscht wird, ist doch vorhanden -- oder sehe ich das falsch?
So sieht das bei mir aus- Die aus meiner Sicht vorhanden "Macken" hab ich ja schon erwähnt:


Das Tool läuft - soweit getestet - auf allen Oberflächen, hier gerade in Cinnamon (Testing)

[theSplit]

Also, ich habe mir Journalctl jetzt auch noch etwas genauer angesehen... hatte vermutet das Tool ist viel umfangreicher, aber es hält sich in Grenzen.

Ich würde eher an einem grafischen Aufbau um die Software herum denken, als komplett alles nachzuempfinden - wichtig hierbei wäre das die Ausgabe von Journalctl direkt an die UI Anwendung geleitet wird und dargestellt wird. Die ganze "Logik" würde ich persönlich schon in Journalctl belassen, nur dass das Interface versucht auf die Parameter einzugehen und die Eingabe des Suchmusters bzw. anderer Parameter etwas zu vereinfachen.

Wenn ich richtig deute, müsste ein Interface ja folgende Sachen anbieten:
Shortcuts (in Form von Buttons) um das "--system" Journal oder "--user" Journal anzeigen zu lassen oder "--dmesg" für aktuelle Kernel Ausgaben in der aktuellen Sitzung.
Ein Kalender für die Datums und Uhrzeitauswahl (von/ab und oder optional bis).
Dann ein Dropdown mit einer Auswahl der Units, um nach einer oder mehreren (?) Units zu suchen, die Eingabe einer optionalen Boot ID bzw. einer Auswahl der Boot Ids.
und so weiter.

Ich will gar nicht auf alle Parameter eingehen, aber das Bild wird vermutlich klar.

Das UI und etwas Logik müsste dann natürlich noch die Darstellung, eigentlich wie bei "gnome-log" übernehmen und die Ausgabe von Journalctl entsprechen darstellen, auslesen/auswerten, kategorisieren (falls erwünscht).
Für die Darstellung von bestimmen Logs oder Units, könnte man Tabs (also Registerkarten) verwenden, die dynamisch erzeugt werden.
Oder man hat ein Dropdown oder einen "Baum", wie es gnome-logs auch glaube ich verwendet.

Eine Suchfunktion oder das Filtern der von Journalctl übergebenen Daten wäre wohl noch das extra Goodie, zum Beispiel das nach einer Zeitspanne gesucht werden kann, eine Sortierung wie neuester Eintrag zuerst, ältester zuletzt könnte man entweder direkt über eine Checkbox, die Journalctl "--reverse" mitgibt, lösen.

Jetzt wäre natürlich die Frage, wie viel (hunderte) MB Logs ausgewertet werden. Wenn man dann zum Beispiel den Output in eine Datei umleiten würde, welche als "temporäre Datei" definiert ist, könnte man über Optionen zum Beispiel im UI ein Speicherlimit setzen, also wieviel MB/GB von einer Log maximal dargestellt werden sollen dürfen.

Damit einhergehend, will man die "temporäre Datei" permanent machen, könnte diese an einem fixen Pfad kopiert bzw. verschoben werden, auf Knopfdruck. So das man dann mit anderen Tools wie "more" durch die Datei gehen kann oder eine Kopie der Datei/des Log anlegt.

Sind nur ein paar Ideen, aber ich glaube so ein Tool für ein Tool wäre die bessere herangehensweise anstatt zu versuchen "journalctl" mit all seinen Features komplett zu ersetzen.

Theoretisch würde es schon reichen, wenn Gnome-Logs dies tun würde - es ist ja nun schon einmal da oder auch mehr Optionen/Einstellungsmöglichkeiten bieten würde, wie man die Daten filtern/durchsuchen kann. Und natürlich wenn man irgendwie die "Macken" die hier im Thema genannt wurden sind, ausbügeln kann. Ist halt die Frage ob es was komplett neues braucht wenn es die Tools schon gibt und diese mehr oder minder seit Jahren gut funktionieren und auch an die Bedürfnisse der jeweiligen Anwender angepasst bzw. dafür entwickelt worden sind.

Aber ich geb zu, mit einem intelligenten UI könnte man vielleicht etwas vereinfachen.