5 Commits
Author SHA1 Message Date
0bd77e28d8 monitoring: CVE-Alarme vorerst stumm, Deploy-Fallstricke dokumentiert (gitops#47)
Die CVE-Pipeline aus #47 ist deployt und sammelt Daten, die Alarm-Zustellung
ist aber bewusst abgeklemmt: room="security" routet auf einen Null-Receiver.

Grund: die Regeln erzeugen eine Alarm-Instanz pro CVE pro Image (bei 14 von 29
gescannten Images bereits 59 CRITICAL / 445 HIGH). group_by legt alle in eine
Gruppe, matrix-alerts.py schickt eine Nachricht pro Alarm -> Schwall. Dazu
steht save_state() hinter der Sende-Schleife: bricht ein Send ab (Synapse
rate-limitet nach ~10 mit 429), wird kein State gespeichert, der Receiver
antwortet 502 und Alertmanager wiederholt die ganze Gruppe -- mit leerer
Deduplizierung. Details und Weg zum Scharfschalten im README.

Ausserdem dokumentiert: Config-Aenderungen an prometheus.yml/alerts.yml/
alertmanager.yml werden von "docker compose up -d" NICHT aktiv. Die Dateien
sind einzeln gemountet, Docker haengt den Mount am Inode, git pull erzeugt
beim Umbenennen einen neuen -- der Container sieht weiter die alte Datei.
Es braucht --force-recreate; ein SIGHUP laedt nur den alten Inhalt erneut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 16:09:37 +02:00
6ffab68583 monitoring: State von matrix-alerts persistent machen
Der Receiver (ea33c3b) merkt sich die Firing-Nachricht pro Alarm, um sie beim
Resolved per Edit abzuhaken. Die State-Datei lag aber unter /tmp im Writable
Layer des Containers. Das ueberlebt ein "compose restart", nicht aber ein
"up -d", das den Container neu baut -- also genau jeden Deploy. Danach haetten
alle offenen Alarme ihre Event-Zuordnung verloren und sich ueber den Fallback
als separate Nachricht aufgeloest, statt die urspruengliche abzuhaken.

Jetzt: named volume matrix_alerts_data auf /state, Pfad per MATRIX_STATE_FILE.

Verifiziert: Testalarm eingekippt, State geschrieben, Container per
--force-recreate neu gebaut (Container-ID 7e013a99d892 -> b1f95380dede),
State unveraendert vorhanden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-01 04:51:08 +02:00
sorbandClaude Opus 5 9deb205dce Merge branch 'rework/monitoring'
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 12:13:01 +02:00
sorbandClaude Opus 5 f9a9cb406f monitoring: Stack vollstaendig provisionierbar machen
- Grafana-Provisioning ergaenzt: Datasources (prometheus/loki) mit den
  bestehenden UIDs, damit alle Dashboards weiter funktionieren, sowie vier
  Dashboard-Provider passend zu den vorhandenen Ordnern.
- 9 Dashboards aus der laufenden Instanz exportiert und bereinigt: id/version
  entfernt, hart kodierte und verwaiste Datasource-UIDs auf die
  provisionierten UIDs umgeschrieben.
- Images von :latest auf feste Versionen gepinnt (Prometheus v3.3.1,
  Loki 3.7.1, Alloy v1.16.0, Grafana 12.0.0, node-exporter v1.9.1).
- Alloy: Docker-Metadaten (container, compose_service, compose_project) als
  Loki-Labels via discovery.relabel.
- .env-Variablen auf GRAFANA_ADMIN_USER/GRAFANA_ADMIN_PASSWORD vereinheitlicht,
  .env.example ergaenzt, .env bleibt ungetrackt.
- prometheus.yml kommentiert (Remote-Write-Quellen, Fremd-Stack-Targets),
  toten auskommentierten Matrix-Job entfernt.
- README mit Deployment, Struktur, externen Abhaengigkeiten und offenen
  Sicherheitspunkten (offene Ports 9090/3100/9100).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 12:13:01 +02:00
sorbandClaude Opus 5 00fb7f51d7 monitoring: Bestandsaufnahme des laufenden Stacks
Import des bisherigen Stands aus /opt/monitoring auf dem Operating-Host,
unveraendert. Images auf :latest, Grafana ohne Provisioning (Datasources und
Dashboards nur in der grafana.db), keine Dokumentation.

Dient als Ausgangspunkt fuer den Umbau auf einen vollstaendig
provisionierbaren Stack.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-30 12:12:11 +02:00