4277b10f55
- Neuer Abschnitt "Karten erstellen (Aufgaben-Workflow)" mit Workflow A/B - Bekannte Struktur erweitert: Workflows, Columns, Lanes für Board 1 - Pitfalls ergänzt: Arrival Rule, Parent-Link API, linkedCards read-only - Settings und Plans aktualisiert Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
189 lines
7.3 KiB
Markdown
189 lines
7.3 KiB
Markdown
# Plan: CRIF Nächtliche False-Positive Problemmeldungen beheben
|
|
|
|
## Problem
|
|
|
|
**Kanbanize-Ticket:** #13461 - "VAE-Meldungen erhält jede Nacht Nachricht über CRIF"
|
|
|
|
**Symptome:**
|
|
- Jede Nacht kommt eine Zabbix-Problemmeldung zum CRIF-Export
|
|
- Problem löst sich nach ca. 15 Minuten automatisch
|
|
- Die Zeiten sind sehr unregelmäßig
|
|
|
|
**Betroffener Trigger:**
|
|
- TriggerID: 44829
|
|
- Name: `processing_backup_monitoring_hours_crif`
|
|
- Host: SRV-JOB01
|
|
- Kategorie: Interface/CRIF
|
|
|
|
## Hintergrund
|
|
|
|
Laut Dokumentation (troubleshooting.md:151-164):
|
|
- **Ablauf:** NAV erstellt Export → Scheduled Task (02:00) lädt zu CRIF FTP hoch → Dateien werden ins Backup-Verzeichnis verschoben
|
|
- **Trigger-Funktion:** Prüft ob Dateien jünger als 1 Tag im `\\vinos.local\sys\nav\interfaces\CRIFBuergel\backup` Ordner existieren
|
|
- **Häufige Ursache:** NAV Aufgabenwarteschlange läuft nicht (aber hier löst sich das Problem selbst → kein echter Fehler)
|
|
|
|
## Hypothese (BESTÄTIGT durch Phase 1)
|
|
|
|
**VERIFIZIERTE FAKTEN:**
|
|
- Trigger 44829 auf SRV-JOB01 überwacht CRIF-Backup (korrekt dokumentiert)
|
|
- Item: `processing_backup_monitoring_hours_crif` (Trapper-Type, empfängt Werte)
|
|
- Events feuern um ~01:15-01:45 CET (nicht 02:00!)
|
|
- Scheduled Task "Transfer-FilesWinSCP" läuft um 02:00
|
|
- **ABER:** Backup-Dateien landen schon um 01:07-01:41 (vorher!)
|
|
|
|
**Erkannte Ursache:**
|
|
Es gibt einen **ANDEREN Prozess** der die Backup-Dateien um ~01:00-01:30 erstellt (vermutlich NAV/Business Central Export). Der 02:00 Task ist nur der **Transfer**, nicht die Erstellung.
|
|
|
|
Der Trigger prüft um ~01:30 und findet zu dem Zeitpunkt noch keine neuen Dateien (Export läuft noch), dann sind sie 15-45 Min später fertig → Auto-Recovery.
|
|
|
|
**Problem:** Timing zwischen NAV-Export (unregelmäßig 01:07-01:41) und Monitoring-Check (~01:30) ist zu eng.
|
|
|
|
## Implementierungsplan
|
|
|
|
### Phase 1: Diagnose & Datensammlung ✅ ABGESCHLOSSEN
|
|
|
|
**Ergebnisse:**
|
|
|
|
**Trigger 44829 (verifiziert via Opus-Agent):**
|
|
- Host: SRV-JOB01 (hostid 10636)
|
|
- Item: 99026 "processing_backup_monitoring_hours_crif" (Trapper-Type)
|
|
- Expression: `{86644}=1` (feuert wenn Item-Wert = 1)
|
|
- Tags: IFS-Meldungen, VAE-Meldungen, fts
|
|
|
|
**Event-Pattern (7 Tage):**
|
|
- Häufigkeit: 5 Events in 7 Tagen (täglich nachts)
|
|
- Timing: 01:15-01:45 CET
|
|
- Dauer bis Recovery: 15-45 Min (Durchschnitt: 36 Min)
|
|
- 100% Auto-Recovery
|
|
|
|
**Scheduled Task "Transfer-FilesWinSCP":**
|
|
- Läuft um: 02:00:00 täglich
|
|
- Dauer: 2-3 Sekunden
|
|
- LastTaskResult: 0 (erfolgreich)
|
|
|
|
**KRITISCHER FUND: Timing-Diskrepanz**
|
|
- Backup-Dateien landen: 01:07-01:41 (unregelmäßig!)
|
|
- Scheduled Task läuft: 02:00 (zu spät!)
|
|
- → Es gibt einen ANDEREN Prozess der die Dateien erstellt
|
|
|
|
**Hypothese bestätigt:** NAV/Business Central erstellt Exports um ~01:00-01:30, Transfer-Task transportiert sie um 02:00. Trigger prüft während der Export-Erstellung läuft.
|
|
|
|
### Phase 2: Lösungsansatz entwickeln
|
|
|
|
**EMPFOHLENE LÖSUNG (basierend auf Phase 1):**
|
|
|
|
**Option A: Monitoring-Check-Timing verschieben** ⭐ BESTE LÖSUNG
|
|
- **Problem:** Check läuft während NAV-Export (01:15-01:45)
|
|
- **Lösung:** Item-Update-Intervall so setzen dass Check NACH Export läuft (z.B. 02:30 oder 03:00)
|
|
- **Vorteil:** Einfach, keine False-Positives mehr
|
|
- **Nachteil:** Erkennt Probleme erst 1-2h später
|
|
|
|
**Option B: Grace Period / Hysteresis einbauen**
|
|
- **Problem:** Export braucht 15-45 Min aber Trigger ist ungeduldig
|
|
- **Lösung:** Trigger feuert erst wenn 2-3 Checks in Folge fehlschlagen (z.B. "no data for 2 hours")
|
|
- **Vorteil:** Erkennt echte Ausfälle vs. temporäre Export-Phasen
|
|
- **Nachteil:** Komplexere Trigger-Logic
|
|
|
|
**Option C: Maintenance Window**
|
|
- **Problem:** Nächtliche Wartung/Export = False-Positive
|
|
- **Lösung:** Maintenance Window 01:00-02:00 CET
|
|
- **Vorteil:** Sauber, professionell
|
|
- **Nachteil:** Echte Ausfälle in diesem Fenster werden nicht gemeldet
|
|
|
|
**Option D: NAV-Export-Prozess finden und direkt überwachen**
|
|
- **Problem:** Wir überwachen Backup-Dateien, nicht den Prozess
|
|
- **Lösung:** NAV Aufgabenwarteschlange direkt überwachen (siehe troubleshooting.md:160 "Häufigste Ursache: NAV läuft nicht")
|
|
- **Vorteil:** Root-Cause-Monitoring statt Symptom-Monitoring
|
|
- **Nachteil:** Erfordert NAV-Zugriff und neue Items
|
|
|
|
**EMPFEHLUNG:** Kombination A + B
|
|
1. Check-Timing auf 02:30 verschieben (nach Export UND Transfer)
|
|
2. Hysteresis: "Problem erst wenn 2 Checks (30 Min) fehlschlagen"
|
|
3. Damit: False-Positives weg + echte Ausfälle erkannt
|
|
|
|
### Phase 3: Fix implementieren (Option A - Check-Timing verschieben)
|
|
|
|
**Ziel:** Item-Update-Intervall so setzen dass Check NACH NAV-Export + Transfer läuft.
|
|
|
|
**Schritte:**
|
|
|
|
1. **Item 99026 Details abrufen:**
|
|
- Aktuelles Update-Intervall prüfen
|
|
- Type = Trapper → Werte werden gepusht, kein Poll-Intervall
|
|
- → Das Script das die Werte pusht muss gefunden werden
|
|
|
|
2. **Monitoring-Script finden:**
|
|
- Auf SRV-JOB01: Scheduled Task der das Item befüllt
|
|
- Wahrscheinlich: PowerShell-Script das Backup-Ordner prüft
|
|
- Task-Name vermutlich: "Zabbix*CRIF*" oder ähnlich
|
|
- Pfad vermutlich: `C:\Skripte\` oder `C:\Tasks\`
|
|
|
|
3. **Scheduled Task anpassen:**
|
|
- Backup der Task-Definition erstellen
|
|
- Task-Zeitplan von aktuell (vermutlich 01:30) auf **02:30** verschieben
|
|
- Begründung: NAV-Export läuft 01:07-01:41, Transfer 02:00, Check danach um 02:30
|
|
|
|
4. **Dokumentation aktualisieren:**
|
|
- `troubleshooting.md` Abschnitt "CRIF Bürgel Export-Monitoring" ergänzen
|
|
- Neues Timing dokumentieren
|
|
- Begründung für Änderung festhalten
|
|
|
|
5. **Verifikation:**
|
|
- Morgen (03.02.2026) um ~02:30 Events prüfen
|
|
- Bestätigen: Kein False-Positive mehr
|
|
- 3-5 Nächte beobachten
|
|
|
|
### Phase 4: Dokumentation & Abschluss
|
|
|
|
1. **Troubleshooting.md aktualisieren:**
|
|
- Abschnitt "CRIF Bürgel Export-Monitoring" erweitern
|
|
- Fix und Erkenntnisse dokumentieren
|
|
- Pitfall hinzufügen falls relevant
|
|
|
|
2. **README.md aktualisieren:**
|
|
- Trigger-ID Eintrag aktualisieren falls Name/Beschreibung geändert
|
|
|
|
3. **Kanbanize-Kommentar erstellen:**
|
|
- Problemdokumentation nach Template
|
|
- User-Freigabe einholen bevor gepostet wird
|
|
|
|
4. **Git Commit:**
|
|
- Dokumentationsänderungen committen
|
|
- Aussagekräftige Commit-Message
|
|
|
|
## User-Entscheidung
|
|
|
|
✅ Option A gewählt: Monitoring-Check-Timing verschieben
|
|
- Check-Zeit von ~01:30 auf 02:30 verschieben
|
|
- Damit läuft Check NACH NAV-Export (01:07-01:41) UND Transfer-Task (02:00)
|
|
|
|
## Risiken & Überlegungen
|
|
|
|
- **Kein Produktions-Impact:** CRIF-Export läuft, nur Monitoring ist zu sensitiv
|
|
- **Vorsicht:** Schwellwert nicht zu hoch setzen, sonst übersehen wir echte Ausfälle
|
|
- **Testing:** Idealerweise würden wir 2-3 Nächte beobachten nach dem Fix
|
|
|
|
## Verification Strategy
|
|
|
|
**Sofort nach Fix:**
|
|
1. Scheduled Task Status prüfen: NextRunTime = 02:30?
|
|
2. Task manuell triggern um zu testen
|
|
|
|
**Nächste Nacht (03.02.2026):**
|
|
1. Um ~02:35: Zabbix Events prüfen
|
|
2. Bestätigen: Kein neues Problem-Event
|
|
3. Bestätigen: Item-Wert = 0 (OK)
|
|
|
|
**Langfristig (3-5 Nächte):**
|
|
1. Event-Historie beobachten
|
|
2. Bestätigen: Keine False-Positives mehr
|
|
3. Optional: NAV-Export simuliert ausfallen lassen um zu testen ob echter Alarm käme
|
|
|
|
## Success Criteria
|
|
|
|
- [ ] Trigger 44829 feuert nicht mehr jede Nacht
|
|
- [ ] Wenn CRIF-Export tatsächlich fehlt, wird er trotzdem erkannt
|
|
- [ ] User erhält keine nächtlichen Problemmeldungen mehr
|
|
- [ ] Dokumentation ist aktualisiert
|
|
- [ ] Kanbanize-Kommentar erstellt und User-approved
|