Troubleshooting fuer Alerting
Warum fehlt mein Alert?
Pruefe diese Punkte in genau dieser Reihenfolge:
- Tenant selbst aktiv?
jobs.alerts.config.enabledauftrue?- konkrete Alert-Definition in
jobs.alerts.config.alerts[]ebenfallsenabled: true? - Upstream-Laufzeitdaten vorhanden und frisch?
- Alert-Loop wartet nicht mehr auf Packages?
Typische Ursachen
| Symptom | Wahrscheinliche Ursache | Wo pruefen |
|---|---|---|
| gar keine Alerts | jobs.alerts deaktiviert | Tenant-Config und Worker Runtime |
| Message-Alerts fehlen | Message-Sync veraltet oder gefiltert | Message Popups und Worker Runtime |
| iFlow-Alerts fehlen | Package- oder Artefakt-Sync veraltet | Artifacts und Worker Runtime |
| Keystore-Alerts fehlen | Keystore-Sync veraltet | Keystore Entries |
| Daily-No-Message-Alert fehlt | Wochentag oder Zeitfenster passt nicht | Alert-Definition in daily_check |
Konkrete Checks
Check 1: Alert-Config vorhanden
Erwartete Struktur:
jobs.alerts.config.enabledjobs.alerts.config.repeat_intervaljobs.alerts.config.alerts[]
Typische Beispielwerte:
repeat_interval = 60type = alert_messagestype = alert_iflowstype = alert_keystoretype = alert_iflow_no_messages_daily
Check 2: Upstream-Daten vorhanden
Alerting wertet gespeicherte Laufzeitdaten aus, nicht direkte Live-CPI-Antworten.
Pruefe dazu:
- Message-Alerts: Message Popups
- iFlow-Alerts: Artifacts
- Keystore-Alerts: Keystore Entries
Check 3: Worker-Abhaengigkeit erfuellt
Der Alert-Loop wartet explizit zuerst auf den Package-Abschluss. Wenn der Package-Sync noch nicht als fertig gilt, koennen Alerts trotz korrekter Config verspaetet sein.
Siehe Worker Runtime Troubleshooting.
Warum sehe ich nur acknowledged oder outdated?
Beobachtete Laufzeitstatus sind:
alertedacknowledgedoutdated
Wichtige Bedeutung:
alertedbedeutet aktuell offen in der Alert-Lebensdaueracknowledgedbedeutet, dass ein Benutzer den Zustand geaendert hatoutdatedbedeutet, dass eine aeltere Alert-Zeile durch eine neuere Zeile derselben Trigger-Kette ersetzt wurde
Einige Overview-Abfragen schliessen outdated explizit aus. Ein historischer Alert kann also gespeichert sein, aber nicht mehr in der Hauptsicht auftauchen.
Warum gilt ein Alert als laenger als 48 Stunden offen?
Open-too-long-Filterung nutzt:
origin_time_alerted, falls vorhanden- sonst
time_alerted
Dadurch kann eine erneuerte Alert-Kette weiterhin als lange offen gelten, wenn sie die urspruengliche Open-Zeit vererbt.
Warum loest Acknowledge das Problem nicht?
Acknowledge aendert den Persistenzzustand des Alerts, beseitigt aber nicht automatisch die technische Ursache.
Wenn das zugrunde liegende Problem bestehen bleibt:
- bleibt der Alert fachlich weiter relevant
- spaetere Auswertungen koennen die Alert-Kontinuitaet fortschreiben
- die naechste Pruefung sollte auf die Laufzeitquelle gehen, nicht nur auf die Alert-Zeile
Schnelle Diagnosepfade
- fehlender Message-Alert: Message Popups Troubleshooting
- fehlender Keystore-Alert: Keystore Entries
- veraltete Alert-Overview: Worker Runtime Troubleshooting