Edit

Share via


Create diagnostic settings in Azure Monitor

Create and edit diagnostic settings in Azure Monitor to send Azure platform metrics and logs to different destinations like Azure Monitor Logs, Azure Storage, or Azure Event Hubs. You can use different methods to work with the diagnostic settings, such as the Azure portal, the Azure CLI, PowerShell, and Azure Resource Manager.

Important

The Retention Policy as set in the Diagnostic Setting settings is now deprecated and can no longer be used. Use the Azure Storage Lifecycle Policy to manage the length of time that your logs are retained. For more information, see Migrate diagnostic settings storage retention to Azure Storage lifecycle management

Use the az monitor diagnostic-settings create command to create a diagnostic setting with the Azure CLI. See the documentation for this command for descriptions of its parameters.

Important

You can't use this method for an activity log. Instead, use Create diagnostic setting in Azure Monitor by using a Resource Manager template to create a Resource Manager template and deploy it with the Azure CLI.

The following example command creates a diagnostic setting by using all three destinations. The syntax is slightly different depending on your client.

To specify resource-specific mode if the service supports it, add the export-to-resource-specific parameter with a value of true.`

az monitor diagnostic-settings create  \
--name KeyVault-Diagnostics \
--resource /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.KeyVault/vaults/mykeyvault \
--logs    '[{"category": "AuditEvent","enabled": true}]' \
--metrics '[{"category": "AllMetrics","enabled": true}]' \
--storage-account /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> \
--workspace /subscriptions/<subscription ID>/resourcegroups/<resource group name>/providers/microsoft.operationalinsights/workspaces/<log analytics workspace name> \
--event-hub-rule /subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.EventHub/namespaces/<event hub namespace>/authorizationrules/RootManageSharedAccessKey \
--event-hub <event hub name> \
--export-to-resource-specific true

Troubleshooting

Here are some troubleshooting tips.

Metric category isn't supported

When you deploy a diagnostic setting, you receive an error message similar to "Metric category 'xxxx' isn't supported." You might receive this error even though your previous deployment succeeded.

The problem occurs when you use a Resource Manager template, REST API, the CLI, or Azure PowerShell. Diagnostic settings created via the Azure portal aren't affected because only the supported category names are presented.

The problem occurs because of a recent change in the underlying API. Metric categories other than AllMetrics aren't supported and never were except for a few specific Azure services. In the past, other category names were ignored when deploying a diagnostic setting. The Azure Monitor back end redirected these categories to AllMetrics. As of February 2021, the back end was updated to specifically confirm the metric category provided is accurate. This change can cause some deployments to fail.

If you receive this error, update your deployments to replace any metric category names with AllMetrics to fix the issue. If the deployment was previously adding multiple categories, only keep one with the AllMetrics reference. If you continue to have the problem, contact Azure support through the Azure portal.

Setting disappears because of non-ASCII characters in resourceID

Diagnostic settings don't support resource IDs with non-ASCII characters. For example, consider the term "Preproducción." Because you can't rename resources in Azure, your only option is to create a new resource without the non-ASCII characters. If the characters are in a resource group, you can move the resources under it to a new one. Otherwise, you need to re-create the resource.

Possibility of duplicated or dropped data

Every effort is made to ensure all log data is sent correctly to your destinations, however it's not possible to guarantee 100% data transfer of logs between endpoints. Retries and other mechanisms are in place to work around these issues and attempt to ensure log data arrives at the endpoint.

Inactive resources

When a resource is inactive and exporting zero-value metrics, the diagnostic settings export mechanism backs off incrementally to avoid unnecessary costs of exporting and storing zero values. The back-off may lead to a delay in the export of the next non-zero value.

When a resource is inactive for one hour, the export mechanism backs off to 15 minutes. This means that there is a potential latency of up to 15 minutes for the next nonzero value to be exported. The maximum backoff time of two hours is reached after seven days of inactivity. Once the resource starts exporting nonzero values, the export mechanism reverts to the original export latency of three minutes.

This behavior only applies to exported metrics and doesn't affect metrics-based alerts or autosacle.

Next steps