Warum OpenTelemetry?

Wenn du ein Monitoring-System baust, passiert immer das Gleiche:

Du wählst einen Vendor (Datadog, New Relic, Prometheus)
Du instrumentierst deinen Code gegen dessen API
2 Jahre später wechselst du zu einem anderen Vendor
Jetzt musst du deinen GESAMTEN Instrumentierungs-Code neu schreiben

Das ist die Definition von Vendor Lock-in.

OpenTelemetry (OTel) löst das: ein einziger Standard für Observability, der zu jedem beliebigen Vendor exportiert.

Dein Code instrumentiert gegen OTel, nicht gegen Datadog oder Prometheus. Danach konfigurierst du einen "Exporter", der entscheidet, wohin deine Daten gehen — Prometheus, Grafana Loki, Datadog oder OpenSearch.

Standards statt Vendor Lock-in.

Was ist OpenTelemetry?

OpenTelemetry ist ein Projekt der Cloud Native Computing Foundation. Es hat drei Säulen:

1. Traces (Distributed Tracing)

Verfolgt einen Request millisekundengenau durch dein System:

User Request comes in
├── API Gateway (5ms)
├── Auth Service (12ms)
│   └── Database Call (8ms)
├── Business Logic (45ms)
│   ├── Cache Check (2ms)
│   └── Database Query (30ms)
└── Response (2ms)
TOTAL: 67ms

Du siehst nicht nur, dass der Request 67ms gedauert hat, sondern wo die Zeit verbraucht wurde (Auth 12ms ist okay, Database 30ms könnte man optimieren).

2. Metriken (Quantitative Daten)

Numerische Messwerte über die Zeit:

Request-Rate (pro Sekunde)
Error-Rate (%)
Latenz (P50, P95, P99)
Memory-Auslastung
CPU-Auslastung
Custom-Metriken (Bestellungen pro Minute, Conversions, etc.)

3. Logs (Qualitative Daten)

Textuelle Daten, die Kontext liefern:

Error-Stacktraces
Business-Events ("User registriert")
Debug-Informationen

OTel vereint alle drei in einem einzigen Framework.

Installation in 10 Minuten

Schritt 1: Den OpenTelemetry Collector deployen

Der OTel Collector ist ein leichtgewichtiger Agent, der Observability-Daten von deinen Services einsammelt und weiterleitet.

# Add the chart repository
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm repo update

# Install the Collector
helm install otel-collector open-telemetry/opentelemetry-collector \
  --namespace observability --create-namespace

Das war's. Der Collector läuft jetzt in deinem Cluster.

Schritt 2: Den Collector konfigurieren (YAML)

Der Collector muss wissen, wohin deine Daten gehen sollen. Leg eine values.yaml an:

# Receives data from your applications
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

  # Optional: Scrape Prometheus metrics
  prometheus:
    config:
      scrape_configs:
        - job_name: 'kubernetes-pods'
          kubernetes_sd_configs:
            - role: pod

# Process the data (optional)
processors:
  batch:
    timeout: 10s
    send_batch_size: 1024

# Export to backends
exporters:
  prometheus:
    endpoint: "0.0.0.0:8888"
  otlp:
    endpoint: loki.observability:3100

# Wire everything together
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp, prometheus]
      processors: [batch]
      exporters: [prometheus]

Deployen:

helm install otel-collector open-telemetry/opentelemetry-collector \
  -f values.yaml --namespace observability

Schritt 3: Deine Anwendung instrumentieren

In deiner Node.js/Python/Go/Java-App:

Node.js-Beispiel:

const opentelemetry = require("@opentelemetry/api");
const { NodeSDK } = require("@opentelemetry/sdk-node");
const { getNodeAutoInstrumentations } = require("@opentelemetry/auto-instrumentations-node");
const { OTLPTraceExporter } = require("@opentelemetry/exporter-trace-otlp-grpc");

// Auto-instrumentation (traces, metrics for Express, DB, HTTP)
const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({
    url: "http://otel-collector:4317"
  }),
  instrumentations: [getNodeAutoInstrumentations()]
});

sdk.start();

// That's it! Every request is now traced
const express = require("express");
const app = express();

app.get("/api/users/:id", (req, res) => {
  // OpenTelemetry automatically traces:
  // - Request comes in
  // - Database query (if using Prisma/Sequelize)
  // - Response goes out
  res.json({ id: req.params.id, name: "John" });
});

app.listen(3000);

Python-Beispiel:

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace.export import BatchSpanProcessor

# Setup
otlp_exporter = OTLPSpanExporter(
    endpoint="otel-collector:4317",
    insecure=True
)
trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(otlp_exporter)
)

# Use it in your Flask/FastAPI app
from flask import Flask
app = Flask(__name__)

@app.route("/api/users/<id>")
def get_user(id):
    # Automatically traced
    return {"id": id, "name": "John"}

Schritt 4: Metriken visualisieren

Verbinde Prometheus oder Grafana mit dem Collector:

# In your Prometheus config
scrape_configs:
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector:8888']

Grafana öffnen → Add Data Source → Prometheus → Queries erstellen:

# Request rate per second
rate(http_server_request_count[1m])

# P95 Latency
histogram_quantile(0.95, http_server_request_duration_seconds_bucket)

# Error rate
rate(http_server_request_count{status_code=~"5.."}[1m])

Fertig.

Was du jetzt hast

Nach 10 Minuten:

Traces über dein ganzes System
Metriken in Prometheus
Visualisierungen in Grafana
Vendor-agnostisch (jeder Exporter funktioniert)

Typische Use Cases

1. Einen langsamen Endpoint finden

Grafana shows: /api/checkout takes 2 seconds
You open Jaeger/Grafana Traces
You see:
  - Payment Service takes 1.8s
  - Database query takes 1.7s

Sofort klar, wo das Problem liegt.

2. Service-Abhängigkeiten entdecken

Don't know which services depend on each other?
OTel traces show: Service A calls Service B
                  Service B calls Database
                  Service C is unused (can be deleted)

3. Correlation IDs fürs Debugging

User says: "My order 12345 was not processed"
You search the order ID in logs
OTel traces follow: API → Database → Queue → Worker
You see: Worker crashed at step 3

Best Practices

1. Nutze Auto-Instrumentation

Erstell nicht jeden Span manuell. Auto-Instrumentations erledigen 95% der Arbeit:

go install github.com/open-telemetry/opentelemetry-go-instrumentation/cmd/otelcontribcol@latest

2. Sampling bei hohem Volumen

Wenn du 100.000 Requests/Sekunde hast, kannst du nicht alles tracen. Nutze Sampling:

processors:
  probabilistic_sampler:
    sampling_percentage: 10  # Only sample 10%

3. Custom Spans für Business-Logik

const tracer = opentelemetry.trace.getTracer("my-app");
const span = tracer.startSpan("process-order");
span.setAttributes({
  "order.id": orderId,
  "order.amount": amount,
  "order.currency": "EUR"
});
// ... your business logic
span.end();

Integration mit KI-Ops

KI-Ops läuft in deiner Infrastruktur und nutzt deine OTel-Traces und -Metriken für präzise Analysen und Recommendations. Deine Daten verlassen deine Umgebung dabei nicht:

# KI-Ops analyzes traces from your OTel setup
ki-ops analyze --include-traces --include-metrics

# Output:
# Problem: /api/checkout takes 5 seconds (should be <1s)
# Root Cause (based on traces): Payment Service is 3s slow
# Why: Query without index on transactions table
#
# Recommendation:
# CREATE INDEX idx_payment_status ON transactions(status, created_at)

KI-Ops liefert eine datengestützte Empfehlung mit vollständiger Erklärung, nicht nur einen blinden Befehl. Dein Team validiert, prüft und führt die Änderung durch — mit allen notwendigen Tests (kubectl --dry-run, Datenbank-Migrationen, etc.) und Audit-Trail. KI-Ops bleibt read-only und nicht-invasiv. Möchtest du das in deiner Umgebung sehen? Demo buchen.

Das Fazit

OpenTelemetry ist nicht kompliziert:

OTel Collector deployen (5 Min)
Apps instrumentieren (3 Min)
In Grafana visualisieren (2 Min)

Danach hast du volle Sichtbarkeit über dein System — ohne Vendor Lock-in.

Und das macht deine Incident Response exponentiell schneller.

Ausprobieren:

git clone https://github.com/open-telemetry/opentelemetry-demo
cd opentelemetry-demo
docker-compose up
# Open http://localhost:8080 — done

OpenTelemetry in 10 Minuten: Der Standard für moderne Observability