常⽤中间件的监控⼯具与指标汇总Kafka ⼏种主流监控⼯具：
1. Kafka Web Conslole 测试环境使⽤功能全⾯强⼤ - 不推荐⽣产环境使⽤
2. Kafka Manager 管理集群使⽤
3. KafkaOfftMonitor 实时监控使⽤ - 测试监控推荐
KafkaOfftMonitor 中的参数项说明：
topic：创建时topic名称
partition：分区编号
offt：表⽰该parition已经消费了多少条message
logSize：表⽰该partition已经写了多少条message
Lag：表⽰有多少条message没有被消费。
Owner：表⽰消费者
Created：该partition创建时间
Last Seen：消费状态刷新最新时间。
Kafka主要解决了⽣产者（客户端）与消费者（服务端）的3⼤问题：
1）解耦
2）异步
3）削峰（负载均衡）
kafka本⾝的指标
kafka本⾝的指标
指标名称名词解释指标解析
UnderReplicatedPartitions未复制分区数长期处于⼤于0的状态
IsrShrinksPerSec/IsrExpandsPerSec收缩副本数/ 扩
展副本数如果IsrShrinksPerSec（ISR缩⽔）增加了，但并没有随之⽽来的IsrExpandsPerSec（ISR扩展）的增加，需修改
broker的⽤户可配置参数
ActiveControllerCount活跃控制器计
数通常来说，这个值（ActiveControllerCount）不可能⼤于1，但是当遇到这个值等于0且持续了⼀⼩段时间（<1秒）的时候，必须发出明确的告警
OfflinePartitionsCount离线分区计数这个指标报告了没有活跃leader的partition数，因此⾮0的这个值需要被告警出来，从⽽防⽌服务中断。任何没有活跃leader的partition都会彻底不可⽤，且该parition上的消费者和⽣产者都将被阻塞，直到leader变成可⽤。
LeaderElectionRateAndTimeMs 领导选举率和
次数
leader选举的频率（每秒钟多少次）和
集群中⽆leader状态的时长（以毫秒为
单位），尽管不像
UncleanLeaderElectionsPerSec这个
指标那么严重，但你也需要时长关注
它，就像上⽂提到的，leader选举是在
与当前leader通信失败时才会触发的，
所以这种情况可以理解为存在⼀个挂掉
的broker。
这个指标如果存在的话很糟糕，这说
UncleanLeaderElectionsPerSec未清理领导选
举/每秒这个指标如果存在的话很糟糕，这说明kafka集群在寻找partition leader节点上出现了故障，通常，如果某个作为partition leader的broker挂了以后，⼀个新的leader会被从ISR集合中选举出来，不⼲净的leader选举（Unclean leader elections ）是⼀种特殊的情况，这种情况是副本池中没有存活的
副本。基于每个topic必须拥有⼀个leader，⽽如果⾸领是从处于不同步状态的副本中选举出来的话，意味着那些与之前的leader没有被同步的消息，将会永久性丢失。事实上，不⼲净的leader选举将牺牲持久性（consistency）来保证可⽤性（availability）。所以，我们必须明确地得到这个指标的告警，从⽽告知数据的丢失。
TotalTimeMs各种服务请求
的时间TotalTimeMs 这个指标是由4个其他指标的总和构成：
1) queue：处于请求队列中的等待时间
2) local:leader节点处理的时间
3) remote：等待follower节点响应的时间（只有当quired.acks=-1时）
4) respon：发送响应的时间
通常情况下，这个指标值是⽐较稳定的，只有很⼩的波动。当你看到不规则的数据波动，你必须检查每⼀
个queue,local,remote和respon的值，从⽽定位处造成延迟的原因到底处于哪个阶段。
PurgatorySize 炼狱容量⼤⼩
（临时存放区
域）
请求炼狱（request purgatory）作为⼀
个临时存放的区域，使得⽣产
(produce)和消费(fetch)的请求在那⾥等
待直到被需要的时候。每个类型的请求
都有各⾃的参数配置，从⽽决定是否
（将消息）添加到炼狱中：
fetch：当fetch.wait.max.ms定义的时间
已到，还没有⾜够的数据来填充
（congsumer的fetch.min.bytes）请求
的时候，获取消息的请求就会被扔到炼
狱中。
produce：当quired.acks=-
1，所有的⽣产请求都会被暂时放到炼
狱中，直到partition leader收到
follower的确认消息。
关注炼狱的⼤⼩有助于判断导致延迟的
原因是什么，⽐如说，导致fetch时间
的增加，很显然可以认为是由于炼狱中
fetch的请求增加了。
BytesInPerSec/ BytesOutPerSec 每秒输⼊字节
数/每秒输出字
节数
通常，磁盘的吞吐量往往是决定kafka
性能的瓶颈，但也不是说⽹络就不会成
为瓶颈。
跟踪节点之间的⽹络吞吐量，可以帮助
你找到潜在的瓶颈在哪⾥，⽽且可以帮
助决策是否需要把端到端的消息做压缩
处理。
主机层⾯的中间性能指标
指标名称名词解释指标解析
Page cache read ratio页缓存读取率kafka在设计最初的时候，通过内核中的页缓存，来达到沟通可靠性（基于磁盘）和⾼效性（基于内存）之间的桥梁。
如果这个值⽐较⼤，则等价于更快的读取速度，从⽽有更好的性能。
如果发现页缓存读取率<80%，则说明需要增加broker了。
Disk usage磁盘使⽤情况由于kafka将所有数据持久化到磁盘上，很有必要监控⼀下kafka的剩余磁盘空间。当磁盘占满时，kafka会失败，所以，随着时间的推移，跟踪磁盘的增长率是很有必要的。⼀旦你了解了磁盘的增长速率，你就可以在磁盘将要占满之前选择⼀个合适的时间通知管理员。
CPU usage CPU使⽤情况尽管kafka主要的瓶颈通常是内存，但并不妨碍观察⼀下cpu的使⽤率。虽然即便在使⽤gzip压缩的场景下，cpu都不太可能对性能产⽣影响，但是，如果发现cpu使⽤率突然增⾼，那肯定要引起重视了。
Network bytes Sent / received 发送/接收的⽹
络字节数
如果你只是在监控kafka的⽹络in/out指
标，那你只会了解到跟kafka相关的信
息。如果要全⾯了解主机的⽹络使⽤情
况，你必须监控主机层⾯的⽹络吞吐
量，尤其是当你的kafka主机还承载了
其他与⽹络有关的服务。⾼⽹络使⽤率
是性能下降的⼀种表现，此时需要联系
TCP重传和丢包错误，来决定性能的
问题是否是⽹络相关的。
JVM垃圾回收指标
由于kafka是由scala编写的，且运⾏在java虚拟机上，需要依赖java的垃圾回收机制来释放内存，如果kafka集群越活跃，则垃圾回收的频率也就越⾼。指标名称MBean 名称指标解析
ParNew count
年轻代（新对象）java.lang:type=GarbageCollector,name=ParNew
ParNew是⼀个stop-the-world的垃圾回收，
意味着所有应⽤线程都将被暂停，直到垃圾
回收完成，所以ParNew延迟的任何增加都
会对kafka的性能造成严重影响。
ParNew time年轻代回收时间（毫秒）java.lang:type=GarbageCollector,name=ParNew
年轻代回收耗时越⼤说明年轻代回收会导致
应⽤线程被暂停时间越长，导致Kafka性能
影响。
ConcurrentMarkSweep
(CMS) ⽼年代(长期存活的对象)回收java.lang:type=GarbageCollector,name=ConcurrentMarkSweep
这种垃圾回收清理了堆上的⽼年代不⽤的内
存，CMS是⼀个短暂暂停的垃圾回收算法，
尽管会造成应⽤线程的短暂停顿，但这只是
间歇性的，如果CMS需要⼏秒钟才能完成，
或者发⽣的频次增加，那么集群就没有⾜够
的内存来满⾜基本功能。
ConcurrentMarkSweep
time
⽼年代回收时间(毫秒)java.lang:type=GarbageCollector,name=ConcurrentMarkSweep
⽼年代回收时间越长，消耗的内存越⼤。
消耗的内存过⼤会影响Kafka的性能。
kafka⽣产者指标
kafka的⽣产者是专门把消息推送到broker的topic上供别⼈消费的，如果producer失败了，那consumer也将⽆法消费到新的消息，下⾯是⽣产者的⼏个有⽤的重要监控指标，保证数据流的稳定性。
指标名称MBean 名称指标解析
对⽣产者来说，响应速率表⽰从broker上得
到响应的速率，当broker接收到producer的
数据时会给出响应，根据配置，“接收到”包
含三层意思：
Respon rate
producer从Broker接收到消息的平均响应数/秒kafka.producer:type=producer-
metrics,client-id=([-.w]+)
消息已接收到，但并未确
认(quired.acks == 0)
leader已经把数据写⼊磁盘
(quired.acks == 1)
leader节点已经从其他follower节点上接收到
了数据已写⼊磁盘的确认消息
(quired.acks == -1)
如果响应速率过低，检查broker上配置的
场景来选择合适的值，到底是更看中可⽤性
（availability）还是持久性
（consistency），前者强调消费者是否能尽
快读取到可⽤的消息，⽽后者强调消息是否
准确⽆误地持久化写⼊某个topic的某个
partition的所有副本的磁盘中。
Request rate
数据从producer发送到broker的速率kafka.producer:type=producer-
metrics,client-id=([-.w]+)
请求越多速率越⾼的话，broker就将变得很
慢，因为他要忙于处理⼤量涌⼊的数据。
Request latency average
Producer（⽣产者）发送到broker（中间
商）的平均请求延迟时间（毫秒），即发送上⼀批消息与下⼀批消息的间隔时间（平均延迟时间）kafka.producer:type=producer-
metrics,client-id=([-.w]+)
Producer 发送消息给broker后收到响应确
认后默认会⽴即发送新消息，但是为了提⾼
吞吐量，会设置⼀个延迟时间linger.ms。
batch.size这个producer配置项
并不是只要配置⼀个合适的值就可以⼀劳永
逸了，要视情况决定如何选择⼀个更优的批
⼤⼩。要记住，你所配置的批⼤⼩是⼀个上
限值，意思是说，如果数据满了，就⽴即发
送，但如果没满的话，最多只等linger.ms毫
秒。
⼩的批量将会导致更多次数的⽹络通信，然
后降低吞吐量，反之亦然。
Outgoing byte rate
Producer（⽣产者）发送消息到broker（中间商）的消息速率kafka.producer:type=producer-
metrics,client-id=([-.w]+)
监控producer的⽹络传输情况，除了可以决
定是否需要调整⽹络设备，也可以了解
producer的⽣产效率，以及定位传输延迟的
原因。
IO wait time
Producer⽣产者所在服务器的CPU停下来等
待平均时间，即
I/O 线程等待套接字所花费的平均时间（以ns 为单位）kafka.producer:type=producer-
metrics,client-id=([-.w]+)
当producer产⽣了超越他发送能⼒的数据
量，那结果就是只能等待⽹络资源。当如果
producer没有发送速度限制，或者尽可能增
加带宽，就很难说这（⽹络延迟）是个瓶颈
了。因为磁盘的读写速率往往是最耗时的⼀
个环节，所以对producer⽽⾔，最好检查⼀
下I/O等待的时间。
可以考虑更换更快速度的固态磁盘提⾼磁盘
的读写速度来降低IO wait time。
Kafka消费者指标
指标名称MBean 名称指标解析ConsumerLag
(消费者落后于⽣产者的消息数
/MaxLag broker offt - consumer offt
Attribute: records-lag-max,
fetch-manager-metrics,client-id=
([-.w]+)
ConsumerLag是指consumer当前的⽇志偏
移量相对⽣产者的⽇志偏移量，MaxLag和
ConsumerLag的关系很紧密，相当于是观察
到的ConsumerLag的最⼤值，这两个度量指
标的重要性在于，可以决定你的消费者在做
什么。如果采⽤⼀个消费者组在存储设备上
存储⼤量⽼的消息，你就需要重点关注消费
者的延迟。当然，如果你的消费者处理的是
实时消息，如果lag值⼀直居⾼不下，那就说
明消费者有些过载（overloaded）了，遇到
这种情况，就需要采⽤更多的消费者，和把
topic切分成多个parition，从⽽可以提⾼吞
消费者落后于⽣产者的最⼤
消息数
吐量和降低延迟。
注意：ConsumerLag 是kafka之中过载的表
现，正如上⾯的定义中所描述的额⼀样，但
它也可被⽤来表⽰partition leader和follower
之间的offt差异。
BytesPerSec 每秒消耗字节数sumer:type=consumer-
fetch-manager-metrics,client-id=
([-.\w]+)
需要监控消费者的⽹络吞吐量。
⽐如，MessagesPerSec的突然下降可能会
导致消费失败，但如果BytesPerSec还保持
不变，那如果消费少批次⼤体量的消息问题
还不⼤。不断观察⽹络的流量，就像其他度
量指标中提到的⼀样，诊断不正常的⽹络使
⽤情况是很重要的。
MessagesPerSec 每秒消耗的消息数sumer:type=consumer-
fetch-manager-metrics,client-id=
([-.\w]+)
消息的消费速度并不完全等同于⽐特的消费
速度，因为消息本⾝可能有不同⼤⼩。
通过随着时间的推移监控这个指标，可以观
察出消费数据的趋势，然后定出⼀个基线，
从⽽确定告警的阈值。这个曲线的⾛势取决
于你的使⽤场景，但不管怎样，在很多情况
下，定出⼀条基线然后对于异常情况做出告
警是很有必要的。
ZooKeeperCommitsPerSec
消费者补偿提交到ZooKeeper 的⽐率N/A
0.9+版本必须显式地在配置中定义
offts.storage=zookeeper），那你肯定需
要监控这个值。注意到如果想要在0.9+版本
中明确使⽤zookeeper作为offt存储，这个
指标并没有被开放。当zookeeper处于⾼写
负载的时候，将会遇到成为性能瓶颈，从⽽
导致从kafka管道抓取数据变得缓慢。随着时
间推移跟踪这个指标，可以帮助定位到
zookeeper的性能问题，如果发现有⼤量发
往zookeeper的commit请求，你需要考虑的
是，要不对zookeeper集群进⾏扩展，要不
直接把offt的存储变为
kafka（offts.storage=kafka）。记住，这
个指标只对⾼阶消费者有⽤，简单消费者⾃
⾏管理offt。
MinFetchRate
消费者最⼩拉取速率Attribute: fetch-rate,
fetch-manager-metrics,client-id=
([-.w]+)
消费者拉取的速率很好反映了消费者的整体
健康状况，如果最⼩拉取速率接近0的话，
就可能说明消费者出现问题了，对⼀个健康
的消费者来说，最⼩拉取速率通常都是⾮0
的，所以如果发现这个值在下降，往往就是
消费者失败的标志。
Redis ⼏种主流监控⼯具：
1. redis-stat 测试推荐使⽤，安装部署简单，指标清晰
2. RedisLive
3. redis_exporter + grafana + Prometheus Redis插件⽣产环境监控使⽤redis-stat监控参数项说明：
性能指标：Performance
指标名称名词解释
latency Redis响应⼀个请求的时间instantaneous_ops_per_c平均每秒处理请求总数
hi rate(calculated)缓存命中率（计算出来的）
内存指标：memory
指标名称名词解释
ud_memory已使⽤内存
mem_fragmentation_ratio内存碎⽚率
