Skip to content

Log Analytics Queries

Use Log Analytics queries when you need retained history, aggregation, or alert-friendly KQL rather than a live tail.

Prerequisites

  • A Log Analytics workspace receiving Container Apps logs
  • Permission to query the workspace
  • App, revision, and environment naming conventions documented for responders
export WORKSPACE_ID="<log-analytics-workspace-id>"
export APP_NAME="app-python-api-prod"

When to Use

  • For error-rate and latency trend analysis
  • For scale-event, revision, and restart investigation
  • For scheduled-query alerts and reusable incident queries

Procedure

Start by confirming whether your workspace uses native tables or legacy _CL tables. Then build a small query window before turning it into an alert.

Example pattern using the native table names:

let AppName = "app-python-api-prod";
ContainerAppConsoleLogs
| where TimeGenerated > ago(15m)
| where ContainerAppName == AppName
| where Log contains "ERROR" or Log contains "Exception"
| summarize ErrorCount = count() by bin(TimeGenerated, 5m)
| order by TimeGenerated asc

Slow request pattern when your application writes structured request timing to console logs:

let AppName = "app-python-api-prod";
ContainerAppConsoleLogs
| where TimeGenerated > ago(30m)
| where ContainerAppName == AppName
| where Log has "durationMs"
| project TimeGenerated, RevisionName, ContainerName, Log

Scale and replica events from system logs:

let AppName = "app-python-api-prod";
ContainerAppSystemLogs
| where TimeGenerated > ago(30m)
| where ContainerAppName == AppName
| where Log has_any ("scale", "KEDA", "replica")
| project TimeGenerated, RevisionName, ReplicaName, Reason, Log
| order by TimeGenerated desc

Restart-loop and probe investigation:

let AppName = "app-python-api-prod";
ContainerAppSystemLogs
| where TimeGenerated > ago(2h)
| where ContainerAppName == AppName
| where Reason has_any ("ProbeFailed", "BackOff", "CrashLoopBackOff", "ContainerTerminated")
| summarize FailureCount = count() by RevisionName, ReplicaName, Reason
| order by FailureCount desc

Ingress 4xx or 5xx checks depend on what your app emits to console logs. If your app writes structured HTTP status lines, query those fields or strings from the console-log table that exists in your workspace.

Microsoft Learn currently shows both schema shapes. The Container Apps log-monitoring article uses _CL tables and suffixed columns such as ContainerAppName_s, RevisionName_s, and Log_s, while Azure Monitor's table reference pages document native tables and columns such as ContainerAppName, RevisionName, and Log.

flowchart TD
    A[Identify active table schema] --> B[Filter by app and time range]
    B --> C[Summarize the symptom]
    C --> D[Correlate revision and replica context]
    D --> E[Reuse query in alert rules]

Verification

  • Confirm the query returns current rows for the target app.
  • Confirm table and column names match the workspace schema.
  • Confirm alert thresholds are stable before creating scheduled-query alerts.

Rollback / Troubleshooting

  • If no rows appear, test native and _CL table names.
  • If a copied query fails, adapt the columns to the workspace schema before debugging the app.
  • If alerts are noisy, narrow the time window or raise the threshold.

See Also

Sources