Azure Monitor: what am i actually monitoring when it comes to Storage Account?

Hello TZ, Thank you for posting your query on Microsoft Q&A platform.

Success Server Latency and Success E2E Latency measure the latency of successful requests handled by the Azure Storage service. These metrics are request-centric rather than workload-centric, meaning they track service operations rather than application-level file activity. When Azure Files is accessed via SMB, file reads and writes are internally translated into multiple storage service operations, so they do not map 1:1 to the REST API operation names displayed in these metrics.

Additionally, Azure Storage performs internal service and metadata operations (such as Get*ServiceProperties) which can appear frequently in metrics even if the application does not explicitly use those storage services. As a result, these latency metrics do not directly correlate with spikes in file upload or download activity.

Azure Monitor latency metrics track storage service request latency, not raw SMB protocol operations.

When Azure Files is accessed via SMB, file I/O is handled through the SMB protocol and internally translated by the Azure Files service into multiple storage operations. These internal operations are aggregated and not exposed individually in Azure Monitor metrics.

The Microsoft.Storage/storageAccounts metrics namespace reports account-level service activity, which includes operations across Blob, File, Queue, and Table services. This also includes internal service checks and metadata queries, such as Get*ServiceProperties.

These small, frequent internal operations often dominate the operation counts used in latency metrics, even during heavy file transfers.

As a result, large file uploads typically appear as:

• Ingress/Egress spikes (data transfer)
• Used Capacity growth (stored data)
• Relatively unchanged latency operation mix (expected behavior).

For an SMB-heavy Azure Files workload, Azure Monitor metrics should be interpreted as follows.

Use latency metrics primarily as service health indicators:

• Success Server Latency (Average)
• Success E2E Latency (Average)

Compare the two metrics:

• E2E latency significantly higher than Server latency > network or client-side overhead (network path, SMB protocol processing, client workload).
• Server latency elevated and close to E2E latency > possible storage service processing delays.

These metrics indicate overall request latency, not file I/O throughput.

Use the following metrics to understand workload behavior:

• Ingress / Egress (bytes) > actual data movement
• Transactions > overall storage request volume (not specific operation types)
• Used Capacity > storage growth and upload patterns
• Availability > request success rate

Complement Azure metrics with client-side and AKS telemetry, which is essential for diagnosing SMB performance:

• Pod-level I/O wait and filesystem latency
• Node network throughput and retransmits
• SMB client metrics from the container/node OS

Reference docs:

• Azure Storage metrics in Azure Monitor (all metrics + dimensions)

• Supported metrics for Files service

Thanks,

I think the core is… those latency charts never touch SMB at all, only the acct’s ctrl‑plane hops. if it’s still unclear just check Ingress/Egress once — it’s the only layer that shows the real file flow.