Troubleshooting ClientOtherErrors on Azure Storage Account
The blog is inclined towards troubleshooting clientothererrors reflecting in the metrics. It is a step-by-step process to understand what these errors signify and potential reasons. This will also help in analyzing if these are legitimate ones and also deciding on the action plan ahead.
ClientOtherError usually means expected client-side errors which are not fatal errors. These operations have been completed successfully and therefore don't affect other metrics, such as availability. Some examples of operations that execute successfully but that can result in unsuccessful HTTP status codes include:
- ResourceNotFound (Not Found 404), for example, from a GET request to a blob that doesn't exist.
- ResourceAlreadyExists (Conflict 409), for example, from a CreateIfNotExist operation where the resource already exists.
- ConditionNotMet (Not Modified 304), for example, from a conditional operation such as when a client sends an ETag value and an HTTP If-None-Match header to request an image only if it has been updated since the last operation.
Below are some of the common reasons for some of status code and resulting into clientothererrors
The client is receiving HTTP 404 (Not found) messages:
If the client receives an HTTP 404 (Not found) message from the server, this implies that the object the client was attempting to use (such as an entity, table, blob, container, or queue) doesn't exist in the storage service. Below are some of the possible reasons:
- The object being requested doesn’t exist. The object might not haven’t been created itself or the client or another process previously deleted the object.
- A head operation for GetBlobProperties prior to PutBlob initially checks whether a blob exist or not. This can also result in 404 and is then followed by actual request to create the blob.
The client receives HTTP 409 (Conflict) messages:
Mostly in the client applications, while creating a blob container, queue, table if make use CreateIfNotExists method. If the object being created already exists, it will eventually fail with the HTTP 409 (Conflict) error.
Another example is that of blob getting created and prior to that a check is done to see whether the container in which blog is being created exist or not. If the container doesn’t exist and we don’t check that, the call to create the blob will tend to fail. So having a sanity check prior is also helpful.
Now, let us look at how to analyze them ahead:
Step 1: Identifying ClientOtherErrors
You will mainly notice ClientOtherErrors in the Insights section of Monitoring under the failures tab.
Alternatively, if you split the transactions based on the response type, you can filter these explicitly for the clientothererrors.
Step 2: Enabling Logging configuration
The above 2 options only provide a high-level detail of the number of errors happening or the timelines when the error occurred. This, however, doesn’t provide more robust details as to what the operation was and the exact error resulting in the clientothererrors. For that, we can start by enabling the diagnostic logging on the account.
Monitoring Azure Blob Storage - Azure Storage | Microsoft Learn
Step 3: Running Kusto Queries
For the demo, we have created a diagnostic setting to move the logs to log analytical workspace. After enabling the same, we can make use of Kusto queries to narrow down the transactions. Below are 2 sample queries that can be used:
In the below example, we got multiple operations that weren’t successful.
OR
The first one shall provide only the transactions that fail with response type of ClientOtherErrors specifically while the other one provides all the transactions other than the successful ones which will include authentication errors, clientothererrors, server-side errors etc.
We can check the 404 and 409 errors are shown below:
Step 4: Exporting the Logs
We can export this set of logs to CSV for further assessment.
Step 5: Analyzing the Logs
In the MetricResponsetype column we will filter out specifically clientothererrors. In case we make use of 1st query then additional filtering isn’t required since we will only have the transactions failing with ClientOtherErrors.
We could then check the operation and along with the statuscode and statustext field to understand the exact reason for the error.
You can make use of above steps to analyze the clientothererrors from your side. In case you have validated the above steps but observe something odd or if there is any further understanding required you can reach out to Microsoft support ahead.
Hope this helps!
Reference Link:
Status and error codes (REST API) - Azure Storage | Microsoft Docs
Troubleshoot client application errors in Azure Storage accounts | Microsoft Docs
Published on:
Learn moreRelated posts
Coding at the Speed of Innovation: AI and more with Azure SQL Database
As Build 2024 approaches, the Azure SQL Database team is preparing a great line-up of product announcements. Innovation continues to be a big ...
Azure Custom Policy- PostgreSQL Product - Compliance Report not Available- New Feature Request
If you try to create custom policy to add diagnostic settings for Azure Cosmos DB for PostgreSQL Cluster for log analytics and assign policy a...
Microsoft Causes Fuss Around Azure MFA Announcement
On May 14, Microsoft announced that they will require Azure MFA for connections to services starting in July 2024. No details about the implem...
PostgreSQL for your AI app's backend | Azure Database for PostgreSQL Flexible Server
Use Postgres as a managed service on Azure. As you build generative AI apps, explore advantages of Azure Database for Postgres Flexible Server...
Storage migration: Combine Azure Storage Mover and Azure Data Box
Migrating storage from on-premises can be challenging. That’s why we are on a mission to make your migrations as simple as possible. We've dev...
Loop DDoS Attacks: Understanding the Threat and Azure's Defense
In the realm of cybersecurity, Distributed Denial-of-Service (DDoS) attacks are a significant concern. The recent holiday season has unveiled ...
Azure Communication Services at Microsoft Build 2024
Join us in-person in Seattle or virtually for Microsoft Build 2024 from May 21 to 24. We're excited to share the latest updates from Azure Com...
Azure Developer CLI (azd) – May 2024 Release
This post announces the May release of the Azure Developer CLI (`azd`), which includes a new demo mode, various .NET Aspire enhancements, and ...
Join us at Build 2024: Get the latest on Azure Cosmos DB in Seattle or online!
Are you ready to dive into the future of AI and data innovation? Microsoft Build 2024 is just around the corner, taking place May 21–23 in Sea...