Das Observability-Problem: Silos überall

Moderne 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, springst du zwischen 4-5 verschiedenen UIs herum. Die gleiche Kontext-Information ist überall verteilt. Die meiste Zeit verbringst du damit zu suchen, nicht zu fixen.

KI-Ops vereinigt alle Signale in einer kohärenten Analyse – als SaaS-Tool, der in deiner Infrastruktur läuft.

OpenTelemetry-native Architektur

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

# Deine 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]

Kein Vendor-Lock-in. Alle Standard-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

Du hast einen Latency-Spike in deiner API. KI-Ops findet sofort die Zusammenhänge:

🔴 INCIDENT ERKANNT: 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 ERKANNT
Postgres Connection Pool exhausted.
  → 47 Long-Running Queries blockieren Connection Pool
  → Neue Requests können nicht verbinden
  → API Timeouts cascade zu Postgres Error

💡 EMPFEHLUNGEN:
  1. Increase connection pool size
  2. Cancel long-running queries
  3. Monitor query execution time

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

Praktische Integration: Deine Quellen, sauber angebunden

Skalenta bindet deine Observability-Quellen beim Onboarding an und hält die Integration im Betrieb am Laufen. Die Anbindungen laufen in deiner Umgebung – beispielhaft sieht das so aus:

1. Verbindung zu deinen 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

# Mehrere 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 den W3C Trace Context Standard:

Jeder Request trägt eine eindeutige trace-id
Die gleiche trace-id erscheint in Logs, Metriken und Traces
KI-Ops 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

Daten bleiben bei dir: Cluster-Daten, Logs und Metriken verlassen deine Umgebung nicht – KI-Ops läuft in deiner Cloud oder On-Prem
Compliance by Design: DORA, NIS-2 und EU AI Act von Anfang an mitgedacht, inklusive Audit-Trail
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 werden gecacht, reduziert Prometheus/Loki-Load

Was im Service enthalten ist

Single Pane of Glass: Alle Daten in einer Analyse
Vendor-Unabhängigkeit: Wechsel zwischen Tools ohne Reconfig
Schnelleres Debugging: Request von Entry bis Exit automatisch getraced – weniger MTTR
Bessere Kontextmeldungen: KI-Ops sieht die volle Story, nicht nur Snippets
Zukunftssicher: Neue Log-/Metrik-Systeme einfach hinzufügen
Betrieb durch Skalenta: Integration, Updates und Tuning übernehmen wir – du bekommst die Ergebnisse, nicht den Wartungsaufwand

Sieh dir die Korrelations-Engine an deinen eigenen Signalen an: Demo buchen.

Alle Signale an einem Ort