1. 程式人生 > >ELK從5.6.3升級到6.3.0總結

ELK從5.6.3升級到6.3.0總結

gist lds kibana super alloc 決定 自己 earch 來看

ELK從5.6.3升級到6.3.0總結

由於6.3.0默認有es的監控功能,並且我們現在es總是有各種問題,原有的es開源插件head和HQ的監控都不夠詳細,所以決定升級es集群。我們目前es有5個node。我們的數據流向是filebeat logstash kafka logstash elasticsearch grafana

elasticsearch 升級總結

安裝總結

由於各種配置文件問題,直接rpm -e elasticsearch, 然後安裝6.3.0的es,/etc/elasticsearch/elasticsearch.yml 配置文件不變。

rolling update 總結

根據官網從5.6.3到6.3.0可以rolling upgrade,按照步驟直接操作,但是在升級完一個node之後,等es沒有Initializing Shards和Relocating Shards的時候,等了兩天的時候,Initializing Shards和Relocating Shards一直有,而且新的index貌似大部分都在升級的這個節點,導致數據嚴重不均衡,如果這樣下去,這樣這一個新升級的節點承受不了這麽大的數據量,這時候找了是3臺空閑機器,裝上6.3.0的es加到整個集群中,這樣一直等到了沒有Initializing Shards和Relocating Shards的時候,但是按道理講,es應該變成綠色,但是es集群還有UNASSIGNED shards,不過沒有Initializing Shards和Relocating Shards。當時判斷數據不會丟,所以接著升級,這樣所有節點升級完成。後來發現UNASSIGNED shards應該是升級完後老的index有些邏輯問題,下面詳細說下。

UNASSIGNED shards問題

在升級完所有index後發現還有UNASSIGNED shards的問題,確認集群的設置cluster.routing.allocation.enable已經由“none”設置成null了,看有人說要手動reroute這些shards,看了一下大概有500個shards,當時找了一個狀態yellow的index發現replicas是1,有10個shards,5個UNASSIGNED,(當時認為replica應該是2,後來發現自己是錯的,正常replica就是1,這樣一共兩副本)直接改成2,結果狀態是15個shards,5個UNASSIGNED,我又改回了replicas=1,這樣這個index狀態就green了,然後就按照這個方法改,後來發現replica=2最後一個shard需要20分鐘才確定到node上index才變green,這樣把replica=3,在started shards是14的時候把replica=1,這樣就修復了400多個shards,還剩下10個左右的shard UNASSIGNED,在反復執行一下這個流程,這樣所有的UNASSIGNED shards就解決了。後來發現做這個過程中es報了大量的錯誤,估計這個有很多的邏輯錯誤,es需要反復修復,當時我們的ELK系統中logstash已經判斷es不可用了,但是從es的監控來看es是正常的,估計就是es修復這個UNASSIGNED shards需要耗費寫資源,下次要是再處理這個問題,需要慢慢的處理,不能短時間內修復所有的shards(我當時差不多1個小時就把500多個shards修復了,主要是分片的量小,整個index才不到5m),需要持續監控es的狀態還有日誌,最好在es比較閑的時候做。

最終都升級完成了,es整體的狀態green了。

消費kafka的logstash5.6.3升級到6.3.0問題

配置文件沿用原有的沒有問題,但是升級完後logstash template有問題,logstash無法往es裏面放數據,具體的時間點是所有es節點都升級完成的第二天,(es需要所有節點都升級完成後,es的整個集群才是新版本的),logstash新建index的時候,原有template和新版本的不兼容,當時由於這些日誌logstash已經在kafka裏面commit了offset,如果不能及時解決,這段時間的所有日誌都會丟失(可以找回,但是我們kafka 30多個topics,150多個partition,難度很大),百度了一個解決方案,直接刪除原有logstash的template,重啟logstash,logstash就會在es裏面重新創建template。這樣消費kafka的logstash就算升級完成。後來又仔細看了一下其實只要刪除template中帶_all的配置就行了,新老的區別就只是這一個。

kibana升級總結

這個沒有太多操作,由於kibana的數據放到了es的.kibana index,升級完成後,說kibana數據需要升級,界面也給了升級鏈接,直接按照步驟升級就ok了。升級鏈接

grafana升級總結

這個是這次升級一起搞的,grafana從4.X升級到5.X,直接安裝新的軟件,拷貝/var/lib/grafana/grafana.db就行了。然後啟動grafana就ok了。

收集端filebeat和logstash升級

這個還在計劃中,預計就是停止所有filebeat,然後停止logstash,收集端備份/var/lib/filebeat/registry,和/etc/filebeat/filebeat.yml文件。然後升級filebeat,修改原有用到document_type的地方改成fields。然後logstash也要升級完後對應的修改,然後這兩個組件也要加上xpack.monitor的配置,接著把filebeat和logstash起來就行了。需要註意的是之前裝過filebeat6.2版本,這個版本在centos6上用/etc/init.d/filebeat restart,總是停出問題來,如果文件還是這樣,建議用supervisor啟動filebeat,可以嘗試supervisor的這個配置(stopasgroup = true): stopsignal = KILL。

ELK從5.6.3升級到6.3.0總結