监控 Amazon EventBridge 规则

欢迎来到雲闪世界。亚马逊网络服务 (AWS)于 2019 年 7 月推出了 EventBridge ，它源自CloudWatch Events：一种面向事件驱动架构的无服务器产品，目前包含以下几个组件：

• 通过规则的巴士（代理）将消费者与事件生产者整合在一起。

• 计划完全管理一次性或重复性任务的调用。

• 管道提供生产者和消费者之间的管理集成。

网上有大量资料解释 EventBridge 的工作原理。产品文档是一个很有价值的起点。在这篇文章中，我们将专门深入探讨 EventBridge 规则的监控。

添加图片注释，不超过 140 字（可选）

我们将首先概述指标的工作原理，然后探索当前的规则指标产品并确定其局限性。在介绍了广泛的规则指标之后，我们将提出可以为客户提供附加值的改进建议。

规则指标的工作原理

与其他 AWS 服务一致，EventBridge 规则提供CloudWatch 指标来观察性能。某些指标可能按一个或多个维度细分，以查看特定资源的行为。规则提供三个维度：

• EventBusName：规则的源事件总线的名称。

• EventSourceName：事件源的名称（仅限合作伙伴规则）。

• RuleName：规则的名称。

对于记录的每个指标，其支持的维度都列在“EventBridge 指标”表的“维度”下。但是，在撰写本文时，此表与第一手经验不一致，因此值得亲自尝试使用 CloudWatch 来了解每个指标可用的维度。以FailedInvocations（我们将在后面介绍）为例：RuleName在撰写本文时，仅记录了维度以及默认值，如Region和Namespace，但在下面的屏幕截图中，我们还看到EventBusName左侧设置为my-event-bus。

添加图片注释，不超过 140 字（可选）

观察交通量

有几个关于流量的指标值得分享：

• MatchedEvents：符合规则过滤条件的事件数量。

• TriggeredRules：匹配事件触发的规则数量。

• ThrottledRules：规则被限制的频率，从而延迟调用。

MatchedEvents和TriggeredRules在许多用例中可以互换使用。如果我们想要监控 AWS 账户中所有或特定规则的流量，则两者都适用。异常值ThrottledRules表明规则调用的账户范围限制已被打破。此限制可在“每秒事务调用限制”下调整。

当匹配事件触发规则时，它应该调用目标消费者。上述指标均未涵盖目标调用。这引发了接下来值得探讨的几个问题：

• 规则如何处理调用失败？

• 哪些指标允许我们追踪调用失败？

• 我们如何观察成功的调用？

处理失败的调用

在某些情况下，当规则无法调用目标时，可以重试调用。例如，由于网络问题导致的失败将重试，而权限不足的错误将不会重试。

如果需要重试，规则将遵循其目标消费者重试策略。重试次数和间隔分别最多为 185 次和 24 小时。但是，并非所有目标都提供可配置的重试策略。例如，EventBridge Event Bus 目标的重试策略不可调整。

添加图片注释，不超过 140 字（可选）

监控调用失败

当规则无法调用目标（包括重试）时，我们说它永久无法传递事件。要审查这些情况，我们可以利用上述指标FailedInvocations。这仅显示永久失败，而不考虑需要重试的失败。

重试失败更难观察。2023 年 11 月，EventBridge 引入了几个新指标，包括RetryInvocationAttempts，从表面上看，它完全满足了我们的需求：“重试目标调用的次数”。但是，它不支持维度，因此我们无法查看每个总线或规则的重试次数——我们只能看到整个 AWS 账户的重试次数。如果单个账户使用许多规则，这并不是特别有价值。

在撰写本文时，尚无明确的方法可以跟踪重试失败。这在规则重试策略不可配置的情况下尤其成问题：如果规则最多可以重试 24 小时，而我们无法缩短此间隔，那么如果不依赖下游消费者的指标，我们可能无法轻易观察到 24 小时内的失败。

跟踪成功调用

虽然我们可能很难看到需要重试的失败，但我们可以使用现有指标来监控成功的规则调用，但这需要一点工作。指标SuccessfulInvocationAttempts听起来很理想，但它面临着同样的问题RetryInvocationAttempts：在撰写本文时，没有维度可以按特定规则名称细分此指标，因此除非您的帐户只有一条规则，否则提供的价值有限。

添加图片注释，不超过 140 字（可选）

接下来我们转到Invocations，它计算成功和永久失败的调用。为了排除后者的计数，我们可以利用CloudWatch Metric Math减去FailedInvocations并将Invocations结果作为成功调用的计数。

还有一些其他调用指标我们还没有介绍。其中包括InvocationAttempts和InvocationsCreated，它们同样无法根据特定的总线或规则进行过滤，因此价值不大。还有DeadLetterInvocations，AWS 定义如下：

响应事件时未调用规则目标的次数。这包括会导致再次运行同一规则并造成无限循环的调用。

这个指标需要进一步解释。

死信调用

给定规则支持针对永久无法调用目标的事件的SQS 死信队列集成DeadLetterInvocations，也许可以分享失败事件发送到队列的频率？与最初的想法相反，事实并非如此。相反，我们有InvocationsSentToDlq并InvocationsFailedToBeSentToDlq监控 DLQ 集成行为。

名称可能不太清楚，但DeadLetterInvocations突出显示了规则何时调用自身。为了说明这一点，请考虑以下示例：

• 事件总线my-event-bus是通过规则来设置的my-rule。

• my-rule配置为my-function针对所有事件调用 Lambda。

• my-function使用 EventBridge SDK 将事件发布到my-event-bus。

添加图片注释，不超过 140 字（可选）

我们有一个无限循环！my-function将事件放在调用它的同一事件总线上。如果不进行干预，规则将无限期运行，可能会给 AWS 账户所有者带来巨额成本。AWS 会检测到服务之间的此类循环并自动禁用规则，从而填充指标DeadLetterInvocations。

指标改进建议

我们绝对没有在本文中涵盖所有可用的规则指标。有大量的选项PutEvents和PutPartnerEventsAPI 请求值得进一步探索，但这超出了博客文章的范围。

从我们介绍的内容来看，EventBridge 提供了许多有用的指标，但仍有进一步改进的空间。特别是，对仅提供帐户范围数字的指标中的维度的支持将受到欢迎。例如，维度EventBusName和RuleName对于 非常有价值RetryInvocationAttempts，允许我们查看将针对特定规则重试的调用。对于在生产中利用规则的时间关键型服务而言，重试策略间隔期间每个规则的指标缺失应该是一个严重的问题。

另一个反复出现的主题是指标命名。命名很难！虽然这比较主观，但有几种情况需要考虑。首先，Invocations可能会与混淆InvocationAttempts。从表面上看，这两个指标之间的区别并不清楚。也许前者可以重命名为InvocationAttemptsWithoutRetry或类似，因为它涵盖了成功和永久失败？其次，可能值得重新审视的名称DeadLetterInvocations。从 Lambda推出的递归检测中汲取灵感，也许这个指标可以命名为类似的东西RecursiveInvocationAttempts，或者更通用的名称，例如DiscardedInvocationAttempts？

感谢关注雲闪世界。（Aws解决方案架构师vs开发人员&GCP解决方案架构师vs开发人员）