如何将基于队列的处理延迟传达给非技术团队成员？

我负责使用ApproximateNumberOfMessagesVisibleCloudWatch指标上的扩展策略执行一组SQS队列处理作业。由于多种原因，这些作业可能无法跟上所发送消息的数量：

• 服务降级会降低能够处理的消息的容量。
• AutoScaling 队列深度持续增加时达到最大限制。
• S3中断会影响AutoScaling队列处理作业用来满足需求的其他相关AWS服务（服务）。

在与非技术团队成员讨论中断时，我想传达特定的队列处理延迟，这些延迟可以转化为客户可见的降级。如何使用SQS队列执行此操作？

与任何中断通信一样，非技术读者将主要希望了解：

• 多久了
• 有多糟？

Amazon CloudWatch指标为SQS队列提供以下指标，可以帮助回答以下问题：

• NumberOfMessagesSent：添加到队列中的消息数。
• NumberOfMessagesReceived：调用ReceiveMessage API操作返回的消息数。
• roximateNumberofMessagesVisible：可从队列中检索的消息数。

如果正确绘制图形，则这些度量可以在描述队列处理延迟方面提供强大的视觉帮助。这是我经历的一次中断中的几个示例，其中该作业处理队列消息的能力严重下降：

发送的NumberOfMessages和已接收的NumberOfMessages

• 图表类型：折线图
• 统计：总和
• 时间： 5分钟

这可以绘制发送和接收的消息之间的对比，从而有助于隔离造成延迟的处理组件。在此图中，接收到的度量标准急剧下降，而发送的度量标准继续保持其正常趋势，因此我们可以推断出问题出在队列读取组件而不是队列写入组件。

这是否回答了多长时间/多严重的事件？是; 描述随着时间的推移而受到影响的过程。

收到的NumberOfMessages＆Visible的近似NumberOfMessages

• 图形类型：堆积面积图
• 统计：总和
• 时间： 5分钟

这将在接收到的消息之上绘制队列深度图，这有助于显示队列备份的距离和恢复的方式。在此图中，我们可以看到，当队列读取组件出现问题时，队列深度急剧备份，并在队列读取组件再次开始读取消息时开始恢复。

这是否回答了多长时间/多严重的事件？是; 描述随着时间的推移受到影响的消息。

图形讨论

在这两个图中，当线重叠时，通常可以将队列处理视为正常，而当线分开时，则认为队列处理不正常。这是向非技术团队成员教授的简单模式，并且可以帮助他们快速传播出现在这些图中的问题的位置和方式。

要进一步传达图中的特定点，您可以简单地为它们添加注释：

绘图技巧：

• 标签单位和轴。
• 使用一致的颜色在整个图形中匹配指标。请注意，两个图表中的NumberOfMessagesReceived均为橙色。这将有助于在不同的图表上可视化相同的指标。
• 垂直对齐的图表描述了相似的指标，因此它们可以随时间进行比较。

_{注意：我已经格式化了这些图形以便在StackExchange上呈现，所以这些不一定是我在停运验尸中呈现它们的方式。我在这里明确地从左轴删除了值，以使它们从StackExchange中消失；您需要将它们保存在验尸中。}

其他提示

• 授权您的团队：在训练您的团队成员阅读这些图表之后，没有理由将它们隐藏起来。考虑设置CloudWatch仪表板，并为您的非技术团队成员提供IAM对CloudWatch的只读访问权限，以便他们可以随时查看这些图。
• 设置通知：如果超过了某些商定的较高值，请考虑根据roximateNumberOfMessagesVisible指标设置Cloudwatch警报，并订阅团队成员以通知他们潜在的问题。Cloudwatch警报具有随通知电子邮件一起发送的描述字段-确保包括易于理解的描述，以帮助您的非技术人员传播警报。
• 探索其他数据：根据Evgeny的评论，探索CloudWatch提供的其他数据，并思考如何将这些数据传达给团队。他在队列中使用消息生存期来创建直方图的示例就是这种创造性思维的一个很好的示例，可以通过在应用程序中记录消息发送和消息接收时间来完成。您可以通过ReceiveMessage API响应的每个队列消息上的SentTimeStamp属性获取消息Sent Timestamp 。更多细节在这里。