来自 Azure Functions 的莫名其妙的存储事务

Posted 2023-02-19

【中文标题】来自 Azure Functions 的莫名其妙的存储事务

【英文标题】：Inexplicable storage transactions from Azure Functions

【发布时间】：2020-05-23 15:09:43

【问题描述】：

我有一个项目，其中包含几个按计划运行的基于 .NET Core 的 Azure Functions。其中一个每 10 分钟运行一次，用于更新视图计数，类似于 SO 跟踪问题视图的方式，另一个每周发送一次电子邮件。这些功能在一年左右的时间内运行良好。我最近更新了它们以使用 Azure Functions SDK v3 和 Azure Functions 运行时 v3 以及 .NET Core 3.1（基本上从 .NET Core 2.1 迁移到 .NET Core 3.1，所以我需要更新函数运行时）。

有一次我收到了比平时高得多的账单。事实证明，共享相同底层存储帐户的函数开始对存储进行大量 API 事务。就像每 5 分钟有数千个。通常每次运行都会生成大约 100 个存储事务（可能是检索函数文件？），但在某些时候事务会急剧增加。重新启动函数后，事务恢复正常，几天内一切正常，然后它们再次跳跃并保持高位，直到重新启动。

函数代码没有随着升级而改变，只是 SDK 和运行时。该函数代码通过 SDK 提供的 logger 具有恒定数量的日志写入（如 7 次），并且不以任何其他方式与存储交互。

我有两个相同的环境，一个用于测试，一个用于生产，两者都有相同的问题。该功能失控所需的时间间隔是几天，但每次似乎都不同。但是，如果我同时重新启动测试和生产，下一个峰值同时在两个环境中发生，所以那里有一些确定性。

根据我通过 Metrics 工具进行的调查，有问题的交易类型是 Create、Close 和 ChangeNotify 以及一些 Cancel（但少于其他交易类型）。该存储不用于其他任何用途（实际上它存在只是因为 Azure Functions 需要后备存储来存储其文件或其他东西）

这是相关的触发代码

[FunctionName("ViewCountUpdater")]
public static async Task RunAsync([TimerTrigger("0 */10 * * * *"/*, RunOnStartup = true*/)]TimerInfo timer, ILogger log, ExecutionContext context)

我相信我遇到了 Azure Functions 运行时或 Azure Functions .NET Core SDK 的错误。有没有人遇到过这种情况或知道如何解决它？

【问题讨论】：

您是否在 Azure 支持上开过工单？他们应该能够进行调查，如果是错误，请退款

是的。我已经在 Azure 支持的电子邮件线程中待了好几个星期，但没有任何解决办法。至少有两个人调查了问题，并在确认问题发生后将其发送给其他人。根据电子邮件，我的问题现在已转移到“产品组”，但电子邮件线程中没有新人。我正在考虑在 Azure Functions SDK GitHub 中打开一个问题，但我决定先尝试 SO。

绝对看起来像一个错误。将带有此问题链接的推文发送给 @AzureSupport 和 @jeffhollan，Microsoft Azure Functions 的首席 PM Mgr

@CSharpRocks 我再给它几天时间，我不想跳过 Azure 支持人员，他们一直非常好，而且似乎正在尽力而为。此外，我估计有 10% 的可能性是我做错了什么。我发布这篇文章的主要原因是，如果其他人遇到了这个错误，他们可以在 Google 上找到结果并确认它确实是一个错误。

【参考方案1】：

您是否启用了AzureWebJobsDashboard？如果是，您应该禁用它（从应用程序设置中删除连接字符串）并切换到应用程序洞察力。已知此设置会导致无法正确解释的对存储的意外写入。

https://github.com/Azure/Azure-Functions/issues/832

【讨论】：

连接字符串下没有存储连接字符串。我在设置中有一个 AzureWebJobsStorage 键，但我认为这是函数的默认值（我没有在我的代码中使用它）。

我通读了 GitHub cmets。看起来可疑的相似。我想知道 Azure Functions 是否有可能以某种方式具有隐式仪表板。

是的，即使您没有在代码中明确使用该设置，也必须删除该设置

是的，但我没有 AzureWebJobsDashboard 设置我只有 AzureWebJobsStorage

啊，对不起。我相信存储很好

【参考方案2】：

经过数周的 Azure 支持团队调查，我认为我们已经找到了导致问题的原因，就是这样：

.AddJsonFile("local.settings.json", optional: true, reloadOnChange: true)

配置文件未作为发布过程的一部分发布，并且不存在于 Azure 中。现在的实验似乎证实，当这种情况出现时，交易会激增，而当不出现时，它们是正常的。这不回答

为什么会出现这个错误 是 .NET Core 还是函数运行时的回归？ 为什么该错误是随机发生的，而不是每次运行时发生的？

请注意，测试这需要时间，因为我必须等待数天才能看到随机峰值，而且我永远无法确定它是否会永远消失，所以我不能 100% 确定未来某个时间峰值不会再次发生，结果证明问题出在其他地方。