基於google的監控方案，將es監控歸為兩大類五個子類，分別是黑盒監控和白盒監控（四個**指標），詳情可以參考書籍《sre google運維解密》第53頁
黑盒監控
白盒監控
延時
容量
流量
風險提示：上述指標大部分都是基於es介面進行的採集，因此在es故障期間，上述指標可能無法採集，因此，還需要通過服務監控（程序，埠，日誌，機器）進行部分替代，避免是否覆盤無資料可供參考和分析。
服務監控
語義監控
日誌監控
機器監控
指標說明：
1，active shards：不超過一萬個分片。官方推薦，單個例項jvm記憶體不超過30gb，不超過600個分片。另外，分片是由master來維護其狀態的，而master在任何集群規模下，有且僅有乙個節點在工作，其餘均為熱備節點，因此分片數量越高，master常態的壓力越大，故障後恢復的耗時也越長。
2，功能監控，需要週期性檢測es集群能否建立索引，建立文件，讀取文件，刪除文件，刪除索引。
3，search和indexing rate，需要監控總量，但是需要採集主要index的資料，便於問題定位。例如哪個索引突增流量將集群壓垮了？如果沒有細化的index的相關資料採集，就只能通過index的體積來進行間接判斷，延時也類似。
4，active_shards_percent_as_number，監控該值，可以覆蓋所有非正常的情況，而不必對每種異常情況進行監控，這樣可能會有遺漏，常見的錯誤情況包括：unassigned shards ，initializing shards ，relocating shards，delayed_unassigned_shards
5，number_of_pending_task，反應了master節點尚未執行的集群級別的更改任務（例如：建立索引，更新對映，分配分片）的列表。pending task的任務是分級別的（優先順序排序：immediate>urgent>high>normal>low>languid），只有當上一級別的任務執行完畢後才會執行下一級別的任務。
6，nodes_failed，是從該介面獲取，http://localhost/_cluster/stats?pretty
附：http://localhost/_cluster/health?pretty
"cluster_name" : "jdcloud-es",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 23,
"number_of_data_nodes" : 17,
"active_primary_shards" : 4022,
"active_shards" : 8044,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
Elasticsearch核心概念
elasticsearch使用lucene作為其底層的搜尋引擎，關於lucene的介紹，可以參考官方 lucene關鍵概念 lucene使用inverted index來儲存term在document中位置的對映關係。譬如如下文件 使用inverted index儲存，乙個簡單地對映關係 term ...
Elasticsearch核心概念
一 cluster 1 代表乙個集群，有乙個主節點，通過選舉產生。對外部來說es去中心化，邏輯上是乙個整體。2 主節點負責管理集群狀態，包括管理分片狀態和副本狀態，以及節點的發現和刪除 3 主節點不負責對資料的增刪改查請求處理，只負責維護集群相關狀態 二 shards 分片 1 索引分片，es可以把...
Elasticsearch核心概念
節點是組成elasticsearch集群的基本服務單元，集群中的每個執行中的elasticsearch伺服器都可以稱之為節點，它們共同承擔資料和負載壓力 主節點 負責管理集群範圍內的所有變更 node.master true node.data false 資料節點 儲存資料和其對應的倒排索引 資料...