Einleitung

In modernen Microservice‑Architekturen erzeugen Kubernetes‑Pods massive Log‑Mengen. Ohne gezielte Filterung löst jede Anomalie einen Alert aus, was zu einer überwältigenden Flut von Fehlalarmen führt. Diese Alert‑Flut erhöht die MTTR (Mean Time to Recovery) und belastet SRE‑Teams unnötig. In diesem Leitfaden zeigen wir Schritt für Schritt, wie Sie kontextbasierte Filterregeln implementieren, um die Anzahl unnötiger Alerts zu reduzieren, ohne kritische Vorfälle zu verpassen.

1. Projektplanung und Anforderungsdefinition

1.1 Zielsetzung

Primäres Ziel: Reduktion der Fehlalarme um mindestens 40 % innerhalb von vier Wochen.
Sekundäres Ziel: Verbesserung der MTTR um 15 % durch schnellere Priorisierung echter Incidents.

1.2 Stakeholder & Rollen

SRE‑Team: Definiert kritische KPIs (Latenz, Fehlerquote, SLA‑Verletzungen).
Entwickler: Liefern Log‑Formate und markieren relevante Kontext‑Labels.
Produkt‑Owner: Genehmigt die Schwellenwerte für Alert‑Kategorien.

1.3 Technologie‑Stack

Kubernetes 1.28+
Prometheus für Metriken
Grafana Loki für Log‑Aggregation
Lescopr APM für Tracing und Alert‑Management

2. Architektur der kontextbasierten Filterregeln

2.1 Grundprinzipien

Kontextbasierte Filter kombinieren Log‑Inhalte mit Metadaten wie Pod‑Name, Namespace, aktuelle CPU‑Auslastung und SLA‑Priorität. Dadurch wird unterschieden zwischen kritischen und transienten Ereignissen.

2.2 Komponentenübersicht

Log‑Collector (Loki): Sammelt Roh‑Logs aus allen Pods.
Metric‑Adapter (Prometheus): Stellt Echtzeit‑Metriken bereit (CPU, Memory, Request‑Latency).
Rule‑Engine (Lescopr): Evaluates filter expressions like log.message =~ "timeout" AND pod.cpu_usage < 0.7.

2.3 Beispiel‑Regelsyntax

# lescopr_rules.yaml
- name: "Transient Timeout Spike"
  condition: "log.message =~ 'timeout' && pod.cpu_usage < 0.6"
  severity: "low"
  action: "suppress"
- name: "Critical SLA Breach"
  condition: "log.level == 'ERROR' && pod.namespace == 'production' && pod.latency > 2000"
  severity: "high"
  action: "alert"

3. Implementierungsschritte

3.1 Vorbereitung des Clusters

Namespace anlegen für Observability‑Tools:
```
kubectl create namespace observability
```

Loki und Prometheus via Helm installieren:

helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki-stack -n observability
helm install prometheus prometheus-community/kube-prometheus-stack -n observability

Lescopr‑Agent in jedem Anwendungs‑Namespace deployen:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: lescopr-agent
  namespace: <app-namespace>
spec:
  template:
    spec:
      containers:
      - name: agent
        image: lescopr/agent:latest

3.2 Definition der Kontext‑Labels

Pod‑Labeling: Ergänzen Sie jedes Deployment‑Manifest um Labels, die den Service‑Typ und die SLA‑Priorität beschreiben.
```
metadata:
  labels:
    service: payment
    sla: critical
```
Dynamic Metrics: Nutzen Sie Prometheus‑Exporter, um cpu_usage und latency als Pod‑Labels zu exportieren.

3.3 Erstellen der Filterregeln

Legen Sie die Regeldatei lescopr_rules.yaml im ConfigMap‑Volume ab.

Binden Sie die ConfigMap an den Lescopr‑Agent:

volumeMounts:
- name: rules-config
  mountPath: /etc/lescopr/rules
volumes:
- name: rules-config
  configMap:
    name: lescopr-rules

Starten Sie den Agent neu, damit die Regeln geladen werden.

3.4 Testen und Validieren

Simulieren Sie einen Spike mit kubectl exec und erzeugen Sie ein Timeout‑Log.
Prüfen Sie das Dashboard in Lescopr – der Alert sollte unterdrückt werden, weil die CPU‑Auslastung niedrig ist.
Erhöhen Sie die CPU‑Last (> 70 %) und wiederholen Sie den Test – nun sollte ein hoher Severity‑Alert ausgelöst werden.

4. Monitoring, Optimierung und Governance

4.1 KPI‑Dashboard

Alert‑Rate: Gesamtzahl der Alerts pro Tag.
False‑Positive‑Rate: Anteil der unterdrückten Alerts, die später als kritisch eingestuft wurden.
MTTR: Durchschnittliche Wiederherstellungszeit nach einem echten Incident.

4.2 Regel‑Review‑Prozess

Frequenz	Verantwortlich	Aktion
Wöchentlich	SRE‑Lead	Analyse von False‑Positives und Anpassung der Schwellenwerte
Monatlich	Produkt‑Owner	Validierung der SLA‑Prioritäten und Aktualisierung der Kontext‑Labels
Quartalsweise	Architekt	Review der gesamten Filterlogik und Integration neuer Metriken

4.3 Skalierung auf mehrere Cluster

Zentraler Rule‑Store: Nutzen Sie ein Git‑Ops‑Repository, um Regeln versioniert zu verwalten.
Federated Prometheus: Aggregieren Sie Metriken über mehrere Regionen hinweg, sodass Lescopr konsistente Entscheidungen treffen kann.

5. Fazit und nächster Schritt

Durch die Einführung kontextbasierter Filterregeln für Kubernetes‑Pod‑Logs reduzieren Sie die Alert‑Flut signifikant, verbessern die Sichtbarkeit kritischer Incidents und senken die MTTR. Der Ansatz erfordert initialen Aufwand beim Label‑Management und bei der Definition präziser Schwellenwerte, liefert jedoch langfristig messbare Vorteile für SRE‑ und Produktteams.

Für mehr Details: Die Lescopr-Dokumentation beschreibt die Einrichtung Schritt für Schritt.