Azure Monitor: Add 5 curated dashboards for App insights troubleshooting experience

[yves-chan]

What is this feature?

This PR adds some troubleshooting experiences for Azure Application Insights. It will use the new trace view for the Azure Monitor datasource to view the traces from Azure Application Insights. Included are drilldown experiences for Performance on operations and dependencies, and drill down experiences for Failures on operations, dependencies, and exceptions.

Why do we need this feature?

This feature helps customers of Grafana using Azure Application Insights troubleshoot requests by using the new Azure Monitor trace to view the trace details.

Who is this feature for?

This feature is for customers who monitor their applications using Azure Application Insights and want to troubleshoot requests, dependencies, and exceptions with the help of traces.

Which issue(s) does this PR fix?:

Fixes #

Special notes for your reviewer:

Please check that:

• It works as expected from a user's perspective.
• If this is a pre-GA feature, it is behind a feature toggle.
• The docs are updated, and if this is a notable improvement, it's added to our What's New doc.

[CLAassistant]

All committers have signed the CLA.

[aangelisc]

Hi @yves-chan! Thank you for contributing! I've reviewed this and just have some changes to request:

Most of the dashboard variables e.g. operationName or resultCode should use a query that begins with search "*". Whilst this query is inefficient, it avoids errors in the dashboard where a user may not have requests that have failed and overall provides a nicer UX. WDYT?

Additionally, once this change has been made could you run prettier --fix public/app/plugins/datasource/azuremonitor to ensure the files have the correct styling.

Thank you!

[yves-chan]

Hi @yves-chan! Thank you for contributing! I've reviewed this and just have some changes to request:

Most of the dashboard variables e.g. operationName or resultCode should use a query that begins with search "*". Whilst this query is inefficient, it avoids errors in the dashboard where a user may not have requests that have failed and overall provides a nicer UX. WDYT?

Additionally, once this change has been made could you run prettier --fix public/app/plugins/datasource/azuremonitor to ensure the files have the correct styling.

Thank you!

oh great idea, it is way better to have an experience without failures upon load. Let me also run the prettier fixes, I will tag you again when these changes are in :) thanks!

[yves-chan]

@aangelisc regarding the search keyword do you mind giving me an example? I'm not sure I'm using it correctly

requests
| search "*"
| where $__timeFilter(timestamp)
| where client_Type != "Browser"
| summarize count() by operation_Name

[aangelisc]

Hey @yves-chan, thank you for working on this so quickly. This is what I had in mind:

search "*"
| where $__timeFilter(timestamp)
| where client_Type != "Browser"
| summarize count() by operation_Name

This should be the case for all the variables to avoid empty data in dashboard panels where possible 😊

[yves-chan]

@aangelisc
ah ok I get what you mean, I actually want to keep the tables strict. But I have updated the variables to have a default value of "All" and updated the queries such that they wouldn't error out because of KQL syntax. They should be fixed now!

[yves-chan]

@aangelisc Can I get another review on this please 😄 ?

[aangelisc]

Hi @yves-chan, I still have the same issue. See the image below:

This is because the result_code and operation_name variable queries directly depend on the requests table and if there are no requests in the AI workspace then these queries will fail. This leads to the panels showing the failed status. It would make more sense to search all tables for potential variable values as this will show the below:

See my updated result_code query (operation_name would also have to be updated):

[yves-chan]

hey @aangelisc thanks for the follow up!

I believe that this case should be handled in the query themselves. I default a custom value of "All", which gets passed in the queries and the KQL queries should still be syntactically correct even if there's no data

For cases like the result_code variable, the requests table and the dependencies table both share the resultCode column (and the codes could be different between the two tables) , so I'm a little hesitant to use search * and would like to avoid if possible.

I haven't been able to reproduce the case where there's no data and the panel fails, are you able to inspect the query and share the request and response details for one of the failed panels?

[aangelisc]

Hi @yves-chan,

Never mind me, I didn't have your latest updates locally! I've checked and everything looks great now! Once the build succeeds I'll merge this. Thank you!

[aangelisc]

Could you merge main please @yves-chan?

[yves-chan]

@aangelisc Just merged main to this branch, thanks!