Azure Functions 中令人费解的存储事务

Question

我有一个项目，其中有几个按计划运行的基于 .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 提供的记录器进行恒定数量的日志写入（例如 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 的错误。有没有人经历过这个或知道如何解决它？

Answer 1

经过几周的调查，Azure 支持团队和我认为我们已经找到了导致该问题的行，这就是：

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

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

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

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