Die Wahrheit liegt in der Telemetrie: Wie Produktionsdaten Systeme ins Gleichgewicht bringen

In der Softwareentwicklung gibt es zwei Welten: das Labor und die Produktion. Im Labor funktioniert Load Balancing perfekt. Requests werden gleichmässig verteilt, Server-Instanzen schnurren im Einklang.

Doch dann trifft das System auf die Realität.

Ohne saubere Telemetrie ist der Betrieb eines verteilten Systems ein Blindflug. Man spürt zwar, dass etwas nicht stimmt – Latenzen steigen, Nutzer beschweren sich –, aber die Ursache bleibt im Verborgenen. Erst mit echten Daten aus der Produktion lässt sich ein System korrekt "ausbalancieren".

Ein Blick auf einen echten Telemetrie-Report zeigt, warum das so ist.

[1] LAST-VERLAUF & PERFORMANCE (Korrelation Load vs. Latenz)

Zeit | Auslastung (req/s) | <0.1s (Gut) | 0.1-0.5s | >0.5s (Kritisch)

2026-06-17 00:00 | ( 0.2) | 100.0% | 0.0% | 0.0%
2026-06-17 01:00 | ( 0.2) | 100.0% | 0.0% | 0.0%
2026-06-17 02:00 | ( 0.2) | 100.0% | 0.0% | 0.0%
2026-06-17 03:00 | ( 0.2) | 100.0% | 0.0% | 0.0%
2026-06-17 04:00 | ( 0.2) | 100.0% | 0.0% | 0.0%
2026-06-17 05:00 | ██ ( 0.5) | 90.6% | 6.5% | 2.9%
2026-06-17 06:00 | ██ ( 0.6) | 98.1% | 1.3% | 0.6%
2026-06-17 07:00 | ███████ ( 1.9) | 98.1% | 1.3% | 0.6%
2026-06-17 08:00 | █████████ ( 2.5) | 98.6% | 0.9% | 0.5%
2026-06-17 09:00 | ████████████ ( 3.1) | 98.8% | 0.8% | 0.4%
2026-06-17 10:00 | ███████████ ( 2.8) | 98.6% | 0.8% | 0.5%
2026-06-17 11:00 | █████████ ( 2.4) | 98.6% | 0.8% | 0.5%
2026-06-17 12:00 | ██████ ( 1.7) | 96.0% | 2.5% | 1.6%
2026-06-17 13:00 | ████████ ( 2.2) | 98.1% | 1.2% | 0.7%

[2] INSTANZ-VERGLEICH (Gesamt-Durchschnitt in req/s)

backend_inst_8001 | ████████████████████████████████████████ (1.72 req/s)
backend_inst_8002 | ███████████████████████████████████████ (1.72 req/s)
backend_inst_8003 | ██████████ (0.47 req/s)

[3] VOLUMEN & GESCHÄTZTE RECHENZEIT (Total)

backend_inst_8001 | Calls: 84'597 | CPU-Zeit: ██████████ (~910s)
backend_inst_8002 | Calls: 84'058 | CPU-Zeit: ██████████ (~936s)
backend_inst_8003 | Calls: 22'949 | CPU-Zeit: ██████████████████████████████ (~2,637s)

Der trügerische Schein der Request-Verteilung

Betrachten wir ein System mit drei Backend-Instanzen. Auf den ersten Blick scheint die Lastverteilung asymmetrisch:

• backend_inst_8001: 1.72 req/s (84'597 Calls)
• backend_inst_8002: 1.72 req/s (84'058 Calls)
• backend_inst_8003: 0.47 req/s (22'949 Calls)

Ein naiver Ansatz wäre nun, den Load Balancer so zu konfigurieren, dass er mehr Traffic auf Instanz 8003 leitet, da diese scheinbar weniger zu tun hat. Ein fataler Fehler.

Der CPU-Plot-Twist

Der zweite Teil der Telemetrie-Daten offenbart das wahre Problem. Wenn wir das Request-Volumen mit der geschätzten Rechenzeit (CPU-Zeit) korrelieren, dreht sich das Bild komplett:

• backend_inst_8001: ~910s CPU-Zeit
• backend_inst_8002: ~936s CPU-Zeit
• backend_inst_8003: ~2'637s CPU-Zeit

Obwohl Instanz 8003 nur ein Viertel der Requests von Instanz 8001 verarbeitet, verbraucht sie fast dreimal so viel CPU-Zeit.

Was sagt uns das?

Nicht jeder Request ist gleich. Während die ersten beiden Instanzen vermutlich viele kleine, schnelle Abfragen (z.B. einfache GET-Requests oder Health-Checks) abarbeiten, landen auf Instanz 8003 extrem rechenintensive Operationen. Das könnte an einer unglücklichen Client-Verteilung liegen – vielleicht wird ein spezifischer "Power-Client", der komplexe Report-Generierungen anfragt, durch Sticky Sessions immer auf Instanz 8003 geroutet.

Ohne diese granularen Telemetriedaten hätten wir das System falsch skaliert. Wir hätten Instanz 8003 mit noch mehr Requests bombardiert und sie damit unweigerlich zum Absturz gebracht.

Zudem zeigt der Last-Verlauf des Reports, dass es um 05:00 Uhr und 12:00 Uhr zu Latenz-Spitzen kommt (bis zu 2.9% der Requests dauern >0.5s). Dies korreliert nicht zwingend mit der höchsten Request-Rate (die um 09:00 Uhr mit 3.1 req/s liegt), sondern deutet auf geplante, schwere Batch-Jobs oder Cron-Tasks hin, die zu diesen Uhrzeiten das System blockieren.

Fazit: Telemetrie als Architektur-Werkzeug

Telemetrie ist kein reines Debugging-Tool für den Notfall. Sie ist ein fundamentales Werkzeug für das Architektur-Design.

Erst wenn wir verstehen, welche Art von Last wo und wann entsteht, können wir intelligente Entscheidungen treffen:

1. Workload-Isolation: Rechenintensive Tasks auf dedizierte Worker-Nodes auslagern.
2. Smart Balancing: Traffic nicht nach reiner Anzahl der Requests, sondern nach erwartetem Ressourcen-Verbrauch routen.
3. Client-Analyse: Identifizieren, welche Clients das System dominieren und entsprechende Rate Limits oder dedizierte Infrastruktur bereitstellen.

Gute Software wird im Labor geschrieben. Exzellente Software wird in der Produktion kalibriert.