OpenTelemetry in a Brownfield World
summary
Brownfield systems with only Splunk logs become a sea of timestamps and guessing; the concrete win is replacing vendor-specific hooks with OpenTelemetry instrumentation, exporting via OTLP to a local collector, and forwarding identical traces to Zipkin, Jaeger or DataDog. The demo uses RabbitMQ, MongoDB and ASP.NET (.NET 4.7/.NET 6+), shows service defaults lighting up logs, traces and metrics, and proves the OpenTelemetry Collector + Aspire local UI captures and forwards full distributed traces without changing application logic.
AI-written summary · about
chapters (16)
- 0:00Introduction to OTel
- 2:03Distributed system challenges
- 5:18Defining observability signals
- 7:34Understanding telemetry signals
- 11:19The problem of vendor lock-in
- 15:23OpenTelemetry as a solution
- 17:10Brownfield system realities
- 19:14Why choose OpenTelemetry
- 23:01OTel migration strategy
- 25:38OTel implementation in .NET
- 29:30Handling distributed tracing
- 33:34Incremental migration steps
- 37:11Migrating log generation
- 42:21Implementing tracing
- 46:12Aspire and OTel demo
- 58:31Using the OTel collector
related talks
01h 04mOpenTelemetry in a Brownfield World
59mOpenTelemetry will save your day and night
22mOpenTelemetry – An Observability Framework for Cloud-Native Software
35mOpenTelemetry for Busy People
32mOpenTelemetry feat. logs, metrics and traces
22mBridging the OpenTelemetry Adoption Gap in Cloud-Native Applications
38mPractical introduction to OpenTelemetry tracing
28mGetting Started with OpenTelemetry