Azure Functions 事件中心读写延迟峰值与 StorageException 和 SocketException 峰值

Question

我们有一项生产中的服务受到延迟峰值的影响。 在这些峰值期间，我们看到我们收到了大量的 StorageExceptions 和 SocketExceptions

这些图像超过 4 小时。

更重要的是，这仅发生在我们的 EUS 服务实例（大约有 26 个事件中心触发器）上，而不发生在我们的 WEU（7 个事件中心触发器）和 Canary（EUS2 - 2 个事件中心触发器）上。

我们看到的存储帐户异常的最内部错误是：指定了租用 ID，但 blob 的租用已过期。 众所周知，少量是可以的 - 但 4 小时内 24.5K 感觉不是小量，异常尖峰和延迟尖峰之间存在直接相关性

套接字最内部的异常是： 试图以访问权限禁止的方式访问套接字。 它还与延迟峰值很好地相关。

另一方面，在整个 4 小时的时间段内，可以看到事件流经服务并流向接收事件中心：

所有传出事件都写入每个云中的同一个事件中心（总共 3 个 - 1 个 EUS、1EUS2、1WEU），每个云相应地写入自己的 eventhub。 似乎整个延迟峰值是由于对 eventhub 的写入操作（通过 eventhub 名称 + FQDN AAD 连接完成）：

对这个问题的任何帮助将不胜感激！

Answer 1

我们解决了这个问题——Azure 函数是在消费计划中设置的——这样设置，所以只有一个实例可用。 要增加到不止一个实例，我需要将计划从消费更改为保费。

除此之外，我发现该函数在启动时会为所有触发器创建与所有 Eventhub 的连接 - 在本例中为 26 个 Eventthub。 每个 Eventhub 有 32 个分区，因此每个 Eventhub 有 32 个连接。

消费计划中的 Azure 函数具有 600 个连接的硬限制。

这意味着一旦建立连接，它最终将达到其 600 限制，进入不健康状态并重新启动自身，这反过来又由于启动和处理来自集线器的积压事件而造成延迟峰值。

从消耗升级到高级允许更高的连接限制并添加一个额外的实例（将运行的最小实例从 1 增加到 2），将实例之间打开的连接分开，因此我们没有达到下限。

希望这可以帮助其他人坚持这一点。