本文关键词：Kafka、Prometheus
kafka作为流行的队列工具其强大之处相信不用多说，而使用kafka时相信大多数人都会有这样一个需求，那就是实时监测kafka的指标，比如消费、堆积、性能等等。
通过指令我们可以在kafka集群的主机上查看某个group相关的指标
[root@mx-kafka-1 ~]# pwd
/root
[root@mx-kafka-1 ~]# kafka-consumer-groups.sh --bootstrap-server mx-kafka-1:9092,mx-kafka-2:9092,mx-kafka-3:9092,mx-kafka-4:9092,mx-kafka-5:9092 --group jiguang-log-group --describe
TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
sdk-log-data 1 14182138146 14196116659 13978513 sarama-53c5a1da-3a57-4e94-9458-ded077d103a6 /10.10.130.244 sarama
sdk-log-data 9 14181723308 14196601937 14878629 sarama-b00f3db5-cd3a-440c-bfc2-9025687e1043 /10.10.168.51 sarama
sdk-log-data 8 14182893809 14197037268 14143459 sarama-a6eadc47-5fcb-4fb0-8369-4e72109d42dc /10.10.130.244 sarama
sdk-log-data 3 14183305596 14197462703 14157107 sarama-65dd3c57-7a6e-4bee-944d-405dc17df3d9 /10.10.121.26 sarama
sdk-log-data 4 14182059026 14196893966 14834940 sarama-7ae68ed4-69e7-4380-9e6a-2a2e0dba9c9a /10.10.121.26 sarama
sdk-log-data 10 14180872923 14196189590 15316667 sarama-bb893b6c-fb97-4ca9-8c15-daa1abb008d1 /10.10.121.26 sarama
sdk-log-data 7 14182722934 14197033917 14310983 sarama-984a34d5-df0a-4202-a4f9-716664d8ef04 /10.10.130.244 sarama
sdk-log-data 0 14182510828 14197824186 15313358 sarama-0fdec84e-a572-44de-b9e5-3452a242f43f /10.10.168.51 sarama
sdk-log-data 11 14184173437 14198067999 13894562 sarama-deb5a7b0-6de4-4bd1-bd1c-3db60739f0e3 /10.10.121.26 sarama
sdk-log-data 6 14183175300 14197123342 13948042 sarama-94242065-4149-422c-b961-9718dd7c9d6b /10.10.168.51 sarama
sdk-log-data 5 14182922569 14198291576 15369007 sarama-84ebf3bf-b7de-4752-8025-3d6fb6e10215 /10.10.130.244 sarama
sdk-log-data 2 14182493952 14196799617 14305665 sarama-62121b97-3b76-48b4-a564-44d9eee794cc /10.10.168.51 sarama
在上面的指标中，CURRENT-OFFSET 表示当前消费的offset，LOG-END-OFFSET 表示最新的offset，也就是生产者最新的offset，LAG表示堆积
在与Prometheus的合作中，网络上很多的exporter其数据都来源于zookeeper，自kafka升级到版本2以后，数据不往zookeeper中写入了，则大多exporter再也无法拿到数据，这期间我经历了公司kafka的升级，之前的好些exporter监控方式及图表都已废弃这里不表。
面对版本2以后的kafka，我使用了kafka-offset-exporter来作为kafka的exporter与Prometheus配合，有博客介绍如下
Monitoring Kafka Consumer Offsets。
在它的指标中，
kafka_offset_newest对应系统中查询出来的LOG-END-OFFSET ,
kafka_offset_consumer对应系统中查询出来的CURRENT-OFFSET
堆积（LAG）的计算方式为kafka_offset_newest - on(topic,partition) group_right kafka_offset_consumer{group="jiguang-log-group"}
但是它同样有一个问题。部分partition的指标不准，这导致计算出来的部分结果与实际相去甚远。
监控需要寻求新的方式
万幸，kafka本身就已经自带了监控，通过Yammer Metrics进行指标暴露与注册，可通过JMX进行指标收集。官网链接
这里有一些博客可做参考
如何对kafka进行监控
fxjwind - kafka中支持的jmx reporter
JMX与系统管理
利用jmx_exporter获取kafka metrics数据
kafka各种监控指标
还有这个异常说明无法使用 service:jmx:rmi:///jndi/rmi://111.11.11.111:10001/jmxrmi 连接到111.11.11.111：10001
以及kafka的官网对每个指标都做了说明。
Monitoring Kafka
kafka学习之监控
jmx_exporter
Monitor Kafka with Prometheus +Grafana
Grafana Darshbord
监控方式一 JVM：
本次测试环境:
kafka_2.11-2.1.0
jmx_prometheus_javaagent-0.3.1.jar
1、下载最新的 JMX to Prometheus Exporter到/opt/kafka目录
https://repo1.maven.org/maven2/io/prometheus/jmx/jmx_prometheus_javaagent/0.3.1/jmx_prometheus_javaagent-0.3.1.jar
2、在/opt/kafka目录编辑kafka-agent.yaml
配置1（面向kafka2.0以前的版本）：【部分指标匹配，且部分配置只在低版本kafka有效，例如kafka.consumer等】
hostPort: 127.0.0.1:9999
lowercaseOutputName: true
whitelistObjectNames:
- "kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec"
- "kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec"
- "kafka.network:type=RequestMetrics,name=RequestsPerSec,request={Produce|FetchConsumer|FetchFollower}"
- "kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec"
- "kafka.network:type=RequestMetrics,name=TotalTimeMs,request={Produce|FetchConsumer|FetchFollower}"
- "kafka.network:type=RequestMetrics,name=RequestQueueTimeMs,request={Produce|FetchConsumer|FetchFollower}"
#- "kafka.consumer:type=consumer-fetch-manager-metrics,client-id={client-id}"
- "kafka.server:type={Produce|Fetch},user=([-.\\w]+),client-id=([-.\\w]+)"
- "kafka.server:type=Request,user=([-.\\w]+),client-id=([-.\\w]+)"
- "kafka.[producer|consumer|connect]:type=[producer|consumer|connect]-metrics,client-id=([-.\\w]+)"
- "kafka.producer:type=[consumer|producer|connect]-node-metrics,client-id=([-.\\w]+),node-id=([0-9]+)"
- "kafka.producer:type=producer-metrics,client-id=([-.\\w]+)"
- "kafka.producer:type=producer-topic-metrics,client-id=([-.\\w]+),topic=([-.\\w]+)"
- "kafka.consumer:type=consumer-coordinator-metrics,client-id=([-.\\w]+)"
- "kafka.consumer:type=consumer-fetch-manager-metrics,client-id={client-id}"
- "kafka.consumer:type=consumer-fetch-manager-metrics,client-id={client-id},topic={topic}"
- "kafka.streams:type=stream-metrics,client-id=([-.\\w]+)"
- "kafka.streams:type=stream-task-metrics,client-id=([-.\\w]+),task-id=([-.\\w]+)"
- "kafka.streams:type=stream-processor-node-metrics,client-id=([-.\\w]+),task-id=([-.\\w]+),processor-node-id=([-.\\w]+)"
- "kafka.streams:type=stream-[store-type]-state-metrics,client-id=([-.\\w]+),task-id=([-.\\w]+),[store-type]-state-id=([-.\\w]+)"
- "kafka.streams:type=stream-record-cache-metrics,client-id=([-.\\w]+),task-id=([-.\\w]+),record-cache-id=([-.\\w]+)"
配置2（面向kafka2.0以后的版本）：【kafka2.0以后，匹配所有jmx指标(虚拟机测试每次请求约2秒，生产环境大约10秒。Prometheus默认15秒请求一次)】
lowercaseOutputName: true
jmxUrl: service:jmx:rmi:///jndi/rmi://192.168.112.129:9999/jmxrmi
ssl: false
rules:
- pattern : JMImplementation<type=(.+)><>(.*)
- pattern : com.sun.management<type=(.+)><>(.*)
- pattern : java.lang<type=(.+)><>(.*)
- pattern : java.nio<type=(.+)><>(.*)
- pattern : java.util.logging<type=(.+)><>(.*)
- pattern : kafka<type=(.+)><>(.*)
- pattern : kafka.controller<type=(.+)><>(.*)
- pattern : kafka.coordinator.group<type=(.+)><>(.*)
- pattern : kafka.coordinator.transaction<type=(.+)><>(.*)
- pattern : kafka.log<type=(.+)><>(.*)
- pattern : kafka.network<type=(.+)><>(.*)
- pattern : kafka.server<type=(.+)><>(.*)
- pattern : kafka.utils<type=(.+)><>(.*)
说明：
（1）、端口9999表示jmx暴露数据的端口，与jmx exporter通信。
（2）、在我的虚拟机测试中，只为kafka新建过一个topic,以及一个consumer,配置中所涉及的指标只有kafka.server有效，其他未显示出来。具体以生产环境为准。
3、编辑bin/kafka-server-start.sh添加
export JMX_PORT="9999"
export KAFKA_OPTS="-javaagent:/opt/kafka/jmx_prometheus_javaagent-0.3.1.jar=9990:/opt/kafka/kafka-agent.yaml"
说明：
（1）、端口9990表示jmx暴露的端口，以后访问http://127.0.0.1:9999/metrics获取指标数据。
4、Prometheus配置添加
scrape_configs:
- job_name: kafka
static_configs:
- targets: ["192.168.112.129:9990"]
说明：
（1）：这里的192.168.112.129为我的虚拟机地址
5、Grafana导入dashboard，ID为721。这是网络上使用最多的kafkadashboard，但是内容依旧非常陈旧，需要自行修改。【以下指标图表来自较早版本的导出配置，新的配置包含所有jmx指标，需要自行绘图】
这里有必要说一点，我第一次使用的配置是
配置1的陈旧内容，不能拿到完全的数据，实际是kafka版本升级到2.0以后带来的变化导致，比如通过工具VisualVM连接JMX端口后无法看到kafka.consumer的数据，实际运行的时候也是匹配不到的。所以后来觉得这个方法不行又绕了很多弯路，再后来查了很多资料才发现是自己没看到kafka升级到2.x以后摈弃了一些东西。也是最终使用两个方式并行监控的基础了。
监控方式二：
为了监控更准确的消费者数据
新的数据采集方式经过验证，可以以如下流程图解释
在kafka集群中的某一台主机，开启JMX_PORT=9999端口，运行burrow采集9999端口的数据，使用burrow-exporter将burrow采集到的数据转换成Prometheus是认识的形式，然后暴露给Prometheus进行拉取。
具体操作流程如下：
1、配置kafka，暴露JMX_PORT端口
在kafka-run-class.sh文件中添加-Djava.rmi.server.hostname=ip地址
if [ -z "$KAFKA_JMX_OPTS" ]; then
KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false "
fi
KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=10.10.0.18
-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false "
新添加的语句是KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=10.10.0.18 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false "
事实上只有-Djava.rmi.server.hostname=10.10.0.18是新加的，其他的是从#JMX settings下的if语句里拷贝出来的。
注意：如果不添加上一条，则使用JMX暴露出来的端口可能无法使用甚至无法被链接
启动kafka的时候，语句为JMX_PORT=9999 kafka-server-start.sh -daemon /opt/kafka_2.11-2.0.0/config/server.properties
这样就能将端口9999暴露出来，且运行方式为守护进程的方式
2、启动Burrow
本次操作时间是2018.1.10，Github上最新的release版本还是2018.5.15日提交的。由于kafka升级到了2.0，该版本并不适用，如果直接使用，会导致部分consumer数据无法拿到。
依据github上的操作指示，使用新的go版本和dep工具包，拉取master分支并重新打包一份Burrow.
（当然这一步是需要懂go语言的来做最好了）
我在/data/Burrow目录下载了老版的release版本解压以获取里面的config目录下的文件，并上传新打包的Burrow替换掉老版本的文件。
在config目录下替换burrow.toml文件内容为：
[general]
access-control-allow-origin="*"
[logging]
level="info"
[zookeeper]
servers=["10.10.0.18:2181","10.10.80.94:2181","10.10.125.117:2181", "10.10.4.149:2181", "10.10.104.108:2181"]
[client-profile.kafka-profile]
kafka-version="2.0.0"
client-id="burrow-client"
[cluster.gw]
class-name="kafka"
client-profile="kafka-profile"
servers=["10.10.0.18:9092","10.10.80.94:9092","10.10.125.117:9092","10.10.4.149:9092","10.10.104.108:9092"]
topic-refresh=120
offset-refresh=10
[consumer.consumer_kafka]
class-name="kafka"
cluster="gw"
servers=["10.10.0.18:9092","10.10.80.94:9092","10.10.125.117:9092","10.10.4.149:9092","10.10.104.108:9092"]
client-profile="kafka-profile"
start-latest=true
offsets-topic="__consumer_offsets"
group-whitelist=".*"
group-blacklist="^(console-consumer-|python-kafka-consumer-).*$"
[httpserver.default]
address=":8000"
配置文件来自另一个开源项目ignatev/burrow-kafka-dashboard，该项目是在kubernetes下实现的，我这里借用了他的配置方式。
使用命令nohup ./Burrow --config-dir ./config &后台启动burrow
访问http://10.10.0.18:8000/v3/kafka可以看到结果
{"error":false,"message":"cluster list returned","clusters":["gw"],"request":{"url":"/v3/kafka","host":"mx-kafka-1"}}
表示成功。
burrow没有好看的UI界面，只能提供接口返回json格式的数据，具体使用方式可以参看博客
Kafka消费积压Lag监控工具Burrow的使用
Control Center User Interface
3、转换burrow的指标使Prometheus可见
在实际使用的时候，由于需要将指标导入prometheus，所以需要一个工具对burrow的指标进行转换，在这里，我使用开源的burrow_exporter
新建并进入目录/data/burrow-exporter/
下载最新的release版本的burrow-exporter，解压后可以直接运行里面的burrow-exporter文件，从help里可以看到需要配置的参数
启动命令如下
nohup ./burrow-exporter --burrow-addr="http://10.10.0.18:8000" --metrics-addr="0.0.0.0:9254" --interval="15" --api-version="3" &
注意：--burrow-addr表示burrow的地址，--metrics-addr表示暴露给Prometheus可以访问的地址和端口，-interval表示采集burrow的时间间隔，最需要注意的是 --api-version表示的版本就是burrow暴露出来的版本，比如先前访问burrow时使用的链接是
http://10.10.0.18:8000/v3/kafka，那么这里就需要设置3，老版本如果使用v2那么就要设置2，不过默认就是2，否则会导致异常无法连接。
访问http://10.10.0.18:9254/metrics，便可以看到熟悉的Prometheus指标
最终方案：
但是
通过burrow所采集到的指标只包含consumer的offset和lag，通过burrow在github上的简介可以发现这一点。
为了更完整的获取kafka的数据，我再次搜索了很多地方，终于确订了最终的数据依旧还是jvm所暴露出来的最为完整，在这之前，我测试的时候所使用的配置文件是旧版本的配置文件，自kafka升级到2.0以后，他弃用了kafka.consumer等指标对象，但是kafka.server等其他指标对象依旧可以拿到burrow所不具备的数据。所以最终的kafka监视方案变更为 burrow + jmx_exporter,流程图如下：
在前两个方案中我已详细描述过如何通过端口采集到kafka的数据，这里就不再重复。
最后提一点重要的，jmx_exporter直接导入到Prometheus的方式采集的是单台主机的数据，如果你有一个kafka集群，那么每一台都需要如此配置监控；而burrow的方式，可以从单台主机中拿到集群的消费者数据，所以只需要部署在集群中的其中一台即可。（并未测试多集群，如果你有多个kafka集群，可能需要变更配置了，请自行寻找解决方案）
配合node_exporter的基础指标监控，对于kafka的监控才算完整，当然，这些图表只能自己画了，因为网上并没有现成的。
附加说明：
1、关于配置文件的编写，我的配置2会匹配所有的指标，不过由于不同的人需求不一样，可以参考配置1的方式，通过VisualVM工具在MBeans中所暴露出来的对象，根据规律自行编写。举个例子比如像要获取BytesInPersec对应__consumer__offsets这个指标在VisualVM工具中如图
而此时，在Metadata栏的ObjectName栏则可以看到他的匹配方式，同类型的，使用正则替换即可，具体参考配置1就好。[图片上传失败...(image-3fa8ad-1548668115387)]
2、出现过的问题：
（1）：生产环境链接超时问题。
原因：kafka默认设置的单次拉取超时时间为15s，而由于生产环境主机压力大，15s获取还没有返回，导致数据总是拉取不成功。
解决方案：根据我们自己的实际情况，很多java指标是可以不要的，所以在配置中注释了除去kafka.*其他的所有指标，拉取时间维持在最多10s，基本满足需求，以后有需要再行优化（比如只拉取需要的指标，其他一律忽略等等）。
（2）：Prometheus远程写入influxDB报错问题。
原因：influxDB不支持+/-Inf的字段类型，这点从日志中可以看出来。
日志：如下
prometheus | level=warn ts=2019-01-22T07:00:37.113970782Z caller=queue_manager.go:531 component=remote queue="0:http://influxdb:8086/api/v1/prom/write?db=prometheus&u=prom&p=prom" msg="Error sending samples to remote storage" count=100 err="server returned HTTP status 400 Bad Request: {\"error\":\"+/-Inf is an unsupported value for field value\"}"
解决方案：在指标页中找到返回值为+/-Inf的指标名，从配置文件中将其忽略。（待进一步验证，我设置了一个，告警减少了，但是依然存在，可能有多个指标，某些没照出来吧）
scrape_configs:
- job_name: 'my_job'
static_configs:
- targets:
- my_target:1234
metric_relabel_configs:
- source_labels: [ __name__ ]
regex: 'my_too_large_metric'
action: drop
3、一些自己使用到的指标计算，每个人的需求不一样，仅供参考（如果发现错误，请不吝批评指正）
| 名称 | 指标与公式 |
|---|---|
| Bytes Out Per Topic | sum(kafka_server_brokertopicmetrics_oneminuterate{name="BytesOutPerSec",topic!=""}) by (topic) |
| Kafka log size by topic | sum(kafka_log_log_value{name="Size",topic!=""}) by (topic) |
| 堆积 by Group | sum(kafka_burrow_partition_lag) by (group) |
| Rebalance | kafka_server_delayedoperationpurgatory_value{name="NumDelayedOperations",delayedOperation="Rebalance"} |
| 消费速率 by Group /每秒 | sum(rate(kafka_burrow_partition_current_offset[1m])) by (group) |
依葫芦画瓢的东西我就不多写了，大都差不多。另外node_exporter携带上来的关于主机性能方面的指标也不写了，grafana可以搜索到很多node_exporter的dashboard使用。
