##Kafka集群在马蜂窝大数据平台的优化与应用扩展( 三 )


集群整体架构划分如下图:
##Kafka集群在马蜂窝大数据平台的优化与应用扩展
文章图片

文章图片

②资源隔离
Topic 的流量大小是集群内部进行资源隔离的重要依据 。例如 , 我们在业务中埋点日志量较大的两个数据源分别是后端埋点数据源 server-event 和端上的埋点 mobile-event 数据源 , 我们要避免存储两个数据的主题分区分配到集群中同一个 Broker 上的节点 。通过在不同 Topic 进行物理隔离 , 就可以避免 Broker 上的流量发生倾斜 。
3)权限控制和监控告警
①权限控制
开始介绍时我们说过 , 早期 Kafka 集群没有设置安全验证处于裸跑状态 , 因此只要知道 Broker 的连接地址即可生产消费 , 存在严重的数据安全性问题 。
一般来说, 使用 SASL 的用户多会选择 Kerberos , 但就平台 Kafka 集群的使用场景来说 , 用户系统并不复杂 , 使用 Kerberos 就有些大材小用, 同时 Kerberos 相对复杂 , 存在引发其他问题的风险 。另外 , 在 Encryption 方面, 由于都是运行在内网环境 , 所以并没有使用 SSL 加密 。
最终平台 Kafka 集群使用 SASL 作为鉴权方式, 基于 SASL/ SCRAM + ACL 的轻量级组合方式 , 实现动态创建用户 , 保障数据安全 。
②监控告警
之前在集群的使用中我们经常发现 , 消费应用的性能无缘无故变差了 。分析问题的原因, 通常是滞后 Consumer 读取的数据大概率没有命中 Page- cache , 导致 Broker 端机器的内核要首先从磁盘读取数据加载到 Page- cache 中后 , 才能将结果返还给 Consumer , 相当于本来可以服务于写操作的磁盘现在要读取数据了, 影响了使用方读写同时降低的集群的性能 。
这时就需要找出滞后 Consumer 的应用进行事前的干预从而减少问题发生 , 因此监控告警无论对平台还是用户都有着重大的意义 。下面介绍一下我们的实践思路 。
整体方案:
整体方案主要是基于开源组件 Kafka JMX Metrics+OpenFalcon+Grafana:
Kafka JMX Metrics:Kafka broker 的内部指标都以 JMX Metrics 的形式暴露给外部 。1.1.1 版本 提供了丰富的监控指标 , 满足监控需要;
OpenFalcon:小米开源的一款企业级、高可用、可扩展的开源监控系统;
Grafana:Metrics 可视化系统 , 大家比较熟悉 , 可对接多种 Metrics 数据源 。
关于监控:
Falcon-agent:部署到每台 Broker 上, 解析 Kafka JMX 指标上报数据;
Grafana:用来可视化 Falcon Kafka Metrics 数据 , 对 Cluster、Broker、Topic、Consumer 4 个角色制作监控大盘;
Eagle:获取消费组 Active 状态、消费组 Lag 积压情况 , 同时提供 API , 为监控告警系统「雷达」提供监控数据 。
关于告警:
雷达系统: 自研监控系统 , 通过 Falcon 及 Eagle 获取 Kafka 指标 , 结合设定阈值进行告警 。以消费方式举例 , Lag 是衡量消费情况是否正常的一个重要指标 , 如果 Lag 一直增加 , 必须要对它进行处理 。
发生问题的时候 , 不仅 Consumer 管理员要知道 , 它的用户也要知道 , 所以报警系统也需要通知到用户 。具体方式是通过企业微信告警机器人自动提醒对应消费组的负责人或使用者及 Kafka 集群的管理者 。
监控示例:
##Kafka集群在马蜂窝大数据平台的优化与应用扩展
文章图片

文章图片

##Kafka集群在马蜂窝大数据平台的优化与应用扩展
文章图片

文章图片

##Kafka集群在马蜂窝大数据平台的优化与应用扩展


推荐阅读