Inhaltsverzeichnis
1. Übersicht & Architektur
1.1 Zielsetzung
Das IT Management Monitor & Dashboard Add-on ist eine eigenständige Applikation, die auf demselben RKE2-Kubernetes-Cluster (VMware vSphere) wie das Hauptportal betrieben wird. Es erweitert den bestehenden Prometheus + Grafana Stack um eine umfassende IT-Infrastruktur-Überwachung mit proaktivem Alerting, Kapazitätsplanung und CMDB-Light-Funktionalität.
1.2 Design-Prinzipien
| Prinzip | Umsetzung |
|---|---|
| Eigenständige Applikation | Separates Deployment im Namespace hafs-monitor, eigener Lifecycle |
| Portal-Integration via REST | Anbindung an das Hauptportal über definierte REST APIs |
| Prometheus + Grafana Basis | Erweiterung des bestehenden Monitoring-Stacks (VLAN 60) |
| Event-Driven Alerting | Alerts via RabbitMQ Event Bus an Portal-Ticketsystem |
| CMDB-Light | Schlanke Configuration Management Database ohne ITIL-Overhead |
| AI-gestützte Anomalie-Erkennung | Metriken-Analyse über Claude API für proaktive Warnungen |
1.3 Architektur-Übersicht
IT Management Monitor & Dashboard – Gesamtarchitektur
┌──────────────────────────────────────────────────────────────────┐
│ IT MANAGEMENT MONITOR & DASHBOARD ADD-ON │
│ (Namespace: hafs-monitor) │
│ │
│ ┌─── Frontend ────────────────────────────────────────────┐ │
│ │ │ │
│ │ React Dashboard App (eigenständig) │ │
│ │ • Infrastruktur-Dashboard • Service Health Map │ │
│ │ • Capacity Planning • Executive Dashboard │ │
│ │ • CMDB-Light UI • SLA Monitoring │ │
│ │ • Alerting-Konfiguration • Runbook UI │ │
│ └────────────────────────┬─────────────────────────────────┘ │
│ │ REST API │
│ ┌────────────────────────▼─────────────────────────────────┐ │
│ │ Backend: Node.js / TypeScript (Data Aggregation Layer) │ │
│ │ │ │
│ │ ┌────────────┐ ┌──────────┐ ┌─────────────────────────┐│ │
│ │ │ Infra │ │ Alert │ │ CMDB-Light ││ │
│ │ │ Collector │ │ Engine │ │ Service ││ │
│ │ └────────────┘ └──────────┘ └─────────────────────────┘│ │
│ │ ┌────────────┐ ┌──────────┐ ┌─────────────────────────┐│ │
│ │ │ Capacity │ │ SLA │ │ Runbook ││ │
│ │ │ Planner │ │ Tracker │ │ Executor ││ │
│ │ └────────────┘ └──────────┘ └─────────────────────────┘│ │
│ └──────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌──────────────────┼──────────────────┐ │
│ │ │ │ │
│ ┌─────▼──────┐ ┌───────▼───────┐ ┌──────▼───────────────┐ │
│ │ PostgreSQL │ │ Prometheus │ │ Grafana │ │
│ │ (CMDB- │ │ (Metriken) │ │ (Dashboards) │ │
│ │ Light DB) │ │ │ │ │ │
│ └────────────┘ └──────────────┘ └────────────────────────┘ │
│ │
│ ┌─── Externe Datenquellen ────────────────────────────────┐ │
│ │ │ │
│ │ VMware vSphere API │ Kubernetes API │ SNMP (Netzwerk) │ │
│ │ SAN/Storage API │ MinIO API │ Active Directory │ │
│ └──────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
│
│ REST API + RabbitMQ Events
▼
┌──────────────────────────────────────────────────────────────────┐
│ HAFS SELF-HELP SERVICE PORTAL │
│ │
│ Tickets (M1) │ AI Services (M2) │ Automation (M7) │
│ Asset Mgmt (M9) │ Analytics (M8) │ Notification Service │
└──────────────────────────────────────────────────────────────────┘
1.4 Tech Stack
| Komponente | Technologie | Begründung |
|---|---|---|
| Backend | Node.js 22 / TypeScript | Async I/O ideal für Metriken-Aggregation, Prometheus Client Libraries |
| Frontend | React 19 + Tailwind CSS + Shadcn/UI | Konsistenz mit Portal-Frontend, Rich-Dashboards |
| Datenbank (CMDB) | PostgreSQL 16 (Patroni HA) | Relationale CMDB-Daten, bestehende Infrastruktur |
| Metriken | Prometheus + Alertmanager | Bereits im Cluster deployed (VLAN 60, 10.60.1.x) |
| Dashboards | Grafana | Bereits im Cluster deployed (VLAN 60, 10.60.2.x) |
| Time-Series (Langzeit) | Prometheus + Thanos (optional) | Langzeitdaten für Capacity Planning |
| Message Bus | RabbitMQ | Alert-Events an Portal-Ticketsystem |
| Runbook Execution | Ansible + Terraform | Bestehende IaC-Toolchain |
| AI/Anomalie | Anthropic Claude API (Sonnet 4.5) | Anomalie-Erkennung, Kapazitätsprognosen |
1.5 Kubernetes Deployment
Namespace hafs-monitor – Deployment-Struktur
Namespace: hafs-monitor ├── monitor-backend # Node.js Backend (3 Replicas) ├── monitor-frontend # React Dashboard (2 Replicas) ├── monitor-collector # Infrastruktur-Datensammler (CronJob + Daemon) ├── monitor-alert-engine # Alert-Verarbeitung (2 Replicas) ├── monitor-runbook-worker # Runbook-Ausführung (1-3 Replicas, KEDA) ├── monitor-cmdb-db # PostgreSQL (eigene Instanz oder Schema) └── monitor-config # ConfigMaps + Secrets
2. Infrastruktur-Dashboard
2.1 VMware vSphere Monitoring
Integration über die vSphere REST API (vCenter Server) sowie den Prometheus VMware Exporter.
vSphere Monitoring – Datenquellen & überwachte Objekte
┌──────────────────────────────────────────────────────────────────┐ │ VSPHERE MONITORING │ │ │ │ ┌─── Datenquellen ───────────────────────────────────────┐ │ │ │ │ │ │ │ vCenter Server (10.10.1.x) │ │ │ │ ├── vSphere REST API (HTTPS) │ │ │ │ ├── vSphere Performance Manager (Metriken) │ │ │ │ └── vSphere Events & Alarms │ │ │ │ │ │ │ │ Prometheus VMware Exporter │ │ │ │ └── Scrape-Intervall: 60s │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── Überwachte Objekte ────────────────────────────────┐ │ │ │ │ │ │ │ ESXi Hosts VMs Datastores │ │ │ │ ─────────── ── ────────── │ │ │ │ • CPU (MHz, %) • CPU Ready Time • Kapazität │ │ │ │ • Memory (Usage, • Memory Balloon • Freier Platz │ │ │ │ Swap) • Disk I/O • IOPS │ │ │ │ • Network (TX/RX) • Network I/O • Latenz │ │ │ │ • Hardware Health • Snapshot-Größe • Provisioning │ │ │ │ • Temperature • Uptime • Thin/Thick │ │ │ │ • Power State • Guest OS Status │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
| Metrik | Quelle | Prometheus Metrik | Alert-Schwelle |
|---|---|---|---|
| ESXi CPU-Auslastung | vSphere API | vsphere_host_cpu_usage_percent | Warning: >80%, Critical: >95% |
| ESXi Memory | vSphere API | vsphere_host_memory_usage_percent | Warning: >85%, Critical: >95% |
| VM CPU Ready | vSphere API | vsphere_vm_cpu_ready_ms | Warning: >5%, Critical: >10% |
| Datastore Kapazität | vSphere API | vsphere_datastore_free_bytes | Warning: <20%, Critical: <10% |
| VM Snapshot Alter | vSphere API | vsphere_vm_snapshot_age_hours | Warning: >24h, Critical: >72h |
| Hardware Health | vSphere API | vsphere_host_hardware_status | Critical: Degraded/Failed |
2.2 Kubernetes Monitoring
Erweiterung des bestehenden Prometheus-Stacks mit spezifischen Dashboards für IT-Management.
| Metrik-Bereich | Prometheus Quelle | Überwachte Werte |
|---|---|---|
| Cluster Health | kube-state-metrics | Node Status, Pod Restarts, Failed Deployments |
| Nodes | node-exporter | CPU, Memory, Disk, Network pro Node |
| Pods | cAdvisor + kube-state-metrics | Container CPU/Mem, Restarts, OOMKills |
| Deployments | kube-state-metrics | Desired vs. Available Replicas, Rollout Status |
| Persistent Volumes | kube-state-metrics | PV/PVC Status, Kapazität, Bound State |
| Ingress | NGINX Ingress Metrics | Request Rate, Error Rate, Latenz |
| Resource Quotas | kube-state-metrics | Namespace Limits vs. Nutzung |
2.3 Netzwerk-Monitoring
Netzwerk Monitoring – SNMP Polling & Metriken
┌──────────────────────────────────────────────────────────────────┐ │ NETZWERK MONITORING │ │ │ │ ┌─── SNMP Polling ───────────────────────────────────────┐ │ │ │ │ │ │ │ Prometheus SNMP Exporter │ │ │ │ ├── Core Switches (VLAN-Trunks, Uplinks) │ │ │ │ ├── Access Switches (Port-Status, PoE) │ │ │ │ ├── Router / Firewall (Interface-Metriken) │ │ │ │ └── Scrape-Intervall: 30s │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── Metriken ───────────────────────────────────────────┐ │ │ │ │ │ │ │ Bandbreite (In/Out) │ Packet Loss │ │ │ │ Interface Status │ CRC Errors │ │ │ │ Latenz (ICMP/SLA) │ VLAN Health │ │ │ │ BGP/OSPF Neighbor │ ARP Table Size │ │ │ │ CPU/Memory (Switch) │ Port Flapping │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
| Netzwerk-Alert | Bedingung | Severity |
|---|---|---|
| Interface Down | ifOperStatus != up | Critical |
| High Bandwidth | Auslastung > 80% über 5 min | Warning |
| Packet Loss | Loss > 1% über 5 min | Warning |
| Packet Loss | Loss > 5% über 2 min | Critical |
| Port Flapping | > 3 State Changes in 5 min | Warning |
| Switch CPU | > 85% über 10 min | Warning |
| BGP Neighbor Down | BGP State != Established | Critical |
2.4 Storage Monitoring
| Storage-System | Monitoring-Methode | Metriken |
|---|---|---|
| SAN (FC/iSCSI) | Hersteller-API / SNMP | LUN-Kapazität, IOPS, Latenz, Throughput, Cache Hit Rate |
| MinIO (10.30.3.x) | MinIO Prometheus Endpoint | Bucket-Größe, Object Count, Request Rate, Healing Status |
| VMware Datastores | vSphere API | Kapazität, Provisioned Space, I/O Latenz |
| Persistent Volumes | Kubernetes API | PV-Kapazität, Nutzung, Status |
| Backup (Veeam) | Veeam API / SNMP | Backup-Status, RPO-Einhaltung, Repository-Kapazität |
portal.hafs.de/monitoring/infrastructure
247
Überwachte Systeme
239
Healthy
+2 seit gestern
5
Degraded
+1 seit gestern
3
Down
+1 seit gestern
Systemgruppen – Health-Status
Windows Server
98 %
1 Server degraded: SRV-WIN-FIN-03 (hohe CPU)
Linux Server
96 %
2 degraded, 1 down (SRV-LX-BATCH-07)
Netzwerk-Geräte
92 %
2 Switches degraded, 2 Firewalls hohe Latenz
Storage
99 %
Alle Datastores im grünen Bereich
Kubernetes
94 %
1 Pod CrashLoopBackOff: monitor-collector-7b
Infrastruktur-Dashboard – Echtzeit-Übersicht aller überwachten Systeme mit Health-Status pro Kategorie
3. Service Health Map
3.1 Konzept
Die Service Health Map visualisiert sämtliche IT-Services und deren Abhängigkeiten als interaktive Karte mit Echtzeit-Gesundheitsstatus.
Service Health Map – Abhängigkeitsvisualisierung
┌──────────────────────────────────────────────────────────────────┐ │ SERVICE HEALTH MAP │ │ │ │ ┌──────────────┐ │ │ │ Self-Help │ │ │ │ Portal │ │ │ │ [GRÜN] │ │ │ └──────┬───────┘ │ │ ┌────────────┼────────────┐ │ │ │ │ │ │ │ ┌─────▼────┐ ┌────▼─────┐ ┌────▼─────┐ │ │ │ Ticket │ │ AI │ │ Identity │ │ │ │ Service │ │ Gateway │ │ Service │ │ │ │ [GRÜN] │ │ [GRÜN] │ │ [GELB] │ │ │ └─────┬────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ ┌─────▼────┐ ┌────▼─────┐ ┌────▼─────┐ │ │ │PostgreSQL│ │Anthropic │ │ Active │ │ │ │ Patroni │ │ Claude │ │ Directory│ │ │ │ [GRÜN] │ │ API │ │ [GELB] │ │ │ └─────┬────┘ │ [GRÜN] │ └──────────┘ │ │ │ └──────────┘ │ │ ┌─────▼────┐ │ │ │ SAN │ │ │ │ Storage │ │ │ │ [GRÜN] │ │ │ └──────────┘ │ │ │ │ Legende: [GRÜN] = Healthy [GELB] = Degraded │ │ [ROT] = Down [GRAU] = Unknown │ └──────────────────────────────────────────────────────────────────┘
3.2 Health Status Berechnung
| Status | Farbe | Bedingung | Beispiel |
|---|---|---|---|
| Healthy | Grün | Alle Checks OK, Latenz normal | Service antwortet < p95 SLA |
| Degraded | Gelb | Teilweise Einschränkung, erhöhte Latenz | 1 von 3 Replicas down |
| Down | Rot | Service nicht erreichbar oder kritischer Fehler | Alle Pods in CrashLoopBackOff |
| Unknown | Grau | Keine Metriken verfügbar | Exporter nicht erreichbar |
| Maintenance | Blau | Geplante Wartung aktiv | Maintenance Window aktiv |
3.3 Auto-Discovery
Auto-Discovery Engine – Quellen und CMDB-Anbindung
┌──────────────────────────────────────────────────────────────────┐ │ AUTO-DISCOVERY ENGINE │ │ │ │ Quellen: │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────────────┐ │ │ │ Kubernetes │ │ VMware │ │ SNMP │ │ │ │ API │ │ vSphere API │ │ Walk │ │ │ │ │ │ │ │ │ │ │ │ • Services │ │ • VMs │ │ • Switches │ │ │ │ • Deployments│ │ • Hosts │ │ • Router │ │ │ │ • Ingress │ │ • Datastores │ │ • Drucker │ │ │ │ • ConfigMaps │ │ • Netzwerke │ │ • USV │ │ │ │ (Labels) │ │ │ │ │ │ │ └──────┬───────┘ └──────┬───────┘ └──────────┬───────────┘ │ │ │ │ │ │ │ └──────────────────┼──────────────────────┘ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Discovery Engine │ │ │ │ │ │ │ │ • Neue CIs │ │ │ │ registrieren │ │ │ │ • Dependencies │ │ │ │ erkennen │ │ │ │ • Status │ │ │ │ aktualisieren │ │ │ └────────┬─────────┘ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ CMDB-Light │ │ │ │ (PostgreSQL) │ │ │ └──────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
Discovery wird als CronJob alle 15 Minuten ausgeführt. Neue Configuration Items (CIs) werden automatisch registriert und bestehende aktualisiert.
3.4 Impact-Visualisierung
Bei Ausfall einer Komponente zeigt die Health Map die Auswirkungskaskade:
| Ausgefallene Komponente | Direkt betroffen | Indirekt betroffen |
|---|---|---|
| PostgreSQL Patroni Cluster | Ticket Service, Governance Service | Portal Frontend (Tickets nicht ladbar) |
| Active Directory DC | Identity Service, Security Service | Alle Portal-Logins, PAM-Sessions |
| SAN Storage | Datastores, VMs auf betroffenem LUN | Alle Services auf betroffenen VMs |
| Core Switch (VLAN 20) | Kubernetes Cluster Netzwerk | Alle Portal-Services |
| RabbitMQ Cluster | Async-Kommunikation, Alert-Events | Ticket-Benachrichtigungen, AI-Triage |
portal.hafs.de/monitoring/service-map
Applikationsschicht
Trading App
Portfolio Mgmt
Reporting
↓↓↓
Service-Schicht
API Gateway
Auth Service
Cache Layer
↓↓↓
Infrastruktur-Schicht
Database Cluster
Message Queue
Storage
Auth Service Degraded
auth-svc.hafs-portal.svc.cluster.local
847ms
Response Time
↑ 340 % vs. normal
4.2 %
Error Rate
↑ von 0.1 %
14:23 Response-Zeit überschreitet Schwellenwert
14:25 Error Rate steigt auf 3.8 %
14:27 Auto-Scaling aktiviert (3 → 5 Pods)
14:31 Noch erhöhte Latenz trotz Skalierung
KI-Analyse: Erhöhte Latenz korreliert mit Message-Queue-Ausfall. Auth Service wartet auf Bestätigungen von RabbitMQ. Empfehlung: Fallback-Modus ohne Queue-Bestätigung aktivieren.
Message Queue Down
rabbitmq.hafs-infra.svc.cluster.local
0 %
Verfügbarkeit
14:21
Ausfall seit
Runbook ausführen
Ticket erstellen
Service Health Map – Abhängigkeitskarte mit Echtzeit-Status und Detail-Panel für degradierte Services
4. Capacity Planning
4.1 Ressourcen-Tracking
Capacity Planning Dashboard – CPU-Trend & Ressourcen-Übersicht
┌──────────────────────────────────────────────────────────────────┐ │ CAPACITY PLANNING DASHBOARD │ │ │ │ ┌─── CPU Trend (90 Tage) ────────────────────────────────┐ │ │ │ │ │ │ │ 100% ┤ ···· │ │ │ │ 90% ┤ ── Schwelle 90% ──────────────── ····· │ │ │ │ 80% ┤ ── Schwelle 80% ──── ····· │ │ │ │ 70% ┤ ···· │ │ │ │ 60% ┤ ···· │ │ │ │ 50% ┤ ···· │ │ │ │ 40% ┤···· │ │ │ │ └──┬────┬────┬────┬────┬────┬────┬────┬────┬──► │ │ │ │ -90d -75d -60d -45d -30d -15d Heute +15d +30d │ │ │ │ │ │ │ │ ─── Aktuell (Ist) ···· Prognose (Trend) │ │ │ │ │ │ │ │ Prognose: 80%-Schwelle erreicht in ~22 Tagen │ │ │ │ Empfehlung: Worker-Node hinzufügen oder HPA anpassen │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── Ressourcen-Übersicht ──────────────────────────────┐ │ │ │ │ │ │ │ Ressource Aktuell Trend 80%-Datum Aktion │ │ │ │ ───────── ─────── ───── ───────── ────── │ │ │ │ Cluster CPU 62% ↑ +3%/M 22 Tage Warnung │ │ │ │ Cluster Memory 71% ↑ +2%/M 45 Tage Beobachten │ │ │ │ SAN Storage 55% ↑ +5%/M 50 Tage Beobachten │ │ │ │ MinIO Storage 38% ↑ +8%/M 53 Tage Beobachten │ │ │ │ Network (Uplink)22% → stabil — OK │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
4.2 Prognose-Methodik
| Methode | Beschreibung | Einsatz |
|---|---|---|
| Lineare Regression | Trendberechnung über gleitenden Durchschnitt | Standard-Kapazitätsprognose |
| Saisonale Zerlegung | Erkennung von Wochen-/Monatsmustern | Workload-Spitzen vorhersagen |
| AI-gestützte Analyse | Claude Sonnet 4.5 analysiert Metriken-Kontext | Komplexe Zusammenhänge, Empfehlungen |
| What-If Szenarien | Simulation bei Hinzufügen/Entfernen von Ressourcen | Planungsentscheidungen |
4.3 Schwellenwert-Alerting
| Schwelle | Severity | Aktion |
|---|---|---|
| 80% Auslastung | Warning (Info) | Dashboard-Markierung, Kapazitäts-Ticket (P4) erstellen |
| 90% Auslastung | Warning | Teams-Benachrichtigung an Infra-Team, Ticket (P3) |
| 95% Auslastung | Critical | Sofortige Eskalation an IT-Leitung, Ticket (P2) |
| Prognose: 80% in <30 Tagen | Info | Planungshinweis an Capacity Manager |
| Prognose: 95% in <14 Tagen | Warning | Dringende Kapazitätserweiterung angefordert |
4.4 Right-Sizing Empfehlungen
Das System analysiert die tatsächliche Nutzung gegenüber der zugewiesenen Kapazität und gibt Empfehlungen:
| Empfehlungstyp | Bedingung | Beispiel |
|---|---|---|
| Oversized VM | CPU < 20% und Memory < 30% über 30 Tage | VM app-server-03: 8 vCPU → 4 vCPU empfohlen |
| Undersized VM | CPU > 80% oder Memory > 85% wiederholt | VM db-replica-02: 16 GB RAM → 32 GB empfohlen |
| Idle Resources | CPU < 5% und keine Netzwerk-Aktivität über 14 Tage | VM test-legacy-01: Decommissioning prüfen |
| K8s Pod Limits | Request/Limit-Verhältnis außerhalb Best Practice | Pod ai-gateway: Memory Limit zu niedrig (OOMKill) |
portal.hafs.de/monitoring/capacity
Ressourcen-Auslastung (Durchschnitt)
Top 5 Ressourcen-Verbraucher
| Server | Typ | CPU % | Mem % | Disk % | Trend |
|---|---|---|---|---|---|
| SRV-DB-01 | PostgreSQL Primary | 94 % | 91 % | 76 % | ↑ steigend |
| SRV-APP-TRADE-02 | Trading Engine | 82 % | 79 % | 45 % | ↑ steigend |
| SRV-BATCH-07 | Batch Processing | 78 % | 85 % | 52 % | → stabil |
| SRV-CACHE-03 | Redis Cluster | 45 % | 92 % | 12 % | ↑ steigend |
| SRV-ELASTIC-01 | Elasticsearch | 56 % | 74 % | 81 % | ↑ steigend |
KI-Prognose: Basierend auf aktuellem Trend wird die Disk-Kapazität von SRV-DB-01 in 14 Tagen erschöpft sein. Empfehlung: Datastore-Erweiterung um mindestens 500 GB einplanen oder archivierte Daten auf Cold Storage migrieren. Memory von SRV-CACHE-03 erreicht in ca. 21 Tagen das Limit – Redis-Eviction-Policy prüfen.
Capacity Planning – Ressourcen-Auslastung mit Top-Verbrauchern und KI-gestützter Kapazitätsprognose
5. Alerting Engine
5.1 Architektur
Alert Processing Pipeline – Von Quelle bis Ausgabe
┌──────────────────────────────────────────────────────────────────┐ │ ALERTING ENGINE │ │ │ │ ┌─── Quellen ─────────────────────────────────────────────┐ │ │ │ │ │ │ │ Prometheus vSphere Events SNMP Traps │ │ │ │ Alertmanager K8s Events Custom Health │ │ │ │ Checks │ │ │ └─────────────────────────┬────────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ ALERT PROCESSING PIPELINE │ │ │ │ │ │ │ │ 1. Ingestion → Alle Alerts empfangen │ │ │ │ 2. Deduplication → Doppelte Alerts entfernen │ │ │ │ 3. Correlation → Zusammengehörende Alerts gruppieren │ │ │ │ 4. Enrichment → CMDB-Daten, Impact-Analyse │ │ │ │ 5. Classification→ Severity bestimmen (Info→Emergency) │ │ │ │ 6. Suppression → Maintenance Windows prüfen │ │ │ │ 7. Routing → An richtige Teams/Kanäle senden │ │ │ │ 8. Escalation → Timeout-basierte Eskalation │ │ │ └─────────────────────────┬────────────────────────────────┘ │ │ ▼ │ │ ┌─── Ausgabe-Kanäle ─────────────────────────────────────┐ │ │ │ │ │ │ │ Teams Webhook │ E-Mail │ PagerDuty │ Portal-Ticket │ │ │ │ RabbitMQ Event │ Grafana Annotation │ Runbook-Trigger │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
5.2 Alert-Severity-Level
| Level | Farbe | Beschreibung | Beispiel | Reaktionszeit |
|---|---|---|---|---|
| Info | Blau | Informativer Hinweis, keine Aktion nötig | Backup erfolgreich abgeschlossen | Keine |
| Warning | Gelb | Potentielles Problem, Beobachtung nötig | CPU-Auslastung > 80% seit 10 min | < 4h |
| Critical | Orange | Service beeinträchtigt, zeitnahe Aktion | Datenbank-Replikation verzögert > 5 min | < 1h |
| Emergency | Rot | Service ausgefallen, sofortige Aktion | PostgreSQL Cluster nicht erreichbar | < 15 min |
5.3 Alert-Routing-Regeln
Alert Routing – Regeln nach Team und Severity
┌──────────────────────────────────────────────────────────────────┐ │ ALERT ROUTING REGELN │ │ │ │ Regel 1: Infrastructure Alerts │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Match: label.team == "infrastructure" │ │ │ │ Route: → Teams: #infra-alerts │ │ │ │ → E-Mail: infra-team@hafs.de │ │ │ │ → Portal-Ticket (ab Warning) │ │ │ │ Escal: 30 min → On-Call Infra Lead │ │ │ │ 60 min → IT-Leitung │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Regel 2: Application Alerts │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Match: label.team == "application" │ │ │ │ Route: → Teams: #app-alerts │ │ │ │ → E-Mail: dev-team@hafs.de │ │ │ │ → Portal-Ticket (ab Warning) │ │ │ │ Escal: 30 min → Dev Lead │ │ │ │ 60 min → IT-Leitung │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Regel 3: Security Alerts │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Match: label.team == "security" │ │ │ │ Route: → Teams: #security-alerts (immer) │ │ │ │ → PagerDuty (ab Critical) │ │ │ │ → Portal Security-Ticket (immer) │ │ │ │ Escal: 15 min → CISO │ │ │ │ 30 min → IT-Geschäftsführung │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ Regel 4: Emergency (alle Teams) │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Match: severity == "emergency" │ │ │ │ Route: → PagerDuty (sofort) │ │ │ │ → Teams: #it-emergency │ │ │ │ → SMS an On-Call │ │ │ │ → Portal P1-Ticket (Auto-Create) │ │ │ │ Escal: 10 min → IT-Leitung + Geschäftsführung │ │ │ └─────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
5.4 Eskalationsketten
| Eskalationsstufe | Timeout | Benachrichtigung | Aktion |
|---|---|---|---|
| L1: On-Call Team | 0 min | Teams + E-Mail | Alert wird zugewiesen |
| L2: Team Lead | 30 min (Warning), 15 min (Critical) | Teams + E-Mail + Telefon | Eskalation bei fehlender Reaktion |
| L3: IT-Leitung | 60 min (Warning), 30 min (Critical) | PagerDuty + SMS | Management informiert |
| L4: Geschäftsführung | 120 min (Critical), 30 min (Emergency) | Telefon + SMS | Executive Escalation |
5.5 Alert-Deduplizierung und Korrelation
| Mechanismus | Beschreibung |
|---|---|
| Fingerprinting | Alerts mit identischem Source + Metrik + Labels werden dedupliziert |
| Grouping | Alerts vom selben Host/Service werden zu einem Alert-Cluster zusammengefasst |
| Correlation | Kausale Zusammenhänge erkennen (z.B. Disk Full → DB Fehler → Service Down) |
| Flap Detection | Schnell wechselnde Alerts (OK→FAIL→OK) werden als Flapping markiert |
| Root Cause Analysis | AI-gestützte Ursachenanalyse bei korrelierenden Alerts |
5.6 Maintenance Windows
| Funktion | Beschreibung |
|---|---|
| Geplante Wartung | Zeitfenster definieren, in dem Alerts unterdrückt werden |
| Scope | Pro Host, Service, Namespace oder Cluster-weit |
| Auto-Suppress | Alerts werden gesammelt aber nicht eskaliert |
| Post-Maintenance | Nach Fenster-Ende: Automatische Health-Prüfung aller betroffenen Services |
| Change-Integration | Verknüpfung mit Change Management (M10) – Maintenance Window aus Change Request |
portal.hafs.de/monitoring/alerts/rules
| Name | Metrik | Bedingung | Schwellenwert | Severity | Status | Benachrichtigung | |
|---|---|---|---|---|---|---|---|
| CPU High Usage | cpu_usage_percent |
größer als | 90 % | Critical | Aktiv | Slack, E-Mail, PagerDuty | ✎ |
| Memory High Usage | memory_usage_percent |
größer als | 85 % | Warning | Aktiv | Slack, E-Mail | ✎ |
| Disk Space Low | disk_usage_percent |
größer als | 80 % | Warning | Aktiv | Slack, E-Mail | ✎ |
| Response Time Slow | http_response_time_ms |
größer als | 2.000 ms | Critical | Aktiv | Slack, PagerDuty, Ticket | ✎ |
| Error Rate High | http_error_rate_percent |
größer als | 5 % | Critical | Aktiv | Slack, E-Mail, PagerDuty | ✎ |
| Pod Restarts Frequent | kube_pod_restart_count |
größer als | 3 / 15 min | Warning | Deaktiviert | Slack | ✎ |
6 Regeln · 5 aktiv · 1 deaktiviert
Letzte Auswertung: vor 30 Sekunden
Alert-Konfiguration – Verwaltung von Schwellenwert-Regeln mit Severity-Stufen und Benachrichtigungskanälen
6. SLA Monitoring
6.1 Service-Verfügbarkeit
SLA Monitoring Dashboard – Verfügbarkeit & Uptime
┌──────────────────────────────────────────────────────────────────┐ │ SLA MONITORING DASHBOARD │ │ │ │ ┌─── Aktueller Monat (Februar 2026) ─────────────────────┐ │ │ │ │ │ │ │ Service SLA-Ziel Aktuell Status │ │ │ │ ─────── ──────── ─────── ────── │ │ │ │ Portal Frontend 99.9% 99.97% [OK] │ │ │ │ API Services 99.9% 99.94% [OK] │ │ │ │ AI Gateway 99.5% 99.82% [OK] │ │ │ │ Ticket System 99.9% 99.91% [OK] │ │ │ │ Identity Service 99.9% 99.45% [WARNUNG] │ │ │ │ Datenbank (PG) 99.99% 99.998% [OK] │ │ │ │ Message Bus 99.9% 99.99% [OK] │ │ │ │ Knowledge Search 99.5% 99.71% [OK] │ │ │ │ │ │ │ │ Gesamt-Verfügbarkeit Portal: 99.87% │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── Uptime letzte 12 Monate ────────────────────────────┐ │ │ │ │ │ │ │ Mrz Apr Mai Jun Jul Aug Sep Okt Nov Dez Jan Feb │ │ │ │ █ █ █ █ █ ▓ █ █ █ █ █ █ │ │ │ │ │ │ │ │ █ = SLA eingehalten ▓ = SLA verletzt │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
6.2 Response-Time Monitoring
| Service | p50 Ziel | p95 Ziel | p99 Ziel | Messmethode |
|---|---|---|---|---|
| Portal Frontend (TTFB) | < 200ms | < 500ms | < 1s | Synthetic Monitoring (alle 60s) |
| REST API (Ticket CRUD) | < 100ms | < 300ms | < 800ms | OpenTelemetry Traces |
| AI Gateway (Chat Response) | < 2s | < 5s | < 10s | OpenTelemetry + Custom Metrics |
| Knowledge Search | < 150ms | < 500ms | < 1s | Elasticsearch Query Metrics |
| Authentication (Login) | < 300ms | < 800ms | < 2s | LDAP + OIDC Latenz |
6.3 SLA-Breach-Prognose
Das System berechnet basierend auf dem aktuellen Ausfallbudget eine Prognose:
| Berechnung | Formel |
|---|---|
| Erlaubte Ausfallzeit/Monat (99.9%) | 30 Tage x 24h x 60min x 0.1% = 43,2 Minuten |
| Verbrauchtes Budget | Summe aller Ausfallminuten im aktuellen Monat |
| Verbleibendes Budget | 43,2 min – Verbrauchtes Budget |
| Burn Rate | Verbrauchtes Budget / verstrichene Tage im Monat |
| Prognose SLA-Verletzung | Wenn Burn Rate > Budget / Restliche Tage |
6.4 Monatliche SLA-Reports
| Report-Inhalt | Beschreibung |
|---|---|
| Verfügbarkeits-Übersicht | Uptime pro Service (%, Minuten Downtime) |
| Incident-Zusammenfassung | Alle Ausfälle mit Dauer, Ursache, Resolution |
| Response-Time Analyse | Percentile-Verteilung (p50, p95, p99) pro Service |
| SLA-Trend | 12-Monats-Verlauf der Verfügbarkeit |
| Verbesserungsmaßnahmen | Geplante Actions aus Post-Incident-Reviews |
Reports werden automatisch am 1. jedes Monats generiert und per E-Mail an IT-Leitung und Service Owner versendet.
7. CMDB-Light
7.1 Datenmodell
CMDB-Light Datenmodell (PostgreSQL)
┌──────────────────────────────────────────────────────────────────┐ │ CMDB-LIGHT DATENMODELL (PostgreSQL) │ │ │ │ ┌─── Configuration Items (CIs) ──────────────────────────┐ │ │ │ │ │ │ │ ci_id UUID (PK) │ │ │ │ ci_type ENUM (server, vm, service, database, │ │ │ │ network_device, storage, application)│ │ │ │ name VARCHAR │ │ │ │ display_name VARCHAR │ │ │ │ description TEXT │ │ │ │ status ENUM (discovered, provisioned, │ │ │ │ active, maintenance, decommissioned) │ │ │ │ environment ENUM (production, staging, dev, test) │ │ │ │ location VARCHAR (RZ, Rack, Slot) │ │ │ │ owner_team VARCHAR │ │ │ │ criticality ENUM (low, medium, high, critical) │ │ │ │ attributes JSONB (flexible Attribute) │ │ │ │ discovered_at TIMESTAMPTZ │ │ │ │ last_seen TIMESTAMPTZ │ │ │ │ created_at TIMESTAMPTZ │ │ │ │ updated_at TIMESTAMPTZ │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── CI Relationships ────────────────────────────────────┐ │ │ │ │ │ │ │ relationship_id UUID (PK) │ │ │ │ source_ci_id UUID (FK → CIs) │ │ │ │ target_ci_id UUID (FK → CIs) │ │ │ │ relationship_type ENUM (depends_on, runs_on, │ │ │ │ connects_to, stores_data_on, │ │ │ │ managed_by, contains) │ │ │ │ auto_discovered BOOLEAN │ │ │ │ created_at TIMESTAMPTZ │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── CI Lifecycle Events ─────────────────────────────────┐ │ │ │ │ │ │ │ event_id UUID (PK) │ │ │ │ ci_id UUID (FK → CIs) │ │ │ │ event_type ENUM (discovered, status_change, │ │ │ │ attribute_change, relationship_change)│ │ │ │ old_value JSONB │ │ │ │ new_value JSONB │ │ │ │ source VARCHAR (auto-discovery, manual, api) │ │ │ │ timestamp TIMESTAMPTZ │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
7.2 CI-Typen und Attribute
| CI-Typ | Quelle (Auto-Discovery) | Wichtige Attribute |
|---|---|---|
| Server (ESXi Host) | vSphere API | CPU Cores, RAM, NICs, Firmware, Serial |
| VM | vSphere API | vCPUs, vRAM, Guest OS, IP-Adresse, Datastore |
| Kubernetes Service | K8s API | Namespace, Replicas, Image, Labels, Ports |
| Datenbank | K8s Labels + Port-Scan | Engine, Version, Port, HA-Status |
| Network Device | SNMP | Modell, Firmware, Ports, VLANs, IP |
| Storage (LUN/Bucket) | SAN API / MinIO API | Kapazität, RAID-Level, Protokoll |
| Application | K8s Ingress + Labels | URL, Service-Owner, Criticality |
7.3 Auto-Discovery Mapping
Auto-Discovery Quellen – CI-Mapping
┌──────────────────────────────────────────────────────────────────┐ │ AUTO-DISCOVERY MAPPING │ │ │ │ VMware vSphere API │ │ ├── Datacenter → Location │ │ ├── Cluster → Server-Gruppe │ │ ├── ESXi Host → CI Typ "server" │ │ ├── VM → CI Typ "vm" │ │ │ ├── VM → Host: "runs_on" │ │ │ └── VM → Datastore: "stores_data_on" │ │ └── Datastore → CI Typ "storage" │ │ │ │ Kubernetes API │ │ ├── Deployment → CI Typ "service" │ │ │ ├── Service → Namespace: "contains" │ │ │ └── Service → PVC: "stores_data_on" │ │ ├── Node → Link zu VM (über IP-Matching) │ │ ├── PersistentVolume → CI Typ "storage" │ │ └── Labels (hafs.de/service-owner) → owner_team │ │ │ │ SNMP Walk │ │ ├── sysDescr → CI Typ "network_device" + Modell │ │ ├── ifTable → Interfaces, VLANs │ │ └── Nachbar-Erkennung (CDP/LLDP) → "connects_to" │ └──────────────────────────────────────────────────────────────────┘
7.4 Lifecycle-Tracking
| Status | Beschreibung | Übergang |
|---|---|---|
| Discovered | Vom Auto-Discovery neu erkannt | → Provisioned (manuell bestätigt) |
| Provisioned | Genehmigt und bereitgestellt | → Active (Health Check OK) |
| Active | In Betrieb, wird überwacht | → Maintenance (geplante Wartung) |
| Maintenance | Wartungsmodus, Alerts unterdrückt | → Active (Wartung abgeschlossen) |
| Decommissioned | Außer Betrieb genommen | Endstatus (archiviert) |
7.5 Integration mit Portal Asset Management (M9)
| Datenfluss | Richtung | Beschreibung |
|---|---|---|
| CI-Daten → M9 | Monitor → Portal | Technische CIs als Basis für Asset-Einträge |
| Asset-Metadaten → Monitor | Portal → Monitor | Business-Owner, Kostenträger, Verträge |
| Lifecycle-Events | Bidirektional | Statusänderungen synchronisieren |
| Dependency Map | Monitor → Portal | Technische Abhängigkeiten für Impact-Analyse |
8. Runbook Integration
8.1 Architektur
Runbook Execution Engine – Trigger bis Ergebnis
┌──────────────────────────────────────────────────────────────────┐ │ RUNBOOK INTEGRATION │ │ │ │ ┌─── Trigger ─────────────────────────────────────────────┐ │ │ │ │ │ │ │ Alert Engine │ Manuell (Dashboard) │ │ │ │ Portal-Ticket (M1) │ Scheduler (CronJob) │ │ │ └─────────────────────────┬────────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ RUNBOOK EXECUTION ENGINE │ │ │ │ │ │ │ │ 1. Runbook auswählen (ID / Auto-Match via Alert-Tag) │ │ │ │ 2. Parameter validieren │ │ │ │ 3. Genehmigung prüfen (falls erforderlich) │ │ │ │ 4. Execution Environment starten (K8s Job) │ │ │ │ 5. Runbook ausführen (Ansible / Terraform / Script) │ │ │ │ 6. Output + Exit-Code erfassen │ │ │ │ 7. Ergebnis loggen + Ticket aktualisieren │ │ │ └─────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── Execution Backends ──────────────────────────────────┐ │ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ ┌──────────────────┐ │ │ │ │ │ Ansible │ │ Terraform │ │ Shell Scripts │ │ │ │ │ │ Playbooks │ │ Modules │ │ (kubectl, etc.) │ │ │ │ │ └────────────┘ └────────────┘ └──────────────────┘ │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
8.2 Runbook-Bibliothek (Beispiele)
| Runbook | Trigger | Aktion | Auto/Manuell |
|---|---|---|---|
| Restart Pod | Pod CrashLoopBackOff > 5x | kubectl rollout restart deployment | Auto (mit Limit) |
| Clear Disk Space | Disk Usage > 90% | Log-Rotation, Temp-Bereinigung | Auto |
| Scale Deployment | CPU > 85% für > 10 min | HPA-Limits temporär erhöhen | Manuell (Genehmigung) |
| SSL Cert Renew | Zertifikat läuft in < 14 Tagen ab | cert-manager Renewal triggern | Auto |
| DB Vacuum | PostgreSQL Bloat > Schwelle | VACUUM ANALYZE ausführen | Auto (Maintenance Window) |
| VM Snapshot Cleanup | Snapshot Alter > 72h | vSphere API: Snapshot löschen | Manuell (Genehmigung) |
| Network Port Reset | Port Flapping erkannt | SNMP Set: Port disable/enable | Manuell |
| Backup Retry | Backup fehlgeschlagen | Veeam API: Backup-Job erneut starten | Auto (1x Retry) |
8.3 Genehmigungs-Workflows
| Risikostufe | Genehmigung | Beispiel |
|---|---|---|
| Low Risk | Keine (Auto-Execute) | Log-Rotation, Pod-Restart, Cert Renewal |
| Medium Risk | Team Lead Approval | Deployment Scaling, DB Maintenance |
| High Risk | IT-Leitung Approval | VM-Änderungen, Netzwerk-Konfiguration |
| Critical | Dual Approval (Team Lead + IT-Leitung) | Storage-Operationen, Firewall-Regeln |
8.4 Audit Trail
Jede Runbook-Ausführung wird vollständig protokolliert:
| Feld | Beschreibung |
|---|---|
| Execution ID | Eindeutige ID der Ausführung |
| Runbook ID/Name | Welches Runbook ausgeführt wurde |
| Trigger | Alert-ID, Ticket-ID oder manuell (User) |
| Parameter | Input-Parameter der Ausführung |
| Genehmiger | Wer die Ausführung genehmigt hat (falls erforderlich) |
| Start/Ende | Zeitstempel der Ausführung |
| Exit Code | Erfolg (0) oder Fehler (>0) |
| Output Log | Vollständige Konsolenausgabe (verschlüsselt gespeichert) |
| Betroffene CIs | Welche Configuration Items betroffen waren |
8.5 Portal-Ticket Auto-Resolution
Auto-Resolution Flow – Alert bis Ticket-Abschluss
Alert: "Pod ai-gateway in CrashLoopBackOff"
│
▼
┌──────────────────┐
│ Alert Engine │
│ → Match Runbook: │──► Runbook "restart-pod" gefunden
│ "restart-pod" │
└──────┬───────────┘
│
▼
┌──────────────────┐
│ Auto-Execute │
│ (Low Risk) │──► kubectl rollout restart deployment/ai-gateway
└──────┬───────────┘
│
├──► Erfolg: Pod läuft wieder
│
▼
┌──────────────────┐
│ Portal-Ticket │
│ Auto-Update │──► Ticket-Status: "Resolved (Auto)"
│ │ Resolution Note: "Pod automatisch neu gestartet"
│ │ Runbook-Log angehängt
└──────────────────┘
9. Executive Dashboard
9.1 Übersicht
Executive IT Dashboard – Health Score, KPIs & Kosten
┌──────────────────────────────────────────────────────────────────┐ │ EXECUTIVE IT DASHBOARD │ │ (Für IT-Management / Geschäftsführung) │ │ │ │ ┌─── IT Health Score ─────────────────────────────────────┐ │ │ │ │ │ │ │ ┌───────┐ │ │ │ │ │ │ │ │ │ │ │ 87 │ /100 │ │ │ │ │ │ │ │ │ │ └───────┘ │ │ │ │ "Gut" │ │ │ │ │ │ │ │ Teilbereiche: │ │ │ │ Verfügbarkeit: 92/100 ████████████████████░░░░ │ │ │ │ Performance: 88/100 ██████████████████░░░░░░ │ │ │ │ Sicherheit: 85/100 █████████████████░░░░░░░ │ │ │ │ Kapazität: 82/100 ████████████████░░░░░░░░ │ │ │ │ Compliance: 90/100 ██████████████████░░░░░░ │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ │ ┌─── KPIs auf einen Blick ───────────────────────────────┐ │ │ │ │ │ │ │ Portal-Verfügbarkeit 99.87% (Ziel: 99.9%) │ │ │ │ Offene Incidents 3 (P1: 0, P2: 1) │ │ │ │ MTTR (30 Tage) 42 min (Ziel: < 60 min) │ │ │ │ Alerts diese Woche 127 (↓ 12% vs. Vorw.) │ │ │ │ Kapazität (nächste CPU: 22d Storage: 50d │ │ │ │ Schwelle) Memory: 45d │ │ │ │ Runbooks ausgeführt 34 (Erfolg: 97%) │ │ │ └──────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
87/100
IT Health Score
99.87%
Portal-Verfügbarkeit
42 min
MTTR (30 Tage)
97%
Runbook-Erfolgsrate
9.2 IT Health Score Berechnung
| Teilbereich | Gewichtung | Metriken |
|---|---|---|
| Verfügbarkeit | 30% | Service Uptime, SLA-Einhaltung, Erfolgreiche Health Checks |
| Performance | 20% | Response Times (p95), Error Rate, Throughput |
| Sicherheit | 20% | Offene Vulnerabilities, Security Incidents, Patch-Compliance |
| Kapazität | 15% | Ressourcen-Headroom, Wachstumstrend, Right-Sizing Score |
| Compliance | 15% | Audit Findings, Policy-Compliance, Backup-Erfolgsrate |
9.3 Incident Trends und MTTR
| KPI | Berechnung | Darstellung |
|---|---|---|
| MTTR (Mean Time to Resolve) | Durchschnitt Ticket-Erstellung bis Resolution | Trend-Chart (12 Wochen) |
| MTTD (Mean Time to Detect) | Alert-Zeitpunkt minus geschätzter Beginn | Trend-Chart (12 Wochen) |
| Incident-Volumen | Anzahl P1/P2 Incidents pro Woche | Balkendiagramm nach Severity |
| Wiederkehrende Incidents | Incidents mit gleicher Root Cause in 30 Tagen | Top-5 Liste mit Trend |
| Auto-Resolution Rate | % der Incidents durch Runbooks automatisch gelöst | Trend-Chart + Zielwert |
9.4 Budget vs. Actual
| Kategorie | Budget/Monat | Actual/Monat | Delta | Trend |
|---|---|---|---|---|
| Compute | 5.000 EUR | 4.500 EUR | -500 EUR | ↓ |
| Storage | 2.500 EUR | 2.100 EUR | -400 EUR | → |
| Netzwerk | 2.000 EUR | 1.800 EUR | -200 EUR | → |
| Cloud-Services | 3.500 EUR | 3.200 EUR | -300 EUR | ↑ (Claude API steigend) |
| Lizenzen | 8.000 EUR | 8.200 EUR | +200 EUR | → |
| Support/Wartung | 1.000 EUR | 800 EUR | -200 EUR | → |
| Gesamt | 22.000 EUR | 20.600 EUR | -1.400 EUR |
portal.hafs.de/monitoring/executive
99,94 %
Gesamtverfügbarkeit
+0,02 % vs. Vormonat
23 min
MTTR
−8 min vs. Vormonat
7
Incidents (Monat)
−3 vs. Vormonat
94 %
Kosteneffizienz
+2 % vs. Vormonat
SLA-Compliance
99,94 %
Ziel: 99,90 % · ✓ Erfüllt
99,0 %
99,5 %
99,9 %
100 %
Trading Platform99,99 %
Portfolio Management99,97 %
Reporting99,95 %
Auth Service99,82 %
Incidents nach Kategorie
System Health Trend (30 Tage)
Wöchentliche Verfügbarkeit über alle kritischen Systeme
KW 03
99,91 %
KW 04
99,96 %
KW 05
99,87 %
KW 06
99,98 %
Executive Dashboard – Management-Übersicht mit KPIs, SLA-Compliance und Incident-Trends
10. Portal-Integration
10.1 REST API (Monitor → Portal)
| Endpoint | Methode | Beschreibung |
|---|---|---|
/api/v1/monitor/health | GET | Gesamt-Health-Status aller Services |
/api/v1/monitor/services/{id}/status | GET | Health-Status eines spezifischen Services |
/api/v1/monitor/alerts/active | GET | Alle aktiven Alerts |
/api/v1/monitor/cmdb/items | GET | CMDB Configuration Items (paginiert) |
/api/v1/monitor/cmdb/items/{id}/dependencies | GET | Dependencies eines CIs |
/api/v1/monitor/capacity/forecast | GET | Kapazitätsprognosen |
/api/v1/monitor/sla/current | GET | Aktuelle SLA-Werte |
/api/v1/monitor/sla/report/{month} | GET | Monatlicher SLA-Report |
/api/v1/monitor/executive/score | GET | IT Health Score |
/api/v1/monitor/runbooks | GET | Verfügbare Runbooks |
/api/v1/monitor/runbooks/{id}/execute | POST | Runbook ausführen |
10.2 REST API (Portal → Monitor)
| Endpoint | Methode | Beschreibung |
|---|---|---|
/api/v1/monitor/maintenance-windows | POST | Maintenance Window anlegen |
/api/v1/monitor/alerts/{id}/acknowledge | POST | Alert bestätigen |
/api/v1/monitor/alerts/{id}/silence | POST | Alert stummschalten |
/api/v1/monitor/cmdb/items | POST/PUT | CI manuell anlegen/aktualisieren |
/api/v1/monitor/runbooks/{id}/approve | POST | Runbook-Ausführung genehmigen |
10.3 Event Bus Integration (RabbitMQ)
RabbitMQ Event Bus – Bidirektionale Integration
┌──────────────────────────────────────────────────────────────────┐ │ RABBITMQ EVENT BUS INTEGRATION │ │ │ │ Monitor → Portal (Exchanges) │ │ ──────────────────────────── │ │ monitor.alert.created → Portal: Auto-Ticket erstellen │ │ monitor.alert.escalated → Portal: Ticket-Priorität erhöhen│ │ monitor.alert.resolved → Portal: Ticket auto-schließen │ │ monitor.sla.breach → Portal: P1-Ticket + Notification │ │ monitor.capacity.warning → Portal: Kapazitäts-Ticket │ │ monitor.runbook.completed → Portal: Ticket-Update │ │ monitor.ci.discovered → Portal: Asset-Sync (M9) │ │ monitor.ci.status_changed → Portal: Asset-Update (M9) │ │ │ │ Portal → Monitor (Exchanges) │ │ ──────────────────────────── │ │ portal.ticket.created → Monitor: Alert-Korrelation │ │ portal.change.approved → Monitor: Maintenance Window setzen │ │ portal.change.completed → Monitor: Maintenance Window beenden│ │ portal.asset.updated → Monitor: CMDB-Update │ └──────────────────────────────────────────────────────────────────┘
10.4 Dashboard-Embedding
| Einbettung | Methode | Ziel im Portal |
|---|---|---|
| Service Health Map | React-Komponente (Shared Library) | Portal Dashboard (M8) |
| Grafana Dashboards | Grafana Embedded (iframe / API) | Analytics-Bereich (M8) |
| IT Health Score | REST API Widget | Management Dashboard |
| Active Alerts | REST API + WebSocket (Live) | Portal Header / Notification Center |
| CMDB-Daten | REST API | Asset Management (M9) |
10.5 AI-gestützte Anomalie-Erkennung
AI Anomaly Detection – Datensammlung, Analyse & Aktion
┌──────────────────────────────────────────────────────────────────┐ │ AI ANOMALY DETECTION │ │ │ │ ┌─── Datensammlung ──────────────────────────────────────┐ │ │ │ │ │ │ │ Prometheus Metriken (letzte 24h + 30-Tage-Baseline) │ │ │ │ ├── CPU/Memory/Disk/Network pro Service │ │ │ │ ├── Request Rates, Error Rates, Latency │ │ │ │ └── Business Metriken (Ticket-Volumen, Login-Raten) │ │ │ └─────────────────────────┬────────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Claude Sonnet 4.5 Analyse (Batch, alle 15 min) │ │ │ │ │ │ │ │ Output: │ │ │ │ • Anomalie-Score (0-100) │ │ │ │ • Betroffene Metriken/Services │ │ │ │ • Erklärung der Anomalie │ │ │ │ • Empfohlene Maßnahmen │ │ │ │ • Korrelation mit anderen Events │ │ │ └─────────────────────────┬────────────────────────────────┘ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────┐ │ │ │ Aktion (bei Anomalie-Score > 70): │ │ │ │ │ │ │ │ • Alert erstellen (Severity basierend auf Score) │ │ │ │ • Grafana Annotation setzen │ │ │ │ • Infra-Team benachrichtigen │ │ │ │ • Portal-Ticket (P3) mit AI-Analyse erstellen │ │ │ └─────────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────────────┘
| AI-Analyse Typ | Beschreibung | Frequenz |
|---|---|---|
| Anomalie-Erkennung | Ungewöhnliche Metrik-Muster vs. Baseline | Alle 15 min |
| Kapazitätsprognose | Wann werden Schwellenwerte erreicht? | Täglich |
| Incident-Korrelation | Welche Alerts gehören zusammen? | Bei jedem neuen Alert |
| Root Cause Suggestion | Mögliche Ursache bei korrelierenden Alerts | Bei Alert-Cluster |
| Weekly Summary | Wöchentliche IT-Infrastruktur-Zusammenfassung | Montags 08:00 |
10.6 Technologie-Zusammenfassung
Gesamtarchitektur auf einen Blick
Das IT Monitor Add-on vereint Prometheus + Grafana (Metriken & Dashboards), Node.js/TypeScript (Backend), React 19 (Frontend), PostgreSQL 16 (CMDB-Light), RabbitMQ (Event Bus), Ansible + Terraform (Runbooks) und Claude Sonnet 4.5 (AI-Anomalie-Erkennung). Deployment erfolgt via Helm Charts und Flux v2 (GitOps) im Namespace hafs-monitor.
| Schicht | Technologien |
|---|---|
| Frontend | React 19, TypeScript, Tailwind CSS, Shadcn/UI, Recharts/Visx |
| Backend | Node.js 22, TypeScript, Express/Fastify, Prisma (PostgreSQL) |
| Metriken | Prometheus, Alertmanager, Thanos (optional), kube-state-metrics |
| Visualisierung | Grafana, Custom React Dashboards |
| Datenbank | PostgreSQL 16 (CMDB-Light), Prometheus TSDB (Metriken) |
| Messaging | RabbitMQ (Event Bus zum Portal) |
| Datenquellen | vSphere API, Kubernetes API, SNMP Exporter, MinIO API, SAN API |
| Runbooks | Ansible, Terraform, Shell (ausgeführt als K8s Jobs) |
| AI | Anthropic Claude Sonnet 4.5 (Anomalie-Erkennung, Prognosen) |
| Deployment | Helm Charts, Flux v2 (GitOps), Namespace hafs-monitor |