Create a low-friction on-ramp to being able to use dotnet-monitor with minimal effort

[samsp-msft]

In #3007 I suggest it should be possible to use dotnet-monitor to launch a process

We can take that another big step forward in terms of ease of use by:

• Incorporating it with a UI, similar to #17.
• Securing it by default by:
  • Automatically configuring only an https endpoint
  • Automatically generating an Access Key if one hasn't been specified in config
• Incorporating the serving of a SPA application as the default endpoint action
• Enabling quick access to the results by reporting back a URL with the automatic access key that will bring you directly to the results
• Collecting the app output automatically (aka logs) and exporting that to the application UI

Imagine being able to do something like:

> dotnet-monitor WebApplication1.dll
14:07:36 info: Microsoft.Diagnostics.Tools.Monitor.Startup[60]
      Tell us about your experience with dotnet monitor: https://aka.ms/dotnet-monitor-survey
14:07:36 info: Microsoft.Diagnostics.Tools.Monitor.Startup[76]
      Connection mode: Connect
14:07:36 info: Microsoft.Diagnostics.Tools.Monitor.MonitorApiKeyConfigurationObserver[56]
      API key authentication is not configured, generating a key automatically. See https://go.microsoft.com/fwlink/?linkid=2187444&clcid=0x409 for more details.
14:07:36 info: dotnet-monitor UI can be found at https://localhost:52323/?key=DSF#GIEUUF*FI39U0239UDFHWEFHWEHDWEFGHWE9
14:07:36 info: dotnet-monitor WebApplication1 started. 

Clicking the link (https://localhost:52323/?key={blob}) that is output would navigate to the UI, and if the access key is auto generated, then that would be included in the URL that is returned, making it a one-click to be able to monitor the process. It makes the endpoint secure (why I also suggested only https) but with ease of use.

The UI would then provide easy access to collect dumps, traces, etc, mostly as described in #17 and put you into a dashboard based on the metrics and logs features shown in https://github.com/SachiraChin/dotnet-monitor-ui#updates.

In the case that an access key is configured through config, the SPA UI would be delivered, but would deliver back a UI for the key to be entered, which would then generate a URL that could be cached in the browser for more sustained access.

[Tratcher]

Automatically configuring only an https endpoint

This requires a certificate. Would it use the dev cert? That's only valid for localhost.

Would it bind to a public or loopback IP? If this is loopback then https seems unnecessary.

[samsp-msft]

I would suggest a loopback over https, with a dev cert if a real one is not configured. https because a key is being used, which is not a one-time thing so could be replayed and used to access memory of the target app (via a dump) thereby potentially exposing additional credentials.

What this would enable is a good experience with F5, and a way to diagnose what is going on in a container in a low friction manner. A lot of the feedback we are seeing is that setup and configuration of sidecars etc is making deployment more complicated than it needs to be.