This post will explain why you may see other Docker Containers showing up in your logging when using App Service Linux or Linux Web Apps for Containers.
When creating an application on either App Service Linux or Linux Web App for Containers, you would expect to see logging from just your container.
Starting off, in a very basic scenario, this is usually the case. But as you enable more Azure services on your application there is a chance you may see up to two (2) more containers found in your logging.
You can view this in various locations:
- Diagnose and Solve Problems -> Application Logs (detector)
- Viewing logs through FTP
- Viewing logs directly on the Kudu site
You may see a mix of logging in either
default_docker.log from these containers, as well as in their own respective log files.
Compared to Windows App Service - these services run as Docker Containers along side your application.
The “middleware” container will activate if any of these services are activated:
- AutoHeal (Linux)
- CORS (Enabled through the portal only)
- EasyAuth (Authentication blade)
docker.log, you’ll see this running with the
_middleware suffix -
This container will generate its own log with the naming scheme of
Most output of this will only be on startup, however, depending on where you’re viewing logging - it can interweave with your application stdout (such as streaming logs) - in this case, viewing your applications logs directly can reduce extra noise.
Startup logging from this container looks like the following (and can be found in the above log):
2023-03-15T21:46:22.281Z INFO - Initiating warmup request to container myfakesite_4_1b8de193_middleware for site myfakesite 2023-03-15T21:46:22.320Z INFO - Container myfakesite_4_1b8de193_middleware for site myfakesite initialized successfully and is ready to serve requests.
2023-03-15T21:46:22.052079080Z Updating certificates in /etc/ssl/certs... 2023-03-15T21:46:25.170991072Z 7 added, 0 removed; done. 2023-03-15T21:46:25.176722062Z Running hooks in /etc/ca-certificates/update.d... 2023-03-15T21:46:25.177469243Z done. 2023-03-15T21:46:25.187385847Z Updated CA certificates
NOTE: If you enable CORS through application code, this will not spin up this middleware container. The CORS option in the Azure Portal will only spin up this container if it is actually enabled through there.
The “msiProxy” container will activate if Managed Identity (user, or system assigned) is enabled. This can be enabled through the Identity blade in the Azure App Service Portal.
docker.log, you’ll see this running with the
_msiProxy suffix -
As explained in the middleware section, logging here can interweave with your application stdout - review your application logging separate (such as through its own log
file, if needed).
Startup and general stdout from this container would look like the following and can be viewed in the
YYYY_MM_DD_machinename_msi_docker.log that is automatically created when this container is started:
2023-03-15T21:46:22.281Z INFO - Initiating warmup request to container myfakesite_4_1b8de193_msiProxy for site myfakesite 2023-03-15T21:46:22.320Z INFO - Container myfakesite_4_1b8de193_msiProxy for site myfakesite initialized successfully and is ready to serve requests.
2023-03-15T21:46:18.825803194Z Hosting environment: Production 2023-03-15T21:46:18.831961567Z Content root path: /app 2023-03-15T21:46:18.832871878Z Now listening on: http://[::]:8081 2023-03-15T21:46:19.147393005Z myfakesite : [00000000-000-0000-0000-000000000] Incoming request on /healthcheck?api-version=2021-08-01 2023-03-15T21:46:19.155189998Z myfakesite : [00000000-000-0000-0000-000000000] Request to TokenService: Endpoint 172.16.1.5:8081, Port 8081, Path /healthcheck, Query ?api-version=2021-08-01, Method GET, UserAgent HealthCheck/1.0 2023-03-15T21:46:19.417182701Z myfakesite : [00000000-000-0000-0000-000000000] Returning response for Site , Endpoint 172.16.1.5:8081, Port 8081, Path /healthcheck, Method GET, Result = 200 2023-03-15T21:46:22.313836833Z myfakesite : [00000000-000-0000-0000-000000000] Incoming request on /robots933456.txt 2023-03-15T21:46:22.314948029Z myfakesite : [00000000-000-0000-0000-000000000] Request to TokenService: Endpoint 172.16.1.5:8081, Port 8081, Path /robots933456.txt, Query , Method GET, UserAgent HealthCheck/1.0
- Enabling the above services can cause the
msiProxycontainer to start.
- Ensure you’re actually looking at the correct container name when troubleshooting. If glancing over or moving too fast through logging, you may mistake your application container for the wrong container, which can cause confusion.
- This is especially true if trying to validate
docker runcommands. Make sure you’re looking at your own containers logging.
- All services run through the respective container explained above - enabling all 3 services that start up the middleware container, for example, will not create 3 middleware containers. There will just be one (1), regardless of just three services you have enabled.