【监控】Kafka - 详细指标

本文关键词: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指标,需要自行绘图】

image.png

这里有必要说一点,我第一次使用的配置是配置1的陈旧内容,不能拿到完全的数据,实际是kafka版本升级到2.0以后带来的变化导致,比如通过工具VisualVM连接JMX端口后无法看到kafka.consumer的数据,实际运行的时候也是匹配不到的。所以后来觉得这个方法不行又绕了很多弯路,再后来查了很多资料才发现是自己没看到kafka升级到2.x以后摈弃了一些东西。也是最终使用两个方式并行监控的基础了。


监控方式二:

为了监控更准确的消费者数据
新的数据采集方式经过验证,可以以如下流程图解释

image.png

在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,流程图如下:

image.png

在前两个方案中我已详细描述过如何通过端口采集到kafka的数据,这里就不再重复。

最后提一点重要的,jmx_exporter直接导入到Prometheus的方式采集的是单台主机的数据,如果你有一个kafka集群,那么每一台都需要如此配置监控;而burrow的方式,可以从单台主机中拿到集群的消费者数据,所以只需要部署在集群中的其中一台即可。(并未测试多集群,如果你有多个kafka集群,可能需要变更配置了,请自行寻找解决方案)

配合node_exporter的基础指标监控,对于kafka的监控才算完整,当然,这些图表只能自己画了,因为网上并没有现成的。

image.png
image.png
image.png
image.png
image.png
附加说明:

1、关于配置文件的编写,我的配置2会匹配所有的指标,不过由于不同的人需求不一样,可以参考配置1的方式,通过VisualVM工具在MBeans中所暴露出来的对象,根据规律自行编写。举个例子比如像要获取BytesInPersec对应__consumer__offsets这个指标在VisualVM工具中如图

image.png

而此时,在Metadata栏的ObjectName栏则可以看到他的匹配方式,同类型的,使用正则替换即可,具体参考配置1就好。[图片上传失败...(image-3fa8ad-1548668115387)]

image.png

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使用。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 155,770评论 4 358
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,116评论 1 286
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 105,656评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,372评论 0 201
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 51,704评论 3 285
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,166评论 1 204
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,535评论 2 306
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,259评论 0 193
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,882评论 1 236
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,218评论 2 239
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,760评论 1 255
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,126评论 2 249
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,667评论 3 228
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,935评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,644评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,171评论 2 265
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,119评论 2 258

推荐阅读更多精彩内容