Application Insights Connection String Missing Lab¶

Demonstrate that an Azure Container App without APPLICATIONINSIGHTS_CONNECTION_STRING keeps serving HTTP 200 to clients but emits zero telemetry to Application Insights, then prove the fix by adding the env var and observing telemetry appear in AppRequests and AppTraces.

Lab Metadata¶

flowchart TD
    A[Deploy Container App on helloworld baseline] --> B[Switch to instrumented Python image WITHOUT env var]
    B --> C[Send 20 requests, query AppRequests/AppTraces]
    C --> D[Observe: 20 HTTP 200, 0 AI rows]
    D --> E[Add APPLICATIONINSIGHTS_CONNECTION_STRING env var]
    E --> F[Send 20 fresh requests, re-query AI]
    F --> G[Observe: 20 HTTP 200, AppRequests aggregate=20, AppTraces aggregate=21]

1) Background¶

On Azure Container Apps using the azure-monitor-opentelemetry Python distro, does the presence or absence of APPLICATIONINSIGHTS_CONNECTION_STRING deterministically control whether telemetry reaches Application Insights — and if so, can the failure mode be observed end-to-end (HTTP responses still 200, Application Insights tables empty) and then fully reversed by adding the env var alone, with no code, image, or workload change?

The lab uses a dedicated resource group and Bicep template (infra/main.bicep) that provisions a Log Analytics workspace, a workspace-based Application Insights resource, an Azure Container Registry (Basic), a Container Apps Environment (Consumption), and a Container App with system-assigned managed identity holding the AcrPull role. The initial Container App revision runs mcr.microsoft.com/azuredocs/containerapps-helloworld:latest (no Application Insights SDK in the image at all) so the lab's trigger.sh and verify.sh scripts can deterministically switch the image to hellotelemetry:v3 (built into the lab's ACR with az acr build from app/) and toggle the env var on and off.

Set the base inputs before running the runbook. The remaining variables (APP_NAME, ACR_NAME, ACR_LOGIN_SERVER, APP_INSIGHTS_NAME) are derived from Bicep outputs in the next section because infra/main.bicep appends a deterministic but resource-group-scoped suffix to every resource name (see infra/main.bicep:12-17):

export AZ_SUBSCRIPTION="<subscription-id>"
export RG="rg-aca-lab-aiconn"
export LOCATION="koreacentral"

2) Hypothesis¶

On the same Container App, same image (hellotelemetry:v3, built with azure-monitor-opentelemetry==1.6.4), and same traffic pattern, the presence of the APPLICATIONINSIGHTS_CONNECTION_STRING environment variable is the single controlling input that determines whether AppRequests and AppTraces populate in Application Insights. When absent, the app stays healthy (HTTP 200 to all clients) but the SDK skips export and both tables remain empty.

The alternative hypothesis being tested is that adding a Python OpenTelemetry SDK to the image is sufficient on its own to emit telemetry, regardless of whether the connection string is wired in at runtime.

Prediction (IF / THEN): IF the env var is the single controlling input, THEN after switching to hellotelemetry:v3 WITHOUT APPLICATIONINSIGHTS_CONNECTION_STRING, 20 sequential HTTP GET requests will all return 200 and the KQL summarize query AppRequests | where timestamp > ago(15m) | summarize requestCount=count() by cloud_RoleName will return zero rows. After adding the env var via az containerapp update --set-env-vars and sending 20 fresh requests, the same KQL query will return a single aggregate row with requestCount=20 under cloud_RoleName="unknown_service", and AppTraces | where timestamp > ago(15m) | summarize traceCount=count() by cloud_RoleName will return a single aggregate row with traceCount=21 (1 startup log + 20 per-request endpoint hit logs).

3) Runbook¶

Deploy infrastructure¶

All az and ./trigger.sh / ./verify.sh invocations below assume the working directory is the lab folder. Switch into it from the repository root before running anything:

cd labs/appinsights-connection-string-missing/

1. Create the resource group and deploy the Bicep template. The --parameters baseName="appiconn" value is required (the Bicep template declares param baseName string with no default, see infra/main.bicep:4). --name main gives the deployment a stable, queryable name so the next step can read its outputs:

   az group create \
       --subscription "$AZ_SUBSCRIPTION" \
       --name "$RG" \
       --location "$LOCATION"
   
   az deployment group create \
       --subscription "$AZ_SUBSCRIPTION" \
       --resource-group "$RG" \
       --name main \
       --template-file infra/main.bicep \
       --parameters baseName="appiconn"
   

   Command	Why it is used
   az group create	Creates the lab resource group at $LOCATION (koreacentral) before any child resources are deployed.
   az deployment group create	Deploys infra/main.bicep with the required baseName="appiconn" parameter. --name main gives the deployment a stable, queryable name so step 2 can read its outputs.

   This creates the Log Analytics workspace, Application Insights, ACR, Container Apps Environment, and a Container App running the helloworld baseline image.

2. Read the deployment outputs so the remaining commands and scripts know which resources to act on. IMAGE_TAG is required by trigger.sh (trigger.sh:8); verify.sh does not read IMAGE_TAG because it changes env vars on the already-deployed image rather than swapping the image:

   export APP_NAME=$(az deployment group show \
       --subscription "$AZ_SUBSCRIPTION" \
       --resource-group "$RG" \
       --name main \
       --query "properties.outputs.containerAppName.value" \
       --output tsv)
   
   export ACR_NAME=$(az deployment group show \
       --subscription "$AZ_SUBSCRIPTION" \
       --resource-group "$RG" \
       --name main \
       --query "properties.outputs.acrName.value" \
       --output tsv)
   
   export ACR_LOGIN_SERVER=$(az deployment group show \
       --subscription "$AZ_SUBSCRIPTION" \
       --resource-group "$RG" \
       --name main \
       --query "properties.outputs.acrLoginServer.value" \
       --output tsv)
   
   export APP_INSIGHTS_NAME=$(az deployment group show \
       --subscription "$AZ_SUBSCRIPTION" \
       --resource-group "$RG" \
       --name main \
       --query "properties.outputs.appInsightsName.value" \
       --output tsv)
   
   export IMAGE_TAG="hellotelemetry:v3"
   

   Command	Purpose
   export APP_NAME=$(az deployment group show --subscription "$AZ_SUBSCRIPTION" --resource-group "$RG" --name main --query "properties.outputs.containerAppName.value" --output tsv)	Captures APP_NAME from the live Azure lookup so later commands reuse the exact current value instead of guessing it. Reads the group deployment result directly so you can verify whether the top-level deployment failed before any healthy revision was created.
   export ACR_NAME=$(az deployment group show --subscription "$AZ_SUBSCRIPTION" --resource-group "$RG" --name main --query "properties.outputs.acrName.value" --output tsv)	Captures ACR_NAME from the live Azure lookup so later commands reuse the exact current value instead of guessing it. Reads the group deployment result directly so you can verify whether the top-level deployment failed before any healthy revision was created.
   export ACR_LOGIN_SERVER=$(az deployment group show --subscription "$AZ_SUBSCRIPTION" --resource-group "$RG" --name main --query "properties.outputs.acrLoginServer.value" --output tsv)	Captures ACR_LOGIN_SERVER from the live Azure lookup so later commands reuse the exact current value instead of guessing it. Reads the group deployment result directly so you can verify whether the top-level deployment failed before any healthy revision was created.
   export APP_INSIGHTS_NAME=$(az deployment group show --subscription "$AZ_SUBSCRIPTION" --resource-group "$RG" --name main --query "properties.outputs.appInsightsName.value" --output tsv)	Captures APP_INSIGHTS_NAME from the live Azure lookup so later commands reuse the exact current value instead of guessing it. Reads the group deployment result directly so you can verify whether the top-level deployment failed before any healthy revision was created.

3. Build the instrumented Python image inside the lab's ACR:

   az acr build \
       --subscription "$AZ_SUBSCRIPTION" \
       --registry "$ACR_NAME" \
       --image "$IMAGE_TAG" \
       ./app
   

   Command	Why it is used
   az acr build	Builds the instrumented Python image (hellotelemetry:v3) inside the lab's ACR. No local Docker daemon required.

Trigger the failure (run trigger.sh)¶

Run trigger.sh, which:

• Switches the Container App to ${ACR_LOGIN_SERVER}/hellotelemetry:v3 while removing any pre-existing APPLICATIONINSIGHTS_CONNECTION_STRING env var.
• Waits for the new revision to reach provisioningState=Provisioned with containers[0].runningState=Running.
• Sends 20 sequential HTTP GET requests against the ingress FQDN.
• Sleeps 240 seconds for Application Insights ingestion latency.
• Captures 01-env-before-fix.json (env array is null), 02-traffic-completed-before-fix.txt, 03-ai-requests-before-fix.json, 04-ai-traces-before-fix.json, 05-containerapp-full-config-before-fix.json, and 06-env-telemetry-config.json.

All scripts pass --subscription "$AZ_SUBSCRIPTION" on every az invocation to immunize the run against the Azure CLI's default-subscription drift, which has been observed in long-running shells where unrelated commands silently switch back to a different subscription.

Apply the fix (run verify.sh)¶

Run verify.sh, which:

• Reads the Application Insights connection string from the deployed resource.
• Adds APPLICATIONINSIGHTS_CONNECTION_STRING to the Container App via az containerapp update --set-env-vars.
• Waits for the new revision to reach Healthy.
• Sends 20 fresh HTTP GET requests against the same FQDN.
• Sleeps 240 seconds for Application Insights ingestion latency.
• Captures 07-env-after-fix.json, 08-traffic-completed-after-fix.txt, 09-ai-requests-after-fix.json, 10-ai-traces-after-fix.json, 11-containerapp-full-config-after-fix.json, 12-kql-requests-timeline.json, 13-ai-traces-messages-after-fix.json, 14-revisions-lifecycle.json, and 15-ai-requests-detail-after-fix.json.

The commands that verify.sh runs to emit files 13/14/15 (so readers can regenerate the data without re-running the full script). Files 13 and 15 are KQL queries against Application Insights; file 14 is an az containerapp revision list call post-processed with python3 to derive the hasConnStr flag from each revision's env array:

# evidence/13-ai-traces-messages-after-fix.json
az monitor app-insights query \
    --subscription "$AZ_SUBSCRIPTION" \
    --app "$APP_INSIGHTS_NAME" \
    --resource-group "$RG" \
    --analytics-query "traces | where timestamp > ago(15m) | project timestamp, message, severityLevel | order by timestamp asc | take 25" \
    --output json

# evidence/15-ai-requests-detail-after-fix.json
az monitor app-insights query \
    --subscription "$AZ_SUBSCRIPTION" \
    --app "$APP_INSIGHTS_NAME" \
    --resource-group "$RG" \
    --analytics-query 'requests | where timestamp > ago(15m) | project timestamp, name, resultCode, success, duration, url | order by timestamp asc' \
    --output json

# evidence/14-revisions-lifecycle.json (az + python3 post-processing pipeline)
az containerapp revision list \
    --subscription "$AZ_SUBSCRIPTION" \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --all \
    --output json | python3 -c "
import json, sys
revs = json.load(sys.stdin)
out = []
for r in revs:
    env = (r.get('properties', {}).get('template', {}).get('containers', [{}])[0].get('env') or [])
    has = any(e.get('name') == 'APPLICATIONINSIGHTS_CONNECTION_STRING' for e in env)
    out.append({
        'active': r.get('properties', {}).get('active'),
        'createdTime': r.get('properties', {}).get('createdTime'),
        'hasConnStr': has,
        'image': r.get('properties', {}).get('template', {}).get('containers', [{}])[0].get('image'),
        'name': r.get('name'),
    })
out.sort(key=lambda x: x['createdTime'] or '')
print(json.dumps(out, indent=2))
"

Apply the fix manually (the canonical remediation command)¶

Add APPLICATIONINSIGHTS_CONNECTION_STRING to the Container App env vars, sourcing the value directly from the Application Insights resource so the binding is deterministic:

APPLICATIONINSIGHTS_CONNECTION_STRING=$(az monitor app-insights component show \
    --subscription "$AZ_SUBSCRIPTION" \
    --app "$APP_INSIGHTS_NAME" \
    --resource-group "$RG" \
    --query "connectionString" \
    --output tsv)

az containerapp update \
    --subscription "$AZ_SUBSCRIPTION" \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --set-env-vars "APPLICATIONINSIGHTS_CONNECTION_STRING=${APPLICATIONINSIGHTS_CONNECTION_STRING}"

For production, store the connection string in Azure Key Vault and inject it via --secrets / --env-vars with a secretref: reference rather than embedding the literal value in the Container App template.

Prevention guidance¶

• Wire APPLICATIONINSIGHTS_CONNECTION_STRING from your Bicep / Terraform template at deploy time using a Key Vault secret reference, so a missing env var is impossible to ship by accident.
• When defensively guarding configure_azure_monitor() with a presence check, log the skip path at WARN so operators can grep for Azure Monitor skipped: APPLICATIONINSIGHTS_CONNECTION_STRING absent in container console logs without needing Application Insights to be working in the first place.
• Add a smoke check to CI/CD that sends one synthetic request to the deployed app and then runs AppRequests | where timestamp > ago(5m) | count against Application Insights. Fail the deployment if the count is zero on the first revision.
• Pin azure-monitor-opentelemetry in requirements.txt. Bumping the SDK can change export defaults; this lab was validated against azure-monitor-opentelemetry==1.6.4.
• If you are using the Python distro with Flask, ensure configure_azure_monitor() runs BEFORE the Flask class is fully imported (use import flask and reference flask.Flask(__name__) instead of from flask import Flask). This is the subtle gotcha that :v3 defends against; the import-order failure mode is described from lab-development experience (no per-revision AppRequests/AppTraces evidence file is committed for the :v2 source variant).
• Set OTEL_SERVICE_NAME as a second env var so traces and requests surface in dashboards under the Container App's name instead of the OpenTelemetry default unknown_service.

4) Experiment Log¶

Before-fix evidence (env var absent)¶

• [Measured] 20 HTTP requests sent: all 20 returned HTTP 200 (evidence/00-trigger-run.txt lines reporting request NN → HTTP 200).
• [Measured] AppRequests | where timestamp > ago(15m) | summarize requestCount=count() by cloud_RoleName returned zero rows (evidence/03-ai-requests-before-fix.json tables[0].rows = []).
• [Measured] AppTraces | where timestamp > ago(15m) | summarize traceCount=count() by cloud_RoleName returned zero rows (evidence/04-ai-traces-before-fix.json tables[0].rows = []).
• [Observed] Container App env array on revision ca-appiconn-x2lcxd--0000006 is null — no env vars at all (evidence/01-env-before-fix.json).

Post-fix evidence (env var present)¶

• [Measured] 20 fresh HTTP requests sent: all 20 returned HTTP 200 (evidence/00-verify-run.txt).
• [Measured] AppRequests | where timestamp > ago(15m) | summarize requestCount=count() by cloud_RoleName returned one aggregate row with requestCount=20 under cloud_RoleName="unknown_service" (evidence/09-ai-requests-after-fix.json tables[0].rows = [["unknown_service", 20]]). The 5-minute KQL timeline in evidence/12-kql-requests-timeline.json confirms all 20 requests landed in a single 5-minute bin at 2026-06-22T05:05:00Z.
• [Measured] AppTraces | where timestamp > ago(15m) | summarize traceCount=count() by cloud_RoleName returned one aggregate row with traceCount=21 under cloud_RoleName="unknown_service" (evidence/10-ai-traces-after-fix.json tables[0].rows = [["unknown_service", 21]]). The per-message capture in evidence/13-ai-traces-messages-after-fix.json shows the first trace is the startup log Azure Monitor configured: telemetry export enabled followed by 20 identical / endpoint hit (conn_str_present=True) log lines.
• [Observed] Per-request detail in evidence/15-ai-requests-detail-after-fix.json shows all 20 rows as GET /, resultCode="200", success=true, with a 20-second timestamp spread (2026-06-22T05:09:24Z through 2026-06-22T05:09:44Z) matching the 0.5-second client-side sleep between curl invocations.

Analysis¶

The before-fix and after-fix measurements isolate APPLICATIONINSIGHTS_CONNECTION_STRING as the only intentionally changed variable: same Container App resource, same hellotelemetry:v3 image tag, same gunicorn worker count, same target port 8080, same Container Apps Environment, same traffic pattern (20 sequential GET / requests, 0.5 s sleep between). The 0→20 jump in AppRequests aggregate requestCount and the 0→21 jump in AppTraces aggregate traceCount, in this reproduction, are consistent with the env var being the single controlling input to the SDK's export path.

The after-fix AppTraces message content provides additional discriminating evidence: the startup log Azure Monitor configured: telemetry export enabled is emitted exactly once when configure_azure_monitor() runs at import time, and the 20 / endpoint hit (conn_str_present=True) lines are emitted once per request from inside the Flask handler. Both messages depend on the logger_name=__name__ kwarg being passed to configure_azure_monitor() — without it, only auto-instrumented telemetry (AppRequests, AppDependencies) would export and module-level logger.info(...) calls would stay invisible. Their presence in AppTraces confirms the full export path is wired.

The cloud_RoleName="unknown_service" label is the OpenTelemetry default when neither OTEL_SERVICE_NAME nor service.name is set; it is a cosmetic naming gap, not a telemetry routing gap. Production deployments should also set OTEL_SERVICE_NAME so the Container App name surfaces in dashboards.

Conclusion¶

The hypothesis is confirmed in this reproduction. Adding APPLICATIONINSIGHTS_CONNECTION_STRING to the Container App env vars is necessary and sufficient to enable telemetry export from the azure-monitor-opentelemetry==1.6.4 Python distro running under gunicorn on Azure Container Apps. The alternative hypothesis — that bundling an OpenTelemetry SDK in the image is by itself enough — is rejected: without the env var, configure_azure_monitor() is skipped (when guarded) or crashes the worker (when unguarded), and either way AppRequests stays empty.

Falsification¶

The alternative hypothesis (SDK in image is sufficient on its own) is falsified by the directly evidenced :v3 pair:

• [Observed] evidence/14-revisions-lifecycle.json records revision ca-appiconn-x2lcxd--0000006 as the before-fix run with image=acrappiconnx2lcxd.azurecr.io/hellotelemetry:v3 and hasConnStr=false; aggregate counts in evidence/03-ai-requests-before-fix.json and evidence/04-ai-traces-before-fix.json are both zero rows.
• [Observed] The same file records revision ca-appiconn-x2lcxd--0000007 as the after-fix run with image=acrappiconnx2lcxd.azurecr.io/hellotelemetry:v3 and hasConnStr=true; aggregate counts in evidence/09-ai-requests-after-fix.json and evidence/10-ai-traces-after-fix.json populate to requestCount=20 and traceCount=21 respectively.
• [Observed] The before/after full Container App configs in evidence/05-containerapp-full-config-before-fix.json and evidence/11-containerapp-full-config-after-fix.json differ in exactly one container-level field: the before snapshot's properties.template.containers[0] object contains only the keys image, imageType, name, resources (no env key), while the after snapshot's same object adds an env array whose only element is {name: "APPLICATIONINSIGHTS_CONNECTION_STRING", value: "InstrumentationKey=..."}. The fields that are present in both snapshots are byte-identical across them: image (acrappiconnx2lcxd.azurecr.io/hellotelemetry:v3), imageType (ContainerImage), container name (app), resources (cpu=0.5, memory=1Gi, ephemeralStorage=2Gi), properties.template.scale (minReplicas=1, maxReplicas=1, cooldownPeriod=300, pollingInterval=30), properties.configuration.ingress.targetPort (8080), and identity.type (SystemAssigned).

This rules out "the SDK shipping in the image is sufficient" as the controlling variable — the SDK is identically present in both runs and the only thing that differs is the env var.

Operator takeaway¶

Missing APPLICATIONINSIGHTS_CONNECTION_STRING is an availability-clean observability outage: the app keeps serving HTTP 200 to clients, but operators lose every signal they would normally use to diagnose a real incident. In this reproduction the env var was the single controlling input — flipping it on with no other change converted a fully silent app into a fully observable one within one revision deployment cycle. Treat connection-string injection as a deploy-time gate, not a runtime configuration the app reads later.

Support takeaway¶

When escalating an "Application Insights is empty but the app is up" case on Azure Container Apps, run this sequence in order before assuming a platform issue:

1. Confirm whether the env var is wired into the current revision at all:

   az containerapp show \
       --subscription "$AZ_SUBSCRIPTION" \
       --name "$APP_NAME" \
       --resource-group "$RG" \
       --query "properties.template.containers[0].env[?name=='APPLICATIONINSIGHTS_CONNECTION_STRING']"
   

   Command	Purpose
   az containerapp show --subscription "$AZ_SUBSCRIPTION" --name "$APP_NAME" --resource-group "$RG" --query "properties.template.containers[0].env[?name=='APPLICATIONINSIGHTS_CONNECTION_STRING']"	Extracts only the Application Insights connection-string env var from the live revision template so support can prove whether telemetry silence starts with missing configuration rather than with ingestion.

2. Look for the startup log line Azure Monitor configured: telemetry export enabled (or your app's equivalent) to confirm the SDK actually ran configure_azure_monitor(). Its absence usually means the env var was never read by the worker:

   az containerapp logs show \
       --subscription "$AZ_SUBSCRIPTION" \
       --name "$APP_NAME" \
       --resource-group "$RG" \
       --container app \
       --tail 100
   

   Command	Purpose
   az containerapp logs show --subscription "$AZ_SUBSCRIPTION" --name "$APP_NAME" --resource-group "$RG" --container app --tail 100	Pulls recent application logs from the app container so you can confirm whether the SDK emitted its startup line and actually initialized telemetry export.

3. If the env var IS present and the SDK startup log IS visible but AppRequests is still empty: check whether you are using from flask import Flask before configure_azure_monitor(), which in this lab's development experience silently broke Flask auto-instrumentation even with a valid connection string. The :v2 source variant is documented in this lab only as a lab-development observation — the :v2 source file was not committed to the repo, and no per-revision AppRequests/AppTraces capture file is committed for it (the canonical falsification pair in this lab is the :v3 before/after run, not a :v2/:v3 comparison).

4. If the env var IS present and AppTraces is populating but AppRequests is not: the SDK is exporting, but the web-framework auto-instrumentation is not wrapped. Cross-check Flask import order, gunicorn worker class (sync vs gevent), and whether any other middleware is re-wrapping the Flask app after SDK init.

4b) Phase B Falsification Gates¶

The 2026-06-25 evidence-pack overlay adds a Phase B verifier under labs/appinsights-connection-string-missing/. Unlike the live-Azure Phase A workflow (trigger.sh + fix-and-capture.sh), the new labs/appinsights-connection-string-missing/verify.sh is a pure file processor: it reads only the committed canonical cohort under labs/appinsights-connection-string-missing/evidence/ (20 canonical files — 2 script logs + 6 before-fix captures + 5 after-fix captures + 4 KQL captures + 3 image-lineage captures, anchored on the 2026-06-22T05:02:57Z koreacentral deployment) and emits four derived gate JSONs. The four gates encode cohort integrity (no foreign artifacts, all required files present, temporal coherence), before-fix failure attribution (missing env var anchor plus AppRequests/AppTraces both empty plus 20 HTTP 200 availability anchor), after-fix recovery materialization (env var present on byte-identical container plus aggregate AppRequests/AppTraces with the expected counts plus per-message corroboration plus recovery PASS marker), and single-variable falsification continuity (byte-identical container config after stripping env, before/after revision pair --0000006/--0000007 on the same image, same registry, same container name). All 16 sub-gates pass on the 2026-06-22 cohort.

The four gates together block three classes of overclaim AND narrow a fourth: evidence-pack-was-contaminated-with-stale-or-foreign-artifacts is blocked by Gate 16's canonical-file presence check + temporal coherence window + non-junk-extras predicate; the-empty-AppRequests-table-could-have-meant-the-SDK-was-broken-or-no-traffic-was-sent is blocked by Gate 17's cohort_binding_note framing of sub-gates (b) and (c) as absence-style predicates that require sub-gate (a) (env=null anchor) AND sub-gate (d) (20 HTTP 200 availability anchor) for interpretation; recovery-was-partial-or-the-aggregate-counts-were-incidental is blocked by Gate 18's BOTH-not-OR sub-gate composition (all five sub-gates must independently pass; sub-gate (d) corroborates sub-gate (c) by per-message breakdown so the traceCount=21 aggregate is decomposed into 1 startup + 20 endpoint-hit records, ruling out coincidental row counts); and Gate 19 narrows the claim to env-var-only delta + byte-identical container config + same registry + same container name — it does NOT prove the underlying resource was not torn down and recreated (timestamp / no-recreation claims are dropped per Lab 21 Q1 as not soundly evidenced by this cohort). The gates do NOT prove the platform always materializes telemetry within 240 seconds of fix application — App Insights ingestion latency can vary, and this cohort captured a single 240 s window; a longer ingestion-window lab would be needed to bound that claim. The full per-file provenance and honest-disclosure notes are in labs/appinsights-connection-string-missing/evidence/README.md.

Expected Evidence¶

Reproduced end-to-end in koreacentral on 2026-06-22. All raw evidence is committed under labs/appinsights-connection-string-missing/evidence/:

# Excerpt from evidence/13-ai-traces-messages-after-fix.json
# (KQL: traces | where timestamp > ago(15m) | project timestamp, message, severityLevel | order by timestamp asc | take 25)
2026-06-22T05:08:50.418265Z: Azure Monitor configured: telemetry export enabled
2026-06-22T05:09:24.936228Z: / endpoint hit (conn_str_present=True)
2026-06-22T05:09:25.990563Z: / endpoint hit (conn_str_present=True)
2026-06-22T05:09:26.981778Z: / endpoint hit (conn_str_present=True)
... (17 more / endpoint hit lines)
2026-06-22T05:09:44.415933Z: / endpoint hit (conn_str_present=True)

// Excerpt from evidence/14-revisions-lifecycle.json showing the controlling variable
{ "name": "ca-appiconn-x2lcxd--0000006", "image": "...hellotelemetry:v3", "hasConnStr": false, "active": false },
{ "name": "ca-appiconn-x2lcxd--0000007", "image": "...hellotelemetry:v3", "hasConnStr": true,  "active": true }

Clean Up¶

./cleanup.sh   # deletes the entire resource group (lab is fully disposable)

Or, if you want to keep the environment and only stop the running app:

az containerapp revision deactivate \
    --subscription "$AZ_SUBSCRIPTION" \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --revision "$(az containerapp show --subscription "$AZ_SUBSCRIPTION" --name "$APP_NAME" --resource-group "$RG" --query 'properties.latestRevisionName' --output tsv)"

Related Playbook¶

• Application Insights Connection String Missing

See Also¶

• Observability Tracing Lab
• Log Analytics Ingestion Gap Lab
• Diagnostic Settings Missing Lab

Sources¶

• Collect and read OpenTelemetry data in Azure Container Apps
• Connection strings in Application Insights
• Enable Azure Monitor OpenTelemetry for Python applications
• Observability in Azure Container Apps