880
HBase 集群監控
為什麼需要監控？
為了保證係統的穩定性，可靠性，可運維性。
- 掌控集群的核心性能指標，了解集群的性能表現。
- 集群出現問題時及時報警，便於運維同學及時修複問題。
- 集群重要指標值異常時進行預警，將問題扼殺在搖籃中，不用等集群真正不可用時才采取行動。
- 當集群出現問題時，監控係統可以幫助我們更快的定位問題和解決問題
如何構建 HBase 集群監控係統？
公司有自己的監控係統，我們所要做的就是將 HBase 中我們關心的指標項發送到監控係統去，問題就轉換為我們開發，采集並返回哪些 HBase 集群監控指標項。
HBase 集群監控指標
采集的監控數據主要包括以下幾個方麵：某台機器 OS 層麵上的數據，例如 CPU、內存、磁盤、網絡、load、網絡流量等；某台 regionserver（或master）機器 jvm 的狀態，例如關於線程的信息，GC 的次數和時間，內存使用狀況，以及 ERROR、WARN、Fatal 事件出現的次數；regionserver（或 master）進程中的統計信息。
可以通過以下地址獲取 HBase 提供的 JMX 信息的 web 頁麵
https://your_master:60010/jmx //所有的bean
JMX web 頁麵的數據格式是json格式，信息很多！
OS 監控數據
HBase 中對於 OS 的監控數據，主要是 OperatingSystem 的對象來進行的，如下就是我提取出來的 JSON 信息，
{
"name" : "java.lang:type=OperatingSystem",
"modelerType" : "com.sun.management.UnixOperatingSystem",
"MaxFileDescriptorCount" : 1000000,
"OpenFileDescriptorCount" : 413,
"CommittedVirtualMemorySize" : 1892225024,
"FreePhysicalMemorySize" : 284946432,
"FreeSwapSpaceSize" : 535703552,
"ProcessCpuLoad" : 0.0016732901066722444,
"ProcessCpuTime" : 59306210000000,
"SystemCpuLoad" : 0.018197029910060655,
"TotalPhysicalMemorySize" : 16660848640,
"TotalSwapSpaceSize" : 536862720,
"AvailableProcessors" : 8,
"Arch" : "amd64",
"SystemLoadAverage" : 0.0,
"Name" : "Linux",
"Version" : "2.6.32-431.11.7.el6.ucloud.x86_64",
"ObjectName" : "java.lang:type=OperatingSystem"
}
其中比較重要的指標有 OpenFileDescriptorCount , FreePhysicalMemorySize , ProcessCpuLoad , SystemCpuLoad , AvailableProcessors , SystemLoadAverage
JVM 監控數據
Hbase 中對於 JVM 的監控數據，主要是 JvmMetrics 的對象來進行的，如下就是我提取出來的 JSON 信息，
{
"name" : "Hadoop:service=HBase,name=JvmMetrics",
"modelerType" : "JvmMetrics",
"tag.Context" : "jvm",
"tag.ProcessName" : "Master",
"tag.SessionId" : "",
"tag.Hostname" : "uhadoop-qrljqo-master2",
"MemNonHeapUsedM" : 53.846107,
"MemNonHeapCommittedM" : 85.84375,
"MemNonHeapMaxM" : 130.0,
"MemHeapUsedM" : 79.05823,
"MemHeapCommittedM" : 240.125,
"MemHeapMaxM" : 989.875,
"MemMaxM" : 989.875,
"GcCountParNew" : 15190,
"GcTimeMillisParNew" : 72300,
"GcCountConcurrentMarkSweep" : 2,
"GcTimeMillisConcurrentMarkSweep" : 319,
"GcCount" : 15192,
"GcTimeMillis" : 72619,
"ThreadsNew" : 0,
"ThreadsRunnable" : 21,
"ThreadsBlocked" : 0,
"ThreadsWaiting" : 144,
"ThreadsTimedWaiting" : 18,
"ThreadsTerminated" : 0,
"LogFatal" : 0,
"LogError" : 0,
"LogWarn" : 0,
"LogInfo" : 0
}
JvmMetrics 主要統計的信息包括：內存的使用狀態信息；GC的統計信息；線程的統計信息；以及事件的統計信息。
內存的統計信息主要是：JVM 當前已經使用的 NonHeapMemory 的大小、以及配置的 NonHeapMemory 的大小；JVM 當前已經使用的 HeapMemory 的大小、以及配置的 HeapMemory 的大小； JVM 運行時的可以使用的最大的內存的大小。
GC 的統計較為簡單，僅統計了進程在固定間隔內 GC 的次數和花費的總時間。
線程的統計，主要是統計進程內當前線程的處於 NEW 、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED 這六種狀態下的線程數量。
對於事件的統計，主要統計固定時間間隔內的 Fatal、Error、Warn 以及 Info 的數量。(這塊好像不怎麼重要)
Region Servers 健康
你也可以通過如下地址：
https://your_master:60010/jmx?qry=Hadoop:service=HBase,name=Master,sub=Server
獲得到 Region Servers 健康值：
{
"name" : "Hadoop:service=HBase,name=Master,sub=Server",
"modelerType" : "Master,sub=Server",
"tag.liveRegionServers" : "xxx",
"tag.deadRegionServers" : "",
"tag.zookeeperQuorum" : "xxx",
"tag.serverName" : "xxx2,60000,1495683310213",
"tag.clusterId" : "e5e044a3-ef9f-48f7-ba63-637376f5fa90",
"tag.isActiveMaster" : "true",
"tag.Context" : "master",
"tag.Hostname" : "xxx",
"masterActiveTime" : 1495683312239,
"masterStartTime" : 1495683310213,
"averageLoad" : 143.66666666666666,
"numRegionServers" : 3,
"numDeadRegionServers" : 0,
"clusterRequests" : 1297834323
}
MemoryPool
從全部的 JSON 值中你會看到很多種 MemoryPool 值，比如 Par Eden Space 、CMS Perm Gen、Par Survivor Space、CMS Old Gen、Code Cache ，按需獲取吧。
總結
任何一個服務的監控係統都是一個不斷迭代，不斷優化的過程，不可能一開始就做到最好。監控總是比問題發生來的更早一些，而每一次出問題，又進一步加強相應方麵的監控，我們需要讓監控係統從出問題時才報警到可能出現問題時就預警逐漸過渡，最終讓監控係統成為我們保證係統穩定性的一個有力工具。
最後
監控指標有很多，但請按需獲取 ! 轉載文章請注明原出處，謝謝支持！ https://www.54tianzhisheng.cn/2017/10/21/HBase-metrics/
參考資料
推薦相關文章
最後更新：2017-10-21 22:03:24