Three separate "Application Insights" resources, one per microservice, each hold their own requests telemetry. An engineer must run a single Kusto Query Language query that aggregates failure counts across all three resources at once, without first copying their data into one shared resource. Which approach lets one query span the separate resources?
- AAdd a workspace-based diagnostic setting to each resource so all three forward telemetry into one Log Analytics workspace before any query is written.
- BUse the join operator on operation_Id to combine the requests tables from the three resources into a single correlated result set for aggregation.
- CApply the make-series operator over the requests table so the failures are expanded into a continuous time series across the chosen interval.
- DReference each resource with the app expression inside a union, so one query reads the requests telemetry from all three resources and aggregates the failures together. Correct
Why A is wrong: Routing the resources to one workspace would centralise the data and is a sound long-term design, but it changes the ingestion configuration rather than letting a single query span the existing separate resources as the requirement states.
Why B is wrong: The join operator correlates rows by a shared key and is tempting because the query spans multiple inputs, but join matches records within reachable tables and does not by itself address telemetry held in other Application Insights resources.
Why C is wrong: The make-series operator builds a gap-filled time series and is plausible for trend analysis, but it shapes data from a single accessible scope and does nothing to reach across three distinct resources.
Why D is correct: The app expression names another Application Insights resource within a query, and combining several app references under a union lets one statement read and aggregate telemetry across all three resources at once.