Question

Difficulty: Very hardQuery and Analyze Application Insights Telemetry

You are monitoring a high-volume Azure App Service web application using Azure Application Insights. You need to write an optimized Kusto Query Language (KQL) query to count the number of slow external HTTP dependency calls.

The query must meet the following requirements:
1. Dynamically calculate the 90th percentile duration of all HTTP dependencies over the last 24 hours and use this as a threshold.
2. Filter the `dependencies` table to include only HTTP calls whose duration exceeds this threshold.
3. Join the filtered dependencies with the `requests` table to associate them with their parent operations.
4. Group the results by the operation name (from the `requests` table) and the dependency target (from the `dependencies` table) to display the total count of slow dependency calls.
5. Apply time-range filters as early as possible to minimize the volume of data scanned and prevent query performance issues.

Complete the KQL query below by filling in the blanks with the correct KQL functions, table fields, or join operators.

Answer:let start = ago(24h);
let threshold = 【toscalar】(
dependencies
| where timestamp >= start
| where type == "Http"
| summarize percentile(duration, 90)
);
dependencies
| where 【timestamp】 >= start
| where type == "Http" and duration > threshold
| join kind=【inner】 (
requests
| where 【timestamp】 >= start
) on operation_Id
| summarize SlowCount = count() by RequestName = name, Target = target

Answer

The query must evaluate the subquery as a scalar value using toscalar, filter both tables early using timestamp, and perform an inner (or innerunique) join to group by fields from both tables.
The correct query uses toscalar to dynamically retrieve a single numeric threshold for comparison, restricts the data scan on both tables using the timestamp column for optimization, and uses an inner join to correlate and preserve columns from both tables so they can be grouped by request name and dependency target.

Step-by-Step Solution

1
Wrap the threshold subquery with the correct KQL function.
Using the toscalar function converts the single-column, single-row table output of the subquery into a scalar value.
In KQL, comparing a scalar field like duration to a subquery's result using scalar operators (like >) requires the subquery to be explicitly evaluated as a scalar value.
2
Identify the performance-critical filtering field for the tables.
Using the timestamp column to restrict query execution to the last 24 hours.
Applying time-range filters using the timestamp field on both tables before joining prevents full-table scans of the historical telemetry store, which is critical for query efficiency and avoiding timeouts on high-volume workspaces.
3
Select the correct join operator that preserves the required schema.
Using the inner (or innerunique) join kind.
Since the final projection requires columns from both tables (name from requests and target from dependencies), a semi-join cannot be used. An inner join preserves and correlates the columns from both tables based on the operation_Id.

Key Concept

Writing optimized KQL queries that combine scalar subqueries, early time-range filtering, and appropriate schema-preserving joins to troubleshoot App Insights telemetry.
Rate this question