Log Analysis LogAnalysis - GUI zum betrachten und durchsuchen von /var/log

[Tommes]

Bin grad schweißgebadet wach geworden, weil mir das Problem keine Ruhe gelassen hat... ... nein, quatsch!

Hab das Problem aber lösen können. Es musste nur eine Anfrage im Script zurückgesetzt werden mit der entschieden wird, ob eine Suchanfrage innerhalb einer Datei oder innerhalb eines Ordners durchgeführt wurde. Für die Profis unter euch... ich musste an einer bestimmten Stelle im Script der URL nur ein &query= anzuhängen um die Anfrage zurückzusetzen. Manchmal kann die Lösung so einfach sein.

Tommes

 

[TeXniXo]

@TeXniXo
Kommst du mit der eingebetteten "Textarea", als Ausgabe-Element der Logeinträge jetzt besser zurecht? Fühlt sich ja fast so an, wie ein iFrame und man benötigt keinen Button "nach oben" mehr.

Absolut! Passt sehr gut so für mich!
Vielen Dank auch für deinen Einsatz!

 

[BigRonin]

Wenn du mir Datei und Zeilennummer sagen kannst ... probier ich das gerne aus

 

[framp]

... Zeilennummer ...

Waere das nicht auch ein nuetzliches Feature dass man diese per Option anzeigen lassen kann? Ich habe dafuer zwar konkret keinen Usecase ... aber vielleicht ja jemand anders?

 

[Tommes]

Wenn du mir Datei und Zeilennummer sagen kannst ... probier ich das gerne aus

In der main.sh Zeile 106 (den rot markierten Teil in der URL ergänzen...

<a href="index.cgi?page=main&section=start&path='${get[path]%/*}'&file=[COLOR="#FF0000"]&query=[/COLOR]" class="text-muted">/..</a>

Danke schonmal fürs Testen.

Waere das nicht auch ein nuetzliches Feature dass man diese per Option anzeigen lassen kann? Ich habe dafuer zwar konkret keinen Usecase ... aber vielleicht ja jemand anders?

Du meinst, das man die Zeilennummer angezeigt bekommt, wo genau der gesuchte Logeintrag in der angezeigten Datei zu finden ist? Oder das jede Zeile von einer Zeilennummer angeführt wird? Das geht erstmal und ich hatte ersteres so auch schonmal bei mir implementiert. Es scheiterte bisher aber immer daran, den grep Befehl wieder so auseinander zu klamüsern das am Ende nichts veroren geht. BigRonin hatte da ja so seine Probleme mit, weshalb es in der Version 0.3 den Fix...

Die Auswertung und Anzeige der Suchergebisse wurde nochmal stark überarbeitet. Abgeschnittene Zeilen, zerstückelte Datumsangaben sowie unnötige Zeilenumbrüche usw. sollten jetzt nicht mehr ausgegeben werden.

... gab. Aber ich schau mir das nochmal an.

 

[BigRonin]

Top ... das war's ... funktioniert einwandfrei !!

 

[Tommes]

Prima. Das beweist schonmal, das ich mein eigenes Script noch verstehe

Danke nochmal fürs testen und zurückmelden. Ich hab auch noch eine Kleinigkeit gefunden, die ich ändern werde und ich versuch mich nochmal an den Zeilennummern. Ein Update wird aber wohl in den nächsten Tagen folgen...

 

[framp]

... Du meinst, das man die Zeilennummer angezeigt bekommt, wo genau der gesuchte Logeintrag in der angezeigten Datei zu finden ist? Oder das jede Zeile von einer Zeilennummer angeführt wird? Das geht erstmal und ich hatte ersteres so auch schonmal bei mir implementiert. Es scheiterte bisher aber immer daran, den grep Befehl wieder so auseinander zu klamüsern das am Ende nichts veroren geht. BigRonin hatte da ja so seine Probleme mit, weshalb es in der Version 0.3 den Fix...

Die erste Variante. Die Matches mit Zeilennummern versehen. Wo gibt es da ein Problem? Wie sieht genau der grep aus? Vielleicht kann ich ja helfen

 

[Tommes]

Wenn du dir das antun willst... genre. Ich versuch das mal zu erklären. Räusper....

Eine Suchanfrage, also nur Suchbegriff, ohne Einbeziehung von Datum und Uhrzeit wird in meinem Script so gestellt.

/bin/find "$PathOrFile" -type f -exec [COLOR="#FF0000"]grep[/COLOR] -E[COLOR="#FF0000"]H[/COLOR] '.*(.*'"${post[searchstring]}"').*' {} \; >> ${result}

Hierbei wird mittels dem grep Optionsschaler -H der Pfad inkl. Dateiname des Suchtreffers angezeigt. ${result} würde als String dann so aussehen...

/var/log/messages[COLOR="#FF0000"]:[/COLOR]2020-04-28T17:50.... bla bla bla

... wobei Pfad und Dateiname vom eigentlichen Suchtreffer durch ein Doppelpunkt getrennt ist. grep grenzt das wohl immer so ab. Über eine for-Schleife werden mir die Ergbnisse von ${result} dann zeilenweise ausgegben. Um jetzt den Pfad/Datei vom Logeintrag einer Zeile zu trennen, schneide ich den String einfach mit ${line%%:*} an der Stelle ab, wo sich der Doppelpunkt befindet so das mir in der ersten Zeile Pfad und Datei ausgegeben wird. Das aber auch nur, wenn sichergestellt ist, das die Zeile mit einem / anfängt und nicht mit einem Logeintrag beginnend mit Datum. In der nächsten Zeile wird dann mit ${line#*:} der Logeintrag ohne Pfad/Dateiname gefiltert und angezeigt.

Kann man das nachvollziehen, was ich bis jetzt geschrieben habe?

Also weiter. Füge ich dem grep jetzt die Zeilennummer mit dem Optionsschalter -n hinzu, also...

/bin/find "$PathOrFile" -type f -exec [COLOR="#FF0000"]grep[/COLOR] -E[COLOR="#FF0000"]n[/COLOR]H '.*(.*'"${post[searchstring]}"').*' {} \; >> ${result}

... dann sieht ${result} folgendermaßen aus...

/var/log/messages[COLOR="#FF0000"]:345:[/COLOR]2020-04-28T17:50.... bla bla bla

Die Zeile 345 erscheint also stets zwischen Pfad/Dateiname und Logeintrag, getrennt von je einem Doppelpunkt. Hier kann ich jetzt nicht mehr so einfach durch String-Beschneidung nach dem Doppelpunkt filtern, da ich nicht nach dem ersten, sondern zweiten filtern müsste. Ein dritter Doppelpunkt erscheint dann in der Uhrzeit, oder bei BigRonin war es dann ein Logeintrag von AvrLogger, wo ein Teil seines Textes fehlte, der einen weiteren Doppelpunkt enthielt.

Wie filter ich also die Zeilennummer das es am Ende vielleicht so aussieht:

Treffer in /var/log/messages, Zeile 345 gefunden
2020-04-28T17:50.... bla bla bla

Anmerkung der Redaktion. RegEx ist und bleibt für mich ein Buch mit sieben Siegeln, daher kann ich mir hier auch nicht mit sed oder ähnlichem weiterhelfen. In diesen Dingen ist PsychoHH König... aber ich wollte ihn erstmal nicht damit nerven. Auch hatte das für mich jetzt nicht sooooo einen hohen Stellenwert gehabt.... bis jetzt.

Tommes

 

[framp]

Ich hoffe ich habe das Problem soweit richtig verstanden und habe das extrahieren des Filenamens und der Zeilennummer wie ich es machen wuerde in ein kleines Script gegossen:

#!/bin/bash

searchString="bla"
echo "2020-04-28T17:50.... bla bla bla" > logfile

grepResult="$(find "logfile" -type f -exec grep -EnH ".*(.*$searchString).*" '{}' \; )"
echo "GrepResult: $grepResult"

lineWithoutHeader="$(cut -f 3- -d: <<< "$grepResult")"
echo "LineWithoutHeader: $lineWithoutHeader"

header="$(cut -f 1-2 -d: <<< "$grepResult")"
echo "Header: $header"

IFS=: headerElements=( $header )
filename="${headerElements[0]}"
#oder
fileName="$(cut -f 1 -d: <<< "$header")"
linenumber="${headerElements[1]}"
#oder
lineNumber="$(cut -f 2 -d: <<< "$header")"

echo "Treffer in $filename, Zeile $linenumber gefunden"
echo "$lineWithoutHeader"

und das Ergebnis des Scripts ist

GrepResult: logfile:1:2020-04-28T17:50.... bla bla bla
LineWithoutHeader: 2020-04-28T17:50.... bla bla bla
Header: logfile:1
Treffer in logfile, Zeile 1 gefunden
2020-04-28T17:50.... bla bla bla

EDIT: Mir ist gerade eingefallen dass man das wohl noch eleganter mit read in der bash erschlagen kann:

IFS=: read fn ln line <<< "$grepResult"
echo "Treffer in $fn, Zeile $ln gefunden"
echo "$line"

 

[Tommes]

Öhm... ich glaub, ich muss doch noch viel lernen. Flöt!

Erstmal ein dickes Danke für deine Ausführungen... Der Hammer!
Das wirft gleich an ganz anderes Licht auf die Sache und ich kann mir dadurch wohl auch gleich die ein- oder andere Abfrage schenken. Ich werde heute wohl nicht mehr dazu kommen, das alles zu probieren, aber soviel steht fest, du wirst im nächsten Update etwas von dem wiederfinden, was du mir grade gegeben hast.

Ich find es ganz große Klasse von euch, das ihr mich da so toll unterstützt. Vielen Dank dafür.

Randnotiz an mich selber: Vertiefen in‘s Thema cut und read

 

[framp]

Freut mich dass ich helfen konnte .

BTW: Du solltest vor dem Umdefinieren von IFS den alten Inhalt sichern und anschliessend wieder restoren. Da man meinstens vom Default IFS ausgeht (space, tab, newline) kann man sonst ziemlich krude Ergebnisse in seinem bash Script erhalten ... Ich habe mir das der Einfachheit gespart. Siehe dazu auch hier

Oder auch ein

unset IFS

wenn Du sonst kein IFS bei Dir umdefinierst und immer den Default brauchst.

 

[Tommes]

Auch wenn mir dieses IFS auch noch ein wenig suspekt ist, so habe ich bereits verinnerlicht, das man die ursprüngliche Definition vorher in einer Variablen sichert und anschließend wieder zurück schreibt. Trotzdem Danke für den Hinweis. Auch nehme ich immer gerne Hilfe an und habe ein offenes Ohr für gut gemeinte Tipps und Ratschläge. Unser aller Ziel ist doch, etwas zu erschaffen, was es so noch nicht gibt und je mehr Leute ihre Ideen einbringen und ihr wissen miteinander teilen umso besser wird das Ergebnis am Ende.

Anderseits zählt für mich primär nicht das Ergebnis, sondern der Weg dorthin.

 

[framp]

Dieses IFS ist ein Tokenseparator bei allen moeglichen bash Tokenizingoperationen (Siehe auch das Tokenizing vermittels bash array in meinem Beispielscript) und man ist dadurch sehr einfach in der Lage Dinge zu splitten. Viele User der bash kennen dieses nette Feature der bash aber nicht.

 

[Tommes]

LogAnalysis Version 0.5 Release Notes vom 02.05.2020
(...sobald von den Machern von CPHub freigegeben!)

• Das Ausgabefeld (textarea) für die Anzeige von Dateiinhalten sowie Suchergebnissen wurde auf "readonly" gesetzt.
• Durch weitere Codeoptimierungen konnten die anfänglich bemängelten "Gedenksekunden" wärend des Seitenladevorganges weiter verkürzt werden.
• Wenn man während des Ladevorganges großer Log-Dateien auf die Schaltfläche "Ausgabe ohne Zeilenumbrüche" geklickt hat, wurde kein Popup-Fenster geöffnet, sondern der Inhalt auf der aktuellen Seite ausgegeben. Fehler wurde in so fern behoben, das die o.a. Schaltfläche erst angezeigt wird, wenn die Seite vollständig geladen ist.
• Beim wechseln in einen Hauptordner oder beim verzweigen in einen Unterordner von /var/log wurde eine Systemvariable nicht zurückgesetzt, was dazu führte, das in den nachfolgenden Suchergebnissen Pfad und Datei des Fundortes nicht mehr angezeigt wurden oder die Suche komplett fehlgeleitet wurde. Fehler wurde behoben.
• Die Überschrift des Ausgabefeldes für die Suchergebnisse zeigt jetzt die aktuelle Aktion an (Ordnersuche, Dateisuche, Dateiinhalt anzeigen).
• Die Überschrift des Popup-Fensters zur Anzeige der Suchergbnisse bzw. des Dateiinhaltes zeigt jetzt ebenfalls die aktuelle Aktion an (Ordnersuche, Dateisuche, Dateiinhalt anzeigen).
• Beim durchsuchen von Ordnern als auch beim durchsuchen innerhalb von Dateien wird die Zeilennummer des Treffers und ggf. der Pfad ausgegeben.

Viel Spaß weiterhin mit dieser App

Tommes

 

[framp]

Habe mir die neue Version eben gezogen. Sieht mittlerweile wirklich sehr gut aus und Zeilennummern sind auch drin :thumbsup: .

Ein paar kleine Anmerkungen habe ich noch

1) Als ich meinen Vorschlag mit den Zeilennummer machte dachte ich an eine Anzeige wie folgt:

00002: nmbd version 4.4.16 started.

wobei 00002 die Zeilennummer ist und sich dahinter ein Link verbirgt der einen sofort zu dem Logfile in dieser Zeile springen laesst.

Dann kann man recht schnell im Tool an die entsprechenden Logstellen springen und drin blaettern, denn oft will man ja wissen was sich in dieser Zeit im Log getan hat.

2) Ich hatte eine Suche ueber den ganzen Verzeichnisbaum von /var/log gestartet und das dauerte mir zu lange. Also wollte ich die Suche abbrechen und habe den Reloadbutton im FF benutzt. Danach war ich aus dem Tool ganz draussen und musste es wieder neu starten. Vielleicht gibt es die Moeglichkeit einen cancel search Button irgendwo unterzubringen?

 

[Tommes]

Habe mir die neue Version eben gezogen. Sieht mittlerweile wirklich sehr gut aus...

Ich fühle mich geehrt. Ich hätte anfangs aber auch nicht gedacht, das sich noch so vieles an der Optik und Haptik verbessern läßt.

1) ...meinen Vorschlag mit den Zeilennummern ... wobei 00002 die Zeilennummer ist und sich dahinter ein Link verbirgt der einen sofort zu dem Logfile in dieser Zeile springen laesst.

Das Problem ist, das innerhalb eines HTML textarea Element keine weiteren TAG's zugelassen werden. Die Ausgabe der Suchergbnisse sowie das Anzeigen von Dateiinhalten läuft aber innerhalb eines HTML textarea Elementes bzw. TAG um einerseits das komplette Scrollen der Seite zu vermeiden und damit Benutzer wie blinddark den Inhalt mit einem ScreenReader oder anderen alternativen Technologien besser erfassen kann. (Wobei ich leider noch kein Feedback von blinddark erhalten habe, ob er mit dem Seitenaufbau nun besser zurecht kommt) Jedenfalls ist es mir daher nicht möglich Linkverweise zu setzten oder sonstige HTML-TAG's innerhalb der textarea zu verarbeiten. Es funktioniert noch nicht mal ein einfacher Zeilenumbruch ala <br />. Echt gruselig... aber hier kann ich deinen Wünschen und Anforderungen erstmal nicht gerecht werden.

2) Ich hatte eine Suche ueber den ganzen Verzeichnisbaum von /var/log gestartet und das dauerte mir zu lange. Also wollte ich die Suche abbrechen und habe den Reloadbutton im FF benutzt. Danach war ich aus dem Tool ganz draussen und musste es wieder neu starten.

Schrecklich diese Benutzer! Was macht ihr auch immer für einen Quatsch. Auf solche Eventuallitäten muss man als Entwickler erstmal kommen. Ob ich hier eine Lösung finde, kann ich aktuell noch nicht beantworten, aber wie immer... ich kümmer mich.

Tommes

 

[framp]

... Das Problem ist, das innerhalb eines HTML textarea Element keine weiteren TAG's zugelassen werden...

Sowas hatte ich mir fast gedacht. Egal - das waere nur die Sahnehaube gewesen

...Schrecklich diese Benutzer! Was macht ihr auch immer für einen Quatsch...

Am besten sind die Monkeytester

 

[mamema]

wollte das Tool ausprobieren, habe aber den Screenshot (angehängt). Weiss da jeman Rat?

 

[Tommes]

Bist du mit Admin Rechten auf der DS angemeldet? Auch mal den Browsercache löschen (F5) bzw. STRG + F5