Message processing failed! But what's the root cause?
summary
Shows how to find root causes across services by combining integration tests, message-level unit tests that assert outgoing messages and ordering, and distributed traces exported with OpenTelemetry. Demonstrates using W3C traceparent header propagation, .NET’s ActivitySource / Activity API and auto-instrumentation for SQL and Service Bus, and a stock-reservation pattern to avoid negative inventory. Calls out real costs: extra memory, latency, bandwidth, storage and ongoing maintenance, and recommends start small and enrich traces.
AI-written summary · about
chapters (9)
- 0:00Start
- 14:16An example
- 18:21Recap
- 23:17Distributed tracing
- 26:03Observability
- 28:04What is a trace?
- 32:34Getting started
- 38:08Can you connect a user action to a trace?
- 49:40What's the catch?
related talks
37mMessage processing failed! But what's the root cause?
01h 13mMessage Processing Failed! But What’s the Root Cause?
55mMessage processing failed! But what's the root cause?
59mOpenTelemetry will save your day and night
13mSparking Joy for Engineers with Observability
01h 02mOpenTelemetry Tracing — Real Challenges in Complex Systems
31mTroubleshooting and Monitoring Production Applications using OpenTelemetry
32mDisintegrated telemetry: The pains of monitoring asynchronous workflows