Freigeben über


Anzeigen von Integritätsdienstfehlern

Gilt für: Azure Local 2311.2 und höher; Windows Server 2022, Windows Server 2019

Dieser Artikel bietet ausführliche Informationen zu Fehlern im Gesundheitsdienst in Azure Local und Windows Server.

Informationen zu Gesundheitsdienstfehlern

Der Integritätsdienst überwacht ständig Ihren „Direkte Speicherplätze“-Cluster, um Probleme zu erkennen und „Fehler“ zu generieren. Ein Cmdlet zeigt alle aktuellen Fehler an, sodass Sie die Integrität Ihrer Bereitstellung problemlos überprüfen können, ohne jede Entität oder jedes Feature überprüfen zu müssen. Fehler sind auf Präzision, leichte Verständlichkeit und Umsetzbarkeit ausgelegt.

Jeder Fehler umfasst fünf wichtige Felder:

  • Schweregrad
  • Beschreibung des Problems
  • Empfohlene nächste Schritte zum Beheben des Problems
  • Identifizierende Informationen zur fehlerbehafteten Entität
  • Die physische Stelle (falls zutreffend)

Es folgt ein Beispiel eines typischen Fehlers:

Severity: MINOR
Reason: Connectivity has been lost to the physical disk.
Recommendation: Check that the physical disk is working and properly connected.
Part: Manufacturer Contoso, Model XYZ9000, Serial 123456789
Location: Seattle DC, Rack B07, Node 4, Slot 11

Hinweis

Die physische Stelle wird von der Konfiguration der Fehlerdomäne abgeleitet. Weitere Informationen zu Fehlerdomänen finden Sie unter Fehlerdomänenunterstützung. Wenn Sie diese Informationen nicht bereitstellen, ist das Standortfeld weniger nützlich. Beispielsweise zeigt es möglicherweise nur die Slotnummer an.

Referenzinformationen zu Fehlern finden Sie im Referenzdokument zu Gesundheitsdienstfehlern.

Ursachenanalyse

Der Integritätsdienst kann die potenzielle Kausalität zwischen fehlerhaften Entitäten bewerten, um Fehler zu identifizieren und zu kombinieren, die Folgen desselben zugrunde liegenden Problems sind. Durch erkennen von Kausalketten ergeben sich kürzere Berichte. Wenn zum Beispiel ein Server ausfällt, ist davon auszugehen, dass auch alle Laufwerke innerhalb des Servers ohne Verbindung sind. Daher wird nur ein Fehler für die Grundursache ausgelöst – in diesem Fall für den Server.

Verwendung in PowerShell

Führen Sie zur Anzeige aktueller Fehler in PowerShell das folgende Cmdlet aus:

Get-HealthFault

Dadurch werden alle Fehler zurückgegeben, die sich auf den „Direkte Speicherplätze“-Cluster auswirken. In den meisten Fällen beziehen sich diese Fehler auf die Hardware oder Konfiguration. Wenn keine Fehler vorliegen, gibt das Cmdlet nichts zurück.

Hinweis

In einer Nicht-Produktionsumgebung können Sie auf eigene Gefahr mit diesem Feature experimentieren, indem Sie Fehler selbst auslösen. Hierzu können Sie beispielsweise einen physischen Datenträger entfernen oder einen Knoten herunterfahren. Nachdem der Fehler angezeigt wird, fügen Sie den physischen Datenträger erneut ein oder starten den Knoten neu, damit der Fehler nicht mehr angezeigt wird.

Verwendung in .NET und C#

In diesem Abschnitt wird gezeigt, wie Sie eine Verbindung mit dem Integritätsdienst herstellen, Objekte ermitteln und Fehlerabfragen ausführen.

Verbinden

Zum Abfragen des Integritätsdiensts richten Sie eine CimSession-Sitzung mit dem Cluster ein. Dazu benötigen Sie einige Dinge, die nur in microsoft .NET vollständig verfügbar sind, was bedeutet, dass Sie dies nicht direkt über eine Web- oder mobile App tun können. In den Codebeispielen in diesem Abschnitt wird C# verwendet, die unkomplizierteste Wahl für diese Datenzugriffsschicht.

using System.Security;
using Microsoft.Management.Infrastructure;

public CimSession Connect(string Domain = "...", string Computer = "...", string Username = "...", string Password = "...")
{
    SecureString PasswordSecureString = new SecureString();
    foreach (char c in Password)
    {
        PasswordSecureString.AppendChar(c);
    }

    CimCredential Credentials = new CimCredential(
        PasswordAuthenticationMechanism.Default, Domain, Username, PasswordSecureString);
    WSManSessionOptions SessionOptions = new WSManSessionOptions();
    SessionOptions.AddDestinationCredentials(Credentials);
    Session = CimSession.Create(Computer, SessionOptions);
    return Session;
}

Der angegebene Benutzer muss ein lokaler Administrator des Zielcomputers sein.

Es wird empfohlen, das Kennwort SecureString direkt anhand benutzerspezifischen Eingaben in Echtzeit zu erstellen, damit das Kennwort auf keinen Fall in Klartext im Arbeitsspeicher gespeichert wird. Dies trägt dazu bei, eine Reihe von Sicherheitsrisiken zu entschärfen. In der Praxis ist es jedoch üblich, für Prototypen die oben beschriebene Vorgehensweise zu verwenden.

Objekte ermitteln

Sobald die CimSession-Sitzung eingerichtet ist, können Sie Windows Management Instrumentation (WMI) im Cluster abfragen.

Bevor Sie Fehler oder Metriken abrufen können, müssen Sie Instanzen mehrerer relevanter Objekte abrufen. Rufen Sie zuerst MSFT_StorageSubSystem ab, das „Direkte Speicherplätze“ im Cluster darstellt. Damit können Sie jeden MSFT_StorageNode im Cluster und jedes MSFT_Volume der Datenvolumes abrufen. Schließlich müssen Sie MSCluster_ClusterHealthService, den Integritätsdienst selbst, abrufen.

CimInstance Cluster;
List<CimInstance> Nodes;
List<CimInstance> Volumes;
CimInstance HealthService;

public void DiscoverObjects(CimSession Session)
{
    // Get MSFT_StorageSubSystem for Storage Spaces Direct
    Cluster = Session.QueryInstances(@"root\microsoft\windows\storage", "WQL", "SELECT * FROM MSFT_StorageSubSystem")
        .First(Instance => (Instance.CimInstanceProperties["FriendlyName"].Value.ToString()).Contains("Cluster"));

    // Get MSFT_StorageNode for each cluster node
    Nodes = Session.EnumerateAssociatedInstances(Cluster.CimSystemProperties.Namespace,
        Cluster, "MSFT_StorageSubSystemToStorageNode", null, "StorageSubSystem", "StorageNode").ToList();

    // Get MSFT_Volumes for each data volume
    Volumes = Session.EnumerateAssociatedInstances(Cluster.CimSystemProperties.Namespace,
        Cluster, "MSFT_StorageSubSystemToVolume", null, "StorageSubSystem", "Volume").ToList();

    // Get MSFT_StorageHealth itself
    HealthService = Session.EnumerateAssociatedInstances(Cluster.CimSystemProperties.Namespace,
        Cluster, "MSFT_StorageSubSystemToStorageHealth", null, "StorageSubSystem", "StorageHealth").First();
}

Dies sind die gleichen Objekte, die Sie in PowerShell mit Cmdlets wie Get-StorageSubSystem, Get-StorageNode und Get-Volume abrufen.

Sie können auf die gleichen Eigenschaften zugreifen, die unter Klassen der Speicherverwaltungs-API dokumentiert sind.

using System.Diagnostics;

foreach (CimInstance Node in Nodes)
{
    // For illustration, write each node's Name to the console. You could also write State (up/down), or anything else!
    Debug.WriteLine("Discovered Node " + Node.CimInstanceProperties["Name"].Value.ToString());
}

Abfragefehler

Rufen Sie Diagnose auf, um alle aktuellen Fehler für das Ziel CimInstance abzurufen. Hierbei kann es sich entweder um den Cluster oder um ein beliebiges Volume handeln.

public void GetFaults(CimSession Session, CimInstance Target)
{
    // Set Parameters (None)
    CimMethodParametersCollection FaultsParams = new CimMethodParametersCollection();
    // Invoke API
    CimMethodResult Result = Session.InvokeMethod(Target, "Diagnose", FaultsParams);
    IEnumerable<CimInstance> DiagnoseResults = (IEnumerable<CimInstance>)Result.OutParameters["DiagnoseResults"].Value;
    // Unpack
    if (DiagnoseResults != null)
    {
        foreach (CimInstance DiagnoseResult in DiagnoseResults)
        {
            // TODO: Whatever you want!
        }
    }
}

Optional: MyFault-Klasse

Es kann sinnvoll sein, eine eigene Darstellung von Fehlern zu erstellen und beizubehalten. Beispielsweise speichert die Klasse MyFault-Klasse verschiedene wichtige Fehlereigenschaften, darunter auch die FaultId. Diese kann später dazu genutzt werden, um Updates zu verknüpfen, Benachrichtigungen zu entfernen oder zu deduplizieren, wenn derselbe Fehler mehrmals erkannt wird.

public class MyFault {
    public String FaultId { get; set; }
    public String Reason { get; set; }
    public String Severity { get; set; }
    public String Description { get; set; }
    public String Location { get; set; }

    // Constructor
    public MyFault(CimInstance DiagnoseResult)
    {
        CimKeyedCollection<CimProperty> Properties = DiagnoseResult.CimInstanceProperties;
        FaultId     = Properties["FaultId"                  ].Value.ToString();
        Reason      = Properties["Reason"                   ].Value.ToString();
        Severity    = Properties["PerceivedSeverity"        ].Value.ToString();
        Description = Properties["FaultingObjectDescription"].Value.ToString();
        Location    = Properties["FaultingObjectLocation"   ].Value.ToString();
    }
}
List<MyFault> Faults = new List<MyFault>;

foreach (CimInstance DiagnoseResult in DiagnoseResults)
{
    Faults.Add(new Fault(DiagnoseResult));
}

Die vollständige Liste der Eigenschaften in jedem Fehler (DiagnoseResult) finden Sie weiter unten im Abschnitt Fehlereigenschaften.

Fehlerereignisse

Wenn Fehler erstellt, entfernt oder aktualisiert werden, generiert der Integritätsdienst WMI-Ereignisse. Diese sind notwendig, um den Zustand Ihrer Anwendung ohne häufige Abfragen synchron zu halten, und können z. B. dabei helfen, den Zeitpunkt für das Versenden von E-Mail-Warnungen zu bestimmen. Um diese Ereignisse zu abonnieren, verwendet der folgende Beispielcode das Observer-Entwurfsmuster.

Abonnieren Sie zunächst MSFT_StorageFaultEvent-Ereignisse.

public void ListenForFaultEvents()
{
    IObservable<CimSubscriptionResult> Events = Session.SubscribeAsync(
        @"root\microsoft\windows\storage", "WQL", "SELECT * FROM MSFT_StorageFaultEvent");
    // Subscribe the Observer
    FaultsObserver<CimSubscriptionResult> Observer = new FaultsObserver<CimSubscriptionResult>(this);
    IDisposable Disposeable = Events.Subscribe(Observer);
}

Implementieren Sie dann einen Observer, dessen OnNext()-Methode immer dann aufgerufen wird, wenn ein neues Ereignis generiert wird.

Jedes Ereignis enthält einen ChangeType-Wert, der angibt, ob ein Fehler erstellt, entfernt oder aktualisiert wird. Außerdem gibt er die relevante FaultId an.

Darüber hinaus umfasst jedes Ereignis alle Eigenschaften des Fehlers selbst.

class FaultsObserver : IObserver
{
    public void OnNext(T Event)
    {
        // Cast
        CimSubscriptionResult SubscriptionResult = Event as CimSubscriptionResult;

        if (SubscriptionResult != null)
        {
            // Unpack
            CimKeyedCollection<CimProperty> Properties = SubscriptionResult.Instance.CimInstanceProperties;
            String ChangeType = Properties["ChangeType"].Value.ToString();
            String FaultId = Properties["FaultId"].Value.ToString();

            // Create
            if (ChangeType == "0")
            {
                Fault MyNewFault = new MyFault(SubscriptionResult.Instance);
                // TODO: Whatever you want!
            }
            // Remove
            if (ChangeType == "1")
            {
                // TODO: Use FaultId to find and delete whatever representation you have...
            }
            // Update
            if (ChangeType == "2")
            {
                // TODO: Use FaultId to find and modify whatever representation you have...
            }
        }
    }
    public void OnError(Exception e)
    {
        // Handle Exceptions
    }
    public void OnCompleted()
    {
        // Nothing
    }
}

Grundlegendes zum Fehlerlebenszyklus

Fehler sind nicht dazu gedacht, vom Benutzer als „gesehen“ oder „gelöst“ markiert zu werden. Sie werden erstellt, wenn der Integritätsdienst ein Problem ermittelt, und sie werden erst dann automatisch entfernt, wenn der Integritätsdienst das Problem nicht mehr feststellen kann. Im Allgemeinen spiegelt dies wider, dass das Problem behoben wurde.

In einigen Fällen kann es jedoch vorkommen, dass der Integritätsdienst Fehler erneut ermittelt, z. B. nach einem Failover, bei einer unterbrochenen Verbindung usw. Aus diesem Grund kann es sinnvoll sein, Ihre eigene Darstellung von Fehlern dauerhaft zu speichern, um sie problemlos deduplizieren zu können. Dies ist besonders wichtig, wenn Sie E-Mail-Warnungen oder ähnliches senden.

Fehlereigenschaften

Die folgende Tabelle zeigt verschiedene wichtige Eigenschaften des Fehlerobjekts. Das vollständige Schema finden Sie in der Klasse MSFT_StorageDiagnoseResult in storagewmi.mof.

Property Beispiel
Fehler-ID {12345-12345-12345-12345-12345}
Fehlertyp Microsoft.Health.Fehlertyp.Volumen.Kapazität
`Reason` „Auf dem Volume ist kaum noch Speicherplatz verfügbar.“
PerceivedSeverity 5
Fehlerobjektbeschreibung Contoso XYZ9000 Seriennummer 123456789
Fehlerhafte Objektposition Rack A06, RU 25, Slot 11
Empfohlene Aktionen {"Erweitern Sie das Volume, oder migrieren Sie Workloads zu anderen Volumes."}

FaultId: Eindeutige ID innerhalb des Bereichs eines Clusters.

PerceivedSeverity PerceivedSeverity = { 4, 5, 6 } = { „Information“, „Warnung“ und „Fehler“ } oder entsprechende Farben wie Blau, Gelb und Rot.

FaultingObjectDescription Teilinformationen für Hardware, für Softwareobjekte in der Regel leer.

FaultingObjectLocation: Standortinformationen für Hardware, für Softwareobjekte in der Regel leer.

RecommendedActions: Liste der empfohlenen Maßnahmen, unabhängig und in keiner bestimmten Reihenfolge. Derzeit hat diese Liste häufig die Länge 1.

Eigenschaften von Fehlerereignissen

Die folgende Tabelle zeigt verschiedene wichtige Eigenschaften des Fehlerereignisses. Das vollständige Schema finden Sie in der Klasse MSFT_StorageFaultEvent in storagewmi.mof.

Hinweis: ChangeType gibt an, ob ein Fehler erstellt, entfernt oder aktualisiert wird. Außerdem wird die FaultId angegeben. Ein Ereignis enthält auch alle Eigenschaften des betroffenen Fehlers.

Property Beispiel
Änderungstyp 0
Fehler-ID {12345-12345-12345-12345-12345}
Fehlertyp Microsoft.Health.Fehlertyp.Volumen.Kapazität
`Reason` „Auf dem Volume ist kaum noch Speicherplatz verfügbar.“
PerceivedSeverity 5
Fehlerobjektbeschreibung Contoso XYZ9000 Seriennummer 123456789
Fehlerhafte Objektposition Rack A06, RU 25, Slot 11
Empfohlene Aktionen {"Erweitern Sie das Volume, oder migrieren Sie Workloads zu anderen Volumes."}

ChangeType: ChangeType = { 0, 1, 2 } = { "Create", "Remove", "Update" }.

Referenz zu Gesundheitsdienstfehlern

Der Health Service in Azure Local und Windows Server kann Fehler in verschiedenen Systemkomponenten erkennen, einschließlich Speicher, Netzwerk und Rechenressourcen.

Für eine detaillierte Übersicht über Gesundheitsfehler, einschließlich Zuordnungen der Fehlerschwere, Gesundheitseinstellungen (Datentypen, Fehlerzuordnungen, Standardwerte und Beschreibungen) und die Liste der gesammelten Metriken, laden Sie die Fehlertabelle für den Gesundheitsdienst herunter.

Überlegungen zu Gesundheitsdienststörungen

  • Einige Fehler sind standardmäßig deaktiviert. Um einen Fehler zu aktivieren, legen Sie die entsprechende Einstellung für den Zustand auf TRUE fest. Der Fehlertyp Microsoft.Health.FaultType.PhysicalDisk.HighLatency.AverageIO ist standardmäßig deaktiviert. Legen Sie zum Aktivieren die Gesundheitseinstellung System.Storage.PhysicalDisk.HighLatency.Threshold.Tail.Enabled auf "true" fest.

  • Der Zustand von Speichergehäusekomponenten, wie Lüftern, Netzteilen und Sensoren, wird aus den SCSI-Gehäusediensten (SES) abgeleitet. Wenn Ihr Anbieter diese Informationen nicht bereitstellt, kann der Gesundheitsdienst sie nicht anzeigen.

Weitere Verweise