ES老集群用的2.4.1版本，跑的比较好就一直没动，最近看资料ES5.X已经稳定，并且性能有较大提升，心里就发痒了，但由于业务要保持高可用的属性，就得想一个平滑升级的方案，最后想到了多实例过度的办法，5.X版本网上介绍配置变化较大，也做好了踩坑准备，确定好要升级后，立刻动手。
一、对应升级改造方案
使用端口9220和9330 安装并配置好新的ES5.2.1实例——>关掉logstash并将ES2.4.1实例堆栈调小重启（kafka保留3个小时日志所以不会丢失）——>启动ES5.2.1并将logstash开启指向ES5.2.1——>安装新版kibana实例做好指向，老数据用http://host/old访问——>ES5.2.1配置调优。
二、升级后统一用supervisord-monitor管理
github：https://github.com/mlazarov/supervisord-monitor
三、优化前后ES的cpu、IO和thread_pool的监控数据如下
优化前：
优化后：
从监控数据看最高的活跃进程数还是bulk的批量处理操作，如果不调优，直接会block。
四、升级过程——编写了ES5.2.1的安装脚本如下
之前用的rpm包，后考虑直接使用tar包安装，对于需要系统做的调优操作，直接编写自动化安装脚本，一键将所有系统参数配置后，将环境搭建好。
#/bin/sh
#writer:gaolixu
id
elasticsearch ||
useradd
elasticsearch -s
/sbin/nologin
#添加用户
grep
"* - nofile 512000"
/etc/security/limits
.conf ||
echo
"* - nofile 512000"
>>
/etc/security/limits
.conf
#修改文件描述符数量
grep
"elasticsearch - nproc unlimited"
/etc/security/limits
.conf ||
echo
"elasticsearch - nproc unlimited"
>>
/etc/security/limits
.conf
#修改最大打开进程数数量
grep
"fs.file-max = 1024000"
/etc/sysctl
.conf ||
echo
"fs.file-max = 1024000"
>>
/etc/sysctl
.conf
#修改系统文件描述符
grep
"vm.max_map_count = 262144"
/etc/sysctl
.conf ||
echo
"vm.max_map_count = 262144"
>>
/etc/sysctl
.conf
#修改程序最大管理的vm
sysctl -p
cd
/usr/local/src
[ ! -f
/usr/local/src/elasticsearch-5
.2.1.zip ] && wget
https:
//artifacts
.elastic.co
/downloads/elasticsearch/elasticsearch-5
.2.1.zip
[ ! -d
/usr/local/src/elasticsearch-5
.2.1 ] && unzip elasticsearch-5.2.1.zip
mv
elasticsearch-5.2.1
/usr/local/
chown
-R elasticsearch:elasticsearch
/usr/local/elasticsearch-5
.2.1
#修改拥有者所有组
sed
-i
's/-XX:+UseConcMarkSweepGC/-XX:+UseG1GC/'
/usr/local/elasticsearch-5
.2.1
/config/jvm
.options
#GC方式修改为G1
sed
-i
's/-XX:CMSInitiatingOccupancyFraction=75/-XX:MaxGCPauseMillis=200/'
/usr/local/elasticsearch-5
.2.1
/config/jvm
.options
sed
-i
's/-XX:+UseCMSInitiatingOccupancyOnly/#-XX:+UseCMSInitiatingOccupancyOnly/'
/usr/local/elasticsearch-5
.2.1
/config/jvm
.options
五、升级过程——配置文件、索引相关的更新调优
升级期间着实踩了不少坑，老版ES索引配置可以直接写到配置文件里，新版是不行的，必须使用api去设置，另外ES2.X版本的进程数调优，在ES5.X我发现调整与否没有影响。配置文件如下：
cluster.name: yz-5search
path.data:
/data1/LogData5/
path.logs:
/data1/LogData5/logs
bootstrap.memory_lock:
false
#6内核不支持，必须要关闭
bootstrap.system_call_filter:
false
network.host: 10.39.40.94
http.port: 9220
transport.tcp.port: 9330
discovery.zen.
ping
.unicast.hosts: [
"10.39.40.94:9330"
,
"10.39.40.95:9330"
,
"10.39.40.96:9330"
,
"10.39.40.97:9330"
]
discovery.zen.minimum_master_nodes: 2
http.cors.enabled:
true
http.cors.allow-origin:
"*"
为了加快索引效率，编写index的模板配置（index配置不允许写到配置文件了），将参数put到es的里，当然模板也可以通过前端logstash指定（要改logtash觉得麻烦），template脚本如下：
#/bin/sh
#writer:gaolixu
#index template
curl -XPUT
'http://10.39.40.94:9220/_template/cms_logs?pretty'
-d '{
"order"
: 6,
#优先级
"template"
:
"logstash-cms*"
,
#正则匹配索引
"settings"
: {
"index.refresh_interval"
:
"60s"
,
#索引刷新时间
"index.number_of_replicas"
:
"0"
,
#副本数设置为0
"index.number_of_shards"
:
"8"
,
#分片数设置为8，共4台服务器
"index.translog.flush_threshold_size"
:
"768m"
,
#translog触发flush的阀值
"index.store.throttle.max_bytes_per_sec"
:
"500m"
,
#存储的阀值
"index.translog.durability"
:
"async"
,
#设置translog异步刷新到硬盘，更注重性能
"index.merge.policy.segments_per_tier"
:
"25"
,
#每一轮merge的segment的允许数量,默认是10
"index.merge.policy.floor_segment"
:
"100mb"
,
#小于这个值的segment会四舍五入，防止很小的segment的频繁flush
"index.merge.scheduler.max_thread_count"
:
"1"
,
#机械盘设置为1
"index.routing.allocation.total_shards_per_node"
:
"2"
#每个节点上两个分片
}
}'
备：如果是更改，将PUT改为POST
日志保留7天，清除的脚本如下，写入计划任务：
#!/bin/bash
#writer:gaolixu
DATE=`
date
+%Y.%m.%d.%I`
DATA2=`
date
+%Y.%m.%d -d
'-7 day'
`
curl -XDELETE
http://10.39.40.97:9220/logstash-*-${DATA2}*?pretty
由于单个索引达到了35G甚至40G以上，于是在logstash层面对建索引数量进行修改，把每天12个索引修改为每天24个索引：
logstash的修改如下：
index =>
"logstash-cms-front-nginx-%{+YYYY.MM.dd.hh}"
修改为
index =>
"logstash-cms-front-nginx-%{+YYYY.MM.dd.HH}"
备注：supervisor的安装
easy_install meld3
easy_install pip
easy_install supervisor