Add Linux support

[pharring]

Please vote or add comments regarding support for Application Insights Snapshot Debugger for .NET Core application on Linux.

If you comment, it would help if you could describe the environment (e.g. in a Linux VM; in a docker container; in Kubernetes; in Azure App Service for Linux).

See also microsoft/ApplicationInsights-dotnet#1901

[MichalZem]

Hello, I am voting in favor of Linux on Kubernet. Thank you.

[christianacca]

+1

Using AKS

[scp-mb]

Reiterating my original support for this, we're now in full swing migration to AKS and have had to add conditional logic to completely disable the snapshot collector in non-windows environments.

[priyanr]

+1 kubernetes

[clxx]

Kubernetes. Thank you!

[ncoussemacq]

+1 Azure App service for containers (and AKS in the future)

[ariellourenco]

👍🏾 support for Kubernetes!

[niklas-r]

Could we get any information on when this will be supported? Specifically for AKS. Thanks.

[Wolfmarsh]

+1 support for AKS/Linux

[tghamm]

@pharring spent some time digging on this a little today. Why is SnapshotUploader(and 64) unmanaged? That seems like the biggest gatekeeper to letting the community chip in here (in addition to the code being technically closed source in general it seems). I was able to decompile and refactor the latest codebase, get it running in a linux docker container, and produce (I think) a valid dump in a few hours. It's not production grade, but wanted to understand the roadblocks better. Then I realized the uploader being unmanaged and using non-trivial message transports meant I coulnd't really go any further on my own.

[pharring]

Thanks for the interest. I love the enthusiasm, @tghamm. I will be as honest and open with you as I can be.

Linux support (along with containers) has been on our backlog for a long time. Unfortunately, since it's such a big work item, it keeps getting pushed down the priority stack by other things. We had a prototype going a few years ago -- thanks to the work of an incredible intern -- but we weren't funded to take it to production. Since then, I've raised the request several times and each time there has been diminishing enthusiasm from the business side. Snapshot Debugger adoption has not been as high as we expected or wanted.

Some technical pointers:
SnapshotUploader is not actually unmanaged. However, it is heavily tied to Windows via P/Invokes (PssSnapshot APIs, DIASymReader, MinidumpWriteDump and EXCEPTION_CONTEXT) and it is a .NET Framework application, not .NET Core.

The communication between SnapshotCollector and SnapshotUploader is via a named pipe. SnapshotUploader is the server-side so that it can keep going if the client (your app) crashes. The protocol is binary. The first 4 bytes specify the message type (version). There are only 3 kinds of message: Snapshot request, Shutdown request and PDB scan request. The most complex is the Snapshot request (pointer-size, exception-pointers, PSS Snapshot information and metadata-as-JSON).

There's more to it than the uploader, though:

• How to snapshot the process. It'll be some variant of fork. (Presumably you figured that part out already).
• How to capture exception information.
• How to serialize the snapshot process and exception information in a way that the uploader can create a durable crash dump.
• Decide on a crash-dump format. Something natively-Linux-y or something compatible with dotnet-dump

On the service side, we need to recognize and handle the Linux crash-dump format and update our analyzer to work with it.

[HeroMaxPower]

+1 kubernetes

[KenBrannigan]

+1 Azure App service for containers (and AKS in the future)