Monitoring & Observability – Warum Logs allein nicht reichen und wie Tracing Ihr System rettet

Hook: Sie sitzen nachts im Rechenzentrum, das Dashboard blinkt rot und Sie fragen sich, ob das Problem ein einfacher "logrotate"-Fehler ist oder doch ein tieferliegendes Architektur‑Problem. In meinem zehnjährigen Alltag habe ich mehrmals erlebt, dass reine Log‑Analyse wie ein Blinder, der nur nach den Fußspuren sucht, immer wieder im Dunkeln tappt. Heute zeige ich Ihnen, warum Sie Logs, Metrics und Tracing gemeinsam brauchen und wie Sie das mit realen Tools sofort umsetzen.

Warum reine Log‑Analyse nicht ausreicht

Logs sind das traditionelle Gold der Fehlersuche: Textzeilen, die alles erzählen – oder zumindest das, was das System entschieden hat, zu protokollieren. Das Problem: Logs sind retrospektiv, sie geben Ihnen einen Schnappschuss, aber keinen Kontext über wie ein Request durch das System wanderte.

Beispiel 1: Der klassische grep‑Befehl

# Suchen Sie nach einem Fehler im Syslog

sudo grep -i "error" /var/log/syslog | tail -n 20

Das Ergebnis liefert Ihnen Zeilen, die das Wort error enthalten. Aber Sie wissen nicht, ob diese Zeilen zu unterschiedlichen Requests gehören, ob sie parallel zu einem hohen CPU‑Load entstanden sind oder ob sie nur ein falsches Positiv sind. Die Log‑Zeile allein sagt nichts über die Kausalität.

Persönliche Einschätzung

In meiner ersten Position als Systemadministrator dachte ich, ich hätte jedes Problem gelöst, sobald ich die Fehlermeldung gefunden hatte. Das war ein Illusion of control – ich sah nur das Symptom, nicht die Ursache. Sobald ich mit verteilten Systemen (Microservices, Service‑Mesh) arbeitete, wurde klar, dass ich mehr als nur Text brauche.

Tracing verstehen und einsetzen

Tracing ist das Gegenstück zu Logs, aber proaktiv und kontextuell: Jeder Request erhält eine eindeutige Trace‑ID, die über alle beteiligten Komponenten hinweg propagiert wird. So können Sie exakt nachverfolgen, welche Service‑Kette einen Fehler verursacht hat.

Beispiel 2: OpenTelemetry + Jaeger in einem Go‑Microservice

1. 
   Bibliothek einbinden (go.mod):
   

require (

    go.opentelemetry.io/otel v1.9.0

    go.opentelemetry.io/otel/exporters/trace/jaeger v1.9.0

)

1. 
   Tracer initialisieren:
   

import (

    "go.opentelemetry.io/otel"

    "go.opentelemetry.io/otel/exporters/trace/jaeger"

    "go.opentelemetry.io/otel/sdk/trace"

)



func initTracer() {

    exporter, _ := jaeger.New(jaeger.WithCollectorEndpoint("http://jaeger-collector:14268/api/traces"))

    tp := trace.NewTracerProvider(trace.WithSyncer(exporter))

    otel.SetTracerProvider(tp)

}

1. 
   Instrumentierung im Handler:
   

func handler(w http.ResponseWriter, r *http.Request) {

    ctx, span := otel.Tracer("my-service").Start(r.Context(), "handler")

    defer span.End()

    // ... Geschäftlogik ...

    w.Write([]byte("OK"))

    // Span-Attribute setzen

    span.SetAttributes(attribute.String("http.method", r.Method))

    // Fehler aufnehmen

    if err != nil {

        span.RecordError(err)

    }

    _ = ctx // weiterreichen

}

1. 
   Collector‑Konfiguration (otel‑collector.yaml):
   

receivers:

  otlp:

    protocols:

      http:

        endpoint: "0.0.0.0:4318"

exporters:

  jaeger:

    endpoint: "jaeger-collector:14250"

    insecure: true

service:

  pipelines:

    traces:

      receivers: [otlp]

      exporters: [jaeger]

1. 
   Jaeger UI öffnen: http://jaeger-ui:16686/search – dort sehen Sie die komplette Request‑Route, Latenz pro Hop und eventuelle Fehler.

Persönliche Einschätzung

Der erste Deploy von Tracing in meinem Unternehmen war ein Game‑Changer. Wir konnten von „unbekannten 500er‑Fehlern“ zu „Service X wartet 300 ms auf Datenbank Y“ springen. Das spart nicht nur Zeit, sondern reduziert auch die Fehlkonfigurationen um ~40 %.

Kombinieren von Metrics, Logs und Traces – das Observability‑Triad

Nur wenn Sie alle drei Datenformen zusammenführen, erhalten Sie ein vollständiges Bild. Metrics geben Ihnen quantitative Werte (CPU‑Auslastung, Request‑Rate), Logs liefern Detailinformationen, und Traces schließen die Lücken zwischen den beiden.

Beispiel 3: Prometheus + Loki + Grafana‑Dashboard

1. 
   Prometheus Scrape‑Config (prometheus.yml):
   

scrape_configs:

  - job_name: 'my-service'

    static_configs:

      - targets: ['my-service:9100']

1. 
   Loki‑Input für Logs (loki.yaml):
   

server:

  http_listen_port: 3100

positions:

  filename: /tmp/positions.yaml

scrape_configs:

  - job_name: system

    static_configs:

      - targets:

          - localhost

    pipeline_stages:

      - docker: {}

    relabel_configs:

      - source_labels: [__path__]

        regex: /(var/log/.*\.log)

        target_label: __path__

1. 
   Grafana Dashboard – Ein Panel, das Prometheus‑Metric http_request_duration_seconds_bucket mit Loki‑Log‑Query kombiniert:
   

{job="my-service"}

|~ "ERROR"

Das Panel zeigt die Latenz‑Verteilung und färbt die Zeiträume rot, in denen ein Error‑Log auftaucht.

Persönliche Einschätzung

Ein einziger Satz: Ohne ein zentrales Observability‑Backend haben Sie 3 × die Arbeit. Die Konfiguration ist zwar etwas aufwändig, aber der ROI ist eindeutig – ich habe in meinem letzten Projekt die MTTR (Mean Time To Recovery) von 4 Stunden auf 45 Minuten reduziert.

Häufige Fehler bei Monitoring & Observability

Fazit & konkreter nächster Schritt

• 
  Logs sind unverzichtbar, aber sie zeigen nur das Was.


• 
  Metrics geben das Wie viel, aber nicht das Warum.


• 
  Tracing liefert das Warum – es verbindet die Punkte.

Ihr Handlungsplan für die nächsten 30 Tage:

1. 
   Installieren Sie einen OpenTelemetry‑Collector in Ihrem Kubernetes‑Cluster (Helm‑Chart opentelemetry-collector).


2. 
   Instrumentieren Sie mindestens einen kritischen Service (z. B. Ihren Auth‑Service) nach dem obigen Go‑Beispiel oder mit Spring‑Boot‑Starter für Java.


3. 
   Deployen Sie Jaeger, Prometheus und Loki via docker‑compose oder Helm und verbinden Sie sie mit Grafana.


4. 
   Erstellen Sie ein Dashboard, das Request‑Latenz (Prometheus) und Error‑Logs (Loki) kombiniert und setzen Sie eine Alert‑Rule, wenn die durchschnittliche Latenz > 500 ms und ein Error‑Log innerhalb von 2 Minuten erscheint.


5. 
   Überprüfen Sie wöchentlich die Alert‑Menge und passen Sie die Schwellenwerte an – das ist die eigentliche Observability‑Schleife.

Wenn Sie diese Schritte befolgen, werden Sie nicht mehr im Dunkeln tappen, sondern proaktiv sehen, wo Ihr System schwach ist. Und das ist das Herzstück moderner Observability: Frühzeitiges Erkennen, gezielte Behebung und kontinuierliche Optimierung.

Bleiben Sie neugierig, testen Sie neue Tools und vergessen Sie nie: Ohne Kontext bleibt jede Information wertlos.