ElasticSearch 單個節(jié)點監(jiān)控

ky0ncheng 發(fā)布于2019-08-16 11:00 / 2167人閱讀

摘要：會展示這個節(jié)點目前正在服務(wù)中的段的數(shù)量。線程池部分在內(nèi)部維護了線程池。這些線程池相互協(xié)作完成任務(wù)，有必要的話相互間還會傳遞任務(wù)。每個線程池會列出已配置的線程數(shù)量，當(dāng)前在處理任務(wù)的線程數(shù)量，以及在隊列中等待處理的任務(wù)單元數(shù)量。

集群健康監(jiān)控是對集群信息進行高度的概括，節(jié)點統(tǒng)計值 API 提供了集群中每個節(jié)點的統(tǒng)計值。節(jié)點統(tǒng)計值很多，在監(jiān)控的時候仍需要我們清楚哪些指標(biāo)是最值得關(guān)注的。

集群健康監(jiān)控可以參考這篇文章：ElasticSearch 集群監(jiān)控

節(jié)點信息 Node Info :

curl -XGET "http://localhost:9200/_nodes"

執(zhí)行上述命令可以獲取所有 node 的信息

_nodes: {
  total: 2,
  successful: 2,
  failed: 0
},
cluster_name: "elasticsearch",
nodes: {
    MSQ_CZ7mTNyOSlYIfrvHag: {
    name: "node0",
    transport_address: "192.168.180.110:9300",
    host: "192.168.180.110",
    ip: "192.168.180.110",
    version: "5.5.0",
    build_hash: "260387d",
    total_indexing_buffer: 103887667,
    roles:{...},
    settings: {...},
    os: {
      refresh_interval_in_millis: 1000,
      name: "Linux",
      arch: "amd64",
      version: "3.10.0-229.el7.x86_64",
      available_processors: 4,
      allocated_processors: 4
    },
    process: {
      refresh_interval_in_millis: 1000,
      id: 3022,
      mlockall: false
    },
    jvm: {
      pid: 3022,
      version: "1.8.0_121",
      vm_name: "Java HotSpot(TM) 64-Bit Server VM",
      vm_version: "25.121-b13",
      vm_vendor: "Oracle Corporation",
      start_time_in_millis: 1507515225302,
      mem: {
      heap_init_in_bytes: 1073741824,
      heap_max_in_bytes: 1038876672,
      non_heap_init_in_bytes: 2555904,
      non_heap_max_in_bytes: 0,
      direct_max_in_bytes: 1038876672
      },
      gc_collectors: [],
      memory_pools: [],
      using_compressed_ordinary_object_pointers: "true",
      input_arguments:{}
    }
    thread_pool:{
      force_merge: {},
      fetch_shard_started: {},
      listener: {},
      index: {},
      refresh: {},
      generic: {},
      warmer: {},
      search: {},
      flush: {},
      fetch_shard_store: {},
      management: {},
      get: {},
      bulk: {},
      snapshot: {}
    }
    transport: {...},
    http: {...},
    plugins: [],
    modules: [],
    ingest: {...}
 }

上面是我已經(jīng)簡寫了很多數(shù)據(jù)之后的返回值，但是指標(biāo)還是很多，有些是一些常規(guī)的指標(biāo)，對于監(jiān)控來說，沒必要拿取。從上面我們可以主要關(guān)注以下這些指標(biāo):

os, process, jvm, thread_pool, transport, http, ingest and indices

節(jié)點統(tǒng)計 nodes-statistics

節(jié)點統(tǒng)計值 API 可通過如下命令獲取：

GET /_nodes/stats

得到：

_nodes: {
  total: 2,
  successful: 2,
  failed: 0
},
cluster_name: "elasticsearch",
nodes: {
  MSQ_CZ7mTNyOSlYI0yvHag: {
    timestamp: 1508312932354,
    name: "node0",
    transport_address: "192.168.180.110:9300",
    host: "192.168.180.110",
    ip: "192.168.180.110:9300",
    roles: [],
    indices: {
      docs: {
           count: 6163666,
           deleted: 0
        },
      store: {
           size_in_bytes: 2301398179,
           throttle_time_in_millis: 122850
        },
      indexing: {},
      get: {},
      search: {},
      merges: {},
      refresh: {},
      flush: {},
      warmer: {},
      query_cache: {},
      fielddata: {},
      completion: {},
      segments: {},
      translog: {},
      request_cache: {},
      recovery: {}
  },
  os: {
    timestamp: 1508312932369,
    cpu: {
      percent: 0,
      load_average: {
        1m: 0.09,
        5m: 0.12,
        15m: 0.08
      }
    },
    mem: {
      total_in_bytes: 8358301696,
      free_in_bytes: 1381613568,
      used_in_bytes: 6976688128,
      free_percent: 17,
      used_percent: 83
    },
    swap: {
      total_in_bytes: 8455712768,
      free_in_bytes: 8455299072,
      used_in_bytes: 413696
    },
    cgroup: {
      cpuacct: {},
      cpu: {
        control_group: "/user.slice",
        cfs_period_micros: 100000,
        cfs_quota_micros: -1,
        stat: {}
      }
  }
},
process: {
  timestamp: 1508312932369,
  open_file_descriptors: 228,
  max_file_descriptors: 65536,
  cpu: {
    percent: 0,
    total_in_millis: 2495040
  },
  mem: {
    total_virtual_in_bytes: 5002465280
  }
},
jvm: {
  timestamp: 1508312932369,
  uptime_in_millis: 797735804,
  mem: {
    heap_used_in_bytes: 318233768,
    heap_used_percent: 30,
    heap_committed_in_bytes: 1038876672,
    heap_max_in_bytes: 1038876672,
    non_heap_used_in_bytes: 102379784,
    non_heap_committed_in_bytes: 108773376,
  pools: {
    young: {
      used_in_bytes: 62375176,
      max_in_bytes: 279183360,
      peak_used_in_bytes: 279183360,
      peak_max_in_bytes: 279183360
    },
    survivor: {
      used_in_bytes: 175384,
      max_in_bytes: 34865152,
      peak_used_in_bytes: 34865152,
      peak_max_in_bytes: 34865152
    },
    old: {
      used_in_bytes: 255683208,
      max_in_bytes: 724828160,
      peak_used_in_bytes: 255683208,
      peak_max_in_bytes: 724828160
    }
  }
  },
  threads: {},
  gc: {},
  buffer_pools: {},
  classes: {}
},
  thread_pool: {
    bulk: {},
    fetch_shard_started: {},
    fetch_shard_store: {},
    flush: {},
    force_merge: {},
    generic: {},
    get: {},
    index: {
       threads: 1,
       queue: 0,
       active: 0,
       rejected: 0,
       largest: 1,
       completed: 1
    }
    listener: {},
    management: {},
    refresh: {},
    search: {},
    snapshot: {},
    warmer: {}
  },
  fs: {},
  transport: {
    server_open: 13,
    rx_count: 11696,
    rx_size_in_bytes: 1525774,
    tx_count: 10282,
    tx_size_in_bytes: 1440101928
  },
  http: {
    current_open: 4,
    total_opened: 23
  },
  breakers: {},
  script: {},
  discovery: {},
  ingest: {}
}

節(jié)點名是一個 UUID，上面列舉了很多指標(biāo)，下面講解下：

索引部分 indices

這部分列出了這個節(jié)點上所有索引的聚合過的統(tǒng)計值：

docs 展示節(jié)點內(nèi)存有多少文檔，包括還沒有從段里清除的已刪除文檔數(shù)量。

store 部分顯示節(jié)點耗用了多少物理存儲。這個指標(biāo)包括主分片和副本分片在內(nèi)。如果限流時間很大，那可能表明你的磁盤限流設(shè)置得過低。

indexing 顯示已經(jīng)索引了多少文檔。這個值是一個累加計數(shù)器。在文檔被刪除的時候，數(shù)值不會下降。還要注意的是，在發(fā)生內(nèi)部索引操作的時候，這個值也會增加，比如說文檔更新。

還列出了索引操作耗費的時間，正在索引的文檔數(shù)量，以及刪除操作的類似統(tǒng)計值。

get 顯示通過 ID 獲取文檔的接口相關(guān)的統(tǒng)計值。包括對單個文檔的 GET 和 HEAD 請求。

search 描述在活躍中的搜索（ open_contexts ）數(shù)量、查詢的總數(shù)量、以及自節(jié)點啟動以來在查詢上消耗的總時間。用 query_time_in_millis / query_total 計算的比值，可以用來粗略的評價你的查詢有多高效。比值越大，每個查詢花費的時間越多，你應(yīng)該要考慮調(diào)優(yōu)了。

fetch 統(tǒng)計值展示了查詢處理的后一半流程（query-then-fetch 里的 fetch ）。如果 fetch 耗時比 query 還多，說明磁盤較慢，或者獲取了太多文檔，或者可能搜索請求設(shè)置了太大的分頁（比如， size: 10000 ）。

merges 包括了 Lucene 段合并相關(guān)的信息。它會告訴你目前在運行幾個合并，合并涉及的文檔數(shù)量，正在合并的段的總大小，以及在合并操作上消耗的總時間。

filter_cache 展示了已緩存的過濾器位集合所用的內(nèi)存數(shù)量，以及過濾器被驅(qū)逐出內(nèi)存的次數(shù)。過多的驅(qū)逐數(shù) 可能說明你需要加大過濾器緩存的大小，或者你的過濾器不太適合緩存（比如它們因為高基數(shù)而在大量產(chǎn)生，就像是緩存一個 now 時間表達式）。

不過，驅(qū)逐數(shù)是一個很難評定的指標(biāo)。過濾器是在每個段的基礎(chǔ)上緩存的，而從一個小的段里驅(qū)逐過濾器，代價比從一個大的段里要廉價的多。有可能你有很大的驅(qū)逐數(shù)，但是它們都發(fā)生在小段上，也就意味著這些對查詢性能只有很小的影響。

把驅(qū)逐數(shù)指標(biāo)作為一個粗略的參考。如果你看到數(shù)字很大，檢查一下你的過濾器，確保他們都是正常緩存的。不斷驅(qū)逐著的過濾器，哪怕都發(fā)生在很小的段上，效果也比正確緩存住了的過濾器差很多。

field_data 顯示 fielddata 使用的內(nèi)存，用以聚合、排序等等。這里也有一個驅(qū)逐計數(shù)。和 filter_cache 不同的是，這里的驅(qū)逐計數(shù)是很有用的：這個數(shù)應(yīng)該或者至少是接近于 0。因為 fielddata 不是緩存，任何驅(qū)逐都消耗巨大，應(yīng)該避免掉。如果你在這里看到驅(qū)逐數(shù)，你需要重新評估你的內(nèi)存情況，fielddata 限制，請求語句，或者這三者。

segments 會展示這個節(jié)點目前正在服務(wù)中的 Lucene 段的數(shù)量。這是一個重要的數(shù)字。大多數(shù)索引會有大概 50–150 個段，哪怕它們存有 TB 級別的數(shù)十億條文檔。段數(shù)量過大表明合并出現(xiàn)了問題（比如，合并速度跟不上段的創(chuàng)建）。注意這個統(tǒng)計值是節(jié)點上所有索引的匯聚總數(shù)。記住這點。

memory 統(tǒng)計值展示了 Lucene 段自己用掉的內(nèi)存大小。這里包括底層數(shù)據(jù)結(jié)構(gòu)，比如倒排表，字典，和布隆過濾器等。太大的段數(shù)量會增加這些數(shù)據(jù)結(jié)構(gòu)帶來的開銷，這個內(nèi)存使用量就是一個方便用來衡量開銷的度量值。

操作系統(tǒng)和進程部分

OS 和 Process 部分基本是自描述的，不會在細節(jié)中展開講解。它們列出來基礎(chǔ)的資源統(tǒng)計值，比如 CPU 和負載。OS 部分描述了整個操作系統(tǒng)，而 Process 部分只顯示 Elasticsearch 的 JVM 進程使用的資源情況。

這些都是非常有用的指標(biāo)，不過通常在你的監(jiān)控技術(shù)棧里已經(jīng)都測量好了。統(tǒng)計值包括下面這些：

CPU

負載

內(nèi)存使用率（mem.used_percent）

Swap 使用率

打開的文件描述符（open_file_descriptors）

JVM 部分

jvm 部分包括了運行 Elasticsearch 的 JVM 進程一些很關(guān)鍵的信息。最重要的，它包括了垃圾回收的細節(jié)，這對你的 Elasticsearch 集群的穩(wěn)定性有著重大影響。

jvm: {
  timestamp: 1508312932369,
  uptime_in_millis: 797735804,
  mem: {
    heap_used_in_bytes: 318233768,
    heap_used_percent: 30,
    heap_committed_in_bytes: 1038876672,
    heap_max_in_bytes: 1038876672,
    non_heap_used_in_bytes: 102379784,
    non_heap_committed_in_bytes: 108773376,
  }
}

jvm 部分首先列出一些和 heap 內(nèi)存使用有關(guān)的常見統(tǒng)計值。你可以看到有多少 heap 被使用了，多少被指派了（當(dāng)前被分配給進程的），以及 heap 被允許分配的最大值。理想情況下，heap_committed_in_bytes 應(yīng)該等于 heap_max_in_bytes 。如果指派的大小更小，JVM 最終會被迫調(diào)整 heap 大小——這是一個非常昂貴的操作。如果你的數(shù)字不相等，閱讀堆內(nèi)存:大小和交換學(xué)習(xí)如何正確的配置它。

heap_used_percent 指標(biāo)是值得關(guān)注的一個數(shù)字。Elasticsearch 被配置為當(dāng) heap 達到 75% 的時候開始 GC。如果你的節(jié)點一直 >= 75%，你的節(jié)點正處于 內(nèi)存壓力 狀態(tài)。這是個危險信號，不遠的未來可能就有慢 GC 要出現(xiàn)了。

如果 heap 使用率一直 >=85%，你就麻煩了。Heap 在 90–95% 之間，則面臨可怕的性能風(fēng)險，此時最好的情況是長達 10–30s 的 GC，最差的情況就是內(nèi)存溢出（OOM）異常。

線程池部分

Elasticsearch 在內(nèi)部維護了線程池。這些線程池相互協(xié)作完成任務(wù)，有必要的話相互間還會傳遞任務(wù)。通常來說，你不需要配置或者調(diào)優(yōu)線程池，不過查看它們的統(tǒng)計值有時候還是有用的，可以洞察你的集群表現(xiàn)如何。

每個線程池會列出已配置的線程數(shù)量（ threads ），當(dāng)前在處理任務(wù)的線程數(shù)量（ active ），以及在隊列中等待處理的任務(wù)單元數(shù)量（ queue ）。

如果隊列中任務(wù)單元數(shù)達到了極限，新的任務(wù)單元會開始被拒絕，你會在 rejected 統(tǒng)計值上看到它反映出來。這通常是你的集群在某些資源上碰到瓶頸的信號。因為隊列滿意味著你的節(jié)點或集群在用最高速度運行，但依然跟不上工作的蜂擁而入。

這里的一系列的線程池，大多數(shù)你可以忽略，但是有一小部分還是值得關(guān)注的：

indexing 普通的索引請求的線程池

bulk 批量請求，和單條的索引請求不同的線程池

get Get-by-ID 操作

search 所有的搜索和查詢請求

merging 專用于管理 Lucene 合并的線程池

網(wǎng)絡(luò)部分

transport 顯示和傳輸?shù)刂?/em> 相關(guān)的一些基礎(chǔ)統(tǒng)計值。包括節(jié)點間的通信（通常是 9300 端口）以及任意傳輸客戶端或者節(jié)點客戶端的連接。如果看到這里有很多連接數(shù)不要擔(dān)心；Elasticsearch 在節(jié)點之間維護了大量的連接。

http 顯示 HTTP 端口（通常是 9200）的統(tǒng)計值。如果你看到 total_opened 數(shù)很大而且還在一直上漲，這是一個明確信號，說明你的 HTTP 客戶端里有沒啟用 keep-alive 長連接的。持續(xù)的 keep-alive 長連接對性能很重要，因為連接、斷開套接字是很昂貴的（而且浪費文件描述符）。請確認你的客戶端都配置正確。
參考資料
1、nodes-info

2、nodes-stats

3、ES監(jiān)控指標(biāo)
最后：
轉(zhuǎn)載請注明地址：http://www.54tianzhisheng.cn/...

ElasticSearch 云解析監(jiān)控節(jié)點服務(wù)器節(jié)點監(jiān)控單個邊框單個表

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://specialneedsforspecialkids.com/yun/70893.html

上一篇：Java 8 并發(fā)：同步和鎖

下一篇：全文搜索引擎 Elasticsearch 集群搭建入門教程

相關(guān)文章

渣渣為什么要看 ElasticSearch 源碼？

摘要：當(dāng)時自己在本地測試搭建集群后，給分配了另外一個任務(wù)就是去了解中的自帶分詞英文分詞中文分詞的相同與差異以及自己建立分詞需要注意的點。還有就是官網(wǎng)的文檔了，非常非常詳細，還有，版本的是有中文的官方文檔，可以湊合著看。前提人工智能、大數(shù)據(jù)快速發(fā)展的今天，對于 TB 甚至 PB 級大數(shù)據(jù)的快速檢索已然成為剛需，大型企業(yè)早已淹沒在系統(tǒng)生成的浩瀚數(shù)據(jù)流當(dāng)中。大數(shù)據(jù)技術(shù)業(yè)已集中在如何存儲和處理這...

Cciradih 2019-08-19 11:03 評論0 收藏0

發(fā)表評論

登陸后可評論

0條評論

ky0ncheng

男|高級講師

我要關(guān)注我要私信

TA的文章
閱讀更多

使用fiddler進行mock測試

閱讀 711·2021-11-16 11:44

JavaScript中的原型與繼承

閱讀 3541·2019-08-26 12:13

React V16.9來了無痛感升級加入性能檢測【譯-真香】

閱讀 3236·2019-08-26 10:46

JavaScript專題之模擬實現(xiàn)call和apply

閱讀 2352·2019-08-23 12:37

react 官網(wǎng)動畫庫（react-transition-group）的新寫法

閱讀 1180·2019-08-22 18:30

react源碼解析之stack reconciler

閱讀 2526·2019-08-22 17:30

vue基礎(chǔ)知識匯總

閱讀 1835·2019-08-22 17:26

Local Storage 操作小插件 iStorage 介紹

閱讀 2284·2019-08-22 16:20

最新活動

国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

上云采購季！| 2核2G4M爆款云服務(wù)器低至59元/年，更有多臺、長期優(yōu)惠，快來選購！

ElasticSearch 單個節(jié)點監(jiān)控

相關(guān)文章

**渣渣為什么要看 ElasticSearch 源碼？**

發(fā)表評論

0條評論

ky0ncheng

男|高級講師

TA的文章

使用fiddler進行mock測試

JavaScript中的原型與繼承

React V16.9來了無痛感升級加入性能檢測【譯-真香】

JavaScript專題之模擬實現(xiàn)call和apply

react 官網(wǎng)動畫庫（react-transition-group）的新寫法

react源碼解析之stack reconciler

vue基礎(chǔ)知識匯總

Local Storage 操作小插件 iStorage 介紹

最新活動