Examkin

Question

Difficulty: MediumQuery and Analyze Application Insights Telemetry

A cloud-native microservices application deployed on Azure Kubernetes Service (AKS) logs telemetry to a shared Azure Application Insights workspace. You need to write a Kusto Query Language (KQL) query to analyze dependency calls that failed in the last 24 hours. The query must join the dependency logs with custom event telemetry to retrieve the name of the failing dependency and the custom event name, using the `operation_Id` column.

To minimize resource consumption and query execution time, which KQL query should you use?

  1. dependencies
    | where timestamp > ago(24h) and success == false
    | join kind=inner (
    customEvents
    | where timestamp > ago(24h)
    ) on operation_Id
    | project dependencyName = name, eventName = name1    Answer
  2. B
    dependencies
    | where timestamp > ago(24h) and success == false
    | join kind=inner customEvents on operation_Id
    | project dependencyName = name, eventName = name1
  3. C
    dependencies
    | where success == false
    | join kind=inner customEvents on operation_Id
    | where timestamp > ago(24h)
    | project dependencyName = name, eventName = name1
  4. D
    dependencies
    | where success == false
    | join kind=inner (
    customEvents
    | where timestamp > ago(24h)
    ) on operation_Id
    | project dependencyName = name, eventName = name1

Answer

The KQL query that filters both the dependencies and customEvents tables by time range before performing the inner join on operation_Id is the correct and optimized query.
The correct query applies the time range filter on both the left table (dependencies) and the right table (customEvents) before performing the join. In Kusto Query Language (KQL), filtering data as early as possible on both sides of a join is critical to minimize the dataset sizes being processed by the join operator, ensuring optimal query performance and preventing execution timeouts.

Step-by-Step Solution

1
Filter the left table (dependencies) by the time range and status.
Limits the left-side dataset to only failed dependency calls from the last 24 hours.
Filtering early reduces the volume of data sent to subsequent query operators, improving performance.
2
Filter the right table (customEvents) by the time range inside a subquery projection before the join.
Limits the right-side dataset to only custom events from the last 24 hours.
Omitting the time filter on either side of a join forces the query engine to scan the entire history of the unfiltered table to match operation IDs, causing high resource usage.
3
Perform the inner join on the operation_Id column and project the desired fields.
Successfully joins the two filtered datasets and renames duplicate column names (e.g., name to name1 for the right table).
Allows mapping specific custom event telemetry to the corresponding failed dependency call while resolving column naming conflicts.

Key Concept

KQL Query Optimization using Time-Range Filters on Joined Tables
Rate this question

Topics

Query and Analyze Application Insights Telemetry