Analyze metrics from instrumentation

Ravelin Retail runs three services, web-frontend, orders-api, and inventory-api, each instrumented with the Azure Monitor OpenTelemetry distribution and sending telemetry to the same workspace-based Application Insights resource named appi-ravelin-shop. Each service sets its own cloud role name. A customer support ticket includes the operation ID 4bf92f3577b34da6a3ce929d0e0e4736 for a failed order placed yesterday. You need to see every request, dependency call, and exception from all three services that belongs to that one order.

Which two methods can you use? Each correct answer presents a complete solution.

1. AIn Transaction search, search for the operation ID and open the end-to-end transaction details view.The end-to-end transaction view assembles every telemetry item that shares the operation ID into one timeline across all components.
2. BOpen Application Map and select the edge between orders-api and inventory-api.Application Map shows aggregated call volume, latency, and failure rates between components; it does not isolate a single transaction by itself.
3. CIn Logs, run: union requests, dependencies, exceptions | where operation_Id == "4bf92f3577b34da6a3ce929d0e0e4736" | order by timestamp ascoperation_Id carries the trace ID shared by every span in a distributed operation, so filtering on it returns all related items from every service.
4. DIn Logs, run: union requests, dependencies, exceptions | where session_Id == "4bf92f3577b34da6a3ce929d0e0e4736"session_Id identifies a browser user session, not a distributed trace, so it does not match the operation ID.
5. EOpen Live Metrics and filter on cloud role name orders-api.Live Metrics shows a short real-time stream and cannot retrieve yesterday's telemetry for a specific operation.

Wexcombe Energy runs a billing API that sends telemetry to a workspace-based Application Insights resource named appi-wexcombe-billing. In the Logs view of that resource, you need a list of failed requests from the last 24 hours that shows the request name, the result code, and the type and message of the exception thrown while that same request was being processed. Each failed request must appear next to its own exception, not next to exceptions from other requests.

Which query should you run?

1. Arequests | where timestamp > ago(24h) and success == false | join kind=inner (exceptions | where timestamp > ago(24h) | project operation_Id, type, outerMessage) on operation_Id | project timestamp, name, resultCode, type, outerMessageJoining on operation_Id pairs each failed request with exceptions recorded in the same operation, and project returns only the requested columns.
2. Brequests | where timestamp > ago(24h) and success == false | join kind=inner (exceptions | where timestamp > ago(24h) | project cloud_RoleName, type, outerMessage) on cloud_RoleName | project timestamp, name, resultCode, type, outerMessagecloud_RoleName identifies the service, so every failed request is paired with every exception from the whole API, producing wrong and duplicated rows.
3. Cunion requests, exceptions | where timestamp > ago(24h) | project timestamp, name, resultCode, type, outerMessageunion stacks rows from both tables without matching them, so request and exception columns never appear on the same row, and successful requests are not excluded.
4. Dexceptions | where timestamp > ago(24h) | summarize count() by type, bin(timestamp, 1h) | render timechartThis charts exception volume by type per hour, which is useful for trends but loses the link to individual requests and their result codes.

Marlow Civil Engineering runs self-hosted Azure Pipelines agents on 12 Linux virtual machines named vm-agent-01 to vm-agent-12. VM Insights is enabled with its default data collection rule, which sends data to a Log Analytics workspace named law-marlow-build; no other data collection rules exist. Builds slow down in the afternoon, and you suspect the agents are running out of memory. You need a chart of available memory per VM over the last 24 hours in 15-minute intervals.

Which query should you run in law-marlow-build?

1. APerf | where TimeGenerated > ago(24h) and ObjectName == "Memory" and CounterName == "Available MBytes" | summarize avg(CounterValue) by bin(TimeGenerated, 15m), Computer | render timechartThe Perf table is filled only by a data collection rule that defines performance counters for it; the VM Insights rule writes to InsightsMetrics, so this query returns no rows.
2. BInsightsMetrics | where TimeGenerated > ago(24h) and Namespace == "Memory" and Name == "AvailableMB" | summarize avg(Val) by bin(TimeGenerated, 15m), Computer | render timechartVM Insights stores guest performance data in InsightsMetrics, and the Memory namespace with the AvailableMB name holds available memory for each computer.
3. CAzureMetrics | where TimeGenerated > ago(24h) and MetricName == "Available Memory Bytes" | summarize avg(Average) by bin(TimeGenerated, 15m), Resource | render timechartAzureMetrics is populated only when a diagnostic setting exports platform metrics, and none is configured in this scenario.
4. DHeartbeat | where TimeGenerated > ago(24h) | summarize count() by bin(TimeGenerated, 15m), Computer | render timechartHeartbeat records that the agent is alive; it shows availability gaps but contains no memory measurements.

Saltmarsh Outfitters runs an online store whose browser pages send page views to a workspace-based Application Insights resource named appi-saltmarsh-web through the Application Insights JavaScript SDK. The checkout has four ordered pages: Cart, Shipping, Payment, and Confirmation. The product owner wants to see what percentage of users who reach Cart go on to complete each later step, and where most of them drop out.

Which Application Insights experience should you use?

1. AFunnelsFunnels take an ordered list of steps and show how many users complete each step and where they abandon the sequence.
2. BRetentionRetention shows how many users come back to the application over days or weeks, not how they progress through one flow.
3. CPerformancePerformance shows operation durations and dependency timings, which explain slowness but not user drop-off between steps.
4. DLive MetricsLive Metrics streams near-real-time request and failure rates for a few minutes of data and does not analyze user journeys.