运维教程-来自LinkedIn的实践:生产环境下Kafka的调试和最佳实践

跨零代码为大家提供高品质的解决方案,请大家多多来访,跨零不胜感激,在此谢过。

在本文中,LinkedIn的软件工程师Joel Koshy详细阐述了他和一个工程师团队是如何解决生产环境下Kafka的两次事故的。这两次事故是由于多个产品缺陷、特殊的客户行为以及监控缺失的交错影响导致的。

第一个缺陷是在LinkedIn的变更请求跟踪系统中观察到的,部署平台认为这是从服务发出的重复邮件。Koshy指出,其根本原因是由于消息格式的改变,和随后缓存加载在偏移管理器的终止,而这个偏移管理器已经被设置了一个旧的偏移量。由于这个主题分区上的低数据容量,日志压缩和清除触发器在部署的主题上从来没有被触发过。这导致一个旧的偏移量被当作消费者的起点,同时也使得以前已经消费过的消息被重新读取,并触发了重复的电子邮件。

第二个缺陷是在一个数据部署管道中,它里面的Hadoop推送作业器会发送数据到Kafka的非生产环境,然后通过Kafka集群复制到生产集群。在发现取回的偏移量没有有效检查点的时候,复制就被卡住了。它表明前一个检查的偏移量被丢掉了。Koshy是这样描述根本原因的:

Kafka代理之间不清楚首席代理选举的规则,这会导致处于分区的首席代理在完成复制延迟过程中的失败会引起偏移量倒转。Kafka消息的消费者发出读取指定偏移量的请求。消费者会对主题分区检查它们的偏移量,因此它们可以从最后一次检查点(消费者需要重启的点)重新开始。检查可以发生在很多时候,包括消费者失败、重启或者分区被加到主题里以及在消费者实例之间的分区分发规则需要改变的时候。如果一个消费者获取这个代理的主题日志之外的偏移关键字,它会收到OffsetOutOfRange的错误。消费者需要根据它们auto.offset.reset配置,来重新设置它们的偏移为最新或最早的有效偏移。

Koshy指出,

Koshy还着重指出一些尽早发现偏移倒回的最佳实践,包括:通过监控集群中模糊不清的首席选举率,基于消费者延迟的监控和告警从而避免误报。监控日志压缩的指标(特别是最大脏读率传感器的),以及偏移管理的指标(如偏移缓存大小、提交率、组数传感器等)。偏移量自己被存在一个可复制、可分区、可压缩的日志中,它们与内部的_consmer_offsets主题相关联。Koshy推荐在调试进程中尽早导出内部主题,从而避免日志压缩删除那些潜在有用的数据。特定的主题由消息组成,任何的时间偏移提交请求都会被发送到偏移管理代理中。在这种情况下,消费者和代理的日志也是可能有用的。

文章出处:聊聊架构

文/Joel Koshy

从零到一,创造未来!跨零综合IT问题解决服务站,欢迎你的到来。运维教程 只为你绽放。

本文固定链接: http://kua0.com/2018/12/31/运维教程-来自linkedin的实践:生产环境下kafka的调试和最/

为您推荐

发表评论

电子邮件地址不会被公开。 必填项已用*标注