Allow getting entrypoint assembly via diagnostics IPC protocol

[jander-msft]

Scenario

In a Kubenetes environment where a sidecar monitoring application (e.g. dotnet-monitor) is able to observe the dotnet processes in other containers within the same pod, much of the identifying information of the processes will be either arbitrary (e.g. the runtime instance cookie) or the same amongst all processes (e.g. the process ID for each process is 1 because they all are the entrypoint of their respective containers). This makes it difficult from a preconfigured standpoint to identify which process is of interest because they all have the same identifying information or the current set of uniquely identifying information is effectively randomly determined at application start.

Specifically, the dotnet-monitor tool would like to describe via configuration which processes it would like to apply some event source observability. Because this configuration is statically set before the pods and containers are created, it needs to be able to identify which process is of interest based on some known information before the runtimes start. Process ID and runtime instance cookie values are not sufficient, given the previous explanation. The executable name is likely to be dotnet in most cases, so that is not unique enough for identification. What remains is identifying based on command line, the entrypoint assembly (e.g. App1.dll), or environment variables.

• Using command line: The command line of each process is likely to be unique. For example, it would look like "dotnet.exe App1.dll <additional args>" with likely additional arguments to the application. The unique identifying aspect of the command line is likely to be the entrypoint assembly. However, this may be difficult for an external observer to determine because the ordering of arguments may be arbitrary and the exact parsing syntax may not be known to external observers.
• Using environment variables: Using an environment variable to identify each container is a possibility, but it has its own unique challenges. It requires that the author of the Kubernetes pod spec to set the same environment variable with unique values on each container. The dotnet-monitor tool would need to be configured to look up the environment block just to identify each process. If containers are injected via mutating admission webhook controllers from 3rd party packages, the containers may not have the environment variables set. If the pod spec author forgets to add the environment variable to an interesting container, identification won't work until the deployment is updated.
• Using entrypoint assembly: The managed entrypoint assembly is a good candidate for identifying processes. It is likely to be different for each type of application that is deployed. The runtime directly knows what the entrypoint is. Additionally, it is more conceptually understood that dotnet is running a specific entrypoint assembly rather than intuitively understanding which process ID an app happens to be running as, which runtime instance cookie the runtime happens to have, or what environment variable value as process has.

Proposal

Allow getting the entrypoint assembly via the diagnostics IPC protocol, whether as a new command of the process command set or an extension of the existing GetProcessInfo command. The full path of the entrypoint would be desirable, however if that is not available, the partial path provided on the command line or just the file name would be a good fallbacks.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Scenario

In a Kubenetes environment where a sidecar monitoring application (e.g. dotnet-monitor) is able to observe the dotnet processes in other containers within the same pod, much of the identifying information of the processes will be either arbitrary (e.g. the runtime instance cookie) or the same amongst all processes (e.g. the process ID for each process is 1 because they all are the entrypoint of their respective containers). This makes it difficult from a preconfigured standpoint to identify which process is of interest because they all have the same identifying information or the current set of uniquely identifying information is effectively randomly determined at application start.

Specifically, the dotnet-monitor tool would like to describe via configuration which processes it would like to apply some event source observability. Because this configuration is statically set before the pods and containers are created, it needs to be able to identify which process is of interest based on some known information before the runtimes start. Process ID and runtime instance cookie values are not sufficient, given the previous explanation. The executable name is likely to be dotnet in most cases, so that is not unique enough for identification. What remains is identifying based on command line, the entrypoint assembly (e.g. App1.dll), or environment variables.

• Using command line: The command line of each process is likely to be unique. For example, it would look like "dotnet.exe App1.dll <additional args>" with likely additional arguments to the application. The unique identifying aspect of the command line is likely to be the entrypoint assembly. However, this may be difficult for an external observer to determine because the ordering of arguments may be arbitrary and the exact parsing syntax may not be known to external observers.
• Using environment variables: Using an environment variable to identify each container is a possibility, but it has its own unique challenges. It requires that the author of the Kubernetes pod spec to set the same environment variable with unique values on each container. The dotnet-monitor tool would need to be configured to look up the environment block just to identify each process. If containers are injected via mutating admission webhook controllers from 3rd party packages, the containers may not have the environment variables set. If the pod spec author forgets to add the environment variable to an interesting container, identification won't work until the deployment is updated.
• Using entrypoint assembly: The managed entrypoint assembly is a good candidate for identifying processes. It is likely to be different for each type of application that is deployed. The runtime directly knows what the entrypoint is. Additionally, it is more conceptually understood that dotnet is running a specific entrypoint assembly rather than intuitively understanding which process ID an app happens to be running as, which runtime instance cookie the runtime happens to have, or what environment variable value as process has.

Proposal

Allow getting the entrypoint assembly via the diagnostics IPC protocol, whether as a new command of the process command set or an extension of the existing GetProcessInfo command. The full path of the entrypoint would be desirable, however if that is not available, the partial path provided on the command line or just the file name would be a good fallbacks.

Author:	jander-msft
Assignees:	-
Labels:	area-Diagnostics-coreclr, enhancement, untriaged
Milestone:	-