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.* |