Troubleshooting an Azure Container App
  • 25 Nov 2022
  • 1 Minute to read
  • Dark
    Light
  • PDF

Troubleshooting an Azure Container App

  • Dark
    Light
  • PDF

#ServerlessTips - Azure Container Apps
Author: Stephane Eyskens Azure MVP

As we have seen in Getting started with Azure Container App, we can easily have an app up & running. However, when deploying Dapr's sample calculator, I noticed an issue with the multiply operation. It was due to a mistake in one of the YAML files made available by the Dapr folks. How come I figure this out, that's what we'll see here.

Here is what is provided in the initial YAML file provided by Dapr:
Picture418

Where we see the app's identifier (multiplyapp), the app's port, and the image. It was translated into the following command to deploy the multiply app:

az containerapp create -n multiplyapp -g AzugIceland --environment "acaenv" --cpu 1 --memory 2 --enable-dapr --dapr-app-id multiplyapp --dapr-app-port 5000 --dapr-app-protocol http --min-replicas 1 --image dapriosamples/distributed-calculator-python:latest

The above command results in a failure:
Picture59

To figure out the problem, you can click on the revision name, where you will see pointers to system logs and console logs. Both links lead to the Log Analytics workspace with a different KQL query attached to the environment. The workspace contains two custom tables, which you will use in every troubleshooting session:

  • ContainerAppConsoleLogs_CL: This table holds the stdout and stderr of your containers and the daprd container, which is a sidecar injected into your application pod. You can easily filter on the Stream_s attribute to filter out on stderr only.

  • ContainerAppSystemLogs_CL: this table holds the logs from K8s (remember that ACA is built on top of K8s) and the KEDA logs.

Running the following query over the system logs:

ContainerAppSystemLogs_CL
| where RevisionName_s == <revision-name>
| where Type_s != "Normal"
| project Log_s

I could quickly spot issues:
Picture65

The above exceptions mean that the application container is not responding correctly to K8's built-in probing mechanisms. It leads me to check the application logs themselves:

ContainerAppConsoleLogs_CL
| where RevisionName_s == <revision-name>
| where ContainerName_s == "multiplyapp"
| project Log_s

Picture73

That is where I noticed the container was listening on port 5001 and not on port 5000, as indicated in the YAML file. Therefore, simply redeploying the app on the correct port fixed the issue. It was a practical troubleshooting case. What you must remember is the following:

  • Any application-related problem, including Dapr issues, is likely to be found in the ContainerAppConsoleLogs_CL table

  • Any system issue is likely to be found in the ContainerAppSystemLogs_CL table


Was this article helpful?