claude_settings/plans/zesty-finding-harbor.md

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: "ZabbixCRIF" 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