A hard-to-reproduce agent bug needs Application Insights requests joined to container stdout. What correlation key should ops use?
Select an answer to reveal the explanation.
Short Explanation
The trace id is the case number stamped on both the Insights ticket and the container console receipt—ops tape them together.
Full Explanation
A hard-to-reproduce agent bug that needs Application Insights requests joined to container stdout should use the shared OpenTelemetry trace id as the correlation key. When request telemetry and container logs both carry the same trace id (and ideally span id), ops can pivot from a failed municipal agent request in Application Insights to the exact stdout/stderr lines emitted by that Container Apps replica. Trace id correlation beats wall-clock guessing across distributed hosts.
Joining only on approximate wall-clock time with no shared identifiers fails under concurrency—many agents log in the same second, and clock skew across replicas mis-orders events. Matching logs using random usernames typed into chat fails stability and privacy; display names are not unique correlation identifiers and may be PII. Concatenating unrelated resource group names as a join key fails uniqueness: resource group is an ARM scope, not a per-request id, and cannot distinguish one agent invocation from another.
Exam caveat: correlation requires both sides to emit the id—configure OpenTelemetry/logging enrichers so stdout includes TraceId/ParentId, and ensure Application Insights requests use the same context. Without log enrichment, the trace id exists in telemetry but not in container logs. Also prefer structured logs over free text for reliable joins.
Operational check: reproduce the agent bug once with logging enrichment enabled, copy the request’s operation/trace id from Application Insights, query Container Apps console logs for that id, and confirm the joined evidence shows the failing tool call or exception path.