On October 23, the ACR team published a technical deep-dive into the sharded metrics infrastructure behind Azure Container Registry’s new Transactions and Data Transfer metrics. These metrics went GA earlier this year, but the deep-dive explains the operational value — diagnosing traffic spikes, throttling, and regional workload shifts — and the engineering approach that made it possible.

What the new metrics are

ACR now publishes two platform metrics in Azure Monitor:

Transactions — a count of registry API operations, segmented by:

  • ApiName — the operation type: manifest, tag, blob, referrer, catalog, token
  • ResponseType — Success, Redirect, ClientErrorUnauthorized, ClientErrorNotFound, Throttled, etc.
  • Region — the geo-replication that served the request

Data Transfer — total outbound bytes in bytes when ACR serves content (blob downloads, manifest downloads, geo-replication, etc.), segmented by ApiName and Region.

Both are sampled at 1-minute intervals (PT1M) and exportable to Azure Monitor Logs. They replace the old pull/push counts with granular, diagnostic telemetry.

Why these metrics matter

Before these metrics, push and pull counts were all you had. They told you that activity changed, but not why. The new metrics explain it.

Consider a sudden jump in pulls. With pull counts you see a spike and have no idea what drove it. With Transactions you can split by ResponseType and discover the extra requests are blob downloads in one geo-replication region, many of them Throttled. Data Transfer from that same region stays flat — no larger images, just more requests.

Other scenarios the metrics help diagnose:

  • Deployment spikes — high blob and manifest reads
  • Metadata polling — high tag and listing call volume
  • Retry loops — spike in Throttled or ClientErrorUnauthorized responses
  • Regional workload shifts — traffic moving between geo-replicas
  • Larger image layers — Data Transfer rising while Transactions stays flat

The sharded infrastructure

A single sampled registry can exceed 100,000 transactions and hundreds of gigabytes of data transferred (egress) in one hour. All those data points land in internal metrics accounts, and each account has a finite budget.

The ACR team’s solution: shard the metrics across multiple internal metrics accounts.

Each registry’s metrics land on one shard. Different registries are spread across shards. Customers still query one registry in the portal — they never see or choose where that information is coming from.

Geo-replication adds complexity. A geo-replicated registry is served from many regions, and a single request can pass through more than one component (API answerer, blob server, webhook handler). Each step is counted once by the component that handled it. Failed requests count as Transactions but not as Data Transfer, because no bytes were delivered. Every emitting component uses the same ApiName and ResponseType vocabulary, and the ACR team verifies that each counted request produces exactly one data point.

The result is one view of each registry, across every region and component, with accurate counts and no exhausted capacity.

How to use them

A typical investigation workflow:

  1. Open Azure Monitor for your registry and select the Transactions metric.
  2. Split by ResponseType to see successes, redirects, throttling, and errors.
  3. Switch the split to Region to identify which geo-replication is driving changes.
  4. Select New alert rule from the same chart — for example, filter to Throttled and alert when the total over 5 minutes exceeds a threshold.

For egress analysis, chart Data Transfer over time and split by Region to see which geo-replication serves the most data.

Split by ApiName to distinguish deployment-driven traffic (blob/manifest reads) from metadata polling (tag/call listings).

The metrics are standard (non-advanced) platform metrics in Azure Monitor — available in the same location as pull/push counts, without needing the paid advanced platform metrics tier.

What’s next

The sharded metrics path is designed so future metrics can onboard onto the same infrastructure without redesign. The ACR team explicitly positions this as forward-looking: as customer workloads grow and new metrics are added, the sharding model scales with them.

Sources