Alle Signale an einem Ort

Das Observability-Problem: Silos überall

Modern Kubernetes-Deployments haben sie oft:

• Logs: In Loki, ELK oder Splunk
• Metriken: In Prometheus oder Grafana Cloud
• Traces: In Jaeger, Zipkin oder Datadog
• Cluster-Daten: In etcd, nur erreichbar via kubectl

Wenn etwas kaputtgeht, springen Sie zwischen 4-5 verschiedenen UIs herum. Die gleiche Kontext-Information ist überall verteilt. Die meiste Zeit verbringen Sie damit zu suchen, nicht zu fixen.

KI-Ops vereinigt alle Signale in einer kohärenten Analyse.

OpenTelemetry-native Architektur

KI-Ops ist von Grund auf für OpenTelemetry (OTel) gebaut:

# Ihre OTel Collector Konfiguration
receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}
  prometheus: {}
  loki: {}

exporters:
  otlp:
    endpoint: "ki-ops-receiver:4317"

service:
  pipelines:
    traces: [otlp] -> [otlp]
    metrics: [prometheus] -> [otlp]
    logs: [loki] -> [otlp]

Keine Vendor-Lock-in. Alle Standards-Tools sind unterstützt:

| Signal | Unterstützte Systeme | |--------|----------------------| | Logs | Loki, ELK, Splunk, CloudWatch, Stackdriver, syslog, plain files | | Metriken | Prometheus, Grafana Cloud, Datadog, New Relic, CloudWatch | | Traces | Jaeger, Zipkin, Tempo, Datadog APM, Honeycomb | | Cluster | kubectl (lokal), KKE, EKS, GKE, OCP |

Signal-Korrelation: Ein konkretes Beispiel

Sie haben einen Latency-Spike in Ihrer API. Das System findet sofort:

🔴 INCIDENT: Latency P99 von 50ms auf 2500ms (17:23:45 UTC)

📊 METRIKEN (Prometheus)
  ├─ api-service CPU: 15% → 89% in 2 min
  ├─ api-service Memory: 650MB → 1.2GB
  ├─ Outgoing Connections zu Postgres: 120 → 45 (dropped!)
  └─ Error Rate: 0.1% → 12%

📝 LOGS (Loki)
  ├─ 14:23:47 [api-service] "dial tcp 10.0.2.15:5432: i/o timeout"
  ├─ 14:23:52 [api-service] "query timeout: context deadline exceeded"
  ├─ 14:23:55 [postgres] "too many connections (100/100)"
  └─ 14:24:01 [postgres] "some connections closed by client"

🔗 TRACES (Jaeger)
  Request ID: "abc123xyz"
  ├─ api-service.HandleOrder (45ms) → Span 1
  │   └─ postgres.Query (2350ms, timeout!) → Span 2
  │       └─ tcp.connect (2340ms) → BLOCKED
  └─ circuit_breaker [OPEN] after 3 failures

✅ ROOT CAUSE IDENTIFIED
Postgres Connection Pool exhausted.
  → 47 Long-Running Queries blockieren Connection Pool
  → Neue Requests können nicht verbinden
  → API Timeouts cascade zu Postgres Error

Aufgelöst in 30 Sekunden. Ohne manuelles Switching zwischen UIs.

Praktische Integration: 3 einfache Befehle

1. Verbindung zu Ihren Log-Systemen

# Loki
ki-ops connect --logs loki \
  --loki-url http://loki:3100

# Oder Splunk
ki-ops connect --logs splunk \
  --splunk-url https://splunk.company.com \
  --splunk-hec-token $TOKEN

# Oder ELK
ki-ops connect --logs elasticsearch \
  --es-url http://elasticsearch:9200

2. Metrik-Quellen hinzufügen

ki-ops connect --metrics prometheus \
  --prometheus-url http://prometheus:9090

# Pro Tipp: Multiple Prometheus-Instanzen für HA
ki-ops connect --metrics prometheus \
  --prometheus-url http://prom1:9090 \
  --prometheus-url http://prom2:9090

3. Traces aktivieren (Optional)

ki-ops connect --traces jaeger \
  --jaeger-url http://jaeger:16686

Danach? Alles automatisch korreliert.

Trace-Context Propagation

KI-Ops nutzt W3C Trace Context Standard:

• Jeder Request trägt eindeutige trace-id
• Die gleiche trace-id erscheint in Logs, Metriken und Traces
• Claude AI verfolgt die Request-Journey durch alle Services

trace-id: "4bf92f3577b34da6a3ce929d0e0e4736"

api-service [TRACE 1: 45ms]
  └──> postgres-service [TRACE 2: 2340ms]  ← Bottleneck erkannt!
         └──> network [LATENCY SPIKE]      ← Zeigt genaue Stelle

Performance & Datenschutz

• Keine Cloud-Upload: Alle Daten bleiben lokal (Free & Pro)
• Streaming Processing: Logs/Metriken werden on-the-fly analysiert, nicht gepuffert
• Selective Query: Nur relevante Log-Einträge werden abgerufen (Filter-Optimierung)
• Query-Caching: Häufige Abfragen gecacht, reduziert Prometheus/Loki-Load

Was Sie gewinnen

• Single Pane of Glass: Alle Daten in einer Analyse
• Vendor-Unabhängigkeit: Wechsel zwischen Tools ohne Reconfig
• Schneller Debugging: Trace Request von Entry bis Exit automatisch
• Bessere Kontextmeldungen: Der LLM sieht die volle Story, nicht Snippets
• Zukunftssicher: Neue Log/Metric-Systeme einfach hinzufügen

Probieren Sie es aus: ki-ops analyze --with-traces --with-metrics startet die volle Korrelations-Engine.