Organization
Gesamtzustand, standortübergreifende Trends, Inventar und Alarmpriorität.
1. Lernziele
- Telemetrie, Event, Alert, SLE und Marvis Action unterscheiden
- Überwachung über Wireless, Wired und WAN strukturieren
- Alerts nach Kategorie und Severity einordnen
- Templates, Scope, Empfänger und Schwellenwerte konfigurieren
- Wartungsfenster mit Pause Rules abbilden
- Marvis Alerts und Actions korrekt korrelieren
- Webhooks betriebssicher in NOC/ITSM integrieren
- False Positives, Flapping und Alarmfluten reduzieren
- Alarm-Lifecycle und Eskalation definieren
- Alarmqualität über messbare KPIs bewerten
Leitfrage: Ist das Signal eine Beobachtung, eine laufende Störung, eine verletzte Nutzererwartung oder eine durch AI korrelierte Handlungsempfehlung?
2. Das Signalmodell
Telemetrie→Event→Aggregation/Schwelle→Alert→Korrelation→Action→Validierung
Nutzbares Monitoring = Erkennung + Kontext + Priorität + Zuständigkeit + Reaktion + Abschlussnachweis
Die Ebenen können parallel auftreten. Ein einzelner Port-Flap kann als Event sichtbar sein, wiederholte Ausfälle als Alert erscheinen und bei ausreichender Evidenz in eine Marvis Action eingehen.
3. Event, Alert, SLE und Action
| Objekt | Frage | Charakter |
|---|---|---|
| Telemetry | Welcher Messwert liegt vor? | kontinuierlicher Roh-/Statistikwert |
| Event | Was geschah zu einem Zeitpunkt? | einzelne Zustandsänderung/Beobachtung |
| Alert | Welches überwachte Problem besteht oder wiederholt sich? | Schwelle, Zustand oder wiederholte Events |
| SLE | Wie gut war die Nutzererfahrung? | Erfolgsrate gegen Erwartung |
| Potential Anomaly | Was weicht auffällig ab? | früher AI-Hinweis |
| Marvis Action | Was ist relevant und was soll getan werden? | korrelierte, priorisierte AIOps-Aussage |
Juniper-Hinweis: Marvis Actions ersetzen Alerts ausdrücklich nicht. Alerts reagieren ereignisnah; Actions benötigen je Modell genügend Daten für belastbare Korrelation.
4. Datenquellen und Beobachtungspunkte
| Domäne | Beispiele | Typische Aussage |
|---|---|---|
| Wireless | Association, Auth, DHCP, RSSI, Retry, RRM | Client- und RF-Erfahrung |
| Wired | Port, PoE, VLAN, LLDP, CPU, Kabel, Auth | Zugangspfad und Switchzustand |
| WAN | Uplink, Tunnel, Jitter, Loss, App, Routing | Client-to-Cloud und Edge |
| Mist Edge | Ressourcen, Tunnel, PSU, Service, RADIUS | Datapath-/Proxy-Zustand |
| Security | Rogue, Honeypot, Spoofing, Attack Events | Sicherheitsbeobachtung |
| Certificates | RadSec, SSO, PSK-Portal-IDP | Ablaufvorsorge |
| Location | Assets, Zones, SDK, RSSI | Position und Bewegung |
5. Dashboards als Überblick
Site
Full-Stack-Kontext für Wireless, Wired, WAN, Clients, Apps und Events.
Entity
AP, Switch, WAN Edge, Client oder Anwendung mit Zeitverlauf und Details.
Ein Dashboard ist ein Einstieg, kein vollständiger Beweis. Der Drill-down verbindet Aggregat, betroffene Objekte, Zeitachse und Rohereignisse.
6. Insights
Insights liefert Status, Timeline, Traffic, Events und Verbindungsdetails für Sites, Geräte und Clients. Es ist die zentrale Belegansicht, wenn ein Alert zeitlich und technisch eingeordnet werden muss.
| Alertdaten | Insights-Beleg |
|---|---|
| First/Last Seen | Timeline und korrelierte Events |
| Site/Device | Entity Health und Nachbarn |
| Connectivity Failure | Association/Auth/DHCP/DNS-Phasen |
| Offline | Cloudstatus, Restart, Switch/WAN-Kontext |
| Security | Detektionsereignis und Funkkontext |
7. Service Level Expectations
SLEs bewerten die Nutzererfahrung gegen definierte Schwellen. Classifier ordnen den nicht erfolgreichen Anteil Ursachenklassen zu.
SLE-Erfolg = erfolgreiche relevante Vorgänge ÷ alle relevanten Vorgänge im Scope
| SLE-Sicht | Alarm-Sicht |
|---|---|
| Outcome über Nutzer-Minuten/Vorgänge | konkretes überwachtetes Problem |
| Trend und Erfolgsrate | Severity, First/Last Seen, Recurrence |
| Classifier für Fehlanteil | Alerttyp und Details |
| kann Einzelfälle aggregieren | kann ohne breiten SLE-Abfall relevant sein |
8. Events
Events sind zeitgebundene Einzelbeobachtungen wie Device Down, Restart, Port Up/Down oder Konfigurationsänderungen. Nicht jedes Event soll alarmieren.
| Eventtyp | Monitoring-Frage |
|---|---|
| State Change | Ist Gegenereignis/Recovery vorhanden? |
| Audit | Wer änderte wann welches Objekt? |
| Device Event | einmalig oder wiederkehrend? |
| Client Event | isolierter Client oder gemeinsame Ursache? |
| Location Event | Aggregation enthält mehrere Einzelereignisse? |
Eine Alarmstrategie, die jedes Event als Ticket behandelt, erzeugt Noise statt Betriebssicherheit.
9. Alerts: laufende oder wiederkehrende Probleme
Juniper definiert Alerts als Netzwerk- oder Geräteprobleme, die fortbestehen beziehungsweise aus wiederholten Ereignissen entstehen. Sie erscheinen unter Monitor → Alerts, sofern der Alerttyp im wirksamen Template aktiviert ist.
Alert Type aktiviert+Scope+Trigger/Threshold→Alerts Dashboard+E-Mail/Webhook optional
10. Alert-Kategorien
| Kategorie | Charakter | Beispiel |
|---|---|---|
| Infrastructure | häufig direkt aus Device-/Service-Events; teils zustandslos | Device offline, DHCP/DNS, PSU |
| Marvis | mit Marvis Actions verbunden, häufig zustandsbehaftet | Bad Cable, Coverage, MTU |
| Security | meist einzelne Detektion, nicht zwingend aktiver Angriff | Rogue AP, Honeypot, KRACK |
| Certificate | zeitgesteuerte Ablaufwarnung | RadSec-/SSO-Zertifikat |
Zustandsmodell beachten: Infrastructure Events und Security-Detektionen brauchen im empfangenden NOC häufig eigene Korrelations- und Abschlusslogik.
11. Severity
| Farbe | Severity | Betriebliche Interpretation |
|---|---|---|
| Rot | Critical | unmittelbar auf Auswirkung und Eskalationsregel prüfen |
| Orange | Warning | zeitnah bewerten, Trend/Scope beachten |
| Blau | Informational | Kontext/Audit; nicht automatisch Ticket |
Hersteller-Severity ist Eingangswert. Die betriebliche Priorität entsteht zusätzlich aus Business Impact, Scope, Redundanz, Uhrzeit, Nutzerzahl und Wiederholungsrate.
Ticketpriorität = technische Severity × Business Impact × Scope × Dringlichkeit
12. Alerts Dashboard
Das Dashboard zeigt aktivierte Alerts mit Typ, Site, Severity, First Seen, Last Seen, Wiederholungen und Details. Filter und Zeitraum unterstützen die Eingrenzung.
| Feld | Frage |
|---|---|
| First Seen | Wann begann das Problem? |
| Last Seen | Ist es aktuell oder nur kürzlich beobachtet? |
| Recurrence | Flapping oder dauerhafter Zustand? |
| Site/Device | lokal, gemeinsam oder organisationsweit? |
| Details/Insights | Welche technische Evidenz liegt vor? |
13. Alert Templates
Jede Organisation besitzt ein Default Template. Zusätzliche Templates können nach Standort, Personal, Kritikalität oder Zweck erstellt und kopiert werden.
| Template-Inhalt | Beispiel |
|---|---|
| Name/Zweck | 24x7-Critical-Sites |
| Scope | Entire Org oder ausgewählte Sites |
| Alert Types | Infrastructure, Marvis, Security, Certificate |
| Dashboard | Enable Alert |
| Benachrichtigung | Send Email Notification |
| Recipients | Org-/Site-Admins und weitere Empfänger |
Mist Recommended Alerts liefern eine Ausgangsbasis. Änderungen werden dokumentiert, damit spätere Wiederherstellung nicht unbemerkt die Betriebspolitik überschreibt.
14. Scope und Template-Design
| Scope | Geeignet | Risiko |
|---|---|---|
| Entire Org | globale Mindestüberwachung | unterschiedliche Site-Kritikalität |
| Site-Liste | kritische/regionale Standorte | neue Sites fehlen ohne Lifecycle |
| Site Group | Pause Rules und strukturierte Gruppen | Gruppenpflege entscheidet Wirkung |
| Org Devices | Mist Edge und org-zugeordnete Objekte | nicht durch Site-Regel abgedeckt |
Abnahmetest: Für jedes Template wird ein erwarteter positiver und negativer Site-Match dokumentiert.
15. E-Mail-Empfänger
Templates können Org-Admins, Site-Admins und zusätzliche Adressen als Empfänger verwenden. Bei ausgewählten Administratoren müssen E-Mail-Benachrichtigungen im persönlichen Account aktiviert sein.
| Empfängermodell | Vorteil | Kontrolle |
|---|---|---|
| Org Admins | zentral | zu breiter Verteiler? |
| Site Admins | lokale Zuständigkeit | Site-Rollen aktuell? |
| Additional Recipients | NOC/ITSM-Mailadresse | Owner und Zustelltest |
E-Mail eignet sich für Benachrichtigung, aber nur bedingt für deduplizierte, zustandsbehaftete Ticketautomation.
16. Konfigurierbare Schwellenwerte
Für bestimmte Alerttypen erscheint ein Bearbeitungssymbol. Juniper nennt insbesondere ARP-, DHCP-, DNS-Fehler und Device Offline als konfigurierbare Schwellenfälle.
| Parameter | Wirkung | Fehlkonfiguration |
|---|---|---|
| Failure Count | minimale Ereignismenge | zu niedrig erzeugt Noise |
| Impacted Clients | Betroffenheit | kleine Sites werden übersehen |
| Duration/Window | Persistenz | zu lang verzögert Erkennung |
| Offline Threshold | Ausfallzeit vor Alert | Flapping vs. späte Meldung |
Threshold Tuning = Erkennungszeit gegen False-Positive-Rate und Business Impact abwägen
17. Pause Alerts für Wartungsfenster
Alerts können zeitlich begrenzt für die gesamte Organisation, org-level Devices, Site-Geräte, Sites oder Site Groups pausiert werden.
1. Scope
Entire Org oder Site Group/Sites wählen.
Entire Org oder Site Group/Sites wählen.
2. Device Type
Org Devices und/oder Site Devices festlegen.
Org Devices und/oder Site Devices festlegen.
3. Zeitraum
Start und Ende mit Zeitzone prüfen.
Start und Ende mit Zeitzone prüfen.
4. Regel prüfen
Existing Rules und Active-Status kontrollieren.
Existing Rules und Active-Status kontrollieren.
5. Ende
automatische Wiederaufnahme und Alarmtest.
automatische Wiederaufnahme und Alarmtest.
Wirkung: Pausieren unterdrückt im gewählten Scope Alerts und Benachrichtigungen. Es ersetzt kein Change-Ticket und keine Überwachung außerhalb von Mist.
18. Infrastructure Alerts
| Bereich | Beispiele | Korrelationsfrage |
|---|---|---|
| Connectivity | ARP, DHCP, DNS, RADIUS | Server, VLAN, WLAN oder Site gemeinsam? |
| Device | AP/Switch/Gateway down/restarted | Site-, Switch- oder ISP-Ausfall? |
| Hardware | PSU, Fan, Resource Usage | Redundanz und Nutzerwirkung? |
| Port | Up/Down, PoE, Link | konfigurierter Überwachungsport? |
| Mist Edge | Upgrade, Service, Config, RADIUS | Datapath/Auth betroffen? |
Infrastructure Alerts sind teilweise direkte Ereignisabbildungen. Das NOC muss Recovery Events oder aktuellen Istzustand zur Schließung heranziehen.
19. Security Alerts
Security Alerts erkennen definierte Funk- oder Netzwerkereignisse. Viele sind punktuelle Detektionen und beweisen nicht, dass ein Angriff noch aktiv oder erfolgreich ist.
| Beispiel | Aussage | Validierung |
|---|---|---|
| Rogue AP | fremder/klassifizierter AP erkannt | Autorisierung, LAN-Verbindung, Clientassoziation |
| Honeypot SSID | fremder AP sendet eigene SSID | BSSID, Standort, Clientwirkung |
| BSSID Spoofing | gleiches BSSID-Muster auffällig | Signal, Hersteller, legitime Reproduktion |
| Beacon Flood | viele neue BSSIDs/SSIDs | RF-Survey/Testgerät? |
| KRACK/IDP | detektiertes Angriffsmuster | PCAP, Ziel, Erfolg, Incident Response |
Juniper dokumentiert Rate Limits für bestimmte Rogue-/Honeypot-Meldungen. Fehlende Wiederholung bedeutet daher nicht automatisch Entwarnung.
20. Certificate Alerts
Für benutzerseitig eingebrachte RadSec-, SSO- und PSK-Portal-IDP-Zertifikate erscheinen Ablaufwarnungen.
| Vorlauf | Benachrichtigung |
|---|---|
| 30 Tage | erste Warnung |
| 15 Tage | Wiederholung |
| 7 Tage | Wiederholung/Eskalation |
| 3 Tage | kritische Restzeit |
| 1 Tag | unmittelbar vor Ablauf |
Ein Zertifikatsalarm wird erst durch Austausch plus Funktionsprüfung abgeschlossen. Nur Upload oder Verlängerung im PKI-System genügt nicht.
21. Marvis Alerts und Actions
Marvis Alerts sind an die entsprechenden Marvis Actions gekoppelt. Im Webhook-Payload kann der Zustand unter details.state beispielsweise open oder validated sein.
| Zustand | Bedeutung | ITSM-Wirkung |
|---|---|---|
open | Problem aktuell erkannt | Ticket anlegen/aktualisieren |
validated | Marvis bestätigt, dass es nicht mehr aktiv beobachtet wird | technische Verifikation, dann schließen |
Marvis kann wegen benötigter Datengrundlage später als ein direktes Event melden. Dafür liefert die Action mehr Korrelation, Scope und Handlungskontext.
22. Potential Anomalies and Optimizations
Marvis analysiert Telemetrie, Logs und Performance und zeigt potenzielle Anomalien als frühe Hinweise unter Site Insights im Bereich Events an.
| Stärke | Grenze |
|---|---|
| frühe Abweichungserkennung | nicht jede Anomalie ist eine Störung |
| Site- oder Device-Level | Change kann legitime Abweichung erzeugen |
| Remediation-Hinweis | betrieblicher Kontext bleibt beim Operator |
Einordnung: Potential Anomaly ist ein Untersuchungsauftrag, kein automatisch bestätigter Incident.
23. Marvis Minis als synthetische Überwachung
Minis simulieren Nutzerverbindungen auf APs beziehungsweise unterstützten EX-Switches. Sie prüfen Dienste auch ohne reale Clients.
| Test | Möglicher Output |
|---|---|
| DHCP/ARP/DNS | Failure Action/Alert im Marvis-Kontext |
| RADIUS | Erreichbarkeit/Timeout |
| Application Reachability | synthetischer Pfadfehler |
| On-demand Wireless | gezielte Validierung |
Ein erfolgreicher Mini-Test beweist den getesteten synthetischen Pfad, nicht jede Client-, Treiber- oder Applikationsvariante.
24. Alert-Webhooks
Alle im Alert Framework sichtbaren und aktivierten Alerts können als Alert-Webhook an Org- oder Site-Endpunkte gesendet werden.
Mist Alert→HTTP POST→TLS/Auth→Queue→Dedupe/Korrelation→ITSM/NOC
| Payloadfeld | Nutzung |
|---|---|
| org_id/site_id | Mandant und Scope |
| type/group/severity | Routing und Priorität |
| device/mac/name | Configuration Item |
| timestamp | zeitliche Korrelation |
| details/state | Kontext und Lifecycle |
Das reale Schema wird je Alertdefinition geprüft. Die API /api/v1/const/alarm_defs liefert Definitionen und Beispiele für unterstützte Alarmtypen.
25. Webhook Delivery Monitoring
Für Alerts, Audits, Device Up/Down und Ping kann der Delivery-Status der letzten 61 Tage eingesehen werden.
| Ansicht | Information |
|---|---|
| Status | Success oder Failure |
| HTTP | Response Status Code |
| Request | URL, Header und Body |
| Response | Header und Body |
| Error | Fehlermeldung |
Überwachung der Überwachung: Ein funktionierender Alert ohne erfolgreiche Webhook-Zustellung erreicht das NOC nicht. Delivery Failure benötigt einen unabhängigen Alarmweg.
26. Integration in ITSM und Monitoring
| Funktion | Muster |
|---|---|
| Dedupe | Org + Site + Alerttyp + Entity + Zustand |
| Correlation | Site Down bündelt viele AP-Down-Folgen |
| Enrichment | CMDB, Owner, Business Service, Wartung |
| Routing | Wireless/Wired/WAN/Security/PKI-Team |
| Update | Recurrence und Last Seen am Ticket fortschreiben |
| Closure | validated/recovery plus technische Gegenprobe |
| Dead Letter | unbekanntes Schema oder ITSM-Ausfall |
Der Receiver bestätigt schnell, schreibt in eine dauerhafte Queue und verarbeitet danach. Lange Ticket- oder Diagnoseaktionen gehören nicht in den Webhook-HTTP-Request.
27. Alarm-Lifecycle
1. Detect
Event, Threshold oder AI-Modell erkennt Zustand.
Event, Threshold oder AI-Modell erkennt Zustand.
2. Notify
Dashboard, E-Mail und/oder Webhook.
Dashboard, E-Mail und/oder Webhook.
3. Qualify
Scope, Auswirkung, Wartung, Duplikat und Validität.
Scope, Auswirkung, Wartung, Duplikat und Validität.
4. Assign
Owner, Priorität, SLA und Eskalationspfad.
Owner, Priorität, SLA und Eskalationspfad.
5. Diagnose
Insights, SLE, Events, Marvis und externe Systeme.
Insights, SLE, Events, Marvis und externe Systeme.
6. Remediate
manuell oder freigegebene Automation.
manuell oder freigegebene Automation.
7. Verify
Recovery, SLE, Nutzerpfad und Wiederholungsfreiheit.
Recovery, SLE, Nutzerpfad und Wiederholungsfreiheit.
8. Close
Ursache, Maßnahme und Evidenz dokumentieren.
Ursache, Maßnahme und Evidenz dokumentieren.
9. Improve
Threshold, Runbook oder Design korrigieren.
Threshold, Runbook oder Design korrigieren.
28. NOC-Eskalationsmodell
| Stufe | Aufgabe | Exit-Kriterium |
|---|---|---|
| L1 | Alert qualifizieren, Wartung/Duplikat prüfen | Standardlösung oder L2-Eskalation |
| L2 | SLE, Insights, Marvis, Topologie | Ursachendomäne und Maßnahme |
| L3 | PCAP, Config, API, RF/Routing | Root Cause/dauerhafte Korrektur |
| Vendor | Supportbundle, Zeitfenster, IDs, Evidenz | Defect, RMA oder Herstellermaßnahme |
Eine Eskalation enthält First/Last Seen, Zeitzone, Org/Site/Entity IDs, Recurrence, Alertdetails, SLE/Insights und bereits getestete Hypothesen.
29. Alarm-Tuning
| Problem | Maßnahme |
|---|---|
| Alarmflut | Parent/Child-Korrelation und siteweite Ursache |
| Flapping | Persistenz, Hysterese, Recurrence und Cooldown |
| False Positive | Threshold/Scope gegen reale Fälle anpassen |
| False Negative | kleine Sites und kritische Einzelgeräte gesondert |
| zu viele E-Mails | Dashboard/Webhook für NOC, E-Mail nur gezielt |
| verwaiste Templates | Owner und Site-Lifecycle |
| Wartungsnoise | zeitlich definierte Pause Rules |
| stale Tickets | Recovery/validated und Ist-Abfrage |
Ziel: minimale unnötige Meldungen bei maximaler Erkennung geschäftsrelevanter Störungen
30. Monitoring-KPIs
| KPI | Definition | Aussage |
|---|---|---|
| MTTD | Störungsbeginn bis Erkennung | Erkennungsgeschwindigkeit |
| MTTA | Alert bis qualifizierte Annahme | NOC-Reaktion |
| MTTR | Erkennung bis Wiederherstellung | Gesamteffektivität |
| Precision | echte relevante Alerts / alle Alerts | Noise-Qualität |
| Recall | erkannte relevante Incidents / alle relevanten Incidents | Blindstellen |
| Duplicate Rate | Duplikate / Meldungen | Korrelation |
| Delivery Success | erfolgreiche Webhooks / Versuche | Integrationsgesundheit |
| Actionability | Alerts mit Owner/Runbook | Betriebsreife |
31. Praxisfälle
| Symptom | Signalkette | Entscheidung |
|---|---|---|
| 10 APs offline | Device Events → Infrastructure Alerts → Marvis Site/ISP Context | nicht 10 unabhängige Tickets |
| DHCP-Fehler | Client Events → Threshold Alert → SLE Classifier → Marvis Action | VLAN/Server/Scope korrelieren |
| Port flappt | Up/Down Events → Recurrence → Wired Insight | Kabel, Optik, Peer oder Wartung |
| Rogue AP | Security Alert → RF/Neighbor Context | autorisieren, lokalisieren oder Incident |
| Zertifikat läuft ab | 30/15/7/3/1-Tage Alert | Renewal plus Auth-Funktionstest |
| Webhook 429 | Delivery Failure → unabhängiges Monitoring | Receiverkapazität/Backpressure |
32. Systematische Fehlersuche
| Symptom | Prüfung |
|---|---|
| Alert fehlt im Dashboard | Template, Enable Alert, Scope, Trigger, Pause Rule |
| keine E-Mail | Send Email, Recipient, Admin Account Setting, Spam |
| kein Webhook | Topic, Org/Site Config, TLS/DNS/Firewall, Delivery |
| zu viele Meldungen | Threshold, Parent Event, Wartung, Dedupe |
| Alert bleibt offen | stateful/stateless, Recovery, Last Seen, Marvis Validation |
| Marvis kommt später | Modell benötigt genügend Daten; Alerts ersetzen es nicht |
| Security Alert wiederholt nicht | produktspezifisches Reporting Rate Limit |
| falscher Scope | Default vs. Custom Template und Site-Zuordnung |
| Pause wirkt nicht | Zeitzone, Active, Org/Site Device-Auswahl |
| Webhook Body unerwartet | Alarm Definition, Aggregation, Schema-Version |
Beweiskette: Telemetrie → Event → Trigger → Template/Scope → Alert → Notification → Delivery → Ticket → Recovery
33. Produktionscheckliste
Mist-Konfiguration
- Default Template geprüft
- Scope je Template
- Recommended Alerts bewertet
- Thresholds dokumentiert
- E-Mail-Empfänger getestet
- Security/Certificate aktiviert
- Marvis-Subscription passend
- Pause-Rule-Prozess
NOC/Integration
- Webhook TLS/Auth
- Queue und Dedupe
- Delivery Monitoring
- CMDB-Enrichment
- Prioritätsmatrix
- Runbooks und Owner
- Recovery/Closure
- KPIs und Review
Häufige Fehlannahmen
| Aussage | Bewertung | Richtigstellung |
|---|---|---|
| „Jedes Event ist ein Alert.“ | Falsch | Alerts brauchen aktivierten Typ und Triggerlogik. |
| „Marvis ersetzt Alerts.“ | Falsch | Beide Ebenen ergänzen sich. |
| „Critical bedeutet automatisch P1.“ | Falsch | Business Impact fehlt. |
| „Security Alert beweist Angriffserfolg.“ | Falsch | Detektion muss validiert werden. |
| „E-Mail genügt als Incidentprozess.“ | Falsch | Dedupe, Owner, SLA und Closure fehlen. |
| „Pause löscht Telemetrie.“ | Falsch | Sie unterdrückt Alerts/Notifications im Scope. |
| „Webhook 200 bedeutet Ticket erstellt.“ | Falsch | Downstream-Verarbeitung muss überwacht werden. |
34. Offizielle Grundlagen
- Alerts Overview
- Configure and Manage Alerts and Notifications
- Select Alert Scope, Recipients and Types
- Juniper Mist Alert Types
- Webhooks and Alerts
- Webhook Delivery Status
- Marvis Actions Backend Operations
- Potential Anomalies and New Alerts
- Pause Alerts and Certificate Alerts
Fachstand: August 2026. Alerttypen, Severity, Kategorien, Schwellenwerte, Menüs, Webhook-Schemas, Aufbewahrung und Subscription-Anforderungen können sich ändern. Für den produktiven Betrieb gelten die aktuelle Juniper-Dokumentation, die Alarmdefinitionen der eigenen Cloudinstanz und End-to-End-Tests bis zum NOC/ITSM.