Policy for Sending logs to multiple destinations for container apps

introduction:

Welcome, Azure developers! If you want to add a logging policy to your container app 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” option in Monitoring and the “Azure Monitor” option in Monitoring. We will also provide references that walk you through the process and solutions for various use cases.

Option 1: Sending logs to a Log Analytics workspace
Option 2: Send logs to multiple destinations (Log Analytics Workspace and Storage Account)

target
This blog provides valuable insights into enabling logs for Azure container apps using various methods and custom policies. Stay tuned for more tips, tricks, and tutorials for Azure developers!

Let’s get started
If you want to add a policy to send logs to a Log Analytics Workspace and storage account for your container app, there are two ways to enable logs.

Option 1: “Logging Options” under the Monitoring section to only send logs to the Log Analytics Workspace inside the container app environment.

Option 2: “Azure Monitor” in the Monitoring section, which provides several options for adding diagnostic settings and sending logs to multiple destinations.

A reference document with step-by-step instructions can be found here. Log storage and monitoring options for Azure Container Apps | Microsoft Learn

Multiple ways to add custom policies to enable logs for container apps

Use Case 1: I want to send logs for monitoring purposes using a custom policy.

way out:

Evaluating the scenario in question requires two separate policies.

1. To check your assets”appLogsConfiguration.target” is set to “azure-monitor”.
2. To verify that the diagnostic settings have been deployed to the resource:

I chose the “azure-monitor” option because I want to send the logs to multiple destinations.

Now in the Monitoring section, you need to first make sure you have selected Azure Monitor and then add a policy definition that deploys diagnostic settings with something like “deployifnotexists”.

Now we can verify the “properties” by performing additional tests.appLogsConfiguration.target” cannot be changed.

More specifically, a PUT call to this resource type will overwrite any omitted properties, which could result in the loss of information such as VNet configuration or tags for the container app. This means that existing configurations for the container app could be overwritten.

DINE effects will also suffer from these limitations, unless we find a way to build ARM templates that dynamically fetch the values ​​of resource properties and use them to redistribute resources, thus avoiding information loss.

That leaves us with the following options:

• Accept the limitations of the DINE effect. The downside is that some properties may revert to their defaults when the resource is modified.
• Re-evaluate your requirements and use a Deny effect instead. If the Deny effect for “appLogsConfiguration.destination” is not equal to “azure-monitor”, there is no downside as the non-compliant resources will not be deployed at all and there is perfect synergy with the second policy (for diagnostic settings).

Now since you can’t use the DINE effect here, you can use the Deny effect to completely deny the resource deployment if Monitor isn’t selected while deploying the container app. Then you can use another policy with the DINE effect that adds diagnostic settings for the resource. Then you can enable logs for the container app.

Use Case 2: Use case 1 does not work when deploying container apps using Terraform. You cannot apply a deny policy to restrict the use of Monitor to enable logs in monitoring, as resource deployment is blocked and there is no option to deploy monitor settings using Terraform.

way out:

While updating container app environment resources using DINE effect, the corresponding workload profile settings must also exist and the policy cannot fetch the full workload profile details (full array values). That is, adding a policy to add logs to send to LAW will reset the existing workload profile settings for the container app.

To overcome these challenges, you need to use a template associated with a template resource to retrieve the profile properties of an existing resource and pass them to another template that updates the environment resource.

Once the above steps are complete, you will need to update the ARM template code in your policy definition to use the linked templates appropriately. Once the policy definition is updated, you can add logs for LAW.

Reference screenshot of a container app environment showing the log enablement option.

Use Case 3: The customer does not want to use the linked template described in Use Case 2 for security reasons.

way out:

Since the customer does not want to use linked templates, we are left with the last solution to enable logs using the “Logging Options” in Monitoring. Note that this option only sends logs to a Log Analytics workspace.

Reference screenshot showing the option to send logs only to LAW in the container app settings

You can add a custom policy definition that checks the field values ​​and sends the logs to the log analysis workspace as shown below. Also, “Workload Profile“Use it as a parameter and get the current configuration of the container app so that the current configuration remains intact while deploying the logs.

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

“equals”: “log-analytics”

So, hopefully, through this article, you have learned how to enable logging for Azure Container Apps by choosing between two options in Monitoring: ‘Logging Options’ or ‘Azure Monitor’. Learn different ways to add custom policies and solutions for different use cases, such as sending logs to Log Analytics Workspace and storage account, using Terraform, and without linked templates. Follow our step-by-step guide for Azure developers to get the most out of monitoring capabilities for your container apps.