Introduction:

Welcome Azure developers! If you’re looking to add logging policies for your Container Apps in Azure, there are two options to consider. In this blog post, we will walk you through the process of enabling logs using the “logging options” under monitoring and the “Azure Monitor” option under monitoring. We’ll also provide solutions for different use cases and reference materials to help guide you along the way.

Option 1: Sending Logs to Log Analytics Workspace
Option 2: Sending Logs to Multiple Destinations (Log Analytics Workspace and Storage Account)

The goal
This blog provides you with valuable insights on enabling logs for your Azure Container Apps using different methods and custom policies. Stay tuned for more tips, tricks, and tutorials for Azure developers!

Lets get started
If you want to add policy to send logs to Log Analytics Workspace and storage account for your container apps, there are two options to enable your logs.

Option 1: “logging options” under monitoring section which will only send logs to Log Analytics Workspace inside container apps environment

Option 2: “Azure Monitor” under monitoring section which will give you multiple options to add diagnostic settings and send logs to multiple destinations

Reference document on step by step guidance can be found here –   Log storage and monitoring options in Azure Container Apps | Microsoft Learn

Different methods for adding custom policy for enabling logs for Container Apps 

Use Case 1: We want to send logs for monitoring purpose using custom policy

Solution:

We need two separate Policies to evaluate the scenario in question:

           To check if property”appLogsConfiguration.destination” is set to “azure-monitor”
           To check if the diagnostic settings are deployed to the resource

Please note that we are choosing option as “azure-monitor” because we want to send logs to multiple destinations.

Now we need to add the policy definitions which will first check if we are selecting azure monitor under monitoring section and then deploy diagnostic settings with effect as – “deployifnotexists”

Now in further testing, you will see that the property “appLogsConfiguration.destination” is not modifiable.

More specifically, PUT calls to this resource type overwrite any omitted properties, which can cause loss of information such as the VNet Configuration or Tags for container apps. Which means that it can override existing configuration of container apps

The DINE effect would also suffer from this limitation. That is, unless we find a way to build an ARM template that dynamically gets the values of the resource properties and uses those in the resource re-deployment, preventing the loss of information.

This leaves us with below options:

 Accept the limitations of the DINE effect – with the downside that some properties might be reverted to their default values when a resource is remediated.
Re-evaluate your requirements and use the Deny effect instead. This has no downsides, as the Deny effect on “appLogsConfiguration.destination” not equal to “azure-monitor” will prevent non-compliant resources from being deployed at all and will have perfect synergy with the 2nd Policy (for diagnostic settings).

Now, as we cannot use DINE effect here, we can use Deny effect which will completely deny the resource deployment if Monitor is not selected while deploying the container apps. And then other policy with DINE effect which will add diagnostic settings for your resource. And then we will be able to enable logs for container apps.

Use case 2: Use Case 1 will not work if we deploy container apps using terraform as it will block the resource deployment and we don’t have any option to deploy monitor settings using terraform, hence we cannot put deny policy to restrict usage of monitor option under monitoring to enable logs.

Solution:

Using DINE effect, While updating the container apps environment resource, its workload profiles settings should also be present, and Policy is not able to get complete workload profile details (complete Array value). This means if we add policy for adding logs to be send to LAW, it will reset the existing workload profile settings for the container apps.

To overcome the challenge, we must use linked templates with Template resources to get the profile properties of existing resource and pass it to another template which is updating the environment resource.

Once above step is completed, we must update the ARM template code in policy definition to use the linked templates accordingly. Once Policy Definition is updated, we can add logs for LAW

Reference Screenshot of container apps environment showing option to enable logs 

Use case 3: Customer does not want to use Linked templates which is explained in Use Case 2 due to security reasons

Solution:

As customer does not want to use linked templates, we are left with last solution to enable logs using “logging options” under monitoring. Please note that this option will only send logs to Log analytics workspace only.

Reference Screenshot showing option to send logs only to LAW in container apps environment settings

We can add a custom policy definition which will check the field value as below and enable the logs to be send to log analytics workspace. Please note that it will also take “workLoadProfiles” as parameters and fetch the current configuration of container apps so that while deploying logs, current configuration remains intact

field”: “Microsoft.App/managedEnvironments/appLogsConfiguration.destination”,

                      “equals”: “log-analytics”

So from this we hope you have learnt how to enable logging for Azure Container Apps by choosing from two options: ‘logging options’ under monitoring or ‘Azure Monitor’. Discover different methods for adding custom policies and solutions for various use cases such as sending logs to Log Analytics Workspace and storage account, using Terraform, and without linked templates. Follow our step-by-step guidance for Azure developers to get the most out of your container apps’ monitoring capabilities.

​Microsoft Tech Community – Latest Blogs –Read More