Elasticsearch 平常維護命令

時間  2019-11-19
標籤 elasticsearch 平常 維護 命令 欄目 日誌分析 简体版
原文   原文鏈接

 

線上部署了ELK+Redis日誌分析平臺環境, 隨着各種日誌數據源源不斷的收集, 發現過了一段時間以後, ELK查看會原來越慢, 重啓elasticsearch服務器節點以前同步時間也會很長,  這是由於長期以來ELK收集的索引沒有刪除引發的! 如下是ELK批量刪除索引的操做記錄:node

1) 訪問head插件(http://10.0.8.44:9200/_plugin/head/) 或者在elasticsearch節點上使用下面命令查看elk的索引(10.0.8.44是elk集羣中的任意一個節點)vim

[root@elk-node01 ~]# curl -XGET 'http://10.0.8.44:9200/_cat/shards'               

刪除索引的命令
[root@elk-node01 ~]# curl -XDELETE  http://10.0.8.44:9200/索引名

還能夠根據需求,過濾出想要查看的索引,好比查看2018.08.02而且是10.0.52.22的索引
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.44:9200/_cat/shards'  |grep "2018\.08\.02" |grep "10.0.52.22"|awk '{print $1}'

2) 能夠先將要刪除的索引查看出來存到臨時文件裏, 而後進行批量刪除 (索引多的話, 刪除操做會耗費一點時間) bash

好比批量刪除全部的索引(但不會刪除kibana.yml文件中配置的kibana.index索引,就是那些帶.的索引) (cat /root/elk-index.tmp|wc -l 能夠查看要刪除的索引有多少個)
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.44:9200/_cat/shards'|awk '{print $1}'|uniq > /root/elk-index.tmp
[root@elk-node01 ~]# for i in $(cat /root/elk-index.tmp);do curl -XDELETE  http://10.0.8.44:9200/$i;done

3) 爲了方即可以在計劃任務裏面加定時任務刪除30天以前的日誌索引  (這裏線上elk的索引名中帶當天的日期, 日期格式爲%Y.%m.%d.  具體看本身的索引命名規則)服務器

[root@elk-node01 ~]# vim /home/scripts/del_elasticseatch_index.sh
#!/bin/bash
#The index 30 days ago
curl -XGET 'http://10.0.8.44:9200/_cat/shards' |awk '{print $1}' |grep `date -d "30 days ago" +%Y.%m.%d` |uniq > /tmp/index_name.tmp

for index_name in `cat /tmp/index_name.tmp`  
do
    curl -XDELETE  http://10.0.8.44:9200/$index_name
    echo "${index_name} delete success" >> /home/scripts/del_elasticseatch_index.log
done

[root@elk-node01 ~]# crontab -l
0 3 * * * bash /home/scripts/del_elasticseatch_index.sh

上述腳本執行以後, 訪問http://10.0.8.44:9200/_plugin/head/ ,就會發現,ELK索引已被批量刪除了.curl

====================================ES集羣節點切換=======================================elasticsearch

在ELK集羣中任意節點上查看集羣狀態(10.0.8.44是任意一個節點地址).
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.44:9200/_cat/health?v'
epoch      timestamp cluster  status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1542781206 14:20:06  kevin-elk green           3         3      6   3    0    0        0             0                  -                100.0%
 
ELK集羣健康檢查的三種狀態:
green： 每一個索引的primary shard和replica shard都是active狀態的
yellow：每一個索引的primary shard都是active狀態的，可是部分replica shard不是active狀態，處於不可用的狀態
red：   不是全部索引的primary shard都是active狀態的，部分索引有數據丟失了
 
其中 yellow 表示全部主分片可用，但不是全部副本分片均可用，最多見的情景是單節點時，因爲es默認是有1個副本，主分片和副本不能在同一個節點上，因此副本就是未分配unassigned
 
分配分片時可能遇到的坑，須要注意的地方:
1) 分配副本時必需要帶參數"allow_primary" : true, 否則會報錯
2) 當集羣中es版本不一樣時，若是這個未分配的分片是高版本生成的，不能分配到低版本節點上，反過來低版本的分片能夠分配給高版本，若是遇到了，只要升級低版本節點的ES版本便可
 
*符號表示該節點爲當前主節點.
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.45:9200/_cat/nodes?v'
host      ip        heap.percent ram.percent load node.role master name                       
10.0.8.44 10.0.8.44           53          22 0.03 d         m      elk-node01.kevinbo.cn
10.0.8.47 10.0.8.47           39          54 0.03 d         m      elk-node03.kevinbo.cn
10.0.8.45 10.0.8.45           42          20 0.00 d         *      elk-node02.kevinbo.cn
 
若是當上面的主節點(10.0.8.45)出現故障,好比宕機,es服務掛掉或重啓, 則主節點會轉移到其餘的兩個從節點中的一個上面.
在主節點轉移過程當中, 分片也會轉移過去, 若是分片比較多, 數據量比較大, 則須要耗費必定的時間, 在此過程當中, elk集羣的狀態是yellow.
具體表現:
[root@elk-node01 plugins]#  curl -XGET 'http://10.0.8.44:9200/_cat/health?v'
epoch      timestamp cluster  status node.total node.data shards  pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1542769559 11:05:59  kevin-elk yellow          3         3   2560 1898    0    4     1232             8            829.4ms                 67.4%
 
[root@elk-node01 plugins]#  curl -XGET 'http://10.0.8.44:9200/_cat/health?v'
epoch      timestamp cluster  status node.total node.data shards  pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1542769632 11:07:12  kevin-elk yellow          3         3   3074 1898    0    4      718             0                  -                 81.0%
 
[root@elk-node01 plugins]#  curl -XGET 'http://10.0.8.44:9200/_cat/health?v'
epoch      timestamp cluster  status node.total node.data shards  pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1542769637 11:07:17  kevin-elk yellow          3         3   3111 1898    0    4      681             4              221ms                 82.0%
 
...............
...............
...............
[root@elk-node01 plugins]#  curl -XGET 'http://10.0.8.44:9200/_cat/health?v'
epoch      timestamp cluster  status node.total node.data shards  pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1542769761 11:09:21  kevin-elk green           3         3   3796 1898    0    0        0             0                  -                100.0%
 
如上會發現, 在主節點發生變更, 分片轉移過程當中, 查看elk集羣狀態, shards分片會不斷增長, unassign會不斷減小,直至unassign減到0時, 代表分片已經徹底轉移到新的
主節點上, 則此時查看elk的健康狀態就是green了.  
 
在分片轉移過程當中, 訪問http://10.0.8.44:9200/_plugin/head/ 插件界面, 也會看到yellow狀態值,而且後面的分片數會不斷增長中.

====================================ES集羣相關維護命令====================================fetch

1) 查詢elasticsearch集羣信息（下面命令在任意一個節點機器上操做均可以）
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.45:9200/_cat/nodes'   
10.0.8.44 10.0.8.44 54 22 0.00 d m elk-node01.kevinbo.cn
10.0.8.47 10.0.8.47 38 54 0.00 d m elk-node03.kevinbo.cn
10.0.8.45 10.0.8.45 39 20 0.00 d * elk-node02.kevinbo.cn
  
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.45:9200/_cat/nodes?v'
host      ip        heap.percent ram.percent load node.role master name                      
10.0.8.44 10.0.8.44           54          22 0.00 d         m      elk-node01.kevinbo.cn
10.0.8.47 10.0.8.47           38          54 0.00 d         m      elk-node03.kevinbo.cn
10.0.8.45 10.0.8.45           39          20 0.00 d         *       elk-node02.kevinbo.cn
  
2) 查詢集羣中的master
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.45:9200/_cluster/state/master_node?pretty'   
{
  "cluster_name" : "kevin-elk",
  "master_node" : "1dL42NBYSL6mG9pg_ZUg-Q"
}
  
或者
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.45:9200/_cat/master?v'    
id                                            host         ip            node                      
1dL42NBYSL6mG9pg_ZUg-Q 10.0.8.45 10.0.8.45 elk-node02.kevinbo.cn
  
3) 查詢集羣狀態方法
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.45:9200/_cluster/state/nodes?pretty'   
{
  "cluster_name" : "kevin-elk",
  "nodes" : {
    "3Nw9dTQ5Qkmb-HW18kojeA" : {
      "name" : "elk-node01.kevinbo.cn",
      "transport_address" : "10.0.8.44:9300",
      "attributes" : { }
    },
    "wKrnuaSaQYic_r4jKIzPWQ" : {
      "name" : "elk-node03.kevinbo.cn",
      "transport_address" : "10.0.8.47:9300",
      "attributes" : { }
    },
    "1dL42NBYSL6mG9pg_ZUg-Q" : {
      "name" : "elk-node02.kevinbo.cn",
      "transport_address" : "10.0.8.45:9300",
      "attributes" : { }
    }
  }
}
  
4) 查詢集羣的健康狀態
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.44:9200/_cat/health?v'   
epoch      timestamp cluster  status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1542784475 15:14:35  kevin-elk green           3         3      6   3    0    0        0             0                  -                100.0%
  
或者
[root@elk-node01 ~]# curl -XGET 'http://10.0.8.44:9200/_cluster/health?pretty'   
{
  "cluster_name" : "kevin-elk",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 3,
  "active_shards" : 6,
  "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
}
  
5) 查詢集羣索引
[root@elk-node01 ~]# curl -XGET   "http://10.0.8.44:9200/_cat/shards"   
.cx-kibana  0 r STARTED 1 3.1kb 10.0.8.44 elk-node01.kevinbo.cn
.cx-kibana  0 p STARTED 1 3.1kb 10.0.8.45 elk-node02.kevinbo.cn
.ops-kibana 0 p STARTED 1 3.1kb 10.0.8.47 elk-node03.kevinbo.cn
.ops-kibana 0 r STARTED 1 3.1kb 10.0.8.45 elk-node02.kevinbo.cn
.nc-kibana  0 p STARTED 1 3.1kb 10.0.8.44 elk-node01.kevinbo.cn
.nc-kibana  0 r STARTED 1 3.1kb 10.0.8.47 elk-node03.kevinbo.cn
  
6) 查詢集羣索引狀態
[root@elk-node01 ~]# curl -XGET   "http://10.0.8.44:9200/_cat/indices?v"
health status index       pri rep docs.count docs.deleted store.size pri.store.size
green  open   .nc-kibana    1   1          1            0      6.3kb          3.1kb
green  open   .cx-kibana    1   1          1            0      6.3kb          3.1kb
green  open   .ops-kibana   1   1          1            0      6.3kb          3.1kb
  
7) 關閉或打開某個索引
好比關閉.ops-kibana索引
[root@elk-node01 ~]# curl -XPOST "http://10.0.8.44:9200/.ops-kibana/_close"
{"acknowledged":true}
  
[root@elk-node01 ~]# curl -XGET   "http://10.0.8.44:9200/_cat/indices?v" 
health status index       pri rep docs.count docs.deleted store.size pri.store.size
green  open   .nc-kibana    1   1          1            0      6.3kb          3.1kb
green  open   .cx-kibana    1   1          1            0      6.3kb          3.1kb
       close  .ops-kibana   
  
再次打開.ops-kibana索引
  
[root@elk-node01 ~]# curl -XPOST "http://10.0.8.44:9200/.ops-kibana/_open"
{"acknowledged":true}
  
[root@elk-node01 ~]# curl -XGET   "http://10.0.8.44:9200/_cat/indices?v"
health status index       pri rep docs.count docs.deleted store.size pri.store.size
green  open   .nc-kibana    1   1          1            0      6.3kb          3.1kb
green  open   .cx-kibana    1   1          1            0      6.3kb          3.1kb
green  open   .ops-kibana   1   1          1            0      6.3kb          3.1kb
  
8) 刪除索引
# curl -XDELETE  http://10.0.8.44:9200/索引名
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程