線上部署了ELK+Redis日志分析平台環境, 隨着各類日志數據源源不斷的收集, 發現過了一段時間之后, ELK查看會原來越慢, 重啟elasticsearch服務器節點之前同步時間也會很長, 這是因為長期以來ELK收集的索引沒有刪除引起的! 以下是ELK批量刪除索引的操作記錄:
1) 訪問head插件(http://10.0.8.44:9200/_plugin/head/) 或者在elasticsearch節點上使用下面命令查看elk的索引(10.0.8.44是elk集群中的任意一個節點)
[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) 可以先將要刪除的索引查看出來存到臨時文件里, 然后進行批量刪除 (索引多的話, 刪除操作會耗費一點時間)
比如批量刪除所有的索引(但不會刪除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索引已被批量刪除了.
====================================ES集群節點切換=======================================
在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集群相關維護命令====================================
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/索引名
