Alarme und Benachrichtigungen

SPOT trennt Untersuchung und Konfiguration:

• Globales Alerts ist ein schreibgeschütztes Kontrollzentrum für Viewer und Admins.
• Konfiguration → Alerts enthält Konnektoren, Regeln und ML-Abdeckung; Änderungen erfordern Admin-Rechte.

Das Kontrollzentrum verwendet dieselben Flächen, Tabellen, Auswahlzustände und Suche wie die anderen operativen Ansichten. Die Suche kann geleert oder mit Enter angewendet werden und bleibt responsive. Die Seite beginnt direkt mit Alert Control Center, ohne vorangestellte technische Kennzeichnung. Es hat zwei Ansichten:

Kontrollzentrum mit operativen SPOT-Flächen im dunklen Theme.

Dieselbe visuelle Hierarchie und Auswahl im hellen Theme.

• Active wird standardmäßig geöffnet und enthält alle Vorfälle im Zustand pending oder firing, auch wenn keine Benachrichtigungsregel existiert.
• History bewahrt frühere Zustände, Recoveries, Timeline und Zustellungen.

SPOT erkennt einen Vorfall anhand der effektiven Schwellwerte je Quelle, Metrik, Parametersatz, Serie und Host. Regeln erzeugen den Vorfall nicht: Sie bestimmen nur, welche Vorfälle über welchen Konnektor benachrichtigt werden. Das Detail zeigt Target-Namen, Metrik, Serie/Host, Istwert, statische Schwellwerte, ML-Score und -Status, einen verständlichen Grund und verknüpfte Benachrichtigungswege. Open in Metrics Explorer setzt die Untersuchung mit der betroffenen Metrik fort.

Die Richtung gehört zum Metrikvertrag: Meist sind höhere Werte schlechter, bei freier Kapazität und Hit Ratios dagegen niedrigere Werte. mssql-file-free-percent behandelt beispielsweise Warning 15 % und Critical 5 % als Untergrenzen; 98 % frei ist gesund.

Konnektoren

In SaaS steht der plattformverwaltete Konnektor SPOT Email bereit. Regeln dürfen ihn verwenden, Mandanten können ihn aber weder ändern noch löschen. Die E-Mail-Empfänger werden pro Regel festgelegt. On-Prem unterstützt mehrere E-Mail-Konnektoren:

• Generisches SMTP mit STARTTLS.
• Microsoft 365 Relay über MX und Port 25, identifiziert durch öffentliche IP oder Client-Zertifikat.
• Microsoft 365 OAuth2 über smtp.office365.com:587 mit Entra-Tenant, Client-ID und Client-Secret.

Verwende für Microsoft 365 keine Benutzername/Passwort-Anmeldung. Test prüft TLS, Authentifizierung und eine echte Zustellung.

Webhooks unterstützen POST oder PUT, Timeout, nicht sensible Header, eine freigegebene JSON-Vorlage, Basic-, Bearer- oder Secret-Header-Authentifizierung, private CA und mTLS. Die URL darf keine Zugangsdaten, Query-Parameter oder Fragmente enthalten; für die Authentifizierung ist das nur schreibbare Secret-Objekt zu verwenden. SaaS verlangt öffentliches HTTPS und sperrt private, Loopback-, Link-Local- und Metadata-Ziele. On-Prem darf interne Ziele erreichen; HTTP oder unsicheres TLS muss ausdrücklich aktiviert werden.

Secrets sind nur schreibbar und werden nach dem Speichern nicht zurückgegeben. SPOT behält ein gespeichertes Secret nur bei, solange Konnektortyp, Netzwerkziel und Authentifizierungsidentität unverändert bleiben. Ändern sich Webhook-URL oder Authentifizierungsart beziehungsweise Preset, Server, Port, TLS oder OAuth-/SMTP-Identität eines E-Mail-Konnektors, muss der vollständige Zugangssatz neu eingegeben werden. Eine Maske oder ein leeres Feld erlaubt nicht, das vorherige Secret an das neue Ziel weiterzugeben.

Benachrichtigungsregel erstellen und aktivieren

1. Wähle alle alarmierbaren Metriken, eine Operations-Domäne oder einzelne Metriken.
2. Begrenze optional Quellen/Targets und Hosts. Ohne Auswahl gelten alle.
3. Wähle Static, ML oder Static + ML.
4. Für beide Bedingungen wähle Any (OR), den Standard, oder All (AND).
5. Wähle mindestens einen Konnektor und speichere den Entwurf.
6. Prüfe die Vorschau: SPOT listet passende aktive Vorfälle und die erwartete Anzahl E-Mails oder Webhooks je Serie und Host.
7. Aktiviere mit Future only, um nur spätere Übergänge zu melden, oder mit Notify current, um bereits bestehende firing-Treffer einzuschließen.

Die Regel verwendet die effektiven Schwellwerte je Metrik und Quelle. Werte werden nicht in die Regel kopiert; Änderungen unter Thresholds gelten ab der nächsten Auswertung.

Wenn mehrere aktive Regeln denselben Vorfall treffen, behält jede Regel ihren eigenen Benachrichtigungsweg. Die Vorschau macht diese Überschneidung vor der Aktivierung sichtbar. Bei mehr als 20 aktuellen Treffern ist eine ausdrückliche Bestätigung erforderlich.

Alarmlebenszyklus

• pending: Die Bedingung ist neu aufgetreten und bereits unter Active sichtbar.
• firing: ML benötigt 2 unterschiedliche anomale Beobachtungen über mindestens 5 Minuten; ein Score-100-Ereignis mit extremer Auswirkung darf mit einer öffnen.
• unknown: Daten fehlen; Erinnerungen werden ausgesetzt.
• resolved: 2 gesunde Auswertungen wurden beobachtet.

Die Identität eines Vorfalls kombiniert Quelle, Metrik, Parametersatz, Serie und Host und hängt nicht von einer Regel ab. Eine aktive Regel erinnert standardmäßig stündlich an einen offenen Alarm und sendet eine Recovery-Nachricht. Jede Zustellung wird nach Regel, Vorfall, Vorfallgeneration, Übergang und Serie/Host dedupliziert; Wiederholungen erzeugen kein zweites Ereignis.

Persistenz schreitet nur bei einer neuen Beobachtung fort. Das erneute Lesen desselben Buckets öffnet nicht früher und dupliziert keinen Vorfall. Auch die Richtung zählt: Eine Verbesserung außerhalb des erwarteten Musters löst ML nicht aus.

Zustellungen verwenden eine idempotente Queue mit Wiederholungen. Webhooks erhalten stabile Header Idempotency-Key und X-SPOT-Delivery-ID; E-Mails verwenden eine stabile Message-ID. Im Alarmdetail stehen Status, Versuchszahl und bereinigte Fehler. Ein von einer aktiven Regel verwendeter Konnektor kann nicht gelöscht werden.

Inhalt der E-Mail

E-Mails verwenden eine SPOT-HTML-Vorlage mit eingebettetem Logo und einer Textalternative. Betreff und Kopfzeile nennen Schweregrad, Metrik, Target-Namen und Serie oder Host; die technische Target-ID ersetzt den Namen nicht. Wiederherstellungen tragen einen grünen RESOLVED-Betreff und Badge, auch wenn der vorherige Vorfall kritisch war.

Wenn historische Daten verfügbar sind, enthält die Nachricht eine per CID eingebettete Grafik der letzten 12 Stunden mit Istwerten, effektiven Schwellwerten, ML-Evidenz und dem auslösenden Punkt. Dies gilt auch für Vorfälle, die über Notify current einbezogen werden. Eine flache Serie wird mit Abstand zentriert und als Constant gekennzeichnet; Wert, Bereich, Anzahl der Messpunkte und Schwellwerte verhindern, dass sie wie eine leere Grafik wirkt. Kann der Verlauf nicht geladen werden, wird die Nachricht trotzdem zugestellt und weist auf die nicht verfügbare Grafik hin.

hinweis

ML-Regeln bewerten beobachtete Scores. Prädiktive Alarme auf Forecast-Basis sind noch nicht verfügbar.