42 Monitoring mit Prometheus und Grafana

Prometheus und Grafana bilden das Kern-Monitoring-Ecosystem in OpenShift und implementieren umfassende Observability-Frameworks durch Metriken-Sammlung, -Speicherung und -Visualisierung. Diese Cloud-Native-Monitoring-Architektur ermöglicht Echtzeit-System-Monitoring, Performance-Analyse und proaktive Problem-Erkennung für Container-Orchestrierungs-Plattformen.

42.1 Grundlagen der Prometheus-Architektur

Prometheus implementiert eine Pull-basierte Metriken-Sammel-Architektur durch periodisches HTTP-Endpoint-Scraping für Time-Series-Datensammlung. Dieses Pull-Modell reduziert den Netzwerk-Overhead und ermöglicht Service-Discovery-basierte Target-Identifikation ohne explizite Agent-Konfiguration.

Die Time-Series-Datenbank speichert Metrikendaten mit Zeitstempel-Indizierung und Label-basierter multidimensionaler Datenmodellierung. Diese TSDB-Architektur optimiert die Metrik-Speicherung und ermöglicht effiziente Bereichsabfragen für historische Analysen.

[Diagramm: Prometheus-Grafana-Architektur mit Datenfluss und Komponenten]

42.1.1 Prometheus-Komponenten

Prometheus Server ist die zentrale Komponente, die Metriken sammelt, speichert und Abfragen verarbeitet. Er läuft als einzelner Prozess und ist für die gesamte Datensammlung und -speicherung verantwortlich.

AlertManager verwaltet Alerts, die von Prometheus gesendet werden. Er gruppiert, dedupliziert und leitet Benachrichtigungen an verschiedene Empfänger weiter - E-Mail, Slack, PagerDuty, etc.

Service Discovery integriert mit Kubernetes-APIs für automatische Target-Discovery basierend auf Pod-Annotations und Service-Labels. Diese dynamische Erkennung gewährleistet automatische Monitoring-Abdeckung für Deployment-Änderungen ohne manuelle Konfigurationsupdates.

Exporters sind spezialisierte Programme, die Metriken von Drittanbieter-Systemen in das Prometheus-Format konvertieren. Beispiele sind Node Exporter für Systemmetriken oder MySQL Exporter für Datenbankmetriken.

42.1.2 Datenmodell und Metriken-Typen

Prometheus verwendet ein multidimensionales Datenmodell mit Metriken-Namen und Key-Value-Paaren (Labels):

http_requests_total{method="GET", handler="/api/users", status="200"} 1027

42.2 Metriken-Sammlung und Datenmodell

OpenShift stellt verschiedene Metriken-Typen bereit, die unterschiedliche Messmuster abdecken.

42.2.1 Counter-Metriken

Counter implementieren monoton ansteigende Wert-Verfolgung für Event-Counting und Rate-Berechnungszwecke. Diese Counter-Typen eignen sich für Request-Counts, Error-Counts und kumulative Ressourcennutzung-Verfolgung.

Beispiele für Counter:

# HTTP-Requests pro Sekunde
rate(http_requests_total[5m])

# Fehlerrate berechnen
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])

42.2.2 Gauge-Metriken

Gauge-Metriken repräsentieren momentane Wertmessungen für aktuelle Zustandsdarstellung wie CPU-Nutzung, Memory-Verbrauch oder Warteschlangen-Größen. Diese Gauge-Typen ermöglichen Echtzeit-Status-Monitoring.

Typische Gauge-Metriken: - node_memory_MemAvailable_bytes - Verfügbarer Arbeitsspeicher - kube_pod_container_resource_requests_cpu_cores - CPU-Anforderungen - kube_deployment_status_replicas - Anzahl Deployment-Replikas

42.2.3 Histogram-Metriken

Histogram-Metriken implementieren Verteilungsanalyse für Response-Time-Messung und Performance-Charakterisierung. Diese Histogram-Daten ermöglichen Perzentil-Berechnungen und Performance-SLA-Monitoring.

Histogram-Beispiel:

# 95. Perzentil der HTTP-Antwortzeiten
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

# Durchschnittliche Antwortzeit
rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m])

42.2.4 Summary-Metriken

Summary-Metriken bieten vorberechnete Quantil-Informationen für Performance-Metrik-Optimierung und reduzierte Query-Komplexität. Diese Summary-Typen optimieren Query-Performance für häufige Perzentil-Berechnungen.

42.3 PromQL und Query-Funktionen

PromQL (Prometheus Query Language) ermöglicht komplexe Time-Series-Abfragen mit mathematischen Operationen, Aggregationen und Bereichsauswahlen. Diese Abfragesprache unterstützt anspruchsvolle Metrik-Analysen und Custom-Dashboard-Erstellung.

42.3.1 Grundlegende PromQL-Operationen

Einfache Abfragen:

# Aktuelle CPU-Nutzung aller Nodes
node_cpu_seconds_total

# Nur idle CPU-Zeit
node_cpu_seconds_total{mode="idle"}

# Spezifischer Node
node_cpu_seconds_total{instance="worker-1.cluster.local"}

Bereichsabfragen:

# CPU-Nutzung der letzten 5 Minuten
node_cpu_seconds_total[5m]

# Rate-Berechnung über 5-Minuten-Fenster
rate(node_cpu_seconds_total[5m])

42.3.2 Aggregationsfunktionen

Aggregationsfunktionen implementieren Datenzusammenfassung über Zeiträume und Label-Dimensionen für High-Level-Metrik-Berechnungen:

# Durchschnittliche CPU-Nutzung aller Nodes
avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)

# Gesamter Memory-Verbrauch im Cluster
sum(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)

# Höchste CPU-Nutzung
max(rate(node_cpu_seconds_total{mode!="idle"}[5m]))

# Anzahl Nodes mit hoher CPU-Last
count(rate(node_cpu_seconds_total{mode!="idle"}[5m]) > 0.8)

42.3.3 Mathematische Operationen

Mathematische Ausdrücke erweitern Basic-Metriken um berechnete Metriken und abgeleitete Werte:

# Memory-Auslastung in Prozent
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Pod-Restart-Rate
increase(kube_pod_container_status_restarts_total[1h]) > 0

# Disk-Auslastung
(1 - (node_filesystem_avail_bytes / node_filesystem_size_bytes)) * 100

42.3.4 Join-Operationen

Join-Operationen ermöglichen Multi-Metrik-Korrelationen für komplexe Performance-Analysen:

# CPU-Requests vs. tatsächliche Nutzung
rate(container_cpu_usage_seconds_total[5m]) / on (pod) group_left kube_pod_container_resource_requests_cpu_cores

# Network-Traffic pro Service
sum(rate(container_network_receive_bytes_total[5m])) by (pod) 
* on (pod) group_left(service) kube_pod_labels{label_app!=""}

42.4 Grafana-Visualisierung und Dashboard-Management

Grafana bietet umfangreiche Visualisierungsoptionen für Prometheus-Metriken mit interaktiven Dashboards und flexiblen Panel-Konfigurationen.

42.4.1 Dashboard-Architektur

Dashboard-Architektur implementiert modulare Visualisierungskomponenten mit Panel-basierter Metrik-Anzeige und interaktiven Drill-Down-Funktionen. Dieses modulare Design ermöglicht flexible Dashboard-Komposition für verschiedene Monitoring-Anforderungen.

Grundlegende Dashboard-Struktur:

{
  "dashboard": {
    "title": "OpenShift Cluster Overview",
    "panels": [
      {
        "title": "CPU Usage",
        "type": "graph",
        "targets": [
          {
            "expr": "1 - avg(rate(node_cpu_seconds_total{mode=\"idle\"}[5m]))",
            "legendFormat": "CPU Usage %"
          }
        ]
      }
    ],
    "time": {
      "from": "now-1h",
      "to": "now"
    },
    "refresh": "30s"
  }
}

42.4.2 Template-Variablen

Template-Variablen ermöglichen dynamische Dashboard-Parametrisierung für Multi-Environment- oder Multi-Application-Monitoring-Szenarien:

Beispiel für Template-Variablen:

{
  "templating": {
    "list": [
      {
        "name": "namespace",
        "type": "query",
        "query": "label_values(kube_namespace_labels, namespace)",
        "multi": true,
        "includeAll": true
      },
      {
        "name": "pod",
        "type": "query", 
        "query": "label_values(kube_pod_info{namespace=~\"$namespace\"}, pod)",
        "multi": false
      }
    ]
  }
}

Verwendung in Queries:

# Dynamische Namespace-Filterung
rate(container_cpu_usage_seconds_total{namespace=~"$namespace", pod=~"$pod"}[5m])

42.4.3 Panel-Typen und Visualisierungen

42.4.4 Alerting in Grafana

Alert-Visualisierung integriert Prometheus-Alerts in Grafana-Dashboards für einheitliche Monitoring-Erfahrung:

{
  "alert": {
    "name": "High CPU Usage",
    "conditions": [
      {
        "query": {
          "queryType": "prometheus",
          "expr": "avg(rate(node_cpu_seconds_total{mode!=\"idle\"}[5m])) > 0.8"
        }
      }
    ],
    "executionErrorState": "alerting",
    "for": "5m",
    "frequency": "10s"
  }
}

42.5 Performance-Monitoring und SLA-Management

OpenShift bietet umfassende Performance-Monitoring-Funktionen für Anwendungen und Infrastruktur mit integrierten SLA-Tracking-Möglichkeiten.

42.5.1 Application Performance Monitoring

Application-Performance-Monitoring implementiert End-to-End-Response-Time-Tracking und Error-Rate-Monitoring für User-Experience-Quantifizierung:

Key Application Metrics:

# Application Response Time (95th percentile)
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{job="my-app"}[5m]))

# Error Rate
rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m])

# Throughput (requests per second)
sum(rate(http_requests_total[5m])) by (service)

# Apdex Score (Application Performance Index)
(
  sum(rate(http_request_duration_seconds_bucket{le="0.1"}[5m])) +
  sum(rate(http_request_duration_seconds_bucket{le="0.4"}[5m]))
) / 2 / sum(rate(http_request_duration_seconds_count[5m]))

42.5.2 Infrastructure Performance Monitoring

Infrastructure-Performance-Monitoring überwacht Node-Level-Metriken wie CPU, Memory, Disk und Network-Utilization:

Wichtige Infrastruktur-Metriken:

# Node CPU Utilization
100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Memory Utilization
(1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Disk Utilization
100 - (node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100

# Network I/O
rate(node_network_receive_bytes_total[5m]) + rate(node_network_transmit_bytes_total[5m])

# Load Average
node_load1 / count(count(node_cpu_seconds_total) by (cpu))

42.5.3 Custom Business Metrics

Custom-Business-Metriken ermöglichen anwendungsspezifische KPI-Überwachung:

# Business Transaction Volume
sum(rate(business_transactions_total[5m])) by (type)

# Revenue per Minute
sum(rate(order_value_total[1m]))

# User Session Duration
histogram_quantile(0.95, rate(user_session_duration_seconds_bucket[5m]))

# Feature Usage
rate(feature_usage_total[5m])

42.5.4 SLA-Compliance-Tracking

SLA-Compliance-Tracking implementiert Service-Level-Agreement-Monitoring:

# Availability SLA (99.9% target)
(
  sum(rate(http_requests_total{status!~"5.."}[30d])) /
  sum(rate(http_requests_total[30d]))
) * 100

# Response Time SLA (95% < 200ms)
(
  sum(rate(http_request_duration_seconds_bucket{le="0.2"}[30d])) /
  sum(rate(http_request_duration_seconds_count[30d]))
) * 100

# Error Budget Remaining
1 - ((1 - availability_sla) / (1 - 0.999))

42.6 Alert-Management und Incident-Response

Prometheus AlertManager bietet umfassende Alert-Verwaltung mit flexiblen Routing- und Notification-Optionen.

42.6.1 Alert-Rule-Definition

Alert-Rules implementieren Threshold-basierte und Trend-basierte Alert-Trigger:

groups:
- name: cluster-alerts
  rules:
  - alert: HighCPUUsage
    expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) > 0.8
    for: 5m
    labels:
      severity: warning
      component: infrastructure
    annotations:
      summary: "High CPU usage detected"
      description: "CPU usage is {{ $value }}% on {{ $labels.instance }}"

  - alert: PodCrashLooping
    expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
    for: 5m
    labels:
      severity: critical
      component: application
    annotations:
      summary: "Pod {{ $labels.pod }} is crash looping"
      description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} is restarting frequently"

  - alert: DiskSpaceLow
    expr: (1 - node_filesystem_avail_bytes / node_filesystem_size_bytes) > 0.9
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Disk space critically low"
      description: "Filesystem {{ $labels.mountpoint }} on {{ $labels.instance }} is {{ $value }}% full"

42.6.2 AlertManager-Konfiguration

global:
  smtp_smarthost: 'smtp.company.com:587'
  smtp_from: 'alerts@company.com'

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'default'
  routes:
  - match:
      severity: critical
    receiver: 'critical-alerts'
    group_wait: 10s
    repeat_interval: 1h

receivers:
- name: 'default'
  email_configs:
  - to: 'team@company.com'
    subject: '{{ .GroupLabels.alertname }} - {{ .Status }}'
    body: |
      {{ range .Alerts }}
      Alert: {{ .Annotations.summary }}
      Description: {{ .Annotations.description }}
      {{ end }}

- name: 'critical-alerts'
  email_configs:
  - to: 'oncall@company.com'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/...'
    channel: '#alerts-critical'
    title: 'Critical Alert: {{ .GroupLabels.alertname }}'

42.6.3 Alert-Korrelation und Gruppierung

Alert-Korrelations-Logik gruppiert verwandte Alerts für reduzierten Alert-Lärm:

# Gruppierung nach Service und Severity
route:
  group_by: ['service', 'severity']
  group_wait: 30s
  group_interval: 5m
  
# Inhibition Rules - unterdrücke Low-Severity wenn Critical vorhanden
inhibit_rules:
- source_match:
    severity: 'critical'
  target_match:
    severity: 'warning'
  equal: ['alertname', 'instance']

42.7 Security-Monitoring und Compliance

Prometheus kann für Sicherheitsüberwachung und Compliance-Monitoring konfiguriert werden.

42.7.1 Security-Metriken

# Failed Authentication Attempts
sum(rate(authentication_attempts_total{result="failure"}[5m]))

# Privileged Container Count
count(kube_pod_container_info{container_id!=""} * on (pod, namespace, container) 
kube_pod_container_status_running * on (pod, namespace) 
group_left kube_pod_info{host_network="true"})

# Image Pull Errors (potential supply chain issues)
increase(kube_pod_container_status_waiting_reason{reason="ImagePullBackOff"}[1h])

# Network Policy Violations
rate(network_policy_violations_total[5m])

42.7.2 Compliance-Monitoring

# Resource Quota Compliance
(kube_resourcequota_used / kube_resourcequota_hard) > 0.9

# Pod Security Standard Violations
count(kube_pod_container_info * on (pod, namespace) 
group_left kube_pod_spec_containers_security_context_run_as_root)

# Backup Status Monitoring
time() - backup_last_successful_timestamp > 86400

42.8 Capacity Planning und Ressourcen-Optimierung

Prometheus-Daten unterstützen Capacity Planning und Ressourcen-Optimierung durch historische Trend-Analyse.

42.8.1 Ressourcen-Trend-Analyse

# CPU Growth Rate (daily)
deriv(avg_over_time(cluster_cpu_usage[1d])[7d:1d])

# Memory Growth Prediction
predict_linear(avg_over_time(cluster_memory_usage[1d])[30d:1d], 86400 * 30)

# Storage Growth Rate
deriv(avg_over_time(cluster_storage_used[1d])[7d:1d])

# Network Bandwidth Trends
avg_over_time(sum(rate(node_network_receive_bytes_total[5m]))[1d:1h])

42.8.2 Cost-Optimierung

# Unused CPU Resources
sum(kube_pod_container_resource_requests_cpu_cores) - sum(avg_over_time(rate(container_cpu_usage_seconds_total[1d])[7d:1h]))

# Over-provisioned Memory
sum(kube_pod_container_resource_requests_memory_bytes) - sum(avg_over_time(container_memory_working_set_bytes[1d])[7d:1h])

# Idle Nodes Detection  
count(avg_over_time(rate(node_cpu_seconds_total{mode!="idle"}[1h])[24h:1h]) < 0.1)

42.9 Integration mit OpenShift-Operatoren

OpenShift integriert Prometheus tief in das Operator-Framework für erweiterte Monitoring-Funktionen.

42.9.1 Prometheus Operator

Der Prometheus Operator automatisiert Prometheus-Konfiguration und -Deployment:

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  namespace: monitoring
spec:
  serviceAccountName: prometheus
  serviceMonitorSelector:
    matchLabels:
      app: my-application
  ruleSelector:
    matchLabels:
      prometheus: my-prometheus
  retention: 30d
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi

42.9.2 ServiceMonitor CRD

ServiceMonitor Custom Resources definieren, welche Services überwacht werden sollen:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: webapp-monitor
  namespace: monitoring
  labels:
    app: my-application
spec:
  selector:
    matchLabels:
      app: webapp
  endpoints:
  - port: metrics
    interval: 30s
    path: /metrics
    honorLabels: true

42.9.3 PrometheusRule CRD

PrometheusRule definiert Alert-Rules als Kubernetes-Ressourcen:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: webapp-alerts
  namespace: monitoring
  labels:
    prometheus: my-prometheus
spec:
  groups:
  - name: webapp.rules
    rules:
    - alert: WebAppDown
      expr: up{job="webapp"} == 0
      for: 1m
      labels:
        severity: critical
      annotations:
        summary: "WebApp instance is down"

42.10 Performance-Optimierung für große Cluster

Für große OpenShift-Cluster sind spezielle Optimierungen erforderlich, um Prometheus-Performance zu gewährleisten.

42.10.1 Sharding und Federation

# Prometheus Sharding-Konfiguration
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus-shard-0
spec:
  shards: 1
  # Nur bestimmte Namespaces überwachen
  serviceMonitorNamespaceSelector:
    matchLabels:
      shard: "0"

42.10.2 Retention und Speicher-Optimierung

# Optimierte Prometheus-Konfiguration
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus-optimized
spec:
  retention: "15d"
  retentionSize: "50GB"
  # Komprimierung aktivieren
  walCompression: true
  # Ressourcen-Limits
  resources:
    limits:
      memory: 8Gi
      cpu: "4"
    requests:
      memory: 4Gi
      cpu: "2"

42.10.3 Recording Rules für Performance

Recording Rules reduzieren Query-Last durch Vorberechnung häufiger Metriken:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: recording-rules
spec:
  groups:
  - name: performance.rules
    interval: 30s
    rules:
    - record: cluster:cpu_usage:rate5m
      expr: sum(rate(container_cpu_usage_seconds_total[5m])) by (cluster)
    
    - record: cluster:memory_usage:bytes
      expr: sum(container_memory_working_set_bytes) by (cluster)
      
    - record: namespace:pod_cpu_usage:rate5m
      expr: sum(rate(container_cpu_usage_seconds_total[5m])) by (namespace, pod)

Diese Recording Rules können dann in Dashboards verwendet werden:

# Statt komplexer Query
cluster:cpu_usage:rate5m

# Statt
sum(rate(container_cpu_usage_seconds_total[5m])) by (cluster)