Monitor Azure Queue Storage

This article describes:

• The types of monitoring data you can collect for this service.
• Ways to analyze that data.

Note

If you're already familiar with this service and/or Azure Monitor and just want to know how to analyze monitoring data, see the Analyze section near the end of this article.

When you have critical applications and business processes that rely on Azure resources, you need to monitor and get alerts for your system. The Azure Monitor service collects and aggregates metrics and logs from every component of your system. Azure Monitor provides you with a view of availability, performance, and resilience, and notifies you of issues. You can use the Azure portal, PowerShell, Azure CLI, REST API, or client libraries to set up and view monitoring data.

• For more information on Azure Monitor, see the Azure Monitor overview.
• For more information on how to monitor Azure resources in general, see Monitor Azure resources with Azure Monitor.

Important

Metrics and logs in Azure Monitor support only Azure Resource Manager storage accounts. Azure Monitor doesn't support classic storage accounts. If you want to use metrics or logs on a classic storage account, you need to migrate to an Azure Resource Manager storage account. For more information, see Migrate to Azure Resource Manager.

Insights

Some services in Azure have a built-in monitoring dashboard in the Azure portal that provides a starting point for monitoring your service. These dashboards are called insights, and you can find them in the Insights Hub of Azure Monitor in the Azure portal.

Azure Storage insights offer a unified view of storage performance, capacity, and availability. See Monitor storage with Azure Monitor Storage insights.

Resource types

Azure uses the concept of resource types and IDs to identify everything in a subscription. Resource types are also part of the resource IDs for every resource running in Azure. For example, one resource type for a virtual machine is Microsoft.Compute/virtualMachines. For a list of services and their associated resource types, see Resource providers.

Azure Monitor similarly organizes core monitoring data into metrics and logs based on resource types, also called namespaces. Different metrics and logs are available for different resource types. Your service might be associated with more than one resource type.

Data storage

For Azure Monitor:

• Metrics data is stored in the Azure Monitor metrics database.
• Log data is stored in the Azure Monitor logs store. Log Analytics is a tool in the Azure portal that can query this store.
• The Azure activity log is a separate store with its own interface in the Azure portal.

You can optionally route metric and activity log data to the Azure Monitor logs store. You can then use Log Analytics to query the data and correlate it with other log data.

Many services can use diagnostic settings to send metric and log data to other storage locations outside Azure Monitor. Examples include Azure Storage, hosted partner systems, and non-Azure partner systems, by using Event Hubs.

For detailed information on how Azure Monitor stores data, see Azure Monitor data platform.

Azure Monitor platform metrics

Azure Monitor provides platform metrics for most services. These metrics are:

• Individually defined for each namespace.
• Stored in the Azure Monitor time-series metrics database.
• Lightweight and capable of supporting near real-time alerting.
• Used to track the performance of a resource over time.

Collection: Azure Monitor collects platform metrics automatically. No configuration is required.

Routing: You can also route some platform metrics to Azure Monitor Logs / Log Analytics so you can query them with other log data. Check the DS export setting for each metric to see if you can use a diagnostic setting to route the metric to Azure Monitor Logs / Log Analytics.

• For more information, see the Metrics diagnostic setting.
• To configure diagnostic settings for a service, see Create diagnostic settings in Azure Monitor.

For a list of all metrics it's possible to gather for all resources in Azure Monitor, see Supported metrics in Azure Monitor.

For a list of available metrics for Azure Queue Storage, see Azure Queue Storage monitoring data reference.

Important

On January 9, 2024 Storage Analytics metrics, also referred to as classic metrics, retired. If you used classic metrics, see Move from Storage Analytics metrics to Azure Monitor metrics to transition to metrics in Azure Monitor.

Note

Azure Compute, not Azure Storage, supports metrics for managed disks or unmanaged disks. For more information, see Per disk metrics for Managed and Unmanaged Disks.

Azure Monitor resource logs

Resource logs provide insight into operations that were done by an Azure resource. Logs are generated automatically, but you must route them to Azure Monitor logs to save or query them. Logs are organized in categories. A given namespace might have multiple resource log categories.

Collection: Resource logs aren't collected and stored until you create a diagnostic setting and route the logs to one or more locations. When you create a diagnostic setting, you specify which categories of logs to collect. There are multiple ways to create and maintain diagnostic settings, including the Azure portal, programmatically, and though Azure Policy.

Routing: The suggested default is to route resource logs to Azure Monitor Logs so you can query them with other log data. Other locations such as Azure Storage, Azure Event Hubs, and certain Microsoft monitoring partners are also available. For more information, see Azure resource logs and Resource log destinations.

For detailed information about collecting, storing, and routing resource logs, see Diagnostic settings in Azure Monitor.

For a list of all available resource log categories in Azure Monitor, see Supported resource logs in Azure Monitor.

All resource logs in Azure Monitor have the same header fields, followed by service-specific fields. The common schema is outlined in Azure Monitor resource log schema.

For the available resource log categories, their associated Log Analytics tables, and the logs schemas for Azure Queue Storage, see Azure Queue Storage monitoring data reference.

Azure Queue Storage diagnostic settings

When you create the diagnostic setting, choose queue as the type of storage that you want to enable logs for. Then, specify one of the following categories of operations for which you want to collect logs.

Category	Description
StorageRead	Read operations on objects.
StorageWrite	Write operations on objects.
StorageDelete	Delete operations on objects.

The audit resource log category group allows you to collect the baseline of resource logs that Microsoft deems necessary for auditing your resource. What's collected is dynamic, and Microsoft may change it over time as new resource log categories become available. If you choose the audit category group, you can't specify any other resource categories, because the system will decide which logs to collect. For more information, see Diagnostic settings in Azure Monitor: Resource logs.

Destination limitations

For general destination limitations, see Destination limitations. The following limitations apply only to monitoring Azure Storage accounts.

• You can't send logs to the same storage account that you're monitoring with this setting. This situation would lead to recursive logs in which a log entry describes the writing of another log entry. You must create an account or use another existing account to store log information.

• You can't set a retention policy.

  If you archive logs to a storage account, you can manage the retention policy of a log container by defining a lifecycle management policy. To learn how, see Optimize costs by automatically managing the data lifecycle.

  If you send logs to Log Analytics, you can manage the data retention period of Log Analytics at the workspace level or even specify different retention settings by data type. To learn how, see Change the data retention period.

Azure activity log

The activity log contains subscription-level events that track operations for each Azure resource as seen from outside that resource; for example, creating a new resource or starting a virtual machine.

Collection: Activity log events are automatically generated and collected in a separate store for viewing in the Azure portal.

Routing: You can send activity log data to Azure Monitor Logs so you can analyze it alongside other log data. Other locations such as Azure Storage, Azure Event Hubs, and certain Microsoft monitoring partners are also available. For more information on how to route the activity log, see Overview of the Azure activity log.

Analyze monitoring data

There are many tools for analyzing monitoring data.

Azure Monitor tools

Azure Monitor supports the following basic tools:

• Metrics explorer, a tool in the Azure portal that allows you to view and analyze metrics for Azure resources. For more information, see Analyze metrics with Azure Monitor metrics explorer.

• Log Analytics, a tool in the Azure portal that allows you to query and analyze log data by using the Kusto query language (KQL). For more information, see Get started with log queries in Azure Monitor.

• The activity log, which has a user interface in the Azure portal for viewing and basic searches. To do more in-depth analysis, you have to route the data to Azure Monitor logs and run more complex queries in Log Analytics.

Tools that allow more complex visualization include:

• Dashboards that let you combine different kinds of data into a single pane in the Azure portal.
• Workbooks, customizable reports that you can create in the Azure portal. Workbooks can include text, metrics, and log queries.
• Grafana, an open platform tool that excels in operational dashboards. You can use Grafana to create dashboards that include data from multiple sources other than Azure Monitor.
• Power BI, a business analytics service that provides interactive visualizations across various data sources. You can configure Power BI to automatically import log data from Azure Monitor to take advantage of these visualizations.

Azure Monitor export tools

You can get data out of Azure Monitor into other tools by using the following methods:

• Metrics: Use the REST API for metrics to extract metric data from the Azure Monitor metrics database. The API supports filter expressions to refine the data retrieved. For more information, see Azure Monitor REST API reference.

• Logs: Use the REST API or the associated client libraries.

• Another option is the workspace data export.

To get started with the REST API for Azure Monitor, see Azure monitoring REST API walkthrough.

Analyze metrics for Azure Queue Storage

Metrics for Azure Queue Storage are in these namespaces:

• Microsoft.Storage/storageAccounts
• Microsoft.Storage/storageAccounts/queueServices

For a list of all Azure Monitor supported metrics, which includes Azure Queue Storage, see Azure Monitor supported metrics.

Azure portal

You can analyze metrics for Azure Storage with metrics from other Azure services by using Metrics Explorer. Open Metrics Explorer by choosing Metrics from the Azure Monitor menu. For details on using this tool, see Analyze metrics with Azure Monitor metrics explorer.

This example shows how to view Transactions at the account level.

For metrics that support dimensions, you can filter the metric with the desired dimension value. This example shows how to view Transactions at the account level on a specific operation by selecting values for the API Name dimension.

For a complete list of the dimensions that Azure Storage supports, see Metrics dimensions.

PowerShell

List the metric definition

You can list the metric definition of your storage account or the Queue Storage service. Use the Get-AzMetricDefinition cmdlet.

In this example, replace the <resource-ID> placeholder with the resource ID of the entire storage account or the resource ID of the queue. You can find these resource IDs on the Properties pages of your storage account in the Azure portal.

   $resourceId = "<resource-ID>"
   Get-AzMetricDefinition -ResourceId $resourceId

Read metric values

You can read account-level metric values of your storage account or the Queue Storage service. Use the Get-AzMetric cmdlet.

   $resourceId = "<resource-ID>"
   Get-AzMetric -ResourceId $resourceId -MetricNames "UsedCapacity" -TimeGrain 01:00:00

Read metric values with dimensions

When a metric supports dimensions, you can read metric values and filter them by using dimension values. Use the Get-AzMetric cmdlet.

$resourceId = "<resource-ID>"
$dimFilter = [String](New-AzMetricFilter -Dimension ApiName -Operator eq -Value "GetMessages" 3> $null)
Get-AzMetric -ResourceId $resourceId -MetricName Transactions -TimeGrain 01:00:00 -MetricFilter $dimFilter -AggregationType "Total"

Azure CLI

List the account-level metric definition

You can list the metric definition of your storage account or the Queue Storage service. Use the az monitor metrics list-definitions command.

In this example, replace the <resource-ID> placeholder with the resource ID of the entire storage account or the resource ID of the queue. You can find these resource IDs on the Properties pages of your storage account in the Azure portal.

   az monitor metrics list-definitions --resource <resource-ID>

Read account-level metric values

You can read the metric values of your storage account or the Queue Storage service. Use the az monitor metrics list command.

   az monitor metrics list --resource <resource-ID> --metric "UsedCapacity" --interval PT1H

Read metric values with dimensions

When a metric supports dimensions, you can read metric values and filter them by using dimension values. Use the az monitor metrics list command.

az monitor metrics list --resource <resource-ID> --metric "Transactions" --interval PT1H --filter "ApiName eq 'GetMessages' " --aggregation "Total" 

.NET

Azure Monitor provides the .NET SDK to read metric definition and values. The sample code shows how to use the SDK with different parameters. You need to use 0.18.0-preview or a later version for storage metrics.

In these examples, replace the <resource-ID> placeholder with the resource ID of the entire storage account or the queue. You can find these resource IDs on the Properties pages of your storage account in the Azure portal.

Replace the <subscription-ID> variable with the ID of your subscription. For guidance on how to obtain values for <tenant-ID>, <application-ID>, and <AccessKey>, see Use the portal to create a Microsoft Entra application and service principal that can access resources.

List the account-level metric definition

The following example shows how to list a metric definition at the account level:

    public static async Task ListStorageMetricDefinition()
    {
        var resourceId = "<resource-ID>";
        var subscriptionId = "<subscription-ID>";
        var tenantId = "<tenant-ID>";
        var applicationId = "<application-ID>";
        var accessKey = "<AccessKey>";

        MonitorManagementClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;
        IEnumerable<MetricDefinition> metricDefinitions = await readOnlyClient.MetricDefinitions.ListAsync(resourceUri: resourceId, cancellationToken: new CancellationToken());

        foreach (var metricDefinition in metricDefinitions)
        {
            // Enumrate metric definition:
            //    Id
            //    ResourceId
            //    Name
            //    Unit
            //    MetricAvailabilities
            //    PrimaryAggregationType
            //    Dimensions
            //    IsDimensionRequired
        }
    }

Read account-level metric values

The following example shows how to read UsedCapacity data at the account level:

    public static async Task ReadStorageMetricValue()
    {
        var resourceId = "<resource-ID>";
        var subscriptionId = "<subscription-ID>";
        var tenantId = "<tenant-ID>";
        var applicationId = "<application-ID>";
        var accessKey = "<AccessKey>";

        MonitorClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;

        Microsoft.Azure.Management.Monitor.Models.Response Response;

        string startDate = DateTime.Now.AddHours(-3).ToUniversalTime().ToString("o");
        string endDate = DateTime.Now.ToUniversalTime().ToString("o");
        string timeSpan = startDate + "/" + endDate;

        Response = await readOnlyClient.Metrics.ListAsync(
            resourceUri: resourceId,
            timespan: timeSpan,
            interval: System.TimeSpan.FromHours(1),
            metricnames: "UsedCapacity",

            aggregation: "Average",
            resultType: ResultType.Data,
            cancellationToken: CancellationToken.None);

        foreach (var metric in Response.Value)
        {
            // Enumrate metric value
            //    Id
            //    Name
            //    Type
            //    Unit
            //    Timeseries
            //        - Data
            //        - Metadatavalues
        }
    }

Read multidimensional metric values

For multidimensional metrics, you need to define metadata filters if you want to read metric data on specific dimension values.

The following example shows how to read metric data on the metric supporting multidimension:

    public static async Task ReadStorageMetricValueTest()
    {
        // Resource ID for queue storage
        var resourceId = "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{storageAccountName}/queueServices/default";
        var subscriptionId = "<subscription-ID}";
        // How to identify Tenant ID, Application ID and Access Key: https://azure.microsoft.com/documentation/articles/resource-group-create-service-principal-portal/
        var tenantId = "<tenant-ID>";
        var applicationId = "<application-ID>";
        var accessKey = "<AccessKey>";

        MonitorManagementClient readOnlyClient = AuthenticateWithReadOnlyClient(tenantId, applicationId, accessKey, subscriptionId).Result;

        Microsoft.Azure.Management.Monitor.Models.Response Response;

        string startDate = DateTime.Now.AddHours(-3).ToUniversalTime().ToString("o");
        string endDate = DateTime.Now.ToUniversalTime().ToString("o");
        string timeSpan = startDate + "/" + endDate;
        // It's applicable to define meta data filter when a metric support dimension
        // More conditions can be added with the 'or' and 'and' operators, example: BlobType eq 'BlockBlob' or BlobType eq 'PageBlob'
        ODataQuery<MetadataValue> odataFilterMetrics = new ODataQuery<MetadataValue>(
            string.Format("BlobType eq '{0}'", "BlockBlob"));

        Response = readOnlyClient.Metrics.List(
                        resourceUri: resourceId,
                        timespan: timeSpan,
                        interval: System.TimeSpan.FromHours(1),
                        metricnames: "BlobCapacity",
                        odataQuery: odataFilterMetrics,
                        aggregation: "Average",
                        resultType: ResultType.Data);

        foreach (var metric in Response.Value)
        {
            //Enumrate metric value
            //    Id
            //    Name
            //    Type
            //    Unit
            //    Timeseries
            //        - Data
            //        - Metadatavalues
        }
    }

Analyze logs for Azure Queue Storage

You can access resource logs either as a blob in a storage account, as event data, or through Log Analytics queries. For information about how to find those logs, see Azure resource logs.

To get the list of SMB and REST operations that are logged, see Storage logged operations and status messages.

Log entries are created only if there are requests made against the service endpoint. For example, if a storage account has activity in its queue endpoint but not in its table or blob endpoints, only logs that pertain to Queue Storage are created. Azure Storage logs contain detailed information about successful and failed requests to a storage service. This information can be used to monitor individual requests and to diagnose issues with a storage service. Requests are logged on a best-effort basis.

When you view a storage account in the Azure portal, the operations called by the portal are also logged. For this reason, you may see operations logged in a storage account even though you haven't written any data to the account.

Log authenticated requests

The following types of authenticated requests are logged:

• Successful requests
• Failed requests, including time-out, throttling, network, authorization, and other errors
• Requests that use a shared access signature (SAS) or OAuth, including failed and successful requests
• Requests to analytics data (classic log data in the $logs container and class metric data in the $metric tables)

Requests made by the Queue Storage service itself, such as log creation or deletion, aren't logged. For a full list of the logged data, see Storage logged operations and status messages and Storage log format.

Log anonymous requests

The following types of anonymous requests are logged:

• Successful requests
• Server errors
• Time out errors for both client and server
• Failed GET requests with the error code 304 (Not Modified)

Kusto queries

You can analyze monitoring data in the Azure Monitor Logs / Log Analytics store by using the Kusto query language (KQL).

Important

When you select Logs from the service's menu in the portal, Log Analytics opens with the query scope set to the current service. This scope means that log queries will only include data from that type of resource. If you want to run a query that includes data from other Azure services, select Logs from the Azure Monitor menu. See Log query scope and time range in Azure Monitor Log Analytics for details.

For a list of common queries for any service, see the Log Analytics queries interface.

Here are some queries that you can enter in the Log search bar to help you monitor your Queue Storage. These queries work with the new language. For more information, see Log Analytics tutorial.

• To list the 10 most common errors over the last three days.

  StorageQueueLogs
  | where TimeGenerated > ago(3d) and StatusText !contains "Success"
  | summarize count() by StatusText
  | top 10 by count_ desc
  

• To list the top 10 operations that caused the most errors over the last three days.

  StorageQueueLogs
  | where TimeGenerated > ago(3d) and StatusText !contains "Success"
  | summarize count() by OperationName
  | top 10 by count_ desc
  

• To list the top 10 operations with the longest end-to-end latency over the last three days.

  StorageQueueLogs
  | where TimeGenerated > ago(3d)
  | top 10 by DurationMs desc
  | project TimeGenerated, OperationName, DurationMs, ServerLatencyMs, ClientLatencyMs = DurationMs - ServerLatencyMs
  

• To list all operations that caused server-side throttling errors over the last three days.

  StorageQueueLogs
  | where TimeGenerated > ago(3d) and StatusText contains "ServerBusy"
  | project TimeGenerated, OperationName, StatusCode, StatusText
  

• To list all requests with anonymous access over the last three days.

  StorageBlobLogs
  | where TimeGenerated > ago(3d) and AuthenticationType == "Anonymous"
  | project TimeGenerated, OperationName, AuthenticationType, Uri
  

• To create a pie chart of operations used over the last three days.

  StorageQueueLogs
  | where TimeGenerated > ago(3d)
  | summarize count() by OperationName
  | sort by count_ desc
  | render piechart
  

Alerts

Azure Monitor alerts proactively notify you when specific conditions are found in your monitoring data. Alerts allow you to identify and address issues in your system before your customers notice them. For more information, see Azure Monitor alerts.

There are many sources of common alerts for Azure resources. For examples of common alerts for Azure resources, see Sample log alert queries. The Azure Monitor Baseline Alerts (AMBA) site provides a semi-automated method of implementing important platform metric alerts, dashboards, and guidelines. The site applies to a continually expanding subset of Azure services, including all services that are part of the Azure Landing Zone (ALZ).

The common alert schema standardizes the consumption of Azure Monitor alert notifications. For more information, see Common alert schema.

Types of alerts

You can alert on any metric or log data source in the Azure Monitor data platform. There are many different types of alerts depending on the services you're monitoring and the monitoring data you're collecting. Different types of alerts have various benefits and drawbacks. For more information, see Choose the right monitoring alert type.

The following list describes the types of Azure Monitor alerts you can create:

• Metric alerts evaluate resource metrics at regular intervals. Metrics can be platform metrics, custom metrics, logs from Azure Monitor converted to metrics, or Application Insights metrics. Metric alerts can also apply multiple conditions and dynamic thresholds.
• Log alerts allow users to use a Log Analytics query to evaluate resource logs at a predefined frequency.
• Activity log alerts trigger when a new activity log event occurs that matches defined conditions. Resource Health alerts and Service Health alerts are activity log alerts that report on your service and resource health.

Some Azure services also support smart detection alerts, Prometheus alerts, or recommended alert rules.

For some services, you can monitor at scale by applying the same metric alert rule to multiple resources of the same type that exist in the same Azure region. Individual notifications are sent for each monitored resource. For supported Azure services and clouds, see Monitor multiple resources with one alert rule.

Azure Queue Storage alert rules

The following table lists common and recommended alert rules for Azure Queue Storage and the proper metric to use for the alert:

Alert type	Condition	Description
Metric	Queue Storage service is throttled.	Transactions Dimension name: Response type
Metric	Queue Storage requests are successful 99% of the time.	Availability Dimension names: Geo type, API name, Authentication
Metric	Queue Storage egress has exceeded 500 GiB in one day.	Egress Dimension names: Geo type, API name, Authentication

Advisor recommendations

For some services, if critical conditions or imminent changes occur during resource operations, an alert displays on the service Overview page in the portal. You can find more information and recommended fixes for the alert in Advisor recommendations under Monitoring in the left menu. During normal operations, no advisor recommendations display.

For more information on Azure Advisor, see Azure Advisor overview.

Related content

Other Queue Storage monitoring content:

• Azure Queue Storage monitoring data reference. A reference of the logs and metrics created by Azure Queue Storage.
• Performance and scalability checklist for Queue Storage

Overall Azure Storage monitoring content:

• Monitor storage with Azure Monitor Storage insights. Get a unified view of storage performance, capacity, and availability.
• Transition to metrics in Azure Monitor. Move from Storage Analytics metrics to metrics in Azure Monitor.
• Troubleshoot performance issues. See common performance issues and guidance about how to troubleshoot them.
• Troubleshoot availability issues. See common availability issues and guidance about how to troubleshoot them.
• Troubleshoot client application errors. See common issues with connecting clients and how to troubleshoot them.
• Monitor, diagnose, and troubleshoot your Azure Storage (training module). Troubleshoot storage account issues, with step-by-step guidance.

Azure Monitor content:

• Monitor Azure resources with Azure Monitor. General details on monitoring Azure resources.
• Azure Monitor Metrics overview. The basics of metrics and metric dimensions.
• Azure Monitor Logs overview. The basics of logs and how to collect and analyze them.
• Analyze metrics with Azure Monitor metrics explorer. A tour of Metrics Explorer.
• Overview of Log Analytics in Azure Monitor. A tour of Log Analytics.