Skip to main content
Data Infrastructure Insights
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Leistungsprobleme beheben

Beitragende netapp-alavoie
Änderungen vorschlagen
PDFs

Mit diesem Rezept lässt sich ein langsames Volume, ein Datenspeicher, eine virtuelle Maschine, eine Kubernetes Workload oder ein anderes DII Objekt untersuchen, indem Leistungsmetriken, Warnmeldungen und Plattformprotokolle korreliert werden.

Hinweis Der DII MCP ist eine "Vorschau" Funktion und kann sich daher ändern.

Voraussetzungen

  • Name der betroffenen Ressource und ungefähre Uhrzeit des Vorfalls.

  • Ein Zeitraum von 30 Tagen oder weniger.

  • Wenn möglich ein Vergleichszeitraum oder ein bekannter gesunder Ausgangswert.

Verwendete Tools

  • ObjectService_getObjectTypes

  • ObjectService_getMetadataForObjectType

  • ObjectService_query

  • ObjectService_queryPerformanceMetricsForObjects

  • ObjectService_groupObjects

  • AlertsService_getMetadata

  • AlertsService_queryForAlerts

  • LogService_getLogTypes

  • LogService_getLogTypeMetadata

  • LogService_queryLogEvents

Starter-Prompt

Untersuchen Sie die Ursache dafür, dass das Volume example-volume zwischen 09:00 und 11:00 UTC langsam war. Ermitteln Sie den korrekten Objekttyp und die gültigen Metriken, vergleichen Sie Latenz, IOPS und Durchsatz im Zeitraum des Vorfalls, prüfen Sie zugehörige aktive Warnmeldungen und Plattformprotokolle und vergleichen Sie dies mit einem fehlerfreien Zeitraum. Trennen Sie Belege von Hypothesen und ermitteln Sie die nächste erforderliche Messung.

Agent Workflow

  1. Die Ressource wird einem exakten Objekttyp und einer exakten Identität zugeordnet.

  2. Metadaten für diesen Objekttyp werden abgerufen.

  3. Gültige Kennzahlen für Latenz, Operationen, Durchsatz, Auslastung und Kapazität.

  4. Abfrage der aktuellen Objektattribute zur Ermittlung von Platzierung und Beziehungen.

  5. Zeitreihen abrufen über:

    • Das Vorfallfenster

    • Ein vergleichbares intaktes Zeitfenster

  6. Zeitstempel und Aggregationsfunktionen über Metriken hinweg angleichen.

  7. Warnmeldungen abrufen, die sich auf die Ressource beziehen und System, Host, Knoten oder Speicherpool enthalten.

  8. Wählen Sie relevante Log-Streams aus, rufen Sie Metadaten ab und durchsuchen Sie ein enges Intervall um Metrikänderungen.

  9. Plausible Hypothesen testen:

    • Nachfrageanstieg

    • Ressourcensättigung

    • Storage- oder Fabric-Fehler

    • Kapazitätsdruck

    • Host- oder VM-Konflikte

    • Erfassungslücke

  10. Die am besten belegte Erklärung und die noch offenen Alternativen sind zu melden.

Beweisstandards

Erkenntnisse kennzeichnen:

  • Beobachtet: direkt von einem Tool zurückgegeben.

  • Korreliert: Unabhängige Signale haben sich im selben Intervall geändert.

  • Abgeleitet: eine plausible Erklärung, die noch nicht bewiesen ist.

  • Unbekannt: erforderliche Nachweise sind nicht verfügbar.

Korrelation ist nicht gleich Kausalität. Ein gleichzeitig auftretender Alarm sollte als Indiz, nicht als Beweis, gelten, solange der zugrunde liegende Mechanismus nicht geklärt ist.

Metrikanleitung

  • Verwenden Sie AVG`für das allgemeine Verhalten, aber prüfen Sie `MAX, wenn kurze Spitzenwerte wichtig sind.

  • Verwenden Sie `SUM`nur für additive Kennzahlen.

  • Verwendet wird CHANGE oder CHANGE_RATIO für Zähler oder Wachstum, sofern die Metadaten dies unterstützen.

  • Der Vergleich von Reihen mit unterschiedlichen Bucket-Grenzen oder Einheiten sollte vermieden werden.

  • Filter werden vor der Zeitbucket-Aggregation angewendet.

Empfohlene Ausgabe

  1. Umfang und Zeitplan des Vorfalls

  2. Metrische Nachweise

  3. Warnungs- und Protokollnachweise

  4. Vergleich mit einem fehlerfreien Zeitraum

  5. Wahrscheinlichste Erklärung

  6. Alternative Hypothesen

  7. Vertrauen und fehlende Nachweise

  8. Empfohlene nächste Überprüfung

Grenzen und Datenschutz

  • Zeitreihenfenster dürfen 30 Tage nicht überschreiten.

  • Das Performance Tool gibt eine begrenzte Anzahl von Datenreihen zurück; der Filter sollte eingegrenzt werden, bevor das Limit erhöht wird.

  • Empfindliche Rohprotokollfelder, die nicht zur Diagnose beitragen, sollten weggelassen werden.

  • Es sollten keine disruptiven Sanierungsmaßnahmen vorgeschlagen werden, ohne sie zuvor anhand normaler betrieblicher Kontrollen zu validieren.

Folgefragen

Die maximale und die durchschnittliche Latenzzeit während des Vorfalls im Vergleich zur gleichen Stunde am vorherigen fehlerfreien Tag.

Zusammengehörige Workloads werden nach Host oder Speicherpool gruppiert, und es wird ermittelt, ob die Verlangsamung isoliert auftrat oder gemeinsam genutzt wurde.

Die Plattformereignisse werden innerhalb von 15 Minuten nach dem ersten Anstieg der Latenz angezeigt.

"Zurück zu den Rezepten"