Storage Performance Needs Investigation? Review Metrics, Logs, and Failures

A storage problem can be a slow successful request, a wrong path, or a service-side failure. Metrics reveal the pattern over time; request logs identify the operation and response behind that pattern.

Reuse stctmonitorweu, monitor-demo, and law-ctmonitorweu from Configure Log Analytics. The Blob diagnostic setting must still collect StorageRead, StorageWrite, and StorageDelete. Use your actual globally unique account name throughout.

Compare the Metrics

Upload monitor-check.txt to monitor-demo if needed and download it several times. Open Storage account → Monitoring → Metrics, select the Blob namespace/service scope, and use Last hour with one-minute granularity.

Compare these metrics in separate charts where their units differ:

Metric	Aggregation	What to investigate
Transactions	Sum	Request volume; split by API name or Response type.
Availability	Average	The service’s successful/available request classification over the interval.
Success E2E Latency	Average	Service-observed duration of successful requests, including transfer-related waiting.
Success Server Latency	Average	Time spent processing successful requests inside the storage service.

Filter latency charts to the same API, such as GetBlob, before comparing them. A gap between the latency metrics suggests time outside the service’s internal processing. Combine it with application/network evidence; it is not a full browser response-time measurement. A small lab file may produce very low, almost flat latency.

Screenshot 1: Blob metrics showing recent transactions and the two latency measurements for the same time range/API.

Create a Recognizable Failure

Open Azure Cloud Shell → Bash. This lab uses the account-key access already enabled in the storage Trip. Your lab Owner/Contributor account can let the CLI retrieve the key automatically; you do not need to copy it.

az account set --subscription 'CloudTrips TEST'
az storage blob download \
  --account-name stctmonitorweu \
  --container-name monitor-demo \
  --name cloudtrips-deliberately-missing.txt \
  --file /tmp/cloudtrips-deliberately-missing.txt \
  --auth-mode key

Leave that blob absent. Expect BlobNotFound / HTTP 404. Note the UTC time. If you receive a permission or network error instead, resolve that first. For an account using Entra-only access, use --auth-mode login with Storage Blob Data Reader assigned to your user and allow role propagation.

Find the Request Behind the Error

After ingestion, open law-ctmonitorweu → Logs, use Last hour, and run:

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where AccountName == "stctmonitorweu"
| where toint(StatusCode) >= 400
| project TimeGenerated, OperationName, StatusCode, StatusText,
          DurationMs, AuthenticationType, Uri
| order by TimeGenerated desc

Find the row for cloudtrips-deliberately-missing.txt. The CLI may first request the blob’s properties; the recorded operation can therefore be GetBlobProperties rather than GetBlob. The URI, time, and status connect this row to your test.

Screenshot 2: Failed-request query showing the missing blob and its 404 status.

Return to Transactions, remove any GetBlob-only filter, and split by Response type. Client errors can appear while service Availability remains high: a missing blob is a valid service response, and that metric’s availability classification differs from your application’s expectation of success.

Use this summary to compare outcomes:

StorageBlobLogs
| where TimeGenerated > ago(1h)
| where AccountName == "stctmonitorweu"
| summarize Requests=count(), AverageMs=avg(DurationMs), P95Ms=percentile(DurationMs, 95)
    by OperationName, StatusCode
| order by Requests desc

P95 is the duration at or below which approximately 95% of those requests fall. Compare like operations and status codes; with only a few samples, a percentile says little about normal behavior. Investigate 403 using authentication and authorization, 404 using the requested path, and 5xx using service health and retry evidence.

Finish

Keep the account and workspace while other monitoring Trips depend on them. If this ends your storage lab, remove its diagnostic setting and test alert rules, then delete the account when its data is no longer needed. Log ingestion continues while diagnostics remain enabled and requests occur.