Apache Kafka是一个分布式的Release-Subscription消息系统和功能强大的队列，可以处理大量数据，并允许您将消息从一个端点传递到另一个端点。
Kafka适合离线和在线新闻消费。
Kafka消息保留在磁盘上并在群集中复制以防止数据丢失。Kafka建立在Zookeeper同步服务上。它与Apache Storm集成了Apache Storm和Spark，用于实时流媒体数据分析。
尽管我们可以使用Kafka在生产环境中解释，但这并不意味着业务系统并不担心。无论是消费者的消费速度是否都可以匹配生产速度和过多的消息积压。这些可能会影响业务系统的正常运作。
关于业务系统的运营状态，尽管我们可以通过业务监控确定，但业务监控通常需要对数据进行聚合分析并达到一定的阈值以触发警报。因此，当业务监视警报通知时，业务实际上遇到了问题在一段时间内。要应对这种情况，我们通常需要补充系统监视。系统监视会议以监视不同维度（例如硬件，网络，服务器和应用程序）的警报。一旦某个组件的状态错误，将首先警告系统监视，然后商务系统可以进一步警告。在对不同监视系统的警报升级后，最好准确地反映业务系统的操作状态。
话虽如此，除了在发布后的Kafka群集后监视服务的可用性外，我们还必须进一步监视主题的消费情况。
作为监视指标，滞后直接反映了消费者的运行。一种普通的消费者，其滞后值应该很小，甚至接近0，这意味着消费者可以及时生产生产者的信息落后于。
因此，我们将主题用作监视项目，并在相关主题滞后达到阈值时进行多通道警报。
此外，在Kafka操作机制之后，我们知道：
通过上述“主题 - 派对 - 消费者组（组）”之间的关系，以促进警报信息的位置的断层点：
通过Kafka-Consumer-groups.sh脚本，Kafka随附的脚本，我们可以轻松地获得指定的消费者消费的所有主题，以及分区，最新的消费者办公室，日志最新数据偏移，滞后，不消费，消费者ID，等等信息
为了监视Kafka主题，我们使用Zabbix监视平台。考虑到后续业务系统的持续访问，我们通过Zabbix自动发现，以实现特定消费者组（组）（组）和主题自动发现下的所有分区：
自动发现中的三个信息的三个信息，小组，主题和分区可用于进一步过滤不同分区的滞后值和监视系统中的监视项目名称：
1.自动发现配置2.监视项目原型，以通过消费者组，主题和分区形成监视项目名称。警报信息中的名称可以帮助我们快速找到故障点3。触发我们滞后的初始阈值设置为50，可以根据时间进行调整。
原始：https：//juejin.cn/post/71010938222225973256