This post has been republished via RSS; it originally appeared at: IIS Support Blog articles.
Hello bot developers,
I couldn’t wait more to write another blogpost, after my blog on bots: "How bots work". Today's subject is an important one, where we should always intend to use, if we want to understand the insights of our bots.
You may already know how to connect your bot to the application insights, don’t you? This will help the "Azure Bot Services" to produce analytics for your bot. To do this, you are locating to your application insights resource get the keys from there, and copy them over to your Bot Resource's, analytics settings. That simple.. What if you want to go beyond that, and want your bot application to produce Telemetry too? Keep tight: With version 4.2 of Bot Framework SDK, we now have "TelemetryLoggerMiddleware" built into the "Bot.Builder" namespace.
This middleware, simply use "Microsoft.ApplicationInsights.TelemetryClient" libraries to add Telemetry to your application insights project, that you have configured in your "appsettings.json" file. See here, how to wire this middleware up to your bot. You will also notice a switch on "TelemetryLoggerMiddleware" to enable/disable activity logging called "logActivityTelemetry.
Well, It seems easy to use. Let's check a sample stack below, on how these middleware is calling up other libraries. Below is the sample stack trace, when we receive an activity, and how it calls into "Microsoft.ApplicationInsights.TelemetryClient" classes. I am using this stack for one important reason. First let's check that stack -->
Microsoft.Bot.Builder.ApplicationInsights.dll!Microsoft.Bot.Builder.ApplicationInsights.BotTelemetryClient.TrackEvent(string eventName, System.Collections.Generic.IDictionary<string, string> properties, System.Collections.Generic.IDictionary<string, double> metrics)
So let's come to that important reason:
The top function on the above callstack "Microsoft.Bot.Builder.Integration.ApplicationInsights.Core.TelemetryBotIdInitializer.Initialize", has a very important task. It is initializing your telemetry fields, especially: "User" and "Session" which are quite important when you are analyzing your Application Insights. Note that these values are calculated like below. At least for now:
sessionId = StringUtils.Hash(conversationId);
channelId = (string)body["channelId"];
userId = (string)from["id"];
telemetry.Context.Session.Id = sessionId; --> This is has of "conversationID" of the "Activity" Object.
What does all these means?
This means, if you enable Bot Telemetry logger, and check your telemetry on your "Azure Application Insights", you will see actual Users, and Actual Sessions, where a User represents a "Bot User" on channel, and a Session Represent a "Conversation".
In the below picture, we are getting the contents of "dependencies" table on "Azure Portal" --> "Application Insights Project" --> "Logs" blade. A couple of lines at the bottom, doesn’t include any "Session" / "User ID", for the dependency. They are generated when we don’t use "Bot Telemetry Logger Middleware", that is why we cannot associate them to any Conversation. But the "upper lines" are tracked dependencies by Bot Telemetry Logger middleware, which now can be associated to actual "Conversations" and "Users". I think, this is fantastic!
This way, we can go to "Azure Portal" --> "Application Insights Project" --> "Sessions" blade, to see "Active Sessions", which represent a conversation and drill into these sessions, to see what conversation has done:
Isn't it great? Or am I overreacting :)
Likewise, in the "Users Blade" , you can see the actual users, and their timeline:
This is like a summary of a great change, coming up with only 5 lines of code, on Bot Telemetry. And hope you were not aware of this earlier, so that you can feel the same excitement.
Joke aside, that seems to be an important change on our approach to Telemetry.
Hope you like my blogpost,
Stay tuned for the next one,