Wo Solaris seine Logs ablegt und wie fmadm und fmdump bei Hardware- und Softwarefehlern helfen

Worum es geht

Solaris legt die meisten systemweiten Logmeldungen in /var/adm/messages ab; dmesg zeigt die letzten 200 syslog-Einträge aus dieser Datei und ihren rotierten Kopien in chronologischer Reihenfolge an. Davon getrennt landen stdout und stderr der Start-Methode jeder SMF-Service-Instanz in einer eigenen Logdatei pro Instanz unter /var/svc/log/; den genauen Pfad nennt svcs -l <fmri>. Unabhängig davon diagnostiziert die Fault Management Architecture (FMA) mit fmd und den Administrationswerkzeugen fmadm und fmdump Hardwarefehler und einige Softwarefehler. Dabei macht sie aus roher Telemetrie einen diagnostizierten Fehler mit UUID, einer Liste verdächtiger Komponenten und einer empfohlenen Massnahme.

Warum es wichtig ist

FMA gibt es, weil ein einzelnes Hardwareereignis (ein defektes DIMM, eine Festplatte, die erste Fehler meldet) viele rohe Fehlermeldungen erzeugen kann. Die Diagnose-Engines von FMA korrelieren diese zu einem einzigen Fehlereintrag, statt dass Administratoren viele Logzeilen lesen und raten müssen. Das ist ein anderes Denkmodell als unter Linux, wo Kernel-Logs und separate Herstellerwerkzeuge für denselben Zweck üblicherweise stückweise verwendet werden.

So wird es angewendet

• Aktuell fehlerhafte Komponenten auflisten: fmadm faulty zeigt Komponenten, die FMA als ausgefallen, defekt oder anderweitig auffällig diagnostiziert hat, samt der Diagnose-UUID zum Querverweisen. Erforderlich ist die Autorisierung solaris.fm.read (Rechteprofil "Fault Information" oder "Fault Management" oder die Rolle root); auch SMF-Services, die in den Zustand maintenance gewechselt sind, können hier erscheinen.
• Die vollständige Diagnosehistorie statt nur der aktuellen Fehler ansehen: fmdump allein gibt das Fault-Log aus (eine Zeile pro Diagnoseereignis, einschliesslich rotierter Logs); mit -v folgen ausführliche Details pro Ereignis. fmdump -e zeigt stattdessen die rohe Fehlertelemetrie (Ereports); diese liegt in einem privaten Format vor und ist nicht zum Parsen in Skripten gedacht. Zum Lesen dieser Logs ist normalerweise die Rolle root nötig.
• Ein einzelnes Ereignis anhand seiner UUID nachschlagen: fmdump -u <uuid> -v gibt die vollständige Diagnose zu diesem Ereignis aus. Das ist nützlich, wenn ein Service oder ein Monitoring-Alarm bereits eine UUID geliefert hat.
• Bei einem SMF-Service-Ausfall mit svcs -x beginnen (siehe den SMF-Artikel in dieser Reihe); der Befehl nennt den Logpfad. Die betreffende Datei unter /var/svc/log/ lesen: Sie enthält die eigene Fehlerausgabe des Services, getrennt von allem, was FMA diagnostiziert hat.
• Kernel-bezogene und allgemeine Systemmeldungen lassen sich schnell mit dmesg prüfen; für mehr als die letzten 200 Einträge oder für Einträge, die dmesg bereits nicht mehr erfasst, direkt /var/adm/messages lesen.

Stolpersteine

• Bei einem Service-Ausfall nur in /var/adm/messages suchen: Die Ausgabe der Start-Methode des Services steht in seiner eigenen Datei unter /var/svc/log/, nicht im System-Messagelog.
• fmadm faulty für die vollständige Fehlerhistorie halten: Es zeigt aktuelle Fehler, keine behobenen; für die gesamte Zeitleiste, auch mit Fehlern inzwischen reparierter oder ersetzter Komponenten, dient fmdump.
• Annehmen, dass jedes Hardwareproblem einen FMA-Fehler erzeugt: Manche Zustände erscheinen weiterhin nur als rohe Meldungen in /var/adm/messages, insbesondere auf nicht unterstützter oder virtualisierter Hardware, auf der plattformspezifische Diagnosemodule fehlen.