Thomas Peetz
162 lines
3.4 KiB
Markdown
162 lines
3.4 KiB
Markdown
---
|
||
tags:
|
||
- process/task
|
||
reference:
|
||
- "[[Managed Services Team]]"
|
||
---
|
||
## 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
|
||
|
||
- [x] Monitoring - Next Steps [completion:: 2026-04-29]
|