Botframework-sdk: DCR: Standard Bot Diagnostics Endpoint

[johnataylor]

Is your feature request related to a problem? Please describe.
Yes. It can be hard to diagnose deployment problems.

Describe the solution you'd like
A standard endpoint on the bot. This could be somewhat open ended - and developer extensible. The trick would be having the Azure Portal and command line tools know about this endpoint.

[johnataylor]

This is a suggestion from @arturl

[johnataylor]

From discussion @Stevenic @stevengum @daveta @benbrown

Would this belong at the sample level or the SDK level?

The SDK doesn't set up any web endpoints by itself. Could the SDK help to expose the right info and let developers ingest it or use it however they like? The bot knows best about all its internal dependencies.

We'll need to think about this and plan for it in the long term.

[scheyal]

+1, and added supportability, ridealong tags.

In response to the ridealong session, some of my learning is that troubleshooting our stack is challenging. Issues such as timing, timeouts, errors are hard to pinpoint and CSS choice now is to ask the customer to enable profiling, getting memory dump and engage with very time consuming troubleshooting activities, just to find out it is a customer coding problem.

I'd be happy to help in design, proposal. Some of the thoughts around the feature design areas (a bit random here): :

1. Diagnostics endpoint
2. Security requirement (present a key/token for auth/z)
3. Poke entre stack, each "handler" should add its diagnostics payload (channel incoming/outgoing, adaptor, middle layer, underlying dialog turn handlers)
4. Allow customer to add their own custom diagnostics payload
5. Control plane commands (e.g. request verbose level: info/trace), format (json/plain)
6. Custom commands (e.g. dump state db)
7. Include corresponding diagnostics command in BF CLI (but could use REST postman like utilities and automation)
8. "Self-reflection" metadata about the the bot running environment, name, id's, language all in one package that can be handed to investigator (think CSS support engineer)

However, we need to beware of scope creep (some of the items above may be overcreeped already).

The idea is that this is a quick and light diagnostics utility, a tiny mini before app insights diagnostics.
Think of it as a utility for customer support to ask the customer to run a tool to gather diagnostics information to assist in investigating an issue. A one click diagnostics tool. It can be used by the customer, CSS, dev to enable initial troubleshooting on the fly support personal as well as used by the customer for custom monitoring/probing.

[cleemullins]

We need to close on a plan, then figure out what work to do...