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。