Vollständige Sichtbarkeit, ohne eine einzige Codezeile zu ändern

eBPF im Kernel ermöglicht Tracing, Network-Analyse und Performance-Profiling auf Systemebene – transparent für deine Anwendungen, betrieben als SaaS-Tool in deiner Cloud oder On-Prem.

Das eBPF-Versprechen: Transparency ohne Overhead

Traditionelle Observability erfordert:

  • Code-Instrumentation: OpenTelemetry-SDK einfügen, Dependencies hinzufügen
  • Performance-Hit: Jeder Span/Metric kostet CPU
  • Language-Specific: Java braucht JVM-Agent, Node.js braucht Middleware, Go braucht Imports
  • Versionskompabilität: SDK-Updates können Breaking Changes bringen

eBPF macht das obsolet.

Mit eBPF instrumentierst du dein gesamtes Cluster im Kernel selbst — ohne dass jede Anwendung etwas davon weiß. KI-Ops bietet diese Instrumentation als SaaS-Tool: Die eBPF-Programme laufen in deiner Umgebung, deine Cluster-Daten, Logs und Metriken bleiben bei dir.

Was ist eBPF? (Für DevOps erklärt)

eBPF = "Extended Berkeley Packet Filter" = Mini-VM im Linux-Kernel.

Im Kern sind das kleine C-Programme, die:

  1. An Kernel Events "gehängt" werden (Syscalls, Network Packets, Filesystem Operations)
  2. Im Ring-0 Kontext laufen (Kernel Space) → keine Userspace Context-Switches nötig
  3. Ereignisse in Kernel-Memory sammeln
  4. Userspace kann auf die Daten zugreifen ohne die Events zu verpassen

Resultat: Tiefste Visibility mit minimaler Performance-Regression (~1-2% CPU).

KI-Ops eBPF Module

KI-Ops bringt vordefinierte eBPF-Programme mit, die der Service in deiner Infrastruktur ausrollt, betreibt und kontinuierlich tunt:

1. Syscall Tracing

$ ki-ops trace-syscalls --container my-app
Tracing 8234 syscalls in Echtzeit...

[14:23:45.234] Namespace: production, Pod: my-app-xyz
├─ open("/var/log/app.log", O_WRONLY) → fd=42
├─ write(42, "INFO: Request processed", 23) → 23 bytes
├─ fsync(42) → 0 (Success)
│  (23.4ms Latency! Warum fsync so lange?)
├─ connect(tcp:10.0.1.5:5432, SOL_TCP) → SUCCESS
│  (Connection jetzt open, aber vorher: 234ms Latency)
├─ send(socket, "SELECT * FROM users", 45) → 45 bytes
├─ recv(socket, [buffer], 4096) → BLOCKING (1234ms)
│  [Blockiert auf Postgres-Response!]
└─ read(/etc/config/db.conf) → 2789 bytes

LATENCY BREAKDOWN:
├─ Filesystem I/O: 23ms (fsync auf HDD = langsam!)
├─ Network Latency zu DB: 234ms (Connection Setup)
├─ Postgres Query Execution: 1234ms (Query zu langsam)
└─ Total Request Latency: 1491ms

💡 ERKANNTE PROBLEME:
  1. fsync() blockiert UI. Async Logging verwenden?
  2. DB Connection pooling verbessern (zu viel TCP overhead)
  3. Postgres Query optimieren (wahrscheinlich Index-Problem)

2. Network Flow Visibility

$ ki-ops trace-network-flows --namespace production --pod-regex "api-.*"
Capturing network flows...

Pod: api-service-abc123 (IP: 10.42.0.5)
├─ OUTBOUND (Initiiert Connections):
│  ├─ → 10.0.1.5:5432 (postgres) [TCP ESTABLISHED]
│  │  ├─ Packets: 1247 sent, 1289 received
│  │  ├─ Bytes: 487MB sent, 512MB received
│  │  ├─ Latency P50: 12ms, P99: 45ms
│  │  └─ Retransmits: 3 (sehr wenig, gute Netzwerk-Quality)
│  │
│  ├─ → 10.0.2.10:6379 (redis-cache) [TCP ESTABLISHED]
│  │  ├─ Packets: 45234 sent, 45123 received
│  │  ├─ Bytes: 234MB sent, 345MB received
│  │  ├─ Latency P50: 2ms, P99: 8ms
│  │  └─ Retransmits: 0
│  │
│  └─ → 1.1.1.1:53 (DNS) [UDP]
│     ├─ Queries: 847 total
│     ├─ Failures: 12 (1.4% failure rate) ← PROBLEM!
│     ├─ Latency: P50 8ms, P99 234ms (langsam!)
│     └─ Timeout Queries: 23

├─ INBOUND (Empfängt Connections):
│  ├─ ← 10.42.0.1-10.42.0.47 (Kube-Proxy) [TCP LISTEN]
│  │  ├─ Connections: 1247 active, 34892 total (seit Neustart)
│  │  ├─ Avg Connection Lifetime: 4.2 sec
│  │  └─ Dropped Connections: 0
│
└─ CROSS-POD (Andere Pods in Cluster):
   ├─ ← frontend-service-xyz [TCP]
   │  ├─ Requests: 12345/sec
   │  ├─ Errors: 0.2%
   │  └─ Latency: avg 34ms
   └─ ← worker-job-123 [gRPC]
      ├─ Calls: 234/sec
      └─ Latency: avg 156ms (höher, Check gRPC-Serialisierung?)

🔍 ERKANNTE ISSUES:
  1. DNS ist Bottleneck (23 timeouts, P99 234ms)
     → Check CoreDNS Health, add DNS Caching Layer
  2. Postgres Retransmits gering aber vorhanden (TCP tuning?)
  3. Inbound Connections gut verteilt, keine Connection-Leaks

3. Latency Profiling & Root-Cause-Erkennung

$ ki-ops profile-latency --container my-app --duration 60s
Profiling CPU & Latency für 60 Sekunden...

┌─ LATENCY BREAKDOWN (Flame Graph äquivalent)
│
├─ main() [Total: 1234ms per request]
│  ├─ http.HandleRequest() [456ms]
│  │  ├─ json.Unmarshal() [45ms] (JSON parsing)
│  │  ├─ ValidateInput() [12ms]
│  │  └─ ProcessRequest() [399ms]
│  │     ├─ db.Query() [324ms] ← HOTSPOT!
│  │     │  ├─ network.Send() [45ms] (Network latency)
│  │     │  ├─ postgres.Execute() [234ms] (Query execution)
│  │     │  └─ network.Recv() [45ms] (Response)
│  │     │
│  │     ├─ cache.Set() [23ms]
│  │     └─ json.Marshal() [52ms]
│  │
│  ├─ http.WriteResponse() [34ms]
│  └─ [OTHER] [288ms] (Kernel I/O, context switches)
│
└─ ERKANNTE HOTSPOTS (wo CPU/Zeit verschwindet)
   ├─ postgres.Execute: 26% der Total-Latenz
   ├─ Kernel I/O (not visible in code): 23%
   ├─ JSON Serialization: 7%
   └─ (Andere): 44%

💡 ACTIONABLE EMPFEHLUNGEN:
  1. Postgres Query braucht Optimierung
     → EXPLAIN PLAN analysieren, Index hinzufügen?
  2. 23% Kernel I/O ist normal aber prüfbar
     → Check if HDD bottleneck (SSD upgrade?)
  3. JSON Serialization könnte Protobuf werden
     → Trade-off: Complexity vs Performance

eBPF vs. Alternatives

| Ansatz | Setup | Overhead | Visibility | Latenz | |--------|-------|----------|------------|---------| | eBPF (KI-Ops) | Managed Rollout | 1-2% | Kernel-Level | Real-Time | | OpenTelemetry SDK | Code-Änderungen | 5-10% | Anwendungs-Level | Aggregated | | Datadog APM | Agent + SDK | 8-15% | Proprietary | Delayed | | Custom strace | CLI Tool | 50%+ | Basic | Slow | | VirtualMachine Monitoring | Hypervisor | 20%+ | VM-Level | High Latency |

Praktische Anwendungen

Use Case 1: "Warum ist meine API plötzlich langsam?"

ki-ops profile-latency --pod api-service-abc123
# eBPF zeigt exakt welcher Syscall/Function den Bottleneck darstellt
# Z.B.: kernel flusht Buffer auf langsame HDD statt fast SSD
# Erkenntnis: Block Device Tuning, Kernel Parameters, oder Hardware Upgrade

Use Case 2: "DNS ist kaputt aber keiner weiß warum"

ki-ops trace-network-flows --filter "dns"
# eBPF captured alle DNS Queries und Response-Latenz
# Zeigt: CoreDNS antwortet mit 234ms (viel zu lange)
# Analyse: CoreDNS CPU-bottleneck? ETCD Watch lag? Netzwerk jitter?

Use Case 3: "Wir haben einen Memory Leak irgendwo"

ki-ops trace-syscalls --filter "mmap|malloc|brk"
# eBPF tracked alle Memory-Allocation Syscalls
# Zeigt welcher Teil der App ständig Speicher allokiert
# Analyse: Wird Speicher freigegeben?

Security & Performance Considerations

  • Kernel Verifiability: eBPF-Program muss vom Kernel-Verifier genehmigt werden (keine Bugs/Exploits)
  • Memory-Limits: eBPF Stack auf 512 Bytes limitiert (verhindert DoS)
  • CPU-Capping: Long-running Loops nicht erlaubt (Kernel terminiert nach X Instruktionen)
  • RBAC: Benötigt CAP_SYS_RESOURCE + CAP_PERFMON (nur Node-Level, nicht Pod-Level)

KI-Ops läuft als Privileged DaemonSet auf jedem Node (wie kubelet) – in deiner Umgebung, betrieben und gewartet vom Skalenta-Team. Die erfassten Daten verlassen deine Infrastruktur nicht. Das passt direkt auf Compliance-Anforderungen wie DORA, NIS-2 und EU AI Act.

Was du mit eBPF gewinnst

  • 100% Code-Coverage: Tracing von allen Syscalls, nicht nur explizit instrumentierter Code
  • Zero Application Changes: Alte Legacy-Apps automatisch sichtbar
  • Kernel-Aware: Sieht Context-Switches, Page-Faults, I/O-Waits die andere Tools vermissen
  • Performance-Forensics: Exact Latency-Attribution auf Kernel-Subsysteme
  • Security Use Cases: Detect Malware syscall patterns, privilege escalation, etc.

Im SaaS-Tool enthalten

  • Rollout & Betrieb: Skalenta rollt die eBPF-DaemonSets in deinem Cluster aus, betreibt sie und hält sie aktuell – ohne dass du eigene Kernel-Programme pflegen musst.
  • Updates & Tuning: Neue Probes, Kernel-Kompatibilität und Performance-Tuning kommen kontinuierlich vom Team.
  • Datenhoheit: Syscalls, Network-Flows und Profiles bleiben in deiner Cloud bzw. On-Prem-Umgebung.
  • Intelligente Diagnose: KI-Ops erkennt und analysiert Performance-Issues auf Kernel-Ebene und schlägt Optimierungsempfehlungen vor.

Willst du sehen, was eBPF in deinem Cluster sichtbar macht? Demo buchen.

In deiner Umgebung sehen

Wir zeigen dir diese Funktion live an einem Setup wie deinem – managed, in deiner Cloud oder On-Prem.

Demo buchen