ElasticSearch 單個節點監控

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

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

節點信息 Node Info :

curl -XGET 'https://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 長連接對性能很重要，因為連接、斷開套接字是很昂貴的（而且浪費文件描述符）。請確認你的客戶端都配置正確。