Log-Browser, Syslog und Loginsight Text- und Video-Tutorial: Logging in vSphere 6.5

Das Überwachen und Analysieren von Log-Dateien gehört zu den wichtigsten Alltagsaufgaben für „VMware vSphere“-Administratoren. Die vSphere-Version 6.5 wartet hierbei mit einigen Neuerungen auf, wobei die kostenlose Verfügbarkeit der „vCenter“-Version von „Loginsight“ sicher die Interessante ist.

Anbieter zum Thema

VMware Global Inc Zweigndl. Deutschland

Fujitsu Technology Solutions GmbH

Das Überwachen einer vSphere-Umgebung mit geeigneten Tools ist erste Admin-Pflicht. Dabei geht es in erster Linie um Events, aber auch um das Auswerten von Log-Dateien. Hierbei muss man in einer vSphere-Umgebung zwischen Logs der „ESXi“-Hosts, Logs der virtuellen Maschinen und Logs des vCenter-Systems unterscheiden.

ESXi-Hosts schreiben Log-Dateien normalerweise nach /var/log beziehungsweise /var/run/log. Sofern der Host mit lokalen Platten ausgestattet ist, bleiben sie dort je nach Größe des Scratch-Bereiches auch eine gewisse Zeit erhalten. Bei plattenlosen Hosts landen sie in einer RAM-Disk und gehen nach dem Reboot verloren, sofern der Admin nicht mit Hilfe erweiterte Parameter das Streamen von Logs über den Syslog-Dienst an einen externen Datenspeicher oder einen Syslog-Server erzwingt. In ersterem Fall zeigt zum Beispiel /var/run/log auf den konfigurierten Scratch-Bereich:

Über verschiedene Log-Rotate-Parameter kann man zudem Aufbewahrungszeit und Platzbedarf beeinflussen.

Typischerweise generiert ein ESXi-Host rund 50 verschiedene Log-Dateien, wobei es aber durchaus genügt, sich mit den Wichtigsten zu befassen: „hostd.log“, „vpxa.log“, „syslog.log“; „vmkernel.log“, „vmkwarning.log“ oder „vmksummary.log“. Der Host-Daemon (hostd) kümmert sich um das Management von ESXI-Hosts. Dazu kommuniziert er über die vSphere-API mit den verschiedenen Clients, spricht mit dem HA-Agent (Fault Domain Manager) und mit dem vCenter-Agent vpxd. Im hostd.log stehen daher Log-Einträge der einzelnen Management-Services.

In der Datei syslog.log hingegen ist vermerkt, ob diese Dienste korrekt gestartet wurden oder die entsprechenden Watchdogs und Scheduler-Tasks laufen, sowie Informationen über die Benutzung der der DCUI. Das vmkernel.log hingegen liefert Informationen zur Geräteerkennung, Driver-Events, Informationen über das Starten und Beenden virtueller Maschinen sowie Treiber-Informationen.

Mit physischen Zugang zum ESXI-Host kann der Admin Log-Dateien direkt an diesem rudimentär betrachten, entweder via zum Beispiel vi, less, more sowie an der ESXi-Shell (Alt+F1) oder in der DCUI, sofern die ESXi-Shell nicht deaktiviert ist (Default) oder der Zugang über den Lockdown-Mode nicht eingeschränkt ist.

Ist SSH aktiviert, kann der Admin auch Remote auf das Log-Verzeichnis zugreifen. Dank Busybox stehen an der Shell auch Unix-typische Kommandos wie „tail“ zur Verfügung. Mit „tail –f“ lässt sich bekanntlich eine rudimentäre Live-Änderungsverfolgung bewerkstelligen. Komfortabler ist aber ein externer Syslog-Server/Log-Browser.

Auch virtuellen Maschinen schreiben Log-Dateien, also die der VMM-Prozesse auf Hypervisor-Ebene, nicht zu verwechseln mit den Log-Dateien des Gastsystems oder der Gast-Applikationen. Diese finden sich im Verzeichnis der jeweiligen Maschine auf dem Datastore. Um hingegen die Logs der Gastsysteme abzugreifen, braucht man entsprechende Agenten in der virtuellen Maschine.

vCenter Logs und Events

Die Lokalisation der vCenter-Logs differiert zwischen „Windows vCenter“ und der „VCSA“. Windows-vCenter loggen nach „%ALLUSERSPROFILE%\VMWare\vCenterServer\logs”; die Linux-basierte VCSA nach /var/log/vmware. Hier gibt es Unterverzeichnisse für jeden einzelnen Service.

Zwar ist auch dieses Verzeichnis gut gefüllt; die mit Abstand wichtigste Log-Datei des vCenter ist allerdings die des vCenter-Server-Daemons vpxd (vpxd.log), der Gegenspieler von vpxa (vpxa.log) im ESXi-Host. Auch vCenter-Logs lassen sich bei Bedarf an der Kommandozeile der vCenter-Appliance einsehen; wenn der Admin hier an der Appliance-Shell durch Eingabe von „shell“ zur Bash wechselt. Als Betrachter kommen auch hier less, more oder tail in Frage.

Neuerungen in Version 6.5

Jeder ESXi-Host führt ab Version 5.5 von Haus aus einen syslog-Dienst (vmsyslogd) aus, quasi der Standardmechanismus für das Protokollieren von Meldungen aus dem VMkernel und anderen Systemkomponenten. Wie oben gesehen, werden Logs in ESXi auf einem lokalen Scratch-Datenträger oder eine Ramdisk platziert und gehen in letzteren Fall verloren, wenn der Host neu startet.

Der Admin sollte also unbedingt eine dauerhafte Protokollierung aktivieren, um in den Genuss einer dedizierten Aufzeichnung der Aktivitäten für den Host zu gelangen. Diese Remote-Protokollierung erlaubt das Aggregieren der Protokolldateien auf einem zentralen Host. Dieser kann eine spezielle Linux-basierte Syslog-Maschine sein oder eine Log-Management-Lösung wie „VMware vRealize Loginsight“.

Datacenter-Insider-Video Workshop Logging

Eine der bemerkenswertesten Neuerungen in vCenter 6.5 in diesem Kontext ist folgende: In früheren Versionen waren vSphere-Logs eher auf die Problembehandlung als auf IT-Vorgänge oder Sicherheitsanwendungen ausgerichtet. In vSphere 6.5 sind Logs, die von vCenter Server 6.5 über Syslog geliefert werden, allerdings nun mit Daten aus vCenter-Server-Ereignissen angereichert.

Das gibt Administratoren die Möglichkeit, Probleme noch besser zu verfolgen und beheben zu können. Diese Änderungen erfordern trotzdem keine Erhöhung des Log-Levels über die Standardstufe „Info“ hinaus. Sie fügen der vCenter-Service-Instanz und der Datenbank auch keine merkliche Last hinzu, weil diese Informationen ja bereits als Teil der vorhandenen vCenter-Server-Ereignisse aufgezeichnet wurden.

Die erweiterte Log-Funktion bewirkt, dass diese Informationen einfach an Syslog weitergegeben werden. Standardmäßige Fehlerbehebungs- und Support-Protokolle bleiben davon unberührt.

Und noch eine Neuerung darf nicht außer Acht gelassen werden: Bei der vCenter Appliance VCSA 6.0 musste man zur Konfiguration von Remote-Syslog (rsyslog) den vSphere Web Client verwenden. Das war zwar auf dem ersten Blick angenehm, brachte aber leider eine unnötige Abhängigkeit von vCenter Single-Sign On (SSO) und der vSphere Web Client-Benutzeroberfläche mit.

In VCSA 6.5 ist sie Remote-Syslog-Konfigurationen in die VAMI-Benutzeroberfläche gewandert. Als Out-of-Band-Schnittstelle würde diese noch auch dann noch funktionieren, wenn SSO oder vCenter Server inaktiv sind. Hat der Admin hier Änderungen eingetragen, wird der Syslog-Client automatisch neu gestartet:

Das syslog-Ziel für ESXi-Host wird dagegen nach wie vor im Web-Client konfiguriert. Allerdings gibt es dazu kein eigenes Menü. Vielmehr erfolgt der Eintrag ebenfalls mit Hilfe eines erweiterten Parameters.

Man markiert also den betreffenden Host, klickt im Reiter „Konfigurieren“ auf das Menü „System / Erweiterte Systemeinstellungen“ und konfiguriert im einfachsten Fall den Parameter „Syslog.global.logHost“. Standardmäßig steht hier „0“. Sollen die Logs auf einem externen Log-Server ausgegeben werden, trägt man den oder die (auch mehrere Komma-separiert Server sind erlaubt) betreffenden Hosts in der Form „udp://<IP-Adresse-oder-Name>:514“ ein.

Weitere mit der Log-Konfiguration im Zusammenhang stehenden Konfigurationsparameter sind „Syslog.global.logDir“, „Syslog.global.logHost“, „Syslog.global.logDirUnique“, „Syslog.global.defaultRotate“ und „Syslog.global.defaultSize“. Eine detaillierte Erläuterung der Bedeutung findet sich in der VMware Knowledge-Base sowie in der vSphere-Dokumentation.

System Logs und Log-Browser

Markiert der Admin das vCenter-Objekt im Web-Client hat er im Reiter „Überwachen“ im Tab „Systemprotokolle“ die Möglichkeit, komfortabel Log-Bundles von ESXi-Hosts, vCenter und Web-Clients zu erstellen und herunterzuladen, um sie zum Beispiel an den Support von VMware zu senden. Hierzu klickt man auf „Systemprotokolle exportieren“. Außerdem gibt es an dieser Stelle einen Log-Betrachter für die vCenter Protokoll-Datei vpxd.log.

Log-Browser-Plugin aktivieren

Bei vSphere 5.5 und 6.0 bot der Web-Client im Zusammenhang mit der zugehörigen vCenter-Version sogar einen komfortablen Log-Browser für ESXi-Hosts. Markierte man hier einen ESXi-Host im vCenter, stand in Reiter „Monitor“ (Überwachen) der Tab „Log Browser“ zur Verfügung und ebenso ein Quicklink im Navigator.

In vSphere 6.5 lassen sich im oben genannten Tab „System Logs“ (Systemprotokolle) allerdings nur noch die wichtigsten vCenter-Logs (vpxd.log) direkt ansehen; der „alte“ Log-Browser scheint zu fehlen.

Dem ist aber nicht so. Der Protokoll-Browser ist ein Plugin für den vSphere Web Client und noch immer Bestandteil des vCenter Server-Installationspakets. Zum Verwenden des Protokoll-Browsers muss der Admin lediglich das Protokoll-Browser-Plug-In bereitstellen.

Ist das der Fall, lassen sich ein oder mehrere vCenter-Server- und ESXi-Protokolldateien gleichzeitig mit dem Protokoll-Browser anzeigen, durchsuchen und exportieren. Ferner kann der Admin verschiedene Protokolltypen exportieren, verwalten und anzeigen. Das Plugin ist als OSGI-Bundle realisiert. Zum Bereitstellen des Browser-Plugins geht man wie folgt vor:

• 1. Man meldet sich als Administrator an der Bash-Shell der vCenter Server Appliance an, …

• 2. … navigiert zum Verzeichnis, in dem die Manifest-Datei des Protokoll-Browsers abgelegt ist, per Default /usr/lib/vmware-vsphere-client/plugin-packages/logbrowser …

• 3. ... und benennt die Datei plugin-package.xml.unused in plugin-package.xml um.

• 4. Anschließend startet man im vSphere Web Client den VMware Service Lifecycle Manager API-Dienst neu und der vermisste Log-Browser sollte wieder im Inventar auftauchen.

Datacenter-Insider-Video Workshop Logging

Streaming von Ereignissen auf den Remote-Syslog-Server

Zudem können Admins auch Informationen über die vom vSphere-System generierten Ereignisse auf den Remote-Syslog-Server streamen. Das Streaming von Ereignissen wird jedoch nur für die vCenter Server Appliance unterstützt und ist standardmäßig deaktiviert.

Admins können jedoch das Streamen von vCenter Server-Ereignissen auf einen Remote-Syslog-Server über die vCenter Server Appliance-Schnittstelle aktivieren und konfigurieren. Nach einem Neustart der Appliance werden auch die neu generierten Ereignisse auf einen Remote-Syslog-Server gestreamt. Zu diesem Zweck bietet sich VMware Loginsight für vCenter an.

Loginsight for vCenter

Wer Log-Dateien und Events proaktiv überwacht, gewinnt schneller Einblick in ein aus dem Ruder laufendes System. VMware vRealize Loginsight ist eine komplexe Software, die sich in Funktionsumfang und Arbeitsweise am Marktführer Splunk orientiert. Die Software aggregiert Log-Dateien, Metriken und weitere Daten von ESXi-Hosts, physischen oder virtuellen Servern und Desktops, virtuellen Appliances oder Cloud-Instanzen in einem zentralen Repository.

Auf Basis komplexer Analysen auf diesem Repository, wozu moderne Techniken wie Machine Learning (ML) zum Einsatz kommen, werden Grafiken, Reports und Warnmeldungen erzeugt. Auch eine interaktive Analyse ist möglich.

Die Benutzeroberfläche orientiert sich ebenfalls an Splunk mit seinen vorbereiteten Dash-Bord. Während ESXi-Hosts oder vCenter-Server ohne größere Eingriffe auf diesen Systemen mit Loginsight zusammenarbeiten, bedarf es für das Überwachen von physischen Maschinen entsprechender Agents für Windows oder Linux.

Eigentlich ist Loginsight unter der Bezeichnung vRealize Loginsight Teil der vRealize-Suite und schlägt mit nicht unerheblichen Kosten zu Buche. Allerdings stellt VMware seit Frühjahr 2016 eine Variante unter der Bezeichnung „Loginsight für vCenter“ in Form einer virtuellen Linux-Appliance bereit, die sich einfach als OVA-Datei ausrollen und mit einem bestehenden vCenter verbinden lässt.

VMware Loginsight for vCenter richtet sich an Betreiber kleinerer bis mittelgroßer vSphere-Umgebungen und kann mit der beim Erwerb eines vCenters enthaltenen Lizenz bis zu 25 ESXi-Server ohne Zusatzkosten beziehungsweise ohne eigene Loginsight-Lizenz überwachen. Das Produkt ist also nicht kostenfrei, für den Käufer einer vSphere/vCenter-Lizenz fallen aber bis zu einer gewissen Größe der Umgebung keine zusätzlichen Kosten mehr an.

*Der Autor, Thomas Drilling, schreibt freiberuflich IT-Artikel und arbeitet als IT-Berater. Auf Datacenter-Insider betreibt er einen Blog zu Open-Source-Software: „Drillings Open-Source-Eck“.

(ID:45153665)