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。