Examkin

Question

Difficulty: Very hardQuery and Analyze Application Insights Telemetry

You are analyzing telemetry for a high-volume e-commerce API hosted on Azure. You need to identify requests processed within the last 12 hours where the cumulative duration of all associated external dependency calls accounts for more than 75% of the total request duration. The telemetry database contains millions of records per hour, and your query must be optimized to prevent execution timeouts and minimize data scan limits. Which of the following Kusto Query Language (KQL) queries should you use?

  1. let start = ago(12h);
    let dep_metrics = dependencies
    | where timestamp > start
    | summarize total_dep_duration = sum(duration) by operation_Id;
    requests
    | where timestamp > start
    | join kind=inner dep_metrics on operation_Id
    | where total_dep_duration > (duration * 0.75)
    | project operation_Id, name, duration, total_dep_duration    Answer
  2. B
    let start = ago(12h);
    let dep_metrics = dependencies
    | summarize total_dep_duration = sum(duration) by operation_Id;
    requests
    | where timestamp > start
    | join kind=inner dep_metrics on operation_Id
    | where total_dep_duration > (duration * 0.75)
    | project operation_Id, name, duration, total_dep_duration
  3. C
    let start = ago(12h);
    let dep_metrics = dependencies
    | where timestamp > start
    | summarize total_dep_duration = sum(duration) by operation_Id;
    requests
    | join kind=inner dep_metrics on operation_Id
    | where timestamp > start
    | where total_dep_duration > (duration * 0.75)
    | project operation_Id, name, duration, total_dep_duration
  4. D
    dependencies
    | summarize total_dep_duration = sum(duration) by operation_Id
    | join kind=inner (requests) on operation_Id
    | where timestamp > ago(12h)
    | where total_dep_duration > (duration * 0.75)
    | project operation_Id, name, duration, total_dep_duration

Answer

The query that filters both the dependencies and requests tables by the 12-hour timestamp before performing the inner join.
The correct query applies the timestamp filter to both the dependencies table and the requests table prior to the join operation. In Kusto, filtering data as early as possible in the query pipeline reduces the CPU and memory footprint, which is critical for querying high-volume telemetry tables without exceeding resource limits or causing query timeouts.

Step-by-Step Solution

1
Define the start time boundary using a let statement to ensure consistency.
A reusable time variable representing 12 hours ago.
Reusing the time boundary avoids recalculating the duration offset and keeps the query clean.
2
Filter the dependencies table by the start time and aggregate the total duration of dependency calls grouped by operation_Id.
An aggregated temporary dataset of dependency durations for the last 12 hours.
Applying the time filter before summarizing reduces the data volume to process during aggregation.
3
Filter the requests table by the start time before performing the inner join with the dependency durations.
A joined dataset linking requests from the last 12 hours with their respective dependency totals.
Applying the time filter to both tables prior to the join minimizes the join workload, preventing timeouts in high-volume environments.
4
Filter the joined results where the total dependency duration is greater than 75% of the request duration, and project the final columns.
The final filtered list of slow requests matching the criteria.
This completes the logical requirements of the scenario.

Key Concept

Optimizing KQL queries in Azure Monitor by applying time-range filters early on all tables before performing joins.
Rate this question

Topics

Query and Analyze Application Insights Telemetry