-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add LG telemetry #3469
Add LG telemetry #3469
Conversation
I found IBotTelemetryClient would be obsolete in this pr #3440. |
@Danieladu yes, this should follow what @garypretty is doing for all up telemetry/ adaptive telemetry. @garypretty can you please add relevant PR #s to this for reference? |
We are just finalising the details of the other PR today. Once we have done that I'll reflect here. |
@Danieladu @vishwacsena IBotTelemetryClient will now remain. The decision has been taken to extend this interface. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@garypretty can you take a look and approve if this is in line with your changes to instrument adaptive dialogs? |
This is the adaptive PR https://github.com/microsoft/botbuilder-dotnet/pull/3491/files |
...ies/Microsoft.Bot.Builder.LanguageGeneration/Microsoft.Bot.Builder.LanguageGeneration.csproj
Outdated
Show resolved
Hide resolved
We should just leverage the same telemetry client inside action (IDialog) and log the generation behavior in dialog level, and leave LG alone for now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments above
578061a
to
3224ca7
Compare
libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Input/OAuthInput.cs
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the events tracked in this PR appear to be logging the result of a call to .BindToData - I think we should move the tracking into the .BindToData methods - this way we automatically get tracking in the future as LG is used elsewhere in the solution.
Scratch the above, I just realised we don't have access to the TelemetryClient within BindToData - this might be something we can address in the future, but for now the changes look ok to me.
@vishwacsena - I am curious as to what the scenario is that we think folks might want to see these events - I just want to validate that TrackEvent is the right thing to do, or would TrackTrace be more appropriate? It feels like this information is going to be accessed during diagnostic / debug sceanrios, or do you think there is some aspect of this data that we would surface on a dashboard in the future as we do with recognizer results / dialog events? I am ok either way, I just want to validate.
ref: #2783
add LG telemetry client.