码迷,mamicode.com
首页 > 其他好文 > 详细

ELK从5.6.3升级到6.3.0总结

时间:2018-06-29 14:09:54      阅读:407      评论:0      收藏:0      [点我收藏+]

标签:out   区别   signed   执行   logstash   guid   cluster   nal   停止   

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总结

标签:out   区别   signed   执行   logstash   guid   cluster   nal   停止   

原文地址:https://www.cnblogs.com/WisWang/p/9242641.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!