Jetzt schon?
Ja, es sind kaum 3 Jahre vergangen und schon kommt das erste Update zum Thema LogShark. Logshark selbst, d.h. das Java-Programm hat sich nicht geändert, angepasst habe ich lediglich das "Drumherum", d.h den Powershell-Wrapper und die Konfiguration. Und fertig ist die Version 0.2.
Funktioniert das jetzt endlich alles?
NEIN, aber das wenige funktioniert jetzt schon ein bisschen besser.
Und bei gleichbleibendem Entwicklungstempo ist immerhin bereits in wenigen hundert Jahren mit einem fast perfekten Tool zu rechnen. Also "stay tuned"...
Aber jetzt zu etwas ganz Anderem, nämlich zum Wesentlichen.
DSM 7-Szenario
Mit Logshark kann man sich beliebige Textlogs zu Gemüte führen, ich selbst verwende es hauptsächlich für DSM7. Daher also ein paar warme Worte zu diesem Einsatzzweck. Und mehr noch als warme Worte – in der Folge gibt es auch ein paar Details zur Integration in die DSM-Konsole und schließlich einen Download mit allem, was man braucht. Aber der Reihe nach.
Wie bereits in der ersten, kurzen Vorstellung von Logshark erwähnt, kann man LogShark über den Wrapper direkt aus der DSM-Konsole (DSMC) starten. Rechts-Klick auf ein Computerobjekt, LogShark aus dem Kontextmenü wählen und schon erscheinen die gewünschten Logs des Computers bzw. deren relevante Zeilen mit entsprechender Hervorhebung.
Die Konfiguration, über die u.a. festgelegt wird, welche Logs automatisch geöffnet werden sollen und welche Zeilen angezeigt bzw. hervorgehoben werden sollen, erfolgt weiterhin größtenteils über Konfigurationsdateien. Einige Einstellungen habe ich aber auch für die direkte Konfiguration in der DSMC verfügbar gemacht.
Damit kann per "Debug" eingestellt werden, ob der Debug-Modus aktiv sein soll. In dem Fall erfolgen Ausgaben in ein Powershell-Fenster, das dauerhaft geöffnet bleibt und es wird parallel ein Log im Temp-Verzeichnis des Benutzers erstellt.
Außerdem kann eingestellt werden, ob Logs auch dann geöffnet bleiben sollen, wenn sie nicht mehr im Zugriff sind (KeepOpen). Das ist regelmäßig der Fall wenn ein Computer neu startet aber auch wenn Logfiles vom DSM Client entfernt werden.
Wichtig ist auch die Auswahl des Templates aus dem die Logshark-Konfigurationsdatei generiert wird. Verschiedene Templates können z.B. für Clients und DSM-Management Points verwendet werden. Im Download-Paket sind 2 Templates für genau diese beiden Zwecke vorhanden, weitere können bei Bedarf selbst hinzugefügt werden.
Mit TimeBack schließlich kann eingestellt werden welcher Zeitraum in Stunden als relevant erachtet wird. Ältere Logs werden ignoriert.
Und sonst?
Abgesehen von der besseren und vor allem besser dokumentierten Integration in die DSMC gibt es ein paar kleine aber wesentliche Verbesserungen beim Deployment des Tools. Das sollte jetzt nämlich von allen Admin-Arbeitsplätzen verwendbar sein die auch Zugriff auf die DSMC haben. Voraussetzung ist lediglich eine lokale installierte Java Runtime.
Gestartet wird das Tool aus dem Depot, genauer gesagt aus dem Extern$. Das LogShark-Verzeichnis liegt parallel zu dem mittlerweile auch standardmäßig vorhandenen Tools-Verzeichnis für die PSTools. Wo die Java Runtime installiert ist muss nicht mehr statisch konfiguriert werden, sondern wird dynamisch ermittelt.
Haben wollen?
Sagte ich schon, dass ich keine Gewähr übernehme? Benutzung also natürlich auf eigene Gefahr. Wer auf Nummer Sicher gehen möchte testet in einem Testsystem oder legt Variablen und Task manuell an statt sie zu importieren (siehe unten).
Und so wird’s gemacht:
- Das komplette Paket als ZIP herunterladen, Blockierung entfernen
und nach "\\<DSMDepot>\Extern$\Tools\LogShark" entpacken. Das ist das zentrale, an allen Standorten verfügbare LogShark-Verzeichnis. - DSMC öffnen und die Variablengruppe aus <LogShark-Verzeichnis>\Import\LogSharkVars.XML importieren. Dann die Standardwerte für die Variablen festlegen, z.B. auf "Managed Users &
Computers", z.B. wie im Screenshot oben zu sehen.
Achtung! Auch die Debug-Variable muss gesetzt werden, also zum Ausschalten Haken setzen und wieder entfernen. Sonst gibt es beim Start eine Fehlermeldung wegen einer nicht auflösbaren Variablen. Wenn auch die relevanten Logs auf Management Points behandelt werden sollen, kann bei den entsprechenden Objekten (OUs, Gruppen, Computer) die DSMMP.lsc als TemplatePath verwendet werden. - Als nächstes den User defined Task importieren – die "_CatalogObject_ExpInfo.xml" liegt ebenfalls im LogShark-Verzeichnis unter Import.
Das war’s, der Task steht im Kontextmenü der Computerobjekte für Benutzer mit dem Recht die Client-Logfiles zu öffnen zur Verfügung.
Der Prozess läuft im Usercontext, d.h. der angemeldete Benutzer muss das Recht haben auf das DSMLog-Share zuzugreifen.
Es geht auch anders
Es gibt jede Menge Möglichkeiten das Tool, so wie ich es vorkonfiguriert habe, an eigene Wünsche anzupassen. Von anderen Variablen über andere Farben und unterschiedliche Regeln für die anzuzeigenden Logs bis hin zu Änderungen im Code des Powershell Wrappers oder sogar des LogShark Java Codes. Vieles ist möglich. Wenn man sich an der Musterlösung orientiert, sollten Anpassungen ohne allzu viel Rätselraten gelingen. Wenn etwas unklar ist kann ich womöglich helfen – siehe unten.
Sag Bescheid
Noch Fragen? Funktioniert was nicht? Irgendwelche Wünsche? Sind womöglich Anpassungen entstanden, die auch für andere relevant sein könnten?
Ich freue mich über jegliche Rückmeldung - direkt unten als Kommentar oder per Mail an blog@axoquent.de. Sollte dabei etwas von allgemeinem Interesse herauskommen, aktualisiere ich diesen Blogpost.
Änderungen / Ergänzungen
Einige Hinweise zum Thema LogShark finden sich auch im DSM-Forum.
- Start-LogShark.ps1 funktioniert nicht mit Powershell 2.0 (M.Laeseke)
Bemerkung: mit Powershell 3, 4 und 5 funktioniert's
- Die installierte Java Runtime muss eine x86-Version sein (lucky devil)
Bemerkung: momentan startet die x86-DSMC die x86-Powershell und die wiederum die x86-Java Runtime. Wenn man möchte kann man aus der DSMC auch die x64-Powershell aufrufen und so auch eine x64-Java Runtime verwenden. Dazu ersetzt man einfach im Aufruf "%winsysdir%\WindowsPowershell\..." durch "%windir%\sysnative\WindowsPowershell\...
Das funktioniert dann allerdings nicht mehr auf x86-Betriebssystemen.
- Beim Import des User Defined Task darf das XML nicht mit angegeben werden (lucky devil)
Bemerkung: man kann das Import-Verzeichnis natürlich auch zunächst nach lokal kopieren - dann kann man das Verzeichnis leicht über den Dialog auswählen statt den Pfad direkt angeben zu müssen.
Kommentar schreiben