问题描述
在某项工作中，我负责一组基于 SQS 队列的处理作业，并在 CloudWatch 中监控 ApproximateNumberOfMessagesVisible 指标的扩展策略。由于各种原因，这些作业可能无法跟上发送的消息数量：
– 服务退化降低了可以处理的消息容量。
– 当队列深度继续上升时，达到了 AutoScaling 的最大限制。
– S3 故障影响了其他依赖的 AWS 服务（AutoScaling 服务），而这些服务是队列处理作业用于跟上需求的。
在与非技术团队成员讨论故障时，我希望能够传达队列处理的特定延迟，这些延迟可以转化为客户可见的降级。在使用 SQS 队列时，我应该如何做到这一点？
解决方案
在传达队列处理延迟给非技术团队成员时，主要关注以下两个问题：
1. 故障持续了多长时间？
2. 故障有多严重？
Amazon CloudWatch 提供了一些有用的指标，可以帮助回答这些问题，如下所示：
- NumberOfMessagesSent： 已添加到队列的消息数量。
- NumberOfMessagesReceived： 通过调用 ReceiveMessage API 操作返回的消息数量。
- ApproximateNumberOfMessagesVisible： 可从队列检索的消息数量。
通过正确绘制这些指标的图表，可以直观地描述队列处理延迟。以下是我在遇到作业处理能力严重降低的故障时的一些示例图表：
NumberOfMessagesSent & NumberOfMessagesReceived 图表
这个图表将发送的消息数量与接收的消息数量进行对比，有助于分离导致延迟的处理组件。在这个图表中，接收的指标急剧下降，而发送的指标继续保持正常趋势，因此我们可以推断问题出现在队列读取组件而不是队列写入组件。
NumberOfMessagesReceived & ApproximateNumberOfMessagesVisible 图表
这个图表将队列深度绘制在接收的消息上方，有助于显示队列积压的程度以及它是如何恢复的。在这个图表中，我们可以看到队列深度在队列读取组件出现问题时急剧积压，并在队列读取组件重新读取消息时开始恢复。
图表讨论
在这两个图表中，当线条重叠时，队列处理通常被认为是健康的，而当线条分开时，则是不健康的。这是一个容易教给非技术团队成员的模式，可以帮助他们快速了解何处以及如何出现问题。
为了更好地传达图表中的特定点，你可以简单地对其进行注释。此外，还可以遵循以下一些建议来改善图表的可读性：
– 标注单位和坐标轴。
– 在不同的图表中使用一致的颜色来匹配相同的指标，这有助于在不同的图表中对相同的指标进行可视化。
– 垂直对齐描述类似指标的图表，以便更容易在不同的时间段内进行比较。
此外，你可以考虑以下附加建议来更好地传达信息给团队成员：
– 赋予团队权力： 在训练团队成员阅读这些图表后，可以考虑设置一个 CloudWatch 仪表板，并为非技术团队成员赋予只读 IAM 访问权限，以便他们随时查看这些图表。
– 设置通知： 考虑基于 ApproximateNumberOfMessagesVisible 指标设置 Cloudwatch 警报，如果它超过一些约定好的高值，则通知团队成员以通知他们可能出现的问题。Cloudwatch 警报有附带通知电子邮件的描述字段，确保在通知中包含可读的描述，以帮助非技术成员传达警报。
– 探索其他数据： 探索超越 CloudWatch 提供的数据，并思考如何将这些数据传达给团队。例如，你可以通过在应用程序中记录消息的发送和接收时间来使用消息在队列中的生存时间创建直方图。
这些建议将帮助你更好地传达队列处理延迟给非技术团队成员，并使其更好地理解和处理故障情况。