blog: Making continuous .NET profiling practical for production Kubernetes workloads

[danielpacak]

Blog Post Title

Making continuous .NET profiling practical for production Kubernetes workloads

Blog Post Outline

Continuous, low-overhead profiling has become essential for production observability, yet managed runtimes like .NET remain difficult to profile. Their call stacks combine dynamically generated and precompiled code, and unlike native binaries, human-readable function names are not exposed through the standard symbol formats a system profiler relies on. This post describes how a whole-system eBPF profiler reconstructs readable function names from raw instruction addresses with no code changes and under 1% overhead. Since most .NET services run on Kubernetes, I also cover attributing samples to the correct pod and container and mapping frames back to workloads without an in-process agent. I close with the engineering trade-offs of doing this at scale: caching, bounding memory under load, and validating results against real process state across runtime versions.

Technologies Used

• OpenTelemetry eBPF Profiler
• Kuberentes
• .NET

Related Special Interest Groups (SIGs)

• Profiling SIG
• eBPF Profiler SIG
• .NET SIG
• Collector SIG

Sponsoring SIG

Profiling SIG

Sponsor Name

TBD

Additional Information

• feat(dotnet): keep only most recently used strings in memory LRU cache opentelemetry-ebpf-profiler#1338
• [.NET] Keep only most recently used strings in memory LRU cache opentelemetry-ebpf-profiler#1329
• refactor(dotnet): key PE info cache by 4 KiB-header content hash opentelemetry-ebpf-profiler#1431

[svrnm]

Thanks @danielpacak , best you talk with @open-telemetry/profiling-approvers or @open-telemetry/ebpf-profiler-approvers about them sponsoring this blog post, as they would be the first reviewers for it, you can learn more here: https://opentelemetry.io/docs/contributing/blog/#before-submitting-a-blog-post