With the announcement that ‘dotnet monitor’ graduated to a supported tool in .NET ecosystem, I putted it on my list of tools to have a look at. Now the summer vacation has started I finally found some time to try it out.
What is ‘dotnet monitor’?
Before I dive in on how to start using dotnet monitor, let’s explain what it does:
Dotnet monitor aims to simplify collecting diagnostics artifacts (e.g. logs, traces, process dumps) by exposing a consistent REST API regardless of where your application is run. This makes your application easy debuggable no matter if it is running locally, in a docker container, or in Kubernetes.
So dotnet monitor gives you an uniform and easy accessible way to check what is going on inside your dotnet core application.
Getting started
We’ll have a look at how we can use dotnet monitor in a sidecar container in another post, let us now focus on using it as a local tool.
Dotnet monitor is distributed as a .NET Core global tool and can be installed through NuGet:
dotnet tool install -g dotnet-monitor --version 5.0.0-preview.5.*
Now we can invoke dotnet monitor:
dotnet monitor collect
Remark: Calling this command didn’t work the first time. I got a SocketException when I tried to run it. After a reboot, it worked as expected.
Now you can browse to ‘https://localhost:52323/processes’ and see the list of active .NET core processes:
[{"pid":13212,"uid":"fc8be99e-ac72-4e1b-8519-2b50f81093a2","name":"dotnet"},{"pid":8692,"uid":"25913bc1-e7a4-4680-9538-3254fd7a057b","name":"iisexpress"}]
Once you now the correct process id you can further explore these processes in more detail using one of the following endpoints:
/processes/dump/{pid?}/gcdump/{pid?}/trace/{pid?}/logs/{pid?}/metrics
More information: https://github.com/dotnet/dotnet-monitor/tree/main/documentation