From 6ffab685832b071f6610cfbf8f8a1893efe06bba Mon Sep 17 00:00:00 2001 From: sorb Date: Sat, 1 Aug 2026 03:47:18 +0200 Subject: [PATCH] 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 --- monitoring/docker-compose.yml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/monitoring/docker-compose.yml b/monitoring/docker-compose.yml index fbddb8a..f59342c 100644 --- a/monitoring/docker-compose.yml +++ b/monitoring/docker-compose.yml @@ -45,8 +45,15 @@ services: - MATRIX_HOMESERVER=${MATRIX_ALERT_HOMESERVER} - MATRIX_ROOM_ID=${MATRIX_ALERT_ROOM_ID} - MATRIX_TOKEN=${MATRIX_ALERT_TOKEN} + # Ohne das liegt der State unter /tmp im Writable Layer: der ueberlebt + # zwar ein "compose restart", aber kein "up -d", das den Container neu + # baut -- also genau jeden Deploy. Dann verlieren offene Alarme ihre + # Event-Zuordnung und loesen sich ueber den Fallback als separate + # Nachricht auf, statt die Firing-Nachricht abzuhaken. + - MATRIX_STATE_FILE=/state/matrix-alerts-state.json volumes: - ./alertmanager/matrix-alerts.py:/app/matrix-alerts.py:ro + - matrix_alerts_data:/state command: python3 /app/matrix-alerts.py networks: - traefik @@ -137,6 +144,7 @@ services: volumes: prometheus_data: alertmanager_data: + matrix_alerts_data: grafana_data: loki_data: alloy_data: