root/claude_settings
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
dbfc3c4ddcbac542352b42044083b8a74619cb0a
claude_settings/plans/eager-sprouting-lollipop.md
root ff5057b902 Pitfalls: /etc/hosts verboten, Split-Horizon-DNS bei UCS, Proxmox VMID-Wechsel 
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-29 22:46:19 +01:00

11 KiB
Raw Blame History

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

### 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
Reference in New Issue View Git Blame Copy Permalink