# 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