Best practices for Azure Monitoring and ARM Throttling
Article ID: 440868
Updated On:
Products
Issue/Introduction
Symptoms
You observe that Azure Agent metrics report incorrectly or show gaps. In the agent logs, you see HTTP 400 and 429 errors, indicating that requests fail or are rate-limited.
Environment
- DX Application Performance Management (DX APM) Azure Monitoring Extension
- DX Operational Observability (DX O2)
Cause
These errors typically occur due to Azure Resource Manager (ARM) subscription-level read throttling. Azure enforces limits on the number of read requests using a token-bucket mechanism. These limits apply per subscription, per service principal, and per operation type. When you use a single service principal across multiple subscriptions or high-volume environments, you may exceed the available quota, leading to data gaps.
Resolution
To reduce throttling behavior and improve monitoring reliability, you should follow these best practices:
- Use a dedicated service principal per subscription: Assign a separate identity to each subscription instead of sharing one across your entire Azure estate. This reduces contention on a single identity and aligns with Azure RBAC best practices for narrow scoping.
- Split monitoring for high-volume subscriptions: If a single subscription has exceptionally high monitoring demand, you can distribute the workload across multiple service principals to increase the aggregate read quota for that specific subscription.
- Upgrade to the latest version: Ensure you are running the latest version of the Azure extension (e.g., version 26.4.1 or higher), as newer versions often include optimizations for API communication.
- Targeted Fix: A permanent fix for specific parsing errors and reporting issues is targeted to be fixed in release DXO2_SaaS_26.5.1. You should also check with SE teams for any specific exceptions or further guidance.
Fixed in release DXO2_SaaS_26.5.1 and higher. See for steps to download this release.
Feedback
