12.2 Correlating Traces into Azure Monitoring

From OTel SDK to Azure Monitor

Section 12.1 covered creating spans. AI-200 also expects you to know where those spans go and how Azure presents them. The destination is Azure Monitor, commonly through an Application Insights resource connected to a Log Analytics workspace. Your app should not require a proprietary Microsoft-only instrumentation API if OTel exporters are configured correctly—but you must understand the Azure-side concepts the portal and KQL expose.

Exporters and distribution options

Think in layers:

The connection string (or equivalent auth) on the Application Insights resource is what authorizes ingestion. Missing or wrong connection configuration is a classic “I instrumented but see nothing” failure.

Also set resource attributes, especially:

• service.name (becomes a cloud role name style identity)
• service.instance.id when multiple replicas matter
• cloud/resource attributes that identify the Container App, Function App, or AKS workload

Without distinct service names, Application Map collapses unrelated processes into an unhelpful blob.

How traces appear in Application Insights

Azure maps OTel concepts onto familiar Application Insights tables and blades:

When you open a request in Transaction search, you should see a timeline of dependencies: PostgreSQL, Redis, Azure OpenAI HTTP calls, Service Bus. That timeline is only as good as your instrumentation and propagation.

Application Map concepts

Application Map is a topology view built from correlated requests and dependencies. Nodes represent components (your API, databases, external HTTP). Edges represent observed calls.

What the map is good for:

• Spotting which dependency is failing (red indicators)
• Seeing unexpected outbound calls (wrong endpoint, missing private networking intent)
• Understanding fan-out in AI pipelines (API → search → model → bus)

What breaks the map:

• Missing W3C propagation → separate islands
• Identical service.name on every process → misleading consolidation
• Sampling so aggressive that edges rarely appear
• Instrumenting only one side of a call

On scenario questions, if the stem says “Application Map shows the API but not the Functions worker,” look for missing context injection on the queue message or missing instrumentation on the consumer—not “delete Application Insights.”

Correlation across async AI workflows

AI systems are often asynchronous:

1. API accepts a job and returns 202
2. Message lands on Service Bus
3. Azure Functions worker performs retrieval + generation
4. Result written to storage; client polls or receives Event Grid notification

To keep one operation_Id:

• Inject trace context into message application properties when sending
• Extract and create a consumer span linked to the producer
• Continue exporting to the same Application Insights resource (or a workspace that can join the data)

If each stage creates an unrelated root, your “troubleshoot latency” story fragments across three operation IDs.

Portal blades that complement traces

Traces answer “what happened to user X?” Metrics and failure overview answer “is this systemic?” AI-200 wants both instincts.

Container and Functions specifics

For Azure Container Apps and App Service containers, ensure the instrumentation runs inside the container image or via a supported agent pattern, and that environment variables supply the Application Insights connection string from Key Vault / App Configuration references—not hard-coded secrets.

For Azure Functions, use the recommended OpenTelemetry / Application Insights integration for your language stack so triggers create request-like telemetry and outbound SDK calls become dependencies. Worker process cold starts should appear as latency on the first span—not as a mystery gap.

Scenario: correlating a multi-hop failure

Diego sees HTTP 500s on the chat API. Application Map shows the API node healthy-looking but a dependency edge to Azure OpenAI reddening. Transaction search for one operation_Id reveals:

• Request span: 812 ms total
• Dependency to pgvector: 40 ms OK
• Dependency to Azure OpenAI: 770 ms ending in 429

Diego scales the deployment or adds retry/backoff with respect for rate limits. Without correlated dependencies, he might have restarted PostgreSQL. Correlation turned a vague outage into a precise dependency fault.

Data volume, retention, and privacy

Application Insights ingestion has cost and retention settings in the workspace. For AI workloads:

• Avoid putting full prompts with PII in custom dimensions by default
• Prefer hashed user IDs or session tokens when needed
• Use sampling thoughtfully for high-QPS embedding APIs
• Confirm workspace retention meets your incident investigation window

Exam answers that ignore privacy while “logging everything” are weaker than answers that correlate with safe attributes (status codes, durations, deployment names).

Validation checklist after wiring exporters

1. Generate traffic through the happy path and an induced failure.
2. Confirm requests appear in Application Insights within a few minutes.
3. Open one transaction and verify child dependencies exist.
4. Confirm Application Map shows expected nodes with your service.name values.
5. Copy an operation_Id and prepare to query it with KQL (next sections).

If any step fails, debug exporter config and propagation before writing complex KQL. Query languages cannot invent correlation that was never exported.

Bridge to KQL

Once telemetry lands, investigation shifts to Log Analytics tables such as AppRequests, AppDependencies, AppTraces, and container log tables. Section 12.3 teaches the KQL operators you use to analyze those logs; section 12.4 extends into metrics-oriented and AI pipeline troubleshooting patterns.