Troubleshooting von VMware vSphere: Logs, Events und Tasks


    Tags: , , ,

    Log-AuswertungDie wich­tigsten Informations­quellen zur Fehler­analyse in IT-Umgebungen und so­mit auch bei VMware sind Log-Dateien, Tasks und Ereig­nisse. Das gilt sowohl für vCenter als auf für ESXi und virtuelle Maschinen. Ich zeige, wo die wich­tigsten Protokoll­dateien zu finden sind und mit welchen Bord­mitteln man sie durchsucht.

    Das Überwachen einer vSphere-Umgebung mit geeigneten Tools gehört zu den grund­legenden operativen Pflichten. Dies umfasst sowohl Ereignisse (Events), als auch Tasks (also länger laufende Aufgaben wie etwa vMotion), Alarme und Protokoll­dateien.

    Auf Standalone-ESXi-Host werden Ereignisse im Host-Client unter dem Reiter Ereignisse angezeigt, sofern man zuvor im Navigator den Eintrag Überwachen markiert.

    Ereignisse auf ESXi anzeigen im Host-Client

    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".

    Detailanzeige von Host-Ereignissen im vSphere Web Client

    Die Persistenz von Ereignis­objekten hängt von der System­einrichtung 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 Verarbeitungs­last, der Anzahl der virtuellen Maschinen und anderen Faktoren.

    Bei verwalteten Hosts sind Ereignis­objekte dagegen persistent, weil ESXi die Ereignisdaten an den vCenter-Server sendet, der diese Informationen in seiner Datenbank vorhält. Die Ereignis­datenbank von vCenter ist auch primäre Informations­quelle für externe Analyse­lö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 normaler­weise laufen, lässt sich aber bei Bedarf bequem über den Host-Client oder vSphere-Client steuern.

    Syslog-Dienst von ESXi verwalten im Host-Client

    Der Syslog-Service leitet Meldungen vom VMkernel und anderen System­komponenten 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 Daten­speicher­pfad zum gewünschten Log-Verzeichnis umbiegt. Dieses kann somit problemlos auch auf einem Netzwerk­speicher oder VMFS-Datestore liegen.

    Log-Dateien mittels Syslog.global.logHost an einen externen Syslog-Server weiterleiten

    Weitere mit der Log-Konfiguration im Zusammen­hang 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".

    Liste der Log-Dateien auf einem ESXi-Host

    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 ent­sprechenden 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äte­erkennung, ü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-Änderungs­verfolgung bewerk­stelligen. Logs sieht man aber auch in der DCUI, wenn nicht der strenge Lockdown-Mode eingeschaltet ist. Die ent­sprechenden Informationen finden sich im Hauptmenü unter View System Logs.

    ESXi-Logs auf der Server-Konsole ansehen

    Komfortabler ist allerdings der Log-Browser im Host-Client unter Überwachen => Protokolle.

    ESXi-Protokolle im Log-Browser des Host-Clients betrachten

    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.

    syslog des vCSA im VAMI verwalten

    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 Unter­ver­zeichnisse 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 Kommando­zeile 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.

    Log-Dateien des vCSA im Web Client betrachten

    Logs in älteren Versionen waren eher auf die Problem­behandlung als auf IT-Vorgänge oder Sicherheits­anwendungen ausgerichtet. Eine der interes­santesten, aber nicht ganz so offen­sichtlichen Neuerungen in vCenter 6.5 bestand darin, dass es Logs auch mit Daten aus vCenter-Server-Ereignissen anreichert.

    Die Änderungen hatte übrigens keine standard­mäß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 Infor­mationen bereits als vCenter-Server-Ereignisse aufgezeichnet wurden.

    Die erweiterte Log-Funktionalität steuert nur, dass diese Informationen an Syslog weitergegeben werden. Standard­mäß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.

    Log-Dateien im Web-Client exportieren

    LogInsight for vCenter

    Wer Log-Dateien und Events proaktiv überwacht und nicht nur zur nachge­lagerten Fehler­suche, 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 Funktions­umfang 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.

    Dashboards von vRealize Log Insight

    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 Verhaltens­muster in den konfigurierten Datenquellen und gibt auf Basis entdeckter Veränderungen Empfehlungen in Form von Dashboards.

    Content Packs für Log Insight lassen sich vom Marketplace herunterladen

    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

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet ist seit fast 30 Jahren selb­ständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehe­malige 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 zerti­fi­zierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grund­lagenkurse 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 Infor­mationen und Anmel­dung über sein Azure-Blog.

    Verwandte Beiträge

    Weitere Links