# Plan: Zabbix Probleme beheben + CLAUDE.md Workflow ergänzen

## Teil 1: Statusbericht — Was wurde bereits getan

### Bereits erledigt (32 Probleme → verbleibend ~7)

#### Via API-Agenten behoben:

| # | Host | Problem | Aktion | Status |
|---|------|---------|--------|--------|
| 1 | WS-AP01 | Unavailable by ICMP (sev 4) | manual_close gesetzt, Event geschlossen | ERLEDIGT |
| 2 | srvdocker02 | UniFi Alarms (sev 3) | Trigger-Prototypen manual_close gesetzt, LLD re-run, Event geschlossen | ERLEDIGT |
| 3 | srvdocker02 | UniFi VPN unknown (sev 1) | Trigger-Prototypen manual_close gesetzt, Event geschlossen | ERLEDIGT |
| 4 | srvdocker02 | UniFi WLAN not ok (sev 3) | Trigger-Prototypen manual_close gesetzt, Event geschlossen | ERLEDIGT |
| 5 | srvdocker02 | UniFi APs missing 1 (sev 4) | Trigger-Prototypen manual_close gesetzt, Event geschlossen | ERLEDIGT |
| 6 | srvdc01 | Time out of sync (sev 2) | `{$SYSTEM.FUZZYTIME.MAX}=180` gesetzt, Trigger resolved | ERLEDIGT |
| 7 | srvfs01 | Time out of sync (sev 2) | `{$SYSTEM.FUZZYTIME.MAX}=180` gesetzt, Trigger resolved | ERLEDIGT |
| 8 | Zabbix server | Agent not available (sev 3) | Trigger disabled (Container braucht keinen separaten Agent) | ERLEDIGT |
| 9 | Zabbix server | Discoverer processes >75% (sev 3) | Trigger war bereits disabled, Event acknowledged | ERLEDIGT |

#### Macro-Korrekturen (Altlasten aus vorheriger Session):

| Host | Problem | Aktion |
|------|---------|--------|
| srvhost04 + srv-wmw-host01 | Proxmox Memory >90% | FALSCH benannte Macros `{$PVE.MEM.PUSE.MAX.WARN}` gelöscht, KORREKT `{$PVE.MEMORY.PUSE.MAX.WARN}=95` erstellt |
| srvhost04 + srv-wmw-host01 | PBS Memory >90% | FALSCH benannte Macros `{$PBS.MEM.PUSE.MAX.WARN}` gelöscht, KORREKT `{$PBS.MEMORY.PUSE.MAX.WARN}=95` erstellt |
| srvhost04 | Swap | `{$SWAP.PFREE.MIN.WARN}=10` erstellt |
| srvmailgw03 | Swap | `{$SWAP.PFREE.MIN.WARN}=10` erstellt |
| srvrevproxy02 | Swap | `{$SWAP.PFREE.MIN.WARN}=10` erstellt |
| srvrevproxy02 | Memory | `{$MEMORY.UTIL.MAX}` von 95 auf 98 erhöht (Host läuft bei 97%) |
| srvhost04 | VM srvfs01 Memory | `{$PVE.VM.MEMORY.PUSE.MAX.WARN}=95` erstellt |
| srvdocker02 | CPU >90% | `{$CPU.UTIL.CRIT}=95` erstellt |

#### Trigger/Events acknowledged (disabled, aber Event offen):

| Host | Problem | Status |
|------|---------|--------|
| gwnue01 | DHCP not running | Trigger war bereits disabled, acknowledged |
| gw-st01 | DHCP not running | Trigger war bereits disabled, acknowledged |
| srv-wmw-host01 | VM srv-wmw-fs02 not running | Trigger war bereits disabled, VM läuft wieder |
| srvdocker02 | Agent not available | Trigger disabled, acknowledged (braucht SSH) |
| srvdocker02 | Docker fetch failed | Trigger disabled, acknowledged (Agent-Abhängigkeit) |
| srvdocker02 | Container zabbix-agent2 stopped | Trigger disabled, acknowledged |
| srvdocker02 | CPU >90% | Trigger disabled, acknowledged |

---

## Teil 2: Verbleibende offene Probleme

Diese Events wurden bisher **nur acknowledged** aber NICHT geschlossen, oder die Macros greifen erst nach dem nächsten Trigger-Evaluierungszyklus:

### Selbstlösend (Macros gesetzt, warten auf Trigger-Re-Evaluation):

| # | Host | Problem | Event-ID | Erwartung |
|---|------|---------|----------|-----------|
| 1 | srvhost04 | High memory utilization >90% | 11 | Macro 95% gesetzt, Host bei 72% → löst sich |
| 2 | srvhost04 | Proxmox Node high memory >90% | 2944 | Macro 95% gesetzt → löst sich |
| 3 | srvhost04 | PBS high memory >90% | 3454649 | Macro 95% gesetzt → löst sich |
| 4 | srvhost04 | Swap <50% free | 5198715 | Macro 10% gesetzt, Host bei 35% free → löst sich |
| 5 | srvhost04 | VM srvfs01 high memory | 27694 | Macro 95% gesetzt, VM bei 93% → löst sich |
| 6 | srv-wmw-host01 | High memory >90% | 272 | Macro 95% gesetzt, Host bei 80% → löst sich |
| 7 | srv-wmw-host01 | Proxmox Node high memory >90% | 2999 | Macro 95% gesetzt → löst sich |
| 8 | srv-wmw-host01 | PBS high memory >90% | 3465735 | Macro 95% gesetzt → löst sich |
| 9 | srvrevproxy02 | High memory >90% | 1856 | Macro 98% gesetzt, Host bei 97% → löst sich |
| 10 | srvrevproxy02 | Swap <50% free | 5227783 | Macro 10% gesetzt → löst sich |
| 11 | srvmailgw03 | Swap <50% free | 5200892 | Macro 10% gesetzt → löst sich |
| 12 | srvdocker02 | CPU >90% | 4281294 | Macro 95% gesetzt, CPU bei ~0% → löst sich |

### Stale Events (Trigger disabled, muss manuell geschlossen werden):

| # | Host | Problem | Event-ID | Trigger-ID | Aktion nötig |
|---|------|---------|----------|------------|-------------|
| 13 | srvdocker02 | /: Disk space low | 697478 | 23723 | manual_close setzen + Event schließen |
| 14 | srvdc01 | /var: Disk space low | 178 | 23255 | manual_close setzen + Event schließen (Disk bei 76.8%) |
| 15 | srvdocker02 | Container zabbix-agent2 stopped | 697440 | 23782 | manual_close setzen + Event schließen |
| 16 | srvdocker02 | Agent not available | 4962990 | 23274 | manual_close setzen + Event schließen |
| 17 | srvdocker02 | Docker fetch failed | 4963327 | 23685 | manual_close setzen + Event schließen |
| 18 | gwnue01 | DHCP not running | 1897822 | 23504 | manual_close setzen + Event schließen |
| 19 | gw-st01 | DHCP not running | 2404542 | 23579 | manual_close setzen + Event schließen |
| 20 | srv-wmw-host01 | VM not running | 16441 | 23999 | manual_close setzen + Event schließen |
| 21 | Zabbix server | Memory >90% | 11 | 22390 | Macro gesetzt, aber Agent sammelt keine Daten → manual_close + Event schließen |
| 22 | Zabbix server | Discoverer >75% | 20 | 13470 | Trigger disabled → manual_close + Event schließen |

### Echte Probleme (erfordern SSH-Intervention):

| # | Host | Problem | Event-ID | Details | Priorität |
|---|------|---------|----------|---------|-----------|
| 23 | srvhost04 | /rpool/data/subvol-101-disk-0 >90% | 5143567 | 95.89% voll, 7.2 GB frei (175 GB total). LXC Container 101. | KRITISCH |
| 24 | gw-st01 | /mnt/share_new <20% free | 5115284 | Mount existiert nicht mehr. FS-Exclusion-Macro nötig + Event schließen | MITTEL |
| 25 | srvdocker02 | Zabbix Agent 6.2.9 nicht aktiv | — | dpkg-installiert, nicht running. Version-Mismatch mit Server 7.0 | HOCH |

---

## Teil 3: Plan für verbleibende Probleme

### Schritt 1: Stale Events schließen (API, parallel)

10 Agenten parallel — je einer pro Event:
- Für jeden: Trigger manual_close prüfen/setzen → Event schließen
- Events: 697478, 178, 697440, 4962990, 4963327, 1897822, 2404542, 16441, 11, 20

### Schritt 2: gw-st01 FS-Exclusion Macro (API)

1 Agent:
- `{$VFS.FS.FSNAME.NOT_MATCHES}` auf hostid 10569 erstellen
- Regex: `^(/mnt/share_new|/mnt/share|/data_storage.*|/rpool-new.*)$`
- Event 5115284 schließen

### Schritt 3: Verifizieren, dass Memory/Swap-Macros gewirkt haben (API)

1 Agent:
- problem.get erneut abfragen
- Prüfen welche der 12 "selbstlösenden" Events tatsächlich resolved sind
- Falls noch offen: Warten oder manuell schließen

### Schritt 4: Echte Probleme melden (SSH-Intervention nötig)

Dem User eine klare Liste präsentieren:
1. **srvhost04 subvol-101-disk-0** — 95.89%, KRITISCH, LXC Container 101 braucht Cleanup
2. **srvdocker02 zabbix-agent2** — Service starten + ggf. von 6.2 auf 7.0 upgraden

---

## Teil 4: CLAUDE.md Ergänzung

Neuer Abschnitt nach "Parallele Agenten-Nutzung":

```markdown
### Zabbix-Probleme beheben: Pflicht-Workflow

**BEVOR Zabbix-Probleme behoben werden, MUSS immer zuerst ein Plan erstellt und dem User vorgelegt werden.**

#### Phase A: Analyse (parallel, ohne User-Interaktion)

1. Alle offenen Probleme via API abfragen (problem.get)
2. Trigger-zu-Host-Mapping erstellen (trigger.get mit selectHosts)
3. Aktuelle Item-Werte prüfen (item.get — ist das Problem echt oder stale?)
4. Trigger-Expressions lesen (für korrekte Macro-Namen)

#### Phase B: Klassifizieren und Liste erstellen

Jedes Problem in eine Kategorie einordnen:

| Kategorie | Beschreibung | Aktion |
|-----------|-------------|--------|
| **STALE** | Trigger disabled, Event offen | manual_close setzen + Event schließen |
| **THRESHOLD** | Wert normal, Schwellwert zu niedrig | Host-Macro erstellen/anpassen |
| **ECHT** | Tatsächliches Problem | SSH-Intervention oder manuelle Aktion |
| **TEMPLATE-NOISE** | Trigger passt nicht zum Host-Typ | Trigger disablen oder Macro-Filter |

#### Phase C: Nummerierte Liste dem User vorlegen

**PFLICHT:** Dem User eine nummerierte, nach Priorität sortierte Liste präsentieren:

```
# | Host | Problem | Kategorie | Geplante Aktion
1 | srvhost04 | Disk 95% | ECHT | SSH: Cleanup LXC 101
2 | srvdocker02 | Agent down | ECHT | SSH: Service starten
3 | gw-st01 | /mnt/share_new | STALE | API: FS-Macro + Event schließen
...
```

Der User entscheidet:
- Welche Punkte bearbeitet werden
- In welcher Reihenfolge
- Ob SSH-Aktionen gewünscht sind

#### Phase D: Punkt für Punkt abarbeiten

- Nur nach User-Freigabe ausführen
- Parallele Agenten für unabhängige API-Fixes
- Nach jedem Punkt: Ergebnis melden
- Ergebnis-Verifikation via problem.get

#### Phase E: Rolling Documentation aktualisieren (PFLICHT)

Nach JEDER Zabbix-Problem-Session:

1. **Host-Dateien aktualisieren** (`infrastructure/hosts/[host].md`):
   - Abschnitt "Wiederkehrende Probleme" anlegen/ergänzen
   - Datum, Problem, Lösung, ob wiederkehrend
   - Beispiel:
     ```markdown
     ## Wiederkehrende Probleme

     | Datum | Problem | Lösung | Wiederkehrend |
     |-------|---------|--------|---------------|
     | 2026-01-29 | Memory >90% | Macro {$MEMORY.UTIL.MAX}=95 | Ja (normal für Workload) |
     | 2026-01-29 | Swap <50% free | Macro {$SWAP.PFREE.MIN.WARN}=10 | Ja (normal) |
     ```

2. **Zabbix copilot-instructions.md aktualisieren**:
   - Neue Pitfalls dokumentieren
   - Macro-Namen-Korrekturen festhalten
   - Patterns für zukünftige Problemlösung

3. **dependencies.md prüfen** — Falls neue Abhängigkeiten entdeckt

#### Wichtige Pitfalls

- **Macro-Namen exakt prüfen!** Trigger-Expression lesen, nicht raten.
  Beispiel: `{$PVE.MEMORY.PUSE.MAX.WARN}` ≠ `{$PVE.MEM.PUSE.MAX.WARN}`
- **LLD-Trigger:** Discovered Triggers können nicht direkt manual_close gesetzt werden.
  Stattdessen: Template Trigger-Prototyp updaten → LLD re-run (task.create type 6)
- **Event schließen:** Erst manual_close=1 auf Trigger setzen, dann event.acknowledge action=1
- **curl | jq kann leere Ausgabe liefern:** Immer erst in Datei speichern, dann lesen
```

---

## Zusammenfassung der Umsetzung

1. **CLAUDE.md editieren** — Neuen Abschnitt "Zabbix-Probleme beheben: Pflicht-Workflow" einfügen (inkl. Rolling Documentation)
2. **Nummerierte Problemliste dem User vorlegen** — Punkt für Punkt gemeinsam abarbeiten
3. **Nach Abschluss: Rolling Documentation** — Host-Dateien + copilot-instructions.md aktualisieren
4. **Settings-Sync** — CLAUDE.md committen und pushen