.NET › Diagnostics & Performance

What is the purpose of the dotnet-monitor tool, and how does it enable diagnostics in containerized/production environments?

Intermediate

Answer

dotnet-monitor runs as a sidecar or standalone process alongside your application, exposing an HTTP API to collect diagnostics artifacts (traces, dumps, logs, metrics) on demand or automatically when trigger rules match (like high CPU or an exception occurring), without needing direct shell access to the container or manually installing diagnostic tools inside a production container -- particularly valuable in Kubernetes environments where interactive debugging access is often restricted.
# Running as a sidecar in Kubernetes, collecting a trace via its HTTP API:
curl -X POST "http://localhost:52323/trace?pid=1&durationSeconds=30" -o trace.nettrace

# Or configured to auto-collect a dump when CPU exceeds a threshold for 30 seconds
{ "CollectionRuleDefaults": { "Triggers": { "CPUUsage": { "GreaterThan": 90, "SlidingWindowDuration": "00:00:30" } } } }
Real-world example A Kubernetes-hosted microservices platform deploys dotnet-monitor as a sidecar in every pod, allowing on-call engineers to remotely capture a memory dump from a misbehaving production pod via a simple HTTP call, without needing kubectl exec shell access.

Common follow-ups: How do collection rules automate diagnostics without human intervention?;What security considerations apply to exposing dotnet-monitor's API?