Today we are pleased to announce a new set of capabilities within Azure Monitor for routing your Azure resource diagnostic logs and metrics to storage accounts, Event Hubs namespaces, or Log Analytics workspaces. You can now create multiple resource diagnostic settings per resource, enabling you to route different permutations of log categories and metrics to different destinations (in public preview) and route your metrics and logs to a destination in a different subscription. In this post, we’ll walk through these new capabilities and how you can start using them today.

Creating multiple diagnostic settings

A resource diagnostic setting is a rule on an individual Azure resource that determines what logs and metrics among those available for that resource type are to be collected and to where that data will be sent. Resource diagnostic settings have three destinations, or ‘data sinks’ for monitoring data:

• Storage accounts for archival
• Log Analytics workspaces for search and analytics
• Event Hubs namespaces for integration with 3rd party tools or custom solutions

Previously, only one diagnostic setting could be set per resource. We heard feedback that this was too restrictive in two ways:

1. It limited you to sending monitoring data to only one instance of each destination. For example, you could only send the logs and metrics for a particular Application Gateway to one storage account. If you have two independent teams for security and monitoring that each wanted to consume this data, this limited your ability to offer that data separately to both teams.
2. It required that you route the same permutation of log categories and metrics to all destinations. For example, it was impossible to route a particular Batch Account’s service logs into Log Analytics while sending that same account’s metrics into a storage account.

Today, we are introducing the public preview of the ability to create multiple diagnostic settings on a single resource, removing both restrictions above. Let’s take a quick look at how you can set this up in the Azure Portal. Navigate to the Monitor blade, and click on “Diagnostic Settings.”

You’ll notice we’ve renamed this section “Diagnostic Settings” from “Diagnostic Logs” to better reflect the ability to route both log and metric data from a resource. In this blade you’ll see a list of resources that support diagnostic settings. Clicking on one will show you a list of all settings on that resource.

If none exist, you will be prompted to create one.

Clicking “turn on diagnostics” will present the familiar blade for setting a diagnostic setting, but now you will see that a field for “name” has been added. Give your setting a name to differentiate between multiple settings on the same resource.

Click “save,” and now returning to the previous blade you will see the created setting and add an additional setting.

Adding more diagnostic settings will add them to this list. Note that you can have a maximum of three diagnostic settings per resource.

You can also do this using the REST API or in an ARM template. PowerShell support is coming soon. Note that routing data to an additional destination of the same type will incur a service fee per our billing information.

Writing monitoring data across subscriptions

Previously, you could only route metrics and log categories for a resource to a storage account, Event Hubs namespace, or Log Analytics workspace within the same subscription as the resource emitting data. For companies with centralized monitoring teams responsible for keeping track of many subscriptions, we heard that maintaining a destination resource per subscription was tedious, requiring knowledge of the unique storage account (or Event Hubs namespace or workspace) for each subscription. Now you can configure a diagnostic setting to send monitoring data to a destination in a different subscription, provided that your user account has appropriate write access to that destination resource.

Note that authentication is done within a particular Azure Active Directory tenant, so monitoring data can only be routed to a destination within the same tenant as the resource emitting data.

These new capabilities are rolling out to all public Azure regions beginning today. Try them out and let us know your feedback through our UserVoice channel or in the comments below.