监控发布/订阅服务

Posted 2023-02-16

【中文标题】监控发布/订阅服务

【英文标题】：Monitoring pub/sub services

【发布时间】：2021-05-06 19:27:45

【问题描述】：

对于在 Kafka/Redis 中读取/写入主题的每个服务，我们希望在 Prometheus 中拥有一些基本指标：

每个主题的写入速度有多“快” 每个主题的读取速度有多“快” 在 Kafka 中，我可能想确定每个组 ID 读取的“速度”有多快。

要确定从主题中读取的“速度”，可以考虑一种机制，其中某人以10 秒的间隔发布相同的消息，并且消费者在完全处理该消息后发送给 Prometheus。如果图表显示每 12 秒读取一次消息，这意味着我们在读取 any 消息时有 2 秒的延迟。

看起来系统上的每个主题都需要大量重复的手动工作。

问题

我的提议有意义吗？在 Prometheus 的 redis/kafka/... 中，如何确定读取/写入每个主题的“滞后”/“速度”是否有任何最佳实践/工具？

【参考方案1】：

我曾经遇到过完全相同的问题。

手动维护每个主题指标非常累人，而且根本无法扩展。

我切换到使用 kafka_exporter 中的 kafka_consumergroup_lag 指标 这与消费者组一起，主题标签足以让我们知道哪个主题没有被读取/滞后以及哪个消费者组。

还有其他指标，例如读取消息的速率。

至于在时间方面转换这种滞后，要么将生产时间附加到 kafka 消息，然后在 kafka 管道的另一端读取它，然后通过千分尺将时间差从应用程序导出到 Prometheus。

或者更好的是：- 使用诸如 Jaeger 之类的 OpenTracing 工具跟踪 piepline 中的每条消息

使用this 进行 Redis 监控。

所有这些导出器都以 Prometheus 格式发送数据，可以直接集成。

【讨论】：

听起来不错。谢谢！

另外，为了计算每个 consumer-group-id 的延迟，您提到了 2 种方法：kafka_consumergroup_lag metric (kafka_exporter) 并手动计算它：“将生产时间附加到 kafka 消息... ”。你有什么推荐的，为什么？

我，一方面，从来没有用时间来衡量延迟，在大多数情况下，消息数量的延迟已经足够了。我的优先级是使用导出器，然后是跟踪，然后是时间标头，这需要围绕应用程序增加额外的工作。

嗨@Stav我知道我是否可以进一步帮助你