search

dotnet / dotnet-monitor

This repository contains the source code for .NET Monitor - a tool that allows you to gather diagnostic data from running applications using HTTP endpoints
MIT License
638 stars 113 forks source link

Include other details in the /info endpoint results #3212

Open decriptor opened 1 year ago

decriptor commented 1 year ago

Background and Motivation

the /info endpoint provides a couple pieces of information, but it'd be nice if this was expanded a little bit to include other details. I'm not sure what details might be the most useful to others, but there are a couple I think would be nice to have.

Proposed Feature

One of the items I'd like to have included would be the pid of the dotnet-monitor process. In my case, I start dotnet-monitor through a WSL command so the result pid is from the wsl command on Windows instead of the actual dotnet-monitor process. Currently, I depend on either killall or pkill to clear out the dotnet-monitor process, however, that kills all of the dotnet-monitor processes. The problem with this is that we could accidentally be killing other user's dotnet-monitor process. It'd be nice to have it in the info API because the resulting pid comes from the particular dotnet-monitor instance since I'm calling the end point through a specific ip address and port number.

Other things that might be nice to have might be the target OS and version. In the case of linux cat /etc/os-release could produce all of that information.

decriptor commented 1 year ago

I think the OS and version I think is already in the process env endpoint?

jander-msft commented 1 year ago

It'd be nice to have it in the info API because the resulting pid comes from the particular dotnet-monitor instance since I'm calling the end point through a specific ip address and port number.

I think that's a great idea.

Other things that might be nice to have might be the target OS and version. In the case of linux cat /etc/os-release could produce all of that information.

This information should be added to the response of invoking the /process route since you want information about the platform of the target process, not the platform that dotnet-monitor is running on. In your case, they are the same, but the general case is not necessarily true, especially in sidecar deployments.

Additionally, not all Linux distros have /etc/os-release, but I understand the spirit of the suggestion.