Examkin

Question

Difficulty: Very hardQuery and Analyze Application Insights Telemetry

You are troubleshooting a high-volume Azure App Service application. You need to write an optimized Kusto Query Language (KQL) query in Application Insights to analyze dependencies associated with slow requests. Specifically, you want to identify the 95th95\text{th} percentile duration of dependency calls that occurred during requests that took longer than 3 seconds3\text{ seconds} (3000 ms3000\text{ ms}) within the last 24 hours24\text{ hours}.

Which KQL query should you use to retrieve this data with the best query performance?

  1. let timeLimit = ago(24h);
    let slowRequests = requests
    | where timestamp > timeLimit and duration > 3000
    | project operation_Id;
    dependencies
    | where timestamp > timeLimit
    | join kind=inner slowRequests on operation_Id
    | summarize p95 = percentile(duration, 95) by name
    | order by p95 desc    Answer
  2. B
    let slowRequests = requests
    | where duration > 3000
    | project operation_Id;
    dependencies
    | where timestamp > ago(24h)
    | join kind=inner slowRequests on operation_Id
    | summarize p95 = percentile(duration, 95) by name
    | order by p95 desc
  3. C
    let timeLimit = ago(24h);
    let slowRequests = requests
    | where timestamp > timeLimit and duration > 3000
    | project operation_Id;
    dependencies
    | join kind=inner slowRequests on operation_Id
    | summarize p95 = percentile(duration, 95) by name
    | order by p95 desc
  4. D
    dependencies
    | join kind=inner requests on operation_Id
    | where timestamp > ago(24h) and requests.duration > 3000
    | summarize p95 = percentile(duration, 95) by name
    | order by p95 desc

Answer

The correct query is the one that filters both the requests and dependencies tables by the 24-hour time range before joining them.
The correct query applies the time range filter to both the requests and dependencies tables before executing the join. In KQL, when joining two telemetry tables, it is critical to filter both datasets by time range. If one table is left unfiltered, the query optimizer cannot prune partitions effectively, resulting in a scan of all historical logs. Filtering first reduces the volume of data that needs to be loaded into memory and joined, ensuring optimal performance on large datasets.

Step-by-Step Solution

1
Define a time limit variable using the ago() function to represent the last 24 hours.
A reusable timeLimit variable representing the past 24 hours.
Creating a variable ensures consistency in the time filters applied to both telemetry tables.
2
Query the requests table, applying the time filter and filtering for duration > 3000 ms, then project only the operation_Id column.
A lightweight dataset of operation IDs for requests that exceeded the threshold in the last 24 hours.
Projecting only the required key (operation_Id) reduces memory overhead during the join operation.
3
Query the dependencies table, applying the time filter first, and perform an inner join with the filtered requests dataset on operation_Id.
A combined dataset containing dependency call records that occurred within the target 24-hour window and are linked to the slow requests.
Applying the time filter on both tables before the join prevents the query engine from scanning unnecessary partitions, maximizing performance.
4
Summarize the 95th percentile of the dependency duration grouped by the dependency name, and order the results descending.
An ordered list of dependency names and their 95th percentile latency during the slow requests.
This identifies which external resources or operations are contributing most to the application's slow response times.

Key Concept

To maintain high query performance on Application Insights telemetry, KQL queries must filter all joined tables by time-range before executing the join operation.
Rate this question

Topics

Query and Analyze Application Insights Telemetry