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.

Überprüfung des Benachrichtigungsstatus

Beitragende netapp-alavoie
Änderungen vorschlagen

Mithilfe dieses Rezepts lässt sich nachvollziehen, wie DII Warnungen weitergeleitet und unterdrückt werden, ohne Webhook-Endpunktadressen offenzulegen.

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

Voraussetzungen

  • Zugriff auf Benachrichtigungs- und Wartungsfenster-Tools.

  • Ein optionaler Monitor-, Ressourcen- oder Integrationstyp zur Eingrenzung der Überprüfung.

Verwendete Tools

  • NotificationService_getNotificationRules

  • NotificationService_getNotificationRuleById

  • NotificationService_getWebhooks

  • MaintenanceWindowService_getMaintenanceWindows

  • MaintenanceWindowService_getMaintenanceWindowById

  • Optional: MonitorsService_queryMonitors

Starter-Prompt

Der Status der DII-Benachrichtigungen ist zu überprüfen. Zusammenzufassen sind aktive und inaktive Benachrichtigungsregeln, der Monitor- oder Ressourcenbereich jeder Regel, die Anzahl der Webhook-Ziele nach Integrationstyp und die aktuellen Wartungsfenster. Es sind nur Zielnamen, Engine-Typen und Status zurückzugeben, niemals Endpunktadressen.

Agent Workflow

  1. Benachrichtigungsregeln auflisten.

  2. Regeln lassen sich als aktiv, inaktiv, ablaufend oder ohne Ablaufdatum klassifizieren.

  3. Zusammenfassung des Geltungsbereichs jeder Regel:

    • Name oder Gruppe des Monitors

    • Zugehöriges Objekt

    • Breiter Wildcard-Bereich

  4. Eine bestimmte Regel wird nur dann abgerufen, wenn zusätzliche Details erforderlich sind.

  5. Die Webhook-Ziele werden aufgelistet, und das Adressfeld wird sofort aus dem Arbeitsergebnis entfernt.

  6. Ziele nach Engine-Typ und Status gruppieren.

  7. Aktive Wartungsfenster werden aufgelistet.

  8. Unterdrückungsfenster, die sich mit wichtigen Ressourcen oder ungewöhnlich langen Zeiträumen überschneiden, werden identifiziert.

  9. Optional können Regelausdrücke mit verfügbaren Monitoren verglichen werden.

  10. Bericht über Routingabdeckung, allgemeine Regeln, inaktive Regeln und Unterdrückungsrisiken.

Sicherheitsanforderung

Vollständige Webhook-Adressen können Folgendes enthalten:

  • Slack oder Teams Signaturpfade

  • PagerDuty Routing-Schlüssel

  • API Tokens

  • Eindeutige Workflow-Signaturen

  • Benutzerdefinierte Integrationsanmeldedaten

Das Adressfeld darf niemals angezeigt, zitiert, zusammengefasst, gespeichert oder weitergeleitet werden. Ein maskiertes Suffix ist für diesen Workflow ebenfalls nicht erforderlich.

Wenn ein vollständiger Endpunkt in einem Transkript oder einem freigegebenen Artefakt erscheint, sind die Schritte zum Vorfall in "Sicherheit und Datenschutz" zu befolgen.

Interpretation

  • Eine inaktive Regel kann beabsichtigt sein; vor einer Empfehlung zur Entfernung sollte die Zuständigkeit bestätigt werden.

  • Ein weit gefasster Platzhalterausdruck kann zu Benachrichtigungsrauschen oder unbeabsichtigtem Routing führen.

  • Ein Zielstatus kann null oder unbekannt sein; er darf nicht als aktiviert gemeldet werden.

  • Ein erfolgreiches Ergebnis für ein leeres Wartungsfenster bedeutet, dass keine übereinstimmenden Fenster vorhanden sind.

  • Ein langlebiges Fenster kann reale Probleme verschleiern, selbst wenn es technisch aktiv und gültig ist.

Empfohlene Ausgabe

  1. Anzahl der Regeln nach Status

  2. Regelbereich und Zieltyp

  3. Zielanzahlen nach Engine

  4. Aktive Wartungsfenster

  5. Weit gefasste, inaktive oder mehrdeutige Konfigurationen

  6. Sicherheits- und Datenqualitätshinweise

Grenzen und Datenschutz

  • Adressen, Token, UUIDs oder private Ressourcenkennungen dürfen nicht zurückgegeben werden.

  • Dieser Workflow überprüft die Konfiguration, testet aber nicht die Nachrichtenzustellung.

  • Mit den aktuellen Tools können Regeln und Ziele weder erstellt, aktualisiert, deaktiviert noch gelöscht werden.

Folgefragen

Welche aktiven Benachrichtigungsregeln verfügen über breite Platzhalterausdrücke, und mit welchen Überwachungsgruppen können sie übereinstimmen?

Aktuelle und anstehende Wartungsfenster sowie die von ihnen unterdrückten Alarmbereiche werden aufgelistet und erläutert.

Benachrichtigungsziele werden nach Integrationstyp gezählt, und Ziele mit unbekanntem Status werden identifiziert. Adressen werden nicht angezeigt.