3.4 KiB
3.4 KiB
tags, reference
| tags | reference | ||
|---|---|---|---|
|
|
Aufgabenbeschreibung
🧾 Kurzfassung
Ziel des Meetings war die Definition eines standardisierten Monitoring-Ansatzes (Prometheus/Grafana-basiert), der als wiederverwendbare Baseline für verschiedene Kunden (z. B. Hoyer, GStA, Hamburg Wasser) dient und zukünftig effizient ausgerollt werden kann.
🎯 Ziele
- Aufbau eines einheitlichen Monitoring-Stacks
- Ablösung/Ergänzung bestehender Lösungen (z. B. CheckMK)
- Wiederverwendbarkeit & Standardisierung für alle Kunden
- Reduktion von Implementierungsaufwand bei neuen Projekten
🏗️ Technischer Ansatz (Baseline)
- Betrieb über Docker (Container-basiert)
- Basis-Komponenten:
- Prometheus
- Grafana
- Alertmanager
- Enthält bereits:
- Grund-Dashboards (CPU, Disk, etc.)
- Basis-Alerting
- vorkonfigurierte Kommunikation zwischen Komponenten
- Deployment über Git-Repository inkl. Konfiguration & Secrets (Ansible Vault)
👉 Grundprinzip:
80 % Standard (Baseline), 20 % kundenspezifische Anpassungen
🧩 Vorgehen
1. Baseline erstellen
- Ausgangspunkt: bestehendes Repo (Messe München)
- Schritte:
- Repo klonen
- Kunden-spezifische Teile entfernen
- neutrales Basis-Repository erstellen
👉 Verantwortlich: Marcel
2. Lokale Testumgebung
- Aufbau einer VM mit Docker bei euch intern
- Ziel:
- Testen des Setups
- Know-how im Team aufbauen (Configs, Alerts, Container)
3. Rollout bei Kunden
Zielkunden:
- GStA
- Hoyer
Unterschied:
- GStA: später relevant (noch Entwicklung)
- Hoyer: kurzfristiger Bedarf
Bereitstellung:
- per Git (wenn Zugriff möglich)
- oder als Export (offline Szenarien)
🔧 Erweiterungen / Roadmap
Loki (Logging)
- Einführung von Loki für Log-Monitoring
- Vorgehen:
- zunächst intern ausprobieren (Proof of Concept)
- später Integration in Baseline
👉 Ziel: Logs in Grafana sichtbar machen
👉 Verantwortlich: Bastian (+ Team)
Weitere geplante Erweiterungen
- RabbitMQ Monitoring
- Integration zusätzlicher Exporter (je nach Kunde)
- Perspektivisch Kubernetes-Unterstützung
🧪 Hamburg Wasser (Spezialfall)
- Bereits bestehendes Monitoring vorhanden
- Vorgehen:
- vorsichtiges Vorgehen (keine „Experimente“ im Live-System)
- zunächst Loki separat vorbereiten
- später Integration abstimmen
Besonderheit:
- kein Internetzugang → Deployment erschwert (Container-Import notwendig)
📅 Zeitplan (grob)
- ~1–2 Wochen:
- erste Baseline-Version
- interne Testumgebung
- parallel:
- Loki Proof-of-Concept
- danach:
- erste Einsätze bei Kunden
- iterative Erweiterung
👥 Aufgabenverteilung
- Marcel
- Erstellung der Baseline
- Repo-Aufbau
- Frank
- CIP-Struktur & Dokumentation
- Bastian
- Loki evaluieren und implementieren
- Logs in Grafana integrieren
- Team
- Mitwirken bei Tests & Dokumentation
- Know-how-Aufbau im Umgang mit Docker & Monitoring
✅ Nutzen / Ergebnis
- Einheitliches Monitoring für alle Kunden
- Schnellere Rollouts (quasi „Monitoring per Install.exe“)
- Weniger Aufwand und Kosten pro Kunde
- Bessere Wartbarkeit & Transparenz
- Basis für zukünftige Erweiterungen (Observability, Kubernetes)
Überlegungen
Unteraufgaben
- Monitoring - Next Steps [completion:: 2026-04-29]