ClientOtherError - Failing transactions by API name - File Create

Question

I know that:

ClientOtherError :

Authorized request that failed as expected. This error can represent many 300-400 level HTTP status codes and conditions such as NotFound and ResourceAlreadyExists.

I we have high percentage of ClientOtherError (Failing transactions by API name, File, Create and Failing transactions by Response type, File, ClientOtherError) with our Azure blob storage.

I want to know which filename are invloved on this ClientOtherError and also the date of ClientOtherError.

Thank you.

Answer 1

Hi Ciprian Rizea, Welcome to Microsoft Q&A. Thank you for posting your query here!

We have below information available in other Q&A threads for similar issue. I am consolidating and posting it here again for your reference in case you have not gone through it already:

The "ClientOtherError" is a relatively generic error message that could indicate various issues occurring at the client-side when interacting with Azure Files Storage. This error message might not provide specific details about the underlying problem.

To troubleshoot this error:

• Check if there's any client-side network connectivity issue that might be causing intermittent disruptions.
• Ensure that you're using the correct authentication credentials when accessing the Azure Files Storage.
• Monitor the Azure portal for any associated alerts, status changes, or resource health issues related to your storage account.
• Review the client application logs or event logs for more specific error details.

The status of the requested operation. For a complete list of status messages, see Storage Analytics Logged Operations and Status Messages topic. In version 2017-04-17 and later, the status message ClientOtherError isn't used. Instead, this field contains an error code. For example: SASSuccess

For details on which errors can be shown in the report, see Response Type schema and look for response types such as ServerOtherError, ClientOtherError, ClientThrottlingError. Depending on the storage accounts selected, if there are more than three types of errors reported, all other errors are represented under the category of Other.

This type of error occurs when the client does too many requests against the same partition server. When such happens and the partition server gets overloaded, it does internal load balancing operations as part of the normal azure storage healing process.

When the partition being accessed suffers a load balancing operation (reassigning partitions to less loaded servers), the storage service returns 500 or 503 errors.

The limits I previously mentioned (the 800 reads for 5 minutes) are indeed for management operations and not for data ones. In your case, the GetBlob ones are data operations and are not covered by these hard limits. After analyzing the ingress/egress limit and also the transactions per second of your storage account, I verified that you also seem to be far away from hitting the threshold.

Just for the record and improved searchability: In Metrics these errors showed up as ClientOtherError and ClientThrottlingError.

Additional information : Metrics show low PercentSuccess or analytics log entries have operations with transaction status of ClientOtherErrors

The PercentSuccess metric captures the percent of operations that were successful based on their HTTP Status Code. Operations with status codes of 2XX count as successful, whereas operations with status codes in 3XX, 4XX and 5XX ranges are counted as unsuccessful and lower the PercentSuccess metric value. In the server-side storage log files, these operations are recorded with a transaction status of ClientOtherErrors.

It is important to note that these operations have completed successfully and therefore do not 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 does not 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.

Also, To get all the information that are logged you can open the logs in Log Analytics Workspace as shown in the diagram below and run the KQL query.

KQL Query:

Copy

StorageFileLogs  
| where Protocol == "SMB" and TimeGenerated >= ago(7d) and StatusCode contains "-"  
| sort by StatusCode  

Reference:
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-monitoring?tabs=azure-portal#sample-kusto-queries
https://learn.microsoft.com/en-us/azure/storage/files/storage-files-monitoring-reference#fields-that-describe-the-service

https://learn.microsoft.com/en-us/answers/questions/863990/azure-files-failing-transactions

Hope this is helpful!

Kindly let us know if the above helps or you need further assistance on this issue.

Please don't forget to upvote and Accept it as answer.

-Ekta