Kafka的权限控制和监控告警

　　(1)权限控制

　　开始介绍时我们说过，早期Kafka集群没有设置安全验证处于裸跑状态，因此只要知道Broker的连接地址即可生产消费，存在严重的数据安全性问题。

　　一般来说,使用SASL的用户多会选择Kerberos，但就平台Kafka集群的使用场景来说，用户系统并不复杂，使用Kerberos就有些大材小用,同时Kerberos相对复杂，存在引发其他问题的风险。另外，在Encryption方面,由于都是运行在内网环境，所以并没有使用SSL加密。

　　最终平台Kafka集群使用SASL作为鉴权方式,基于SASL/SCRAM+ACL的轻量级组合方式，实现动态创建用户，保障数据安全。

　　(2)监控告警

　　之前在集群的使用中我们经常发现，消费应用的性能无缘无故变差了。分析问题的原因,通常是滞后Consumer读取的数据大概率没有命中Page-cache，导致Broker端机器的内核要首先从磁盘读取数据加载到Page-cache中后，才能将结果返还给Consumer，相当于本来可以服务于写操作的磁盘现在要读取数据了,影响了使用方读写同时降低的集群的性能。

　　这时就需要找出滞后Consumer的应用进行事前的干预从而减少问题发生，因此监控告警无论对平台还是用户都有着重大的意义。下面介绍一下我们的实践思路。

　　整体方案：

　　整体方案主要是基于开源组件KafkaJMXMetrics+OpenFalcon+Grafana：

　　KafkaJMXMetrics：Kafkabroker的内部指标都以JMXMetrics的形式暴露给外部。1.1.1版本提供了丰富的监控指标，满足监控需要

　　OpenFalcon：小米开源的一款企业级、高可用、可扩展的开源监控系统

　　Grafana：Metrics可视化系统，大家比较熟悉，可对接多种Metrics数据源。

　　关于告警：

　　雷达系统:自研监控系统，通过Falcon及Eagle获取Kafka指标，结合设定阈值进行告警。以消费方式举例，Lag是衡量消费情况是否正常的一个重要指标，如果Lag一直增加，必须要对它进行处理。

　　发生问题的时候，不仅Consumer管理员要知道，它的用户也要知道，所以报警系统也需要通知到用户。具体方式是通过企业微信告警机器人自动提醒对应消费组的负责人或使用者及Kafka集群的管理者。

　　关于监控：

　　Falcon-agent：部署到每台Broker上,解析KafkaJMX指标上报数据

　　Grafana：用来可视化FalconKafkaMetrics数据，对Cluster、Broker、Topic、Consumer4个角色制作监控大盘。

　　Eagle：获取消费组Active状态、消费组Lag积压情况，同时提供API，为监控告警系统「雷达」提供监控数据。