Kafka 几种主流监控工具：
- Kafka Web Conslole 测试环境使用 功能全面强大 - 不推荐生产环境使用
- Kafka Manager 管理集群使用
- KafkaOffsetMonitor 实时监控使用 - 测试监控推荐
KafkaOffsetMonitor 中的参数项说明：
topic：创建时topic名称
partition：分区编号
offset：表示该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节点响应的时间（只有当requests.required.acks=-1时） 4) response:发送响应的时间 通常情况下，这个指标值是比较稳定的，只有很小的波动。当你看到不规则的数据波动，你必须检查每一个queue,local,remote和response的值，从而定位处造成延迟的原因到底处于哪个阶段。 |
| PurgatorySize |
炼狱容量大小 （临时存放区域） |
请求炼狱（request purgatory）作为一个临时存放的区域，使得生产(produce)和消费(fetch)的请求在那里等待直到被需要的时候。每个类型的请求都有各自的参数配置，从而决定是否（将消息）添加到炼狱中： fetch：当fetch.wait.max.ms定义的时间已到，还没有足够的数据来填充（congsumer的fetch.min.bytes）请求的时候，获取消息的请求就会被扔到炼狱中。 produce：当request.required.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 名称 |
指标解析 |
| Response rate producer从Broker接收到消息的平均响应数 / 秒
|
kafka.producer:type=producer-metrics,client-id=([-.w]+) |
对生产者来说，响应速率表示从broker上得到响应的速率，当broker接收到producer的数据时会给出响应，根据配置，“接收到”包含三层意思： 消息已接收到，但并未确认(request.required.acks == 0) leader已经把数据写入磁盘(request.required.acks == 1) leader节点已经从其他follower节点上接收到了数据已写入磁盘的确认消息(request.required.acks == -1) 如果响应速率过低，检查broker上配置的request.required.acks参数，根据你的使用场景来选择合适的值，到底是更看中可用性（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 offset - consumer offset Attribute: records-lag-max, kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.w]+) |
ConsumerLag是指consumer当前的日志偏移量相对生产者的日志偏移量，MaxLag和ConsumerLag的关系很紧密，相当于是观察到的ConsumerLag的最大值，这两个度量指标的重要性在于，可以决定你的消费者在做什么。如果采用一个消费者组在存储设备上存储大量老的消息，你就需要重点关注消费者的延迟。当然，如果你的消费者处理的是实时消息，如果lag值一直居高不下，那就说明消费者有些过载（overloaded）了，遇到这种情况，就需要采用更多的消费者，和把topic切分成多个parition，从而可以提高吞吐量和降低延迟。 注意：ConsumerLag 是kafka之中过载的表现，正如上面的定义中所描述的额一样，但它也可被用来表示partition leader和follower之间的offset差异。
|
| BytesPerSec 每秒消耗字节数 |
kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.\w]+) |
需要监控消费者的网络吞吐量。 比如，MessagesPerSec的突然下降可能会导致消费失败，但如果BytesPerSec还保持不变，那如果消费少批次大体量的消息问题还不大。不断观察网络的流量，就像其他度量指标中提到的一样，诊断不正常的网络使用情况是很重要的。 |
| MessagesPerSec 每秒消耗的消息数 |
kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.\w]+) |
消息的消费速度并不完全等同于比特的消费速度，因为消息本身可能有不同大小。 通过随着时间的推移监控这个指标，可以观察出消费数据的趋势，然后定出一个基线，从而确定告警的阈值。这个曲线的走势取决于你的使用场景，但不管怎样，在很多情况下，定出一条基线然后对于异常情况做出告警是很有必要的。 |
| ZooKeeperCommitsPerSec 消费者补偿提交到 ZooKeeper 的比率 |
N/A |
0.9+版本必须显式地在配置中定义offsets.storage=zookeeper），那你肯定需要监控这个值。注意到如果想要在0.9+版本中明确使用zookeeper作为offset存储，这个指标并没有被开放。当zookeeper处于高写负载的时候，将会遇到成为性能瓶颈，从而导致从kafka管道抓取数据变得缓慢。随着时间推移跟踪这个指标，可以帮助定位到zookeeper的性能问题，如果发现有大量发往zookeeper的commit请求，你需要考虑的是，要不对zookeeper集群进行扩展，要不直接把offset的存储变为kafka（offsets.storage=kafka）。记住，这个指标只对高阶消费者有用，简单消费者自行管理offset。 |
| MinFetchRate 消费者最小拉取速率 |
Attribute: fetch-rate, kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.w]+) |
消费者拉取的速率很好反映了消费者的整体健康状况，如果最小拉取速率接近0的话，就可能说明消费者出现问题了，对一个健康的消费者来说，最小拉取速率通常都是非0的，所以如果发现这个值在下降，往往就是消费者失败的标志。 |
Redis 几种主流监控工具：
- redis-stat 测试推荐使用，安装部署简单，指标清晰
- RedisLive
- redis_exporter + grafana + Prometheus Redis插件 生产环境监控使用
redis-stat监控参数项说明：
性能指标：Performance
| 指标名称 | 名词解释 |
|---|---|
| latency | Redis响应一个请求的时间 |
| instantaneous_ops_per_sec | 平均每秒处理请求总数 |
| hi rate(calculated) | 缓存命中率（计算出来的） |
内存指标：memory
| 指标名称 | 名词解释 |
|---|---|
| used_memory | 已使用内存 |
| mem_fragmentation_ratio | 内存碎片率 |
| evicted_keys | 由于最大内存限制被移除的key的数量 |
| blocked_clients | 由于BLPOP,BRPOP,or BRPOPLPUSH而备阻塞的客户端 |
基本活动指标：Basic activity
| 指标名称 | 名称解释 |
|---|---|
| connected_clients | 客户端连接数 |
| conected_laves | slave数量 |
| master_last_io_seconds_ago | 最近一次主从交互之后的秒数 |
| keyspace | 数据库中的key值总数 |
持久性指标: Persistence
| 指标名称 |
名词解释 |
| rdb_last_save_time |
最后一次持久化保存磁盘的时间戳 |
| rdb_changes_sice_last_save |
自最后一次持久化以来数据库的更改数 |
| 指标名称 | 名词解释 |
|---|---|
| rejected_connections | 由于达到maxclient限制而被拒绝的连接数 |
| keyspace_misses | key值查找失败(没有命中)次数 |
| master_link_down_since_seconds | 主从断开的持续时间（以秒为单位) |
ElasticSearch 几种主流监控工具：
- Cerebro 推荐使用
- Elaticsearch-HQ
ElasticSearch 指标说明
集群运行的重要指标：
Status：状态群集的状态。红色：部分主分片未分配。黄色：部分副本分片未分配。绿色：所有分片分配ok。
Nodes：节点。包括群集中的节点总数，并包括成功和失败节点的计数。 Count of Active
Shards：活动分片计数。集群中活动分片的数量。 Relocating Shards：重定位分片。由于节点丢失而移动的分片计数。
Initializing Shards：初始化分片。由于添加索引而初始化的分片计数。 Unassigned
Shards。未分配的分片。尚未创建或分配副本的分片计数。
————————————————
请求检索性能相关的重要指标如下：
query_current：当前正在进行的查询数。集群当前正在处理的查询计数。
fetch_current：当前正在进行的fetch次数。集群中正在进行的fetch计数。
query_total：查询总数。集群处理的所有查询的聚合数。
query_time_in_millis：查询总耗时。所有查询消耗的总时间（以毫秒为单位）。
fetch_total：提取总数。集群处理的所有fetch的聚合数。
fetch_time_in_millis：fetch所花费的总时间。所有fetch消耗的总时间（以毫秒为单位）。
————————————————
索引性能维度相关重要指标：
refresh.total：总刷新计数。刷新总数的计数。
refresh.total_time_in_millis：刷新总时间。汇总所有花在刷新的时间（以毫秒为单位进行测量）。
merges.current_docs：目前的合并。合并目前正在处理中。
merges.total_docs：合并总数。合并总数的计数。
merges.total_stopped_time_in_millis。合并花费的总时间。合并段的所有时间的聚合。
————————————————
节点运行的重要指标：
disk.total ：总磁盘容量。节点主机上的总磁盘容量。
disk.used：总磁盘使用量。节点主机上的磁盘使用总量。
avail disk：可用磁盘空间总量。
disk.avail disk.used_percent：使用的磁盘百分比。已使用的磁盘百分比。
ram：当前的RAM使用情况。当前内存使用量（测量单位）。
percent ram：RAM百分比。正在使用的内存百分比。
max : 最大RAM。 节点主机上的内存总量
cpu：中央处理器。正在使用的CPU百分比。
————————————————
JVM运行的重要指标如下：
mem：内存使用情况。堆和非堆进程和池的使用情况统计信息。
threads：当前使用的线程和最大数量。
gc：垃圾收集。算和垃圾收集所花费的总时间。
————————————————
常用监控指标：
Cluster Health – Nodes and Shards
Search Performance – Request Latency and
Search Performance – Request Rate
Indexing Performance – Refresh Times
Indexing Performance – Merge Times
Node Health – Memory Usage
Node Health – Disk I/O
Node Health – CPU
JVM Health – Heap Usage and Garbage Collection
JVM health – JVM Pool Size
RabbitMQ 主流监控工具：
- rabbitmq_management插件
- RabbitMQ自带的tracing Log插件
集群范围指标
| 指标名称 |
指标字段 |
| Cluster-wide message rates消息速率 |
message_stats |
| Total number of connections连接总数 |
object_totals.connections |
| Total number of channels通道总数 |
object_totals.channels |
| Total number of queues队列总数 |
object_totals.queues |
| Total number of consumers消费者总数 |
object_totals.consumers |
| Total number of messages (ready plus unacknowledged)就绪未确认总数 |
queue_totals.messages |
| Number of messages ready for delivery准备发送消息数 |
queue_totals.messages_ready |
| Number of unacknowledged messages未确认消息数 |
queue_totals.messages_unacknowledged |
| Messages published recently最近发布消息 |
message_stats.publish |
| Message publish rate消息发布率 |
message_stats.publish_details.rate |
| Messages delivered to consumers recently 最近传递给消费者消费数 |
message_stats.publish |
| Message delivery rate消息传递率 |
message_stats.deliver_get.rate |
| Other message stats其他消息统计 |
message_stats |
节点指标：
| 指标名称 |
指标字段 |
| Total amount of memory used使用总量 |
mem_used |
| Memory usage high watermark 内存使用限制 |
mem_limit |
| Is a memory alarm in effect? 内存阀值 |
mem_alarm |
| Free disk space low watermark可用磁盘空间 |
disk_free_limit |
| Is a disk alarm in effect?磁盘空闲警报 |
disk_free_alarm |
| File descriptors available可用有效文件 |
fd_total |
| File descriptors used 使用的文件 |
fd_used |
| File descriptor open attempts可用套接字 |
sockets_total |
| Sockets available sockets_total已使用套接字 |
sockets_used |
| Message store disk reads消息存储磁盘读取 |
message_stats.disk_reads |
| Message store disk writes消息存储磁盘写入 |
message_stats.disk_writes |
| Inter-node communication link节点通信链接数 |
cluster_links |
| GC runs GC运行数 |
gc_num |
| Bytes reclaimed by GC 回收GC的字节数 |
gc_bytes_reclaimed |
| Erlang process limitErlang进程限制总数 |
proc_total |
| Erlang processes used Erlang 进程已使用数 |
proc_used |
| Runtime run queue 运行队列 |
run_queue |
单个队列指标
| 指标名称 |
指标字段 |
| Memory 内存数 |
Memory |
| Total number of messages 消息总数（准备+未确认） |
(ready plus unacknowledged) messages |
| Number of messages ready for delivery准备发送的消息数 |
messages_ready |
| Number of unacknowledged messages 未确认消息数 |
messages_unacknowledged |
| Messages published recently 最近发布的消息 |
message_stats.publish |
| Message publishing rate 消息发布率 |
message_stats.publish_details.rate |
| Messages delivered recently 最近发布的消息 |
message_stats.deliver_get |
| Message delivery rate 消息传递速率 |
message_stats.deliver_get.rate |
| Other message stats 其他消息统计 |
message_stats.* |