Tags: vSphere, ESXi, Log-Management, Troubleshooting
Die wichtigsten Informationsquellen zur Fehleranalyse in IT-Umgebungen und somit auch bei VMware sind Log-Dateien, Tasks und Ereignisse. Das gilt sowohl für vCenter als auf für ESXi und virtuelle Maschinen. Ich zeige, wo die wichtigsten Protokolldateien zu finden sind und mit welchen Bordmitteln man sie durchsucht.
Das Überwachen einer vSphere-Umgebung mit geeigneten Tools gehört zu den grundlegenden operativen Pflichten. Dies umfasst sowohl Ereignisse (Events), als auch Tasks (also länger laufende Aufgaben wie etwa vMotion), Alarme und Protokolldateien.
Auf Standalone-ESXi-Host werden Ereignisse im Host-Client unter dem Reiter Ereignisse angezeigt, sofern man zuvor im Navigator den Eintrag Überwachen markiert.
Bei einem vom vCenter verwalteten ESXi-Host, der im Navigator markiert ist, kann man Ereignisse im vSphere Client unter Überwachen im Abschnitt Aufgaben und Ereignisse => Ereignisse verfolgen. Hier werden natürlich auch Ereignisse von vCenter-Systemen angezeigt.
Um ein zu einem Host gehörendes Ereignis zu finden, muss in der Detailanzeige bei Ziel das Host-System vermerkt sein, in meinem Beispiel "hv1.thomas-drilling.local".
Die Persistenz von Ereignisobjekten hängt von der Systemeinrichtung ab. Bei Standalone-ESXi-Hosts werden sie nur so lange gespeichert, wie der Server sie behalten kann, also bis zum nächsten Neustart von ESXi oder dem Ausschalten einer virtuellen Maschine.
In der Regel kann ein Standalone-Host Ereignisdaten über einen Zeitraum von etwa 15 Minuten speichern, abhängig von seiner Verarbeitungslast, der Anzahl der virtuellen Maschinen und anderen Faktoren.
Bei verwalteten Hosts sind Ereignisobjekte dagegen persistent, weil ESXi die Ereignisdaten an den vCenter-Server sendet, der diese Informationen in seiner Datenbank vorhält. Die Ereignisdatenbank von vCenter ist auch primäre Informationsquelle für externe Analyselösungen wie vRealize LogInsight.
Log-Dateien
Auch beim Auswerten von Log-Dateien muss man in einer vSphere-Umgebung zwischen Logs von ESXi, den virtuellen Maschinen und des vCenter-Systems unterscheiden. Hosts schreiben Log-Dateien normalerweise nach /var/log.
Ist der Host mit lokalen Platten ausgestattet, bleiben sie dort je nach Größe des Scratch-Bereichs erhalten. Plattenlose Server halten Log-Dateien im RAM bzw. in einer RAM-Disk, so dass sie nach dem Reboot verloren gehen.
Allerdings kann man auch hier mit Hilfe erweiterte Parameter Log-Dateien über den Syslog-Dienst an einen externen Datenspeicher oder einen Syslog-Server streamen. Der Dienst vmsyslogd sollte normalerweise laufen, lässt sich aber bei Bedarf bequem über den Host-Client oder vSphere-Client steuern.
Der Syslog-Service leitet Meldungen vom VMkernel und anderen Systemkomponenten in lokale Dateien bzw. einen Datenspeicher im Netzwerk oder auf einem Remote-Host um. Die Log-Ziele, Protokolle (Syslog) und Ports (Default ist UDP 514) lassen sich über den Befehl syslog des esxcli-Systems konfigurieren oder mit Hilfe erweiterter Parameter in der GUI.
So leitet die Option "Syslog.global.logHost" Log-Dateien an einen externen Syslog-Server wie vRealize LogInsight weiter, während "Syslog.global.logDir" den Datenspeicherpfad zum gewünschten Log-Verzeichnis umbiegt. Dieses kann somit problemlos auch auf einem Netzwerkspeicher oder VMFS-Datestore liegen.
Weitere mit der Log-Konfiguration im Zusammenhang stehende Parameter sind "Syslog.global.logDir", "Syslog.global.logHost", "Syslog.global.logDirUnique"“, "Syslog.global.defaultRotate" und "Syslog.global.defaultSize". Eine detaillierte Erläuterung ihrer Bedeutung findet sich in der Knowledge-Base sowie in der vSphere-Dokumentation.
Die wichtigsten ESXi-Logs
Typischerweise erzeugt jeder ESXi-Host über 50 verschiedene Log-Dateien. Es genügt aber in der Regel, sich mit den wichtigsten zu befassen. Dazu gehören "hostd.log", "vpxa.log", "syslog.log", "vmkernel.log", "vmkwarning.log" oder "vmksummary.log".
Bekanntlich kümmert sich der Host-Daemon (hostd) um das Management von ESXi-Hosts. Dazu kommuniziert er über die vSphere-API mit den verschiedenen Clients, mit dem HA-Agenten (FDM) oder mit dem vCenter-Agent vpxd. Daher landen die Log-Einträge der jeweiligen Management-Services in der Datei hostd.log.
Die Datei syslog.log hingegen zeichnet auf, ob diese Dienste korrekt gestartet wurden oder die entsprechenden Watchdogs und Scheduler laufen. Außerdem finden sich hier Informationen über die Benutzung der der Server-Konsole (DCUI).
Das vmkernel.log dagegen liefert Informationen zur Geräteerkennung, über das Starten und Beenden virtueller Maschinen, sowie zu Treiber-Ereignissen.
Log-Files betrachten
Hat man physischen Zugang zum ESXi-Host, dann kann man diese Log-Dateien dort direkt betrachten, beispielsweise auf der ESX-Shell via vi, less oder more. Dank Busybox stehen an der Shell auch Unix-typische Kommandos wie tail zur Verfügung. Mit
tail -f <protokoll.log>
lässt sich bekanntlich eine rudimentäre Live-Änderungsverfolgung bewerkstelligen. Logs sieht man aber auch in der DCUI, wenn nicht der strenge Lockdown-Mode eingeschaltet ist. Die entsprechenden Informationen finden sich im Hauptmenü unter View System Logs.
Komfortabler ist allerdings der Log-Browser im Host-Client unter Überwachen => Protokolle.
Auch virtuelle Maschinen schreiben Log-Dateien. Hierbei handelt es sich um Protokoll-Ausgaben der zugehörigen VMM-Prozesse für die jeweilige VM auf Hypervisor-Ebene. Sie sind nicht zu verwechseln mit den Log-Dateien des Gastsystems oder darin laufender Applikationen. Auch diese stecken auf dem Datastore im Verzeichnis der jeweiligen Maschine.
Möchte man Log-Dateien der Gastsysteme abgreifen, muss innerhalb der VM ein entsprechender Agent für die eingesetzte Log-Verwaltung laufen.
vCenter-Logs und Events
Auch vCenter-Server generieren Logs und auch diese lassen sich über den zuständigen Syslog-Dienst auf einem externen Log-Host konsolidieren. Bei der vCenter Appliance finden sich die zugehörigen Einstellungen seit der Version 6.7 in der Appliance-Management-GUI (Port 5480) im Menü Syslog.
Die Log-Dateien selbst speichert die vCSA im Verzeichnis /var/log/vmware. Windows vCenter dagegen nutzt dafür %ALLUSERSPROFILE%\VMWare\vCenterServer\logs. In beiden Fällen gibt es Unterverzeichnisse für jeden einzelnen Service.
Auch diese sind gut gefüllt, allerdings ist die mit Abstand wichtigste Log-Datei jene des vCenter-Server-Daemons vpxd (vpxd.log), der Gegenspieler von vpxa (vpxa.log) im ESXi-Host.
Auch Log-Dateien von vCenter lassen sich direkt auf der Kommandozeile der Appliance betrachten. Als Viewer kommen ebenfalls less, more oder tail in Frage. Es gibt auch einen grafischen Log-Viewer im Web Client, allerdings (noch) nicht im vSphere Client. Er findet sich für vCenter-Objekte, die im Navigator markiert sind, unter dem Reiter Überwachen im Tab Systemprotokolle.
Logs in älteren Versionen waren eher auf die Problembehandlung als auf IT-Vorgänge oder Sicherheitsanwendungen ausgerichtet. Eine der interessantesten, aber nicht ganz so offensichtlichen Neuerungen in vCenter 6.5 bestand darin, dass es Logs auch mit Daten aus vCenter-Server-Ereignissen anreichert.
Die Änderungen hatte übrigens keine standardmäßige Erhöhung des Log-Levels über "Info" hinaus zur Folge. Sie verursacht auch keine zusätzliche Last für die Service-Instanz oder die Datenbank, da diese Informationen bereits als vCenter-Server-Ereignisse aufgezeichnet wurden.
Die erweiterte Log-Funktionalität steuert nur, dass diese Informationen an Syslog weitergegeben werden. Standardmäßige Fehlerbehebungs- und Support-Protokolle bleiben davon unberührt.
Ganz nebenbei haben User im Tab System-Protokolle auch 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.
LogInsight for vCenter
Wer Log-Dateien und Events proaktiv überwacht und nicht nur zur nachgelagerten Fehlersuche, der gewinnt schneller einen Einblick, ob sich sein System anormal verhält. Zu diesem Zweck bietet VMware vRealize LogInsight an, eine komplexe Software, die sich in Funktionsumfang und Arbeitsweise am Marktführer Splunk orientiert. Sie ist somit weit mehr ist als ein Log-Betrachter und unterstützt auch zahlreiche andere Produkte.
Das Streamen der Log-Dateien von ESXi-Hosts und vCenter-Systemen über den Syslog-Dienst auf vRealsize LogInsight wird genauso konfiguriert wie oben beschrieben. Standardmäßig sammelt die Lösung nämlich nach der initialen Konfiguration eines so genannten Collectors für vSphere nur Tasks und Events ein. Zusätzlich lassen sich diverse Agenten für die zu überwachenden Produkte, darunter auch physische Systeme, herunterladen und installieren.
Auf dieser Datenbasis (Logs, Events, Tasks, Agent-Informationen) arbeitet dann eine ausgeklügelte Machine-Learning-Engine, die es dem Nutzer erspart, einzelne Log-Dateien zu durchsuchen. Vielmehr überwacht LogInsight Verhaltensmuster in den konfigurierten Datenquellen und gibt auf Basis entdeckter Veränderungen Empfehlungen in Form von Dashboards.
Vordefinierte Dashboards werden als so genannte Content-Packs beispielsweise für vSphere und vSAN mitgeliefert. Weitere lassen sich über den integrierten Marketplace beziehen.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
- VMware bringt App mit Benachrichtigungen zu Patches, Schwachstellen und Troubleshooting
- Esxtop in vSphere Web Client integrieren mit Gratis-Tool von VMware Labs
- VMware vSphere 8 Update 2: ESXi Lifecycle Management Service, mehr KI-Rechenleistung, Integration mit Azure AD
- ESXi Free 8.0: Neuerungen, Hardware-Voraussetzungen, Lizenzierung
- VMware vCenter mit dem vSphere Diagnostic Tool analysieren
Weitere Links