Letztes Jahr war ich bei einem Maschinenbauer im Schwarzwald, 180 Mitarbeitende, internes ERP-Portal auf ASP.NET Core 8. Die Entwickler hatten ein echtes Problem: Wenn ein nicht eingeloggter Nutzer auf eine geschützte Seite wollte, gab es einen Redirect zur Login-Seite, dann einen OAuth-Callback, dann wieder einen Redirect zum ursprünglichen Ziel. Drei Requests, drei separate Traces in Jaeger – und wenn etwas schiefging, hat das On-Call-Team manuell in den Logs nach dem Zusammenhang gesucht. Manchmal 20 Minuten für eine Frage, die eigentlich in Sekunden beantwortet sein sollte.
Das ist kein Einzelfall. Das ist Standard-Alltag in jedem KMU, das OAuth oder interne Weiterleitungen nutzt – also praktisch jedes, das ich sehe.
Was Steve Gordon erklärt
Steve Gordons Artikel löst genau dieses Problem auf eine elegante Art: Er beschreibt Middleware für ASP.NET Core, die bei internen Redirects (301, 302, 303, 307, 308) die aktuelle Activity.Id zusammen mit einem Zeitstempel via TempData in einen verschlüsselten Cookie schreibt. Beim nächsten Request – dem, auf den der Browser nach dem Redirect landet – wird diese Information ausgelesen und als Span Link an die neue Activity gehängt. Das Ergebnis: In deinem Tracing-Backend (Jaeger, Tempo, was auch immer) siehst du die kausale Kette der Requests, nicht nur isolierte Spans.
Wichtig: Die Lösung setzt auf eine API, die erst mit .NET 9 (bzw. System.Diagnostics.DiagnosticSource ab Version 9.0.0) verfügbar ist – das Nachträgliche Hinzufügen von Links zu einer bestehenden Activity. Wer noch auf .NET 8 steckt, muss das explizit als NuGet-Dependency hereinziehen. Steve weist darauf hin, dass der Code noch nicht produktionsreif battle-tested ist, und nennt explizit unbehandelte Edge Cases. Das ist ehrlich – und ein Detail, das man im KMU-Kontext unbedingt ernst nehmen muss.
Wie das in einem KMU mit 30–300 Mitarbeitenden wirklich landet
Lass mich direkt sein: Der Artikel ist technisch sauber, Steve weiß was er tut. Die Frage ist nicht ob die Lösung funktioniert, sondern wann sie den Aufwand rechtfertigt.
Was sich lohnt:
Wenn du bereits OpenTelemetry im Einsatz hast, also einen Collector läuft, Traces in einem Backend landen und dein Team tatsächlich mit Traces debuggt – dann ist dieser Middleware-Baustein ein vernünftiger nächster Schritt. Der OAuth-Redirect-Flow ist der häufigste Use Case, und da ist das Problem real. Ich schätze, dass in einem typischen B2B-Portal etwa 15–25 % aller gemeldeten "seltsamen Login-Fehler" durch genau diesen kaputten Trace-Context schwerer zu debuggen sind als nötig.
Die Implementierung selbst ist überschaubar – zwei, drei Stunden für einen erfahrenen .NET-Entwickler, um das zu verstehen und anzupassen. Der Cookie-basierte TempData-Ansatz ist pragmatisch: Er nutzt vorhandene ASP.NET Core Mechanismen, ist verschlüsselt (kann also clientseitig nicht manipuliert werden), und braucht keine externe Infrastruktur.
Was sich nicht lohnt – oder zumindest nicht jetzt:
Wenn du in deinem Team noch kein OpenTelemetry-Fundament hast, ist Span Linking das falsche erste Problem. Ich sehe regelmäßig Teams, die über avancierte Observability-Features reden, aber keine baseline Metrik dafür haben, wie viele Requests überhaupt mit Fehlern enden. Span Linking ist Level 3, und Level 1 wäre: überhaupt strukturiertes Tracing, das jemand täglich anschaut.
Zweites Problem: .NET 9. Viele KMU, die ich berate, sind auf .NET 8 – und das aus gutem Grund. Long Term Support, stabile CI/CD-Pipeline, kein Upgrade-Risiko kurz vor dem nächsten Release-Zyklus. Die Dependency auf System.Diagnostics.DiagnosticSource 9.0.0 als separates NuGet-Paket in einer .NET 8-App einzuziehen ist technisch möglich, aber es ist eine weitere Abhängigkeit, die du erklären, pflegen und beim nächsten Major-Upgrade mitschleppen musst. Das ist kein Showstopper, aber kein Trivialpunkt.
Was im Artikel fehlt:
Steve schreibt für .NET-Entwickler, die bereits im OpenTelemetry-Ökosystem unterwegs sind. Was er nicht adressiert – und das ist keine Kritik, das ist eine andere Zielgruppe – ist die Frage, was du eigentlich mit diesen Span Links siehst, wenn du sie hast.
In meinen Mandaten ist die Einführung von Tracing oft weniger ein technisches Problem als ein kulturelles: Wer schaut sich die Traces an? Wann? Mit welcher Fragestellung? Ich habe Teams gesehen, die perfekte distributed Traces hatten und trotzdem bei jedem Incident zuerst in die Logs gegangen sind, weil der Tracing-Workflow nie wirklich in die tägliche Praxis integriert wurde.
Span Linking bei Redirects hilft genau dann, wenn jemand einem konkreten Request-Flow folgen will. Das ist wertvoll – aber nur wenn du bereits eine Kultur hast, in der Traces ein erstes Debugging-Werkzeug sind, nicht ein Nice-to-Have in der Retention-Policy.
Meine konkrete Empfehlung
Drei Szenarien, drei Antworten:
Du bist auf .NET 9, hast OpenTelemetry laufen, dein Team nutzt Traces aktiv: Lies Steves Artikel komplett, nimm den Middleware-Code, adaptiere ihn für deine Edge Cases (er nennt explizit, dass welche existieren), schreib Tests für den Happy Path und den Cookie-Ablauf-Fall. Zwei Tage Arbeit, dauerhafter Nutzen.
Du bist auf .NET 8, planst bald auf 9 zu migrieren: Merk dir den Artikel, mach ihn zu einem Bestandteil deiner Upgrade-Checkliste. Die explizite NuGet-Dependency zu ziehen lohnt sich nicht für ein Feature, das in sechs Monaten out of the box verfügbar ist.
Du hast noch kein stabiles OpenTelemetry-Fundament: Investiere diese Zeit zuerst in strukturiertes Logging (Serilog oder Microsoft.Extensions.Logging mit strukturierten Feldern), dann in basic Traces für deine kritischen User Journeys, dann in Metriken. Span Linking kommt danach. Reihenfolge matters.
Eine Zahl aus der Praxis: In einem Projekt mit einem 5-köpfigen Dev-Team haben wir gerechnet, dass strukturiertes Logging die mittlere Time-to-Debug eines Incidents von 45 auf 12 Minuten gesenkt hat. Span Linking hat danach weitere 20 % rausgeholt – aber nur weil das Fundament stand.
Der vollständige Original-Beitrag von Steve Gordon: Implementing ASP.NET Core Automatic Span (Activity) Linking for Internal Redirects with Middleware on .NET 9
Wenn du gerade entscheidest, wie tief ihr in Observability investiert – oder warum Tracing bei euch noch niemand nutzt, obwohl es theoretisch läuft – dann ist das genau das Gespräch, für das ich 30 Minuten habe.
— Bernhard