簡介
Elasticsearch提供了許多名額，可以幫助您檢測故障迹象并在遇到不可靠的節點，記憶體不足的錯誤以及較長的垃圾收集時間等問題時采取措施。需要監視的幾個關鍵領域是：
- 叢集運作狀況和節點可用性
- 主機的網絡和系統
- 搜尋性能名額
- 索引性能名額
- 記憶體使用和GC名額
- 資源飽和度和錯誤場景視圖
内置視圖
前置條件
已安裝 DataKit（
DataKit 安裝文檔）
配置
監控名額采集
進入 DataKit 安裝目錄下的 conf.d/db 目錄，複制 elasticsearch.conf.sample 并命名為 elasticsearch.conf。示例如下：
[[inputs.elasticsearch]]
## specify a list of one or more Elasticsearch servers
# you can add username and password to your url to use basic authentication:
# servers = ["http://user:pass@localhost:9200"]
servers = ["http://localhost:9200"]
## Timeout for HTTP requests to the elastic search server(s)
http_timeout = "5s"
## When local is true (the default), the node will read only its own stats.
## Set local to false when you want to read the node stats from all nodes
## of the cluster.
local = true
## Set cluster_health to true when you want to also obtain cluster health stats
cluster_health = true
## Adjust cluster_health_level when you want to also obtain detailed health stats
## The options are
## - indices (default)
## - cluster
# cluster_health_level = "cluster"
## Set cluster_stats to true when you want to also obtain cluster stats.
cluster_stats = true
## Only gather cluster_stats from the master node. To work this require local = true
cluster_stats_only_from_master = true
## Indices to collect; can be one or more indices names or _all
indices_include = ["_all"]
## One of "shards", "cluster", "indices"
indices_level = "shards"
## node_stats is a list of sub-stats that you want to have gathered. Valid options
## are "indices", "os", "process", "jvm", "thread_pool", "fs", "transport", "http",
## "breaker". Per default, all stats are gathered.
node_stats = ["jvm", "http","indices","os","process","thread_pool","fs","transport"]
## HTTP Basic Authentication username and password.
# username = ""
# password = ""
## Optional TLS Config
# tls_ca = "/etc/telegraf/ca.pem"
# tls_cert = "/etc/telegraf/cert.pem"
# tls_key = "/etc/telegraf/key.pem"
## Use TLS but skip chain & host verification
# insecure_skip_verify = false
重新啟動datakit生效
systemctl restart datakit
日志采集
進入 DataKit 安裝目錄下的 conf.d/log 目錄，複制 tailf.conf.sample 并命名為 tailf.conf。示例如下：
[[inputs.tailf]]
# glob logfiles
# required
logfiles = ["/var/log/elasticsearch/solution.log"]
# glob filteer
ignore = [""]
# required
source = "es_clusterlog"
# grok pipeline script path
pipeline = "elasticsearch_cluster_log.p"
# read file from beginning
# if from_begin was false, off auto discovery file
from_beginning = true
## characters are replaced using the unicode replacement character
## When set to the empty string the data is not decoded to text.
## ex: character_encoding = "utf-8"
## character_encoding = "utf-16le"
## character_encoding = "utf-16le"
## character_encoding = "gbk"
## character_encoding = "gb18030"
## character_encoding = ""
# character_encoding = ""
## The pattern should be a regexp
## Note the use of '''XXX'''
# match = '''^\d{4}-\d{2}-\d{2}'''
#Add Tag for elasticsearch cluster
[inputs.tailf.tags]
cluster_name = "solution"
Elasticsearch叢集資訊日志切割grok腳本
📎elasticsearch_cluster_log.p監控名額說明
1.叢集運作狀況和節點可用性
叢集運作狀況和節點可用性的要點
- 叢集狀态: 如果叢集狀态為YELLOW，說明至少有一個副本分片未配置設定或者丢失。盡管這個時候搜尋結果仍然是完整的，但是如果更多的分片消失的話，有可能造成整個索引的資料丢失。如果叢集狀态為RED，則表示至少有一個主分片丢失，索引缺少資料，這意味着搜尋将傳回部分結果，而且新的文檔資料也無法索引到該分片。這時可以考慮設定一個告警，如果狀态為黃色超過 5 分鐘，或者上次檢測狀态為紅色，則觸發警報。
- 初始化（initializing）和未配置設定（unassigned）狀态的分片: 當索引首次建立或者節點重新啟動時，由于 Master節點試圖将分片配置設定給Data節點，是以在轉換為“started”或“unassigned”狀态之前，該分片将暫時處于“initializing”狀态。 如果您看到分片處于初始化狀态或未配置設定狀态的時間過長，則可能是群集不穩定的信号。
2.主機的網絡和系統
主機的網絡和系統的要點
- 磁盤空間: 如果當 Elasticsearch 叢集是寫負載型的，那麼這個名額将變得更加重要。因為一旦空間不足，将不能進行任何插入和更新操作，節點也會下線，這應該是業務上不允許的。如果節點的可用空間小于 20%，應該利用類似 Curator 這樣的工具，删除一些占用空間較大的索引來釋放部分空間。如果業務邏輯上不允許删除索引，那麼另一種方案就是擴容更多的節點，讓 Master 在新節點間重新配置設定分片（盡管這樣會增加 Master 節點的負載）。另外需要記住一點，包含需要分析（analyzed）的字段的文檔占用的磁盤空間比那些不需要分析（non-analyzed）的字段（精确值）的文檔要多得多。
- 節點上的CPU使用率: 利用圖示來展示不同節點類型的 CPU 使用情況會很有幫助。例如，可以建立三個不同的圖來表示群集中的不同節點類型（例如 Data 節點，Master 節點和 Client 節點）的 CPU 使用情況，通過對比圖示來發現是否某一種類型的節點過載了。如果您看到 CPU 使用率增加，這通常是由于大量的搜尋或索引工作造成的負載。設定一個通知，以确定您的節點的 CPU 使用率是否持續增長，并根據需要添加更多的節點來重新配置設定負載。
- 網絡位元組發送/接收: 節點之間的通信是衡量群集是否平衡的關鍵組成部分。 需要監視網絡以確定網絡正常運作，并且能夠跟上群集的需求（例如，在節點間複制或分片的重新配置設定）。 Elasticsearch 提供有關叢集節點間通信的傳輸名額，但是也可以通過發送和接收的位元組速率，來檢視網絡正在接收多少流量。
- 打開檔案描述符: 檔案描述符用于節點間的通信、用戶端連接配接和檔案操作。如果打開的檔案描述符達到系統的限制，那麼新的連接配接和檔案操作将不可用，直到有舊的被關閉。 如果超過80％的可用檔案描述符正在使用中，則可能需要增加系統的最大檔案描述符計數。 大多數 Linux 系統限制每個程序中隻允許有 1024 個檔案描述符。 在生産中使用 Elasticsearch 時，應該将作業系統檔案描述符數量設定為更大的值，例如 64,000。
- HTTP連結: 除了 Java Client 以外的任何語言發送的請求都将使用基于 HTTP 的 RESTful API 與 Elasticsearch 進行通信。 如果打開的 HTTP 連接配接總數不斷增加，則可能表明您的 HTTP 用戶端沒有正确建立持久化連接配接。 重建立立連接配接會在請求響應時間内增加額外的時間開銷。 是以務必確定您的用戶端配置正确，以避免對性能造成影響，或者使用已正确配置 HTTP 連接配接的官方 Elasticsearch 用戶端之一。
3. 查詢性能名額
如果您主要使用 Elasticsearch 進行查詢，那麼您應該關注查詢延遲并在超出門檻值時采取措施。監控 Query 和 Fetch 的相關名額可以幫助您跟蹤查詢在一段時間内的執行情況。例如，您可能需要跟蹤查詢曲線的峰值以及長期的查詢請求增長趨勢，以便可以優化配置來獲得更好的性能和可靠性。
搜尋性能名額的要點:
- 查詢（Query）負載: 監控目前查詢并發數可以大緻了解叢集在某個時刻處理的請求數量。對不尋常的峰值峰谷的關注，也許能發現一些潛在的風險。可能還需要監控查詢線程池隊列的使用情況。
- 查詢（Query）延遲: 雖然 Elasticsearch 并沒有直接提供這個名額，但是我們可以通過定期采樣查詢請求總數除以所耗費的時長來簡單計算平均查詢延遲時間。如果超過我們設定的某個閥值，就需要排查潛在的資源瓶頸或者優化查詢語句。
- 擷取（Fetch）延遲: 查詢（search）過程的第二階段，即擷取階段，通常比查詢（query）階段花費更少的時間。如果您注意到此度量名額持續增加，則可能表示磁盤速度慢、富文檔化（比如文檔高亮處理等）或請求的結果太多等問題。
4.索引性能名額
索引（Indexing）請求類似于傳統資料庫裡面的寫操作。如果您的 Elasticsearch 叢集是寫負載類型的，那麼監控和分析索引（indices）更新的性能和效率就變得很重要。在讨論這些名額之前，我們先看一下 Elasticsearch 更新索引的過程。如果索引發生了變化（比如新增了資料、或者現有資料需要更新或者删除），索引的每一個相關分片都要經曆如下兩個過程來實作更新操作：refresh 和 flush。
索引性能名額的要點:
- 索引（Indexing）延遲: Elasticsearch 并未直接提供這個名額，但是可以通過計算 index_total 和 index_time_in_millis 來擷取平均索引延遲。如果您發現這個名額不斷攀升，可能是因為一次性 bulk 了太多的文檔。Elasticsearch 推薦的單個 bulk 的文檔大小在 5-15MB 之間，如果資源允許，可以從這個值慢慢加大到合适的值。
- Flush 延遲: 由于 Elasticsearch 是通過 flush 操作來将資料持久化到磁盤的，是以關注這個名額非常有用，可以在必要的時候采取一些措施。比如如果發現這個名額持續穩定增長，則可能說明磁盤 I/O 能力已經不足，如果持續下去最終将導緻無法繼續索引資料。此時您可以嘗試适當調低 index.translog.flush_threshold_size 的值，來減小觸發 flush 操作的 translog 大小。與此同時，如果你的叢集是一個典型的 write-heavy 系統，您應該利用 iostat 這樣的工具持續監控磁盤的 IO，必要的時候可以考慮更新磁盤類型。
5.記憶體使用和GC名額
在 Elasticsearch 運作過程中，記憶體是需要密切關注的關鍵資源之一。Elasticsearch 和 Lucene 以兩種方式利用節點上的所有可用 RAM：JVM 堆和檔案系統緩存。 Elasticsearch 運作在 Java 虛拟機（JVM）上，這意味着 JVM 垃圾回收的持續時間和頻率将是其他重要的監控領域。
記憶體使用和GC名額的要點:
- JVM堆記憶體的使用量: Elasticsearch 預設當 JVM 堆棧使用率達到 75%的時候啟動垃圾回收。是以監控節點堆棧使用情況并設定告警閥值來定位哪些節點的堆棧使用率持續維持在 85%變得非常有用，這表明垃圾回收的速度已經趕不上垃圾産生的速度了。要解決這個問題，可以增加堆棧大小，或者通過添加更多的節點來擴充群集。
- JVM堆記憶體的使用量和送出的JVM堆記憶體大小: 和 JVM 堆棧配置設定了多少記憶體（committed）相比，監控 JVM 使用了多少記憶體（used）會更加有用。使用中的堆棧記憶體的曲線通常會呈鋸齒狀，在垃圾累積時逐漸上升在垃圾回收時又會下降。 如果這個趨勢随着時間的推移開始向上傾斜，這意味着垃圾回收的速度跟不上建立對象的速度，這可能導緻垃圾回收時間變慢，最終導緻 OutOfMemoryError。
- 垃圾收集持續時間和頻率: 為了收集無用的對象資訊，JVM 會暫停執行所有任務，通常這種狀态被稱為“Stop the world”，不管是 young 還是 old 垃圾回收器都會經曆這個階段。由于 Master 節點每隔 30s 檢測一下其他節點的存活狀态，如果某個節點的垃圾回收時長超過這個時間，就極可能被 Master 認為該節點已經失聯。
- 記憶體使用情況: Elasticsearch 可以很好地使用任何尚未配置設定給 JVM 堆的 RAM。 和 Kafka 一樣，Elasticsearch 被設計為依靠作業系統的檔案系統緩存來快速可靠地處理請求。如果某個 segment 最近由 Elasticsearch 寫入磁盤，那麼它已經在緩存中。 但是，如果一個節點已被關閉并重新開機，則在第一次查詢一個 segment 的時候，必須先從磁盤讀取資料。是以這是確定群集保持穩定并且節點不會崩潰的重要原因之一。通常，監視節點上的記憶體使用情況非常重要，并盡可能為 Elasticsearch 提供更多的 RAM，以便在不溢出的情況下最大化利用檔案系統緩存。
6.資源飽和度和錯誤
Elasticsearch 節點使用線程池來管理線程對記憶體和 CPU 使用。由于線程池是根據處理器的核數自動配置的，是以調整它們通常是沒有意義的。 但是通過請求隊列和請求被拒絕的情況，來确定你的節點是否夠用是一個不錯的主意。如果出現了狀況，您可能需要添加更多的節點來處理所有的并發請求。
線程池的請求隊列（queues）和拒絕情況（rejections）: 每個 Elasticsearch 節點都維護着很多類型的線程池。具體應該監控哪些線程池，需要根據 Elasticsearch 的使用場景而定。一般來講，最重要的幾個線程池是搜尋（search），索引（index），合并（merger）和批處理（bulk）。每個線程池隊列的大小代表着目前節點有多少請求正在等待服務。 隊列的作用是允許節點追蹤并最終處理這些請求，而不是直接丢棄它們。但是線程池隊列不是無限擴充的（隊列越大占用的記憶體越多），一旦線程池達到最大隊列大小（不同類型的線程池的預設值不一樣），後面的請求都會被線程池拒絕。
資源飽和度和錯誤的要點:
- 線程池隊列: 線程池隊列并不是越大越好，因為線程池越大占用的資源越多，并且增大了節點當機時請求丢失的風險。 如果您看到排隊和拒絕的線程數量持續增加，則需要嘗試減慢請求速率、增加節點上的處理器數量或增加叢集中的節點數量。
- 批處理（bulk）的請求隊列和請求拒絕: 批處理是同時發送多個請求的更有效方式。 通常如果要執行許多操作（建立索引，或者添加，更新或删除文檔），則應嘗試将請求作為批處理發送，而不是多個單獨的請求。批處理請求被拒絕通常與試圖在一個批處理請求中索引太多文檔有關。雖然據 Elasticsearch 的文檔所說，出現批處理請求被拒絕的情況，不一定是必須要擔心的事情，但是應該嘗試實施一些退避政策，以有效處理這種情況。
- 緩存使用率名額: 每個查詢請求都發送到索引中的每個分片，然後命中每個分片的每個段。Elasticsearch逐段緩存查詢，以加快響應時間。另一方面，如果您的緩存占用了太多的堆，它們可能會降低速度而不是加快速度！