ElasticSearch 單個節點監控

ky0ncheng 發布于2019-08-16 11:00 / 2172人閱讀

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

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

集群健康監控可以參考這篇文章：ElasticSearch 集群監控

節點信息 Node Info :

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

執行上述命令可以獲取所有 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: {...}
 }

上面是我已經簡寫了很多數據之后的返回值，但是指標還是很多，有些是一些常規的指標，對于監控來說，沒必要拿取。從上面我們可以主要關注以下這些指標:

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

節點統計 nodes-statistics

節點統計值 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: {}
}

節點名是一個 UUID，上面列舉了很多指標，下面講解下：

索引部分 indices

這部分列出了這個節點上所有索引的聚合過的統計值：

docs 展示節點內存有多少文檔，包括還沒有從段里清除的已刪除文檔數量。

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

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

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

get 顯示通過 ID 獲取文檔的接口相關的統計值。包括對單個文檔的 GET 和 HEAD 請求。

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

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

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

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

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

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

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

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

memory 統計值展示了 Lucene 段自己用掉的內存大小。這里包括底層數據結構，比如倒排表，字典，和布隆過濾器等。太大的段數量會增加這些數據結構帶來的開銷，這個內存使用量就是一個方便用來衡量開銷的度量值。

操作系統和進程部分

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

這些都是非常有用的指標，不過通常在你的監控技術棧里已經都測量好了。統計值包括下面這些：

CPU

負載

內存使用率（mem.used_percent）

Swap 使用率

打開的文件描述符（open_file_descriptors）

JVM 部分

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

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 內存使用有關的常見統計值。你可以看到有多少 heap 被使用了，多少被指派了（當前被分配給進程的），以及 heap 被允許分配的最大值。理想情況下，heap_committed_in_bytes 應該等于 heap_max_in_bytes 。如果指派的大小更小，JVM 最終會被迫調整 heap 大小——這是一個非常昂貴的操作。如果你的數字不相等，閱讀堆內存:大小和交換學習如何正確的配置它。

heap_used_percent 指標是值得關注的一個數字。Elasticsearch 被配置為當 heap 達到 75% 的時候開始 GC。如果你的節點一直 >= 75%，你的節點正處于 內存壓力 狀態。這是個危險信號，不遠的未來可能就有慢 GC 要出現了。

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

線程池部分

Elasticsearch 在內部維護了線程池。這些線程池相互協作完成任務，有必要的話相互間還會傳遞任務。通常來說，你不需要配置或者調優線程池，不過查看它們的統計值有時候還是有用的，可以洞察你的集群表現如何。

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

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

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

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

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

get Get-by-ID 操作

search 所有的搜索和查詢請求

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

網絡部分

transport 顯示和 傳輸地址 相關的一些基礎統計值。包括節點間的通信（通常是 9300 端口）以及任意傳輸客戶端或者節點客戶端的連接。如果看到這里有很多連接數不要擔心；Elasticsearch 在節點之間維護了大量的連接。

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

參考資料

1、nodes-info

2、nodes-stats

3、ES監控指標

最后：

轉載請注明地址：http://www.54tianzhisheng.cn/...

ElasticSearch 云解析監控節點服務器節點監控單個邊框單個表

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/70893.html

渣渣為什么要看 ElasticSearch 源碼？

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

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

發表評論

登陸后可評論

0條評論

ky0ncheng

男|高級講師

我要關注我要私信

TA的文章

使用fiddler進行mock測試

閱讀 716·2021-11-16 11:44
JavaScript中的原型與繼承

閱讀 3548·2019-08-26 12:13
React V16.9來了無痛感升級加入性能檢測【譯-真香】

閱讀 3243·2019-08-26 10:46
JavaScript專題之模擬實現call和apply

閱讀 2357·2019-08-23 12:37
react 官網動畫庫（react-transition-group）的新寫法

閱讀 1189·2019-08-22 18:30
react源碼解析之stack reconciler

閱讀 2532·2019-08-22 17:30
vue基礎知識匯總

閱讀 1841·2019-08-22 17:26
Local Storage 操作小插件 iStorage 介紹

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

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

資訊專欄INFORMATION COLUMN

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

ElasticSearch 單個節點監控

相關文章

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

發表評論

0條評論

ky0ncheng

男|高級講師

TA的文章

使用fiddler進行mock測試

JavaScript中的原型與繼承

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

JavaScript專題之模擬實現call和apply

react 官網動畫庫（react-transition-group）的新寫法

react源碼解析之stack reconciler

vue基礎知識匯總

Local Storage 操作小插件 iStorage 介紹

最新活動