设为首页 收藏本站
查看: 1512|回复: 0

[经验分享] Python: kafka-python版本差异导致的问题

[复制链接]
发表于 2019-1-31 11:16:31 | 显示全部楼层 |阅读模式
背景
  我们有个数据处理平台,有两个用 docker 运行的数据处理模块,分别是:data_api, 和 processor_api,故名思义:
  

data_api:      接受数据;  
processor_api: 处理数据;
  

  数据处理简单架构


踩坑经过
  一直以来,这两个模块都是相安无事,稳定得很,然而在九月份因为更新 kafka 连接地址重启了容器,就出了问题。
  只要用过 docker 的童鞋,都会对 docker logs 很熟悉,这次问题就是,因为 docker 的日志狂刷,按照默认的配置,日志会全部写入 json.log,大约一小时就能刷出 2G 的日志;
  于是感觉特别的神奇,跑了快两年都没这问题,改下链接地址就有这么多日志输出,但是明明容器是正常在工作的。
  排查半天一直找不出原因,就先配置了日志转储才免得磁盘告警。
  今天看到那一堆日志时,发现很多 kafka 链接失败日志:
  

...  
[W 181011 14:18:24 conn:625] : close() called on disconnected connection with error: ConnectionError: Unable to connect to any of the names for xxxx/xxxx(马赛克):9093
  
[E 181011 14:18:24 conn:289] Unable to connect to any of the names for xxxx/xxxx(马赛克):9093
  
....
  

  之前以为是kafka架构的问题没去管,现在还是去谷歌一下,比较幸运地似乎找到一些原因和解决方案,

  相关的链接:
  https://github.com/dpkp/kafka...
  https://github.com/dpkp/kafka...
  大约的意思是因为查找域名失败导致这个bug触发了。
  于是事不延迟,找台机器升级下 kafka-python 版本到 1.4.0 看看,升级完之后发现日志大幅度减少了。

  Golang 视频大优惠,如不感兴趣略过
  升级后的日志大约是升级前的九分之一了,这样来看很明显就是 1.3.5 的问题了。本想着这样就愉快的解决了,然而调整完就有 kafka 消费延迟的告警了,因为一直时不时有少量的消费延迟,所以也没在意。
  直到第二天,累积的延迟量已经触发了第二级别的阈值了,消费延迟超过 30 万条了,立马上监控看看

  lag 图就是延迟条数了,大约 11 号 18点的时候,也就是我们更新版本重启容器之后,在数据写入并没多大改变情况下,lag 数拼命增长,直接去到 80 万了,而且后面还在持续上涨;
  首先排除因素就是 processor_api 消费速度,因为在更新前,一直是不会有延迟这么多的。
  先回滚到旧版本看看,看到延迟立马消失了。

  基本就能定位这个消费延迟的问题是版本导致的。
  既然是消费延迟,那就得看消费速度监控了。刚才已经说了,消费速度是绝对够的,只是不知道为什么还是有延迟而已。
  昨天到今天高延迟时的监控图图:

  时间太长看不出什么问题,选小区间再看看:

  这次看到消费图表,是断断续续的,而看消费者的日志,也看到时不时没有东西打印,仿佛消费完了那样。但是从延迟来看,数据应该是一直有的,不应该出现没有日志打印的情况。
  对比下正常时候的消费速率图:

  正常消费是连续的平稳的,不应该是断断续续有尖峰的,怀疑是 kafka 消费权重没有均匀等问题,找了 kafka 的童鞋,看能不能看到当前 kafka 消费者分配情况。
  kafka 童鞋给了一个神奇的回复,说 kafka 正在 rebalance ...
  Consumer group panama_opsys_detect is rebalancing
  当 kafka 在 rebalancing 状态,是不能够消费的。这样看起来的话,应该是 kafka 在频繁的 rebalance 了。。
  既然消费者进程和链接都没有变化,其实不应该短时间内频繁 rebalance 的。
  因为前面的经验,所以现在都很大可能是版本问题了。
  直接去 kafka-python 官网,找了较新的版本 1.4.2,更新之后,消费和日志都正常了。
  欢迎加入Python ×××流:365534424
  转载请注明来源: https://segmentfault.com/a/11...



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-669979-1-1.html 上篇帖子: Kafka源码深度解析-序列4 -Producer -network层核心原理 下篇帖子: SparkStreaming 中管理 Kafka Offsets 的几种方式
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表