Wie löst man ein fundamentales Observability-Problem in Actor-basierten Systemen, ohne die Performance zu opfern? Discord hat genau das geschafft – und macht seinen Ansatz nun für die gesamte Engineering-Community transparent.
Discord löst Tracing-Problem in verteilten Elixir-Systemen ohne messbare Performance-Einbußen
Discord hat eine technische Lösung für ein grundlegendes Observability-Problem in Actor-basierten Systemen veröffentlicht. Das Unternehmen beschreibt, wie es verteiltes Tracing in seiner auf Elixir aufgebauten Infrastruktur implementiert hat – ohne die Latenz oder den Durchsatz der Plattform spürbar zu beeinträchtigen.
Das Problem: Kontext geht verloren
In Actor-Modellen wie dem von Elixir genutzten BEAM-System kommunizieren Prozesse ausschließlich über asynchrone Nachrichten. Das erschwert Distributed Tracing erheblich: Klassische Ansätze, bei denen ein Trace-Kontext einfach durch den Call Stack weitergegeben wird, funktionieren hier nicht. Sobald eine Nachricht einen Prozess verlässt und einen neuen Actor erreicht, ist der ursprüngliche Kontext verloren.
Entwicklungsteams können bei der Fehlersuche in Produktionssystemen keine durchgängigen Request-Traces mehr rekonstruieren – ein gravierendes Hindernis für schnelle Incident-Response.
Discord betreibt eines der größten BEAM-basierten Systeme weltweit. Die Plattform verarbeitet täglich mehrere Milliarden Events über Millionen von gleichzeitigen Elixir-Prozessen. Entsprechend hoch sind die Anforderungen an Observability – aber auch an die Effizienz der Lösung selbst.
Kontextpropagation auf Prozessebene
Die von Discord entwickelte Lösung setzt auf eine explizite Weitergabe des Trace-Kontexts als Teil jeder Nachricht. Beim Versenden einer Nachricht zwischen Prozessen wird der aktuelle Span-Kontext automatisch eingebettet. Der empfangende Prozess extrahiert diesen Kontext und setzt den Trace nahtlos fort.
Diese Mechanik wurde so tief in die interne Messaging-Infrastruktur integriert, dass Entwickler keine manuelle Annotierung im Anwendungscode vornehmen müssen.
Entscheidend war dabei die Wahl des richtigen Instrumentierungspunkts:
Anstatt auf Anwendungsebene einzugreifen, nutzt Discord Hooks in der eigenen Abstraktion über OTP-Prozesse – transparent für den Großteil des Codebases und zentral wartbar.
Overhead bleibt marginal
Ein zentraler Befund aus Discords interner Messung: Der zusätzliche Overhead durch das Einbetten und Auslesen des Trace-Kontexts liegt im einstelligen Mikrosekunden-Bereich pro Nachricht. Bei den meisten Workloads ist dieser Wert nicht messbar von den normalen Latenzschwankungen zu unterscheiden.
Discord setzt zusätzlich auf Sampling, um die Datenmenge in der Tracing-Pipeline zu begrenzen – nur ein Teil der Requests wird vollständig instrumentiert, was die Last auf das Backend-System erheblich reduziert.
Die gesammelten Traces werden in ein OpenTelemetry-kompatibles System exportiert, was die Integration in bestehende Observability-Stacks wie Jaeger oder Honeycomb ermöglicht.
Strukturelle Erkenntnisse für verteilte Systeme
Discords Ansatz verdeutlicht ein allgemeines Designprinzip:
Observability muss in verteilten Systemen auf der Ebene des Kommunikationsmediums ansetzen – nicht auf der Ebene einzelner Funktionen oder Module.
In nachrichtenbasierten Architekturen – ob BEAM, Akka oder vergleichbaren Frameworks – ist die Nachricht selbst der einzige verlässliche Träger für kontextuellen Zustand.
Einordnung für deutsche Unternehmen
Für deutschsprachige Unternehmen, die auf Elixir, Erlang oder andere Actor-basierte Systeme setzen – etwa in der Telekommunikation, im IoT-Bereich oder bei hochskalierten SaaS-Plattformen – liefert Discords Veröffentlichung einen praxiserprobten Referenzansatz.
Die Kernprinzipien lassen sich auch auf andere asynchrone Architekturen übertragen, etwa auf Kafka-basierte Event-Driven-Systeme oder Microservice-Landschaften mit hohem Nachrichtenvolumen. Teams, die aktuell an der Einführung von OpenTelemetry arbeiten, sollten den technischen Bericht als Grundlage für die eigene Instrumentierungsstrategie in Betracht ziehen.
