Azure 文件存储：ClientOtherError 计数较高

Question

刚刚注意到我在 Azure 中的文件共享存储出现“ClientOtherError”的几率非常高。他们的成功率在 50-100% 之间。

任何人有任何经验可以解释为什么会这样吗？

附图以红色/橙色显示 ClientOtherError 交易，以蓝色显示成功交易。

Answer 1

这是我的错误率比较（Win FS 也由 AKS 集群使用）

我进行了大量的覆盖，也许这会导致错误数量。

Answer 2

客户端其他错误：

授权请求按预期失败。这个错误可以代表 许多 300-400 级别的 HTTP 状态代码和条件，例如 NotFound 和资源已经存在。

我们在 Azure Blob 存储中遇到了非常高比例的 ClientOtherError（响应类型导致的事务失败）。然而，在我们的例子中，这个错误可以被忽略。发生这种情况是因为正在对不存在的文件执行操作。它们基本上是成功的 API 调用，返回非 200 HTTP 状态代码。在我们的场景中，按 API 名称显示的失败事务显示以下项目。

• 删除文件
• 获取Blob属性
• 获取文件属性

blob 存储示例 1：

blob 存储示例 2：

ClientOtherError 通常表示预期的错误，例如未找到、资源已存在。如果您的代码使用 Exists、Create***IfNotExist（例如 CreateTableIfNotExist）等 API，则会经常遇到这些错误。成功执行但可能导致不成功的 HTTP 状态代码的一些操作示例包括：

• ResourceNotFound（未找到 404），例如从 GET 请求到不存在的 blob。
• ResourceAlreadyExists（冲突 409），例如来自资源已存在的 CreateIfNotExist 操作。
• ConditionNotMet（未修改 304），例如来自条件操作，例如当客户端发送 ETag 值和 HTTP If-None-Match 标头来请求图像（仅当图像自上次操作以来已更新时）。

为了进一步调试，您可以使用 Azure 存储日志记录，它将记录有关针对您的存储帐户执行的每个操作的信息。它将包含每个响应的 HTTP 代码。

这里是常见状态代码的列表。许多（不是全部）300-400 级别的 HTTP 状态代码将导致 ClientOtherError。

---

OP 似乎在 Azure 文件共享方面面临这个问题。我怀疑类似的事情正在发生。 Windows Storage Explorer 应用程序可能会执行类似的 API 调用，从而导致 ClientOtherError。 这里的文件共享似乎有类似的API，当文件丢失时可能会导致ClientOtherError。

我想说，在大多数情况下，此错误是预期的并且可以忽略。