Elasticsearch運維經驗總結

Elasticsearch運維經驗總結

2018年12月10日 16:38:41 運小白 閱讀數 3811

 

版本說明：5.6.4（要嚴格注意ES及其插件、第三方工具的版本匹配關係）

系統負載：（日誌集羣，日均寫入10TB，保留7天）

1，出於高可用的考慮，同一個分區的多個副本不會被分配到同一臺機器

以下截圖所示，Index：queries，設置20副本，5分片。這個集羣當前有14個可用數據節點，queries的0分區在這14個數據節點上均有且僅有一個副本，剩餘​​的7個副本顯示UNASSIGNED，並不會在當前14個節點上重複分配

2，Local Gateway參數生效順序（僅在重啓master時生效）

• gateway:expected_nodes，只要達到該值，當即能夠進入恢復狀態，假若有恢復必要的話
• gateway:recover_after_time，若是未達到expected_nodes值，則須要等待recover_after_time時長，無論你當前有多少個nodes了
• gateway:recover_after_nodes，在達到recover_after_time的時間後，還須要達到recover_after_nodes的設置值，才能進入恢復狀態

3，避免全部索引被刪除

• action.destructive_requires_name:true，經過該參數禁止經過正則進行index的刪除操做
• curl -XDELETE http://localhost:9200/*/

4，避免使用虛擬內存（三選一）

• 最佳方式：關閉操做系統的swap分區（swapoff -a）
• 次選：vm.swappiness=0（僅在物理內存不夠時才使用swap分區）
• 最後：bootstrap.memory_lock: true

5，集羣各種角色

• node.master（顯示）
• node.data（顯示）
• node.ingest（顯示）
• node.coordinatint（隱性）
• Every node is implicitly a coordinating node. This means that a node that has all three node.master, node.data and node.ingest set to false will only act as a coordinating node, which cannot be disabled.

6，master數量至少3個，避免腦裂

• discovery.zen.minimum_master_nodes: 2

7，操做命令

• 調整副本數：curl -XPUT http://localhost/yunxiaobai/_settings?pretty -d ‘{「settings」:{「index」:{「number_of_replicas」:」10″}}}’
• 建立index：curl -XPUT ‘localhost:9200/yunxiaobai?pretty’
• 插入數據：curl -XPUT ‘localhost:9200/yunxiaobai/external/1?pretty’ -d ‘ { 「name」:」yunxiaobai」 }’
• 獲取數據：curl -XGET ‘localhost:9200/yunxiaobai/external/1?pretty’
• 刪除索引：curl -XDELETE ‘localhost:9200/jiaozhenqing?pretty’
• 屏蔽節點：curl -XPUT 127.0.0.1:9200/_cluster/settings?pretty -d ‘{ 「transient」 :{「cluster.routing.allocation.exclude._ip」 : 「10.0.0.1」}}’
• 刪除模板：curl -XDELETE http://127.0.0.1:9200/_template/metricbeat-6.2.4
• 調整shard刷新時間：curl -XPUT http://localhost:9200/metricbeat-6.2.4-2018.05.21/_settings?pretty -d ‘{「settings」:{「index」:{「refresh_interval」:」30s」} }}’
• 提交模板配置文件：curl -XPUT localhost:9200/_template/devops-logstore-template -d @devops-logstore.json
• 查詢模板： curl -XGET localhost:9200/_template/devops-logstor-template
• 查詢線程池：http://localhost:9200/_cat/thread_pool/bulk?v&h=ip,name,active,rejected,completed

8，集羣健康狀態

• green：全部的主分片和副本分片都正常運行。
• yellow：全部的主分片都正常運行，但不是全部的副本分片都正常運行。
• red：有主分片沒能正常運行。

9，故障節點分片延時分配

• index.unassigned.node_left.delayed_timeout：1m，該配置表示一個節點故障1m後，系統會開始對該節點上的分片進行恢復操做。若是故障節點上的分片是主分片，那麼即便是延時分配，其餘節點對應的分片副本也會被置爲主分片，不然，該索引沒法正常使用，僅僅是延時了副本的故障恢復。之因此有時候須要調整該值，是爲了不一些糟糕狀況的發生，例如一臺機器死機重啓，那麼由於啓動耗時超過一分鐘，因此係統會對該機器上的分片進行故障恢復，恢復完畢後，這臺機器啓動完畢服務恢復了，那麼這臺機器上的數據就沒有意義了，就被刪除了。這時候，由於這是一個空機器了，因此係統還會觸發平衡操做，這折騰就大了。設置爲0時，表示不等待節點故障當即從新分配。Since elasticsearch 5.x index level settings can NOT be set on the nodes configuration like the elasticsearch.yaml, in system properties or command line arguments.In order to upgrade all indices the settings must be updated via the /${index}/_settings API.
• cluster.routing.allocation.enable」:」none」，該參數配置生效時，能夠建立索引，可是索引是處於不可用狀態的

10，名詞解釋

• indexes和indices區別
  • indices通常在數學，金融和相關領域使用，而indexes使用則相對普遍
  • indexes在美國、加拿大等國的英語裏比較常見。但indices盛行於除北美國家之外的英語裏。
• index和lucene的區別
  • 在集羣級別上的索引稱爲index
  • 在節點級別（各個分片都是一個lucene索引）稱爲lucene

11，滾動升級（升級期間，集羣處於不可用狀態）

• Disable shard allocation
  • curl -XPUT http://localhost:9200/_cluster/settings?pretty -d ‘{ 「persistent」: {「cluster.routing.allocation.enable」 : 「none」 } } ‘，此時能夠建立索引，可是索引不可用
• Stop non-essential indexing and perform a synced flush
  • curl -X POST 「localhost:9200/_flush/synced」 此時集羣不對外進行響應
• Shut down a single node
• Upgrade the node you shut down
• Upgrade any plugins
• Start the upgraded node
• Reenable shard allocation
  • curl -XPUT http://localhost:9200/_cluster/settings?pretty -d ‘{ 「persistent」: {「cluster.routing.allocation.enable」 : 「all」 } } ‘
• Wait for the node to recover
• Repeat

12，關鍵指標（參考x-pack）

• indices.search.query_current/indices.search.query_total
• indices.search.query_time_in_millis
• indices.indexing.index_current/indices.indexing.index_total
• indices.indexing.index_time_in_millis
• jvm.mem.heap_used_percent
• number_of_nodes(_cat/health)
• active_shards_percent_as_number(_cat/health)
• status(_cat/health)

13，如何設置索引的分片數比較合適

條件：

• 每GB的堆對應的分片數量應低於20個
• 每一個節點有jvm堆內存 30G
• fielddata 大小9G
• 磁盤容量1490GB，則可用的磁盤容量爲：1490GB*12.8%=1299.28GB約1299GB
• 儘可能保持分片大小一致

結論：

索引主分片規模爲：
單個分片容量：1200GB/(30*20)=2.165GB
對於一個新建索引，預測總大小10GB，則共設置主分片：10GB/2GB=5個

14，集羣的索引副本數如何肯定

• 當ES的查詢操做較少時（每秒少於一個查詢操做），副本數爲1便可保證了數據的冗餘（何況還有備份）
• ES副本數爲2時，能夠提升查詢性能（副本能夠分擔索引的查詢操做）：代價爲CPU，內存和文件句柄

參考文獻：https://www.elastic.co/guide/en/elasticsearch/guide/2.x/replica-shards.html

https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index

15，es 配置多個 data path 時的分配策略

參考資料：https://cyberdak.github.io/es/2018/07/08/es-disk-allocate-strategy

16，ES集羣的備份和恢復

官方給出的ES集羣的數據備份方式

• S3 Repository
• Azure Repository
• HDFS Repository
• Google Cloud Storage Repository

如下是使用HDFS進行數據備份和恢復，HDFS備份是基於增量備份方式進行備份的，須要安裝repository-hdfs插件並重啓集羣才能生效。

對於使用HDFS來進行備份的方式，這是一種增量備份的方式（同一個存儲庫下，數據是增量備份的，每次備份，系統僅備份發生變化的segment）

使用的API：

#HDFS配置和建立存儲庫

curl -XPUT  「http://localhost:9200/_snapshot/ my_backup」  -d ‘

 { 

       「type」: 「hdfs」, 

       「settings」: {

                    「path」: 「/back/es/」, #存儲庫路徑

                    「load_defaults」: 「true」, #加載Hadoop默認配置

                    「compress」: 「true」, 

                    「uri」: 「hdfs://localhost:8020」 } #Hadoop IP地址

 }

#建立快照

# snapshot_1爲快照名稱

curl -XPUT 「http://localhost:9200/_snapshot/my_backup/snapshot_1?wait_for_completion=true 」 -d ‘{

         「indices」: 「index_1,index_2」, //注意不設置這個屬性，默認是備份全部索引                           

         「include_global_state」: false 

}

 

#ES數據恢復

#本集羣恢復，查找要恢復的快照ID，執行以下命令恢復數據

curl -XPOST   http://localhost:9200/_snapshot/my_backup/backup_1/_restore’

17，curator插件–ES索引管理插件

• curator安裝

pip install elasticsearch-curator

• curator的配置文件

curator須要兩個文件來對集羣進行操做：curator.yml(curator的配置文件)，action_file.yml(curator執行的動做)

curator.yml格式：

更改hosts和port鏈接集羣的地址和端口，更改logfile爲日誌路徑。

action_file.yml格式：

1：模式是匹配

2.：匹配的索引的名稱，支持正則

3,4：指刪除7天前的索引

5：多個任務須要按照順序添加

• curator的執行命令

curator –config curator.yml action_file.yml

以上命名須要加上文件的路徑

• 執行成功後，會將執行的過程寫入日誌文件中–logfile中。

18，自動任務

經過系統的crontab來執行自動任務

• 新建執行腳本

對於自動刪除索引這個任務來講，能夠新建shell腳本curator.sh

#!/bin/sh

/usr/bin/curator –config /root/.curator/curator_config.yml /root/.curator/action_file.yml

• 新建自動任務

crontab -e

crontab格式

30 3 * * * /data1/curator/curator.sh

• 查看自動任務

crontab -l

19，監控

核心監控項：集羣健康狀態，功能監控，索引延遲，流量監控

黑：黑盒監控

白：白盒監控

監控項介紹：

• pendin_task

pending task 反應了master節點還沒有執行的集羣級別的更改任務（例如：建立索引，更新映射，分配分片）的列表。pending task的任務是分級別的（優先級排序：IMMEDIATE>URGENT>HIGH>NORMAL>LOW>LANGUID）,只有當上一級別的任務執行完畢後纔會執行下一級別的任務，這也說明了：當出現HIGH級別以上的pending task任務時，備份和建立索引等一些低級別任務雖然任務對資源佔用很少，也將不會執行，返回異常，「ProcessClusterEventTimeoutException」。

20，kibana調優

• 在啓動文件的開頭添加以下配置項：NODE_OPTIONS=」–max-old-space-size=4096″   其中4096的單位爲MB

21，推薦插件

• • X-pack
  • ElasticHQ

• x-pack許可證書過時的問題

x-pack許可證書分爲試用的許可證書和註冊後的許可證書。安裝證書不用重啓節點

當x-pack禁用security functionality能夠經過以下步驟來安裝證許可證書：

1. 註冊elasticsearch
2. 收到許可證郵件，下載許可證json文件
3. 經過以下API來進行安裝

curl -XPUT u elastic 'http://0.0.0.0:9200/_xpack/license?acknowledge=true&pretty' -H "Content-Type；application/json" -d @json

22，數據直接寫入ES仍是使用ELK？

• 直接寫入ES：適用於非核心場景，簡單直接依賴少
• 須要引入Kafka：適用於核心場景，經過Kafka做爲代理層，既能夠提高ELK集羣總體的穩定性，也能夠引入Hadoop生態作形式的數據分析。
  • 基於多ES集羣消費實現多集羣熱備，實現單集羣故障後快速切換到其餘可用集羣
  • ES故障期間Kafka做爲數據緩衝避免數據丟失，故障恢復後繼續消費故障期間的數據
  • 控制消費速率，避免ES被突增流量壓死
  • 實現批量寫操做，提高ES性能，分佈式直接寫入ES很難作聚合

23，ES引入代理的優點

• 封禁部分高危操做，如調整集羣參數，刪除操做等
• 封禁部分業務訪問，如非受權用戶，測試用戶等

24，集羣出現UNASSIGNED shards

集羣分片分配機制

1.  
   ES集羣的分片分配由「allocators」和「deciders」控制，「allocators」負責返回給「deciders」一個知足要求的nodes列表，「deciders」從列表中肯定到底分片應分配到哪一個nodes。
2.  
   「allocators」按照各節點的分片數量來得到合適的nodes列表（若是有分配權重則另說）
3.  
   「deciders」根據一些過濾器來肯定最終的分配nodes（分配的設置要求）
4.  
   對於一個分片的分配，分爲新建索引的分片分配，對於已經存在的索引，分爲主分片和副本分片的分配
5.  
   對於新建的索引，「allocators」尋找nodes列表的原則是保持集羣的平衡（各個nodes上的分片數儘可能保持一致，不是nodes的size）
6.  
   對於已經存在的索引的主分片:只會容許分配到良好的最新的副本分片上，以後會選擇其餘副本（數據將有丟失）
7.  
   參考資料：https://www.elastic.co/blog/red-elasticsearch-cluster-panic-no-longer

緣由：

• 有目的的延遲

• 分片太多，節點不夠

• 須要重啓分片分配

• 磁盤量達到限制，禁止寫入新的索引

• ES集羣的版本不同

處理流程：

1. 查看有哪些索引有UNASSIGEMED shards  注1

2. 若對應的索引沒用(數據沒有用，索引能夠刪除)直接刪除

3. 查看UNASSIGNED shards的詳細未分配緣由  注2

4. 針對不一樣的緣由提供不一樣的解決辦法

注1：

curl -XGET 「http://hb-dev-es.jdcloud.com:80/_cat/shards?h=index,shard,prirep,state,unassigned.reason」 | grep UNASSIGNED

注2：

curl -XGET 「http://hb-dev-es.jdcloud.com:80/_cluster/allocation/explain?pretty」

25,ES集羣重啓預案及影響分析

ES集羣重啓預案

es每一個節點均是有狀態，不一樣索引分片配置設置不一樣，單個分片可能有冗餘，可能有1備份。所以，爲不影響服務，升級或者重啓es服務須要逐個依次進行（滾動重啓）

1.  
   #注：重啓操做應在集羣狀態爲green時進行，重啓任一一個節點先後，都要保證在集羣狀態恢復到green狀態時。
2.  
   #步驟1-禁用分片分配
3.  
   #若是不由止，當中止某一節點後，分片分配進程會進行UNASSIGNED分片的分配（當集羣狀態達到recovery要求，觸發恢復閾值時）。這樣的狀況下，會形成大量的IO操做。可是禁用分片後，功能上會禁止新建索引。
4.  
   curl -X PUT http://0.0.0.0:9200/_cluster/settings?pretty -d '{"transient": {"cluster.routing.allocation.enable": "none"}}'
5.  
   #步驟2-驗證修改後的配置：
6.  
   curl -X GET http://0.0.0.0:9200/_cluster/settings?pretty
7.  
   #步驟3-執行同步刷新
8.  
   #這一步操做的緣由是：當有分片在集羣重啓過程當中並無發生更新，則跳過對這些分片的同步校驗，提升分片恢復的速度
9.  
   curl -XPOST "http://0.0.0.0:9200/_flush/synced?pretty"
10.  
    #步驟4-重啓client-node節點
11.  
    #重啓client-node組節點有小几率致使寫入丟失（因爲LB的輪詢策略:當一個節點離線後，10s內不會再將請求分配到該節點。能夠經過不要當即重啓另外的client節點來避免此問題）
12.  
    ##子步驟1--重啓一個client-node組的節點
13.  
    ##子步驟2--確認節點加入集羣
14.  
    ##經過命令查看集羣狀態和查看節點數
15.  
    curl -XGET http://0.0.0.0:9200/_cluster/health?pretty
16.  
    ##子步驟3--按照子步驟1-2重啓剩餘的client-node節點
17.  
    #步驟5-重啓master節點
18.  
    ##子步驟1--重啓一個master-node的非master節點
19.  
    ##子步驟2--確認節點加入集羣
20.  
    ##子步驟3--重複子步驟1-2重啓剩餘的非master節點
21.  
    ##子步驟4--重複子步驟1-2重啓剩餘的master節點
22.  
    ##子步驟5--檢查master是否從新選舉成功（30s後會開始選舉：緣由discovery.zen.ping_timeout:30s）
23.  
    ##master選舉過程當中會堵塞寫操做，對search無影響，堵塞API的操做
24.  
    #步驟6-重啓data-node節點
25.  
    ##子步驟1--重啓一個data-node組的data-node節點
26.  
    ##子步驟2--確認節點加入集羣
27.  
    ##子步驟3--重複子步驟1-2重啓剩餘的data節點
28.  
    #步驟7-啓用分片分配
29.  
    curl -X PUT http://0.0.0.0:9200/_cluster/settings?pretty -d '{"transient": {"cluster.routing.allocation.enable": "all"}}'
30.  
     
31.  
     

最後，常見日誌錯誤

 

• 集羣名稱不一致：java.lang.IllegalStateException: handshake failed, mismatched cluster name
• 配置文件報錯：java.lang.IllegalArgumentException: node settings must not contain any index level settings
• org.elasticsearch.cluster.metadata.ProcessClusterEventTimeoutException: failed to process cluster event (put-mapping) within 30s
• cluster state update task [put-mapping[type-2018-05-20-22-25-1526826326]] took [57.2s] above the warn threshold of 30s
• [o.e.a.a.i.m.p.TransportPutMappingAction] failed to put mappings on indices [[[tpmonitor-elasticsearch/Vzr0MlOKRimGGCcMb0wIdA]]], type [type-2018-05-21-22-18-1526912288]
• Failed to connect to server: 10.1.1.1/10.1.1.1:9000: try once and fail.
• [2018-05-22T16:50:59,473][WARN ][o.e.b.ElasticsearchUncaughtExceptionHandler] [172-0] uncaught exception in thread [main]org.elasticsearch.bootstrap.StartupException: java.lang.IllegalStateException: Unable to access ‘path.data’ (/data10/elasticsearch)