Elasticsearch 填坑记

前言

        技术的发展突飞猛进，传统企业数据库Oracle、SqlServer、DB2，Mysql等在今日不断的被各类大厂自研数据库取代，固然也有相似Elasticsearch等优秀的知足海量数据所使用的开源数据库。

       我司多个日志审计与态势感知项目中，也没有免俗，选择了Elasticsearch做为咱们的日志存储与搜索引擎。关于Elasticsearch基础知识就不作更多介绍了，随便搜索下，有大量的介绍和使用文档。

       本文主要介绍咱们在多个项目中，使用Elasticsearch过程当中，各类填坑记录。

       在具体的生产环境中，我相信你们不会用Windows做为Elasticsearch的运行服务器的，因此下文基本都是以Linux（Centos7）为主要的运行环境。

       如下内容，仅供参考，实际遇到的问题，都须要在运维过程当中，去仔细分析，查阅文档。解决问题的方法可能很简单，关键是能准确的定位问题，分析问题。

• 安装

       Elasticsearch安装就很少阐述了，主要记住：建立非root用户，修改linux系统参数，修改jvm运行参数，修改Elasticsearch运行参数，这4个主要部分。

       因为Elasticsearch版本迭代比较快，不一样的版本个别参数可能已经变动或废弃，因此修改前必定要认真阅读对应版本的官方文档，该参数是否还有效，这个地方是一个坑，须要重点注意。

 

• 运行与系统调优

       Elasticsearch的安装其实仍是比较简单的，可是在实际运行中，各类各样的问题就来了。在实际运行中出现的问题，其实主要仍是数据量的问题，随着数据量的增加，就会出现各类资源问题，须要随时解决和调优。

1.内存问题

       官方建议Elasticsearch每一个节点jvm配置内存不要大于系统总内存的一半同时不要大于32G。

       Elasticsearch自己在运行过程当中，随着数据量的增长，内存的使用会愈来愈多，gc回收会愈来愈慢，最终致使Elasticsearch虽然活着，但不响应任何请求。

       这种状况下，扩充节点是个选项，可是大多数的状况，预算是固定的，硬件资源也是固定的，只能采起其余办法。

• 数据要根据业务作成多索引的方式，由于每一个索引都是占用内存的，多索引才有可能关闭部分历史数据索引，释放内存。最好作成定时任务，按照规则关闭不用的索引。

• 定时对索引进行合并（merge segment）

• jvm垃圾回收机制能够考虑配置为 UseG1GC 

• 即便按照官方说明配置成32G如下，好比31G，在短期数据量暴增的状况下，容易带来linux oom问题，若是存在这种状况，建议再配置小一点。

2.文件句柄问题

       linux中，全部的一切都与文件有关，实时打开的文件句柄数是有限制的，Elasticsearch能够看着是基于文件的数据库，随着数据量的增长，打开的句柄愈来愈多，就会致使系统中止对外响应，好比ssh登陆不上去等问题。

       这种状况，首先建议调整linux内核参数，修改系统打开的最大文件句柄数量。

       其次仍是要控制索引的数量，不要无限制的增加下去，想办法控制同时打开的文件句柄数量。

 3.硬盘问题

       硬盘固然是读写速度越快越好，数据量比较大的环境能够考虑冷热数据分离。

       须要注意的是当Elasticsearch数据所在的硬盘空间使用超过80%以上时，就可能出现数据再也不写入该节点的状况，因此须要定时监测硬盘使用量。

       另外，不太建议使用经过网络挂载的硬盘空间。

       总的来讲硬盘有关的问题相对少点，就很少说了。

 4.其余问题

       如下的问题，多是在特定的环境下，特定的版本上出现的。

       运行环境，vmware+centos7.4 ， kernel 3.x，3个ES节点，各64G内存。

       问题1：3个节点中，有2个数据节点频繁宕机，kernel异常日志提示watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [java:5783]。

       各类搜索，建议升级内核版本，大于4.13.0-1017。

       辛辛苦苦给2个节点升级内核，具体方法，自行百度，升级内核的坑就很少说了。

       问题2：升级内核后，问题1基本解决，可是在短期数据流暴增的状况下，出现OOM问题。

       分析缘由，应该仍是jvm内存设置为31G，es索引底层索引内存请求加上jvm内存请求可能超出系统总物理内存（毕竟还有其余程序也要占用内存），致使OOM问题。解决办法，jvm内存适当调小一点。

       固然也能够调整内核参数，取消OOM特性（不建议在生产环境使用）。

       问题3：最郁闷的状况，解决完上述两个问题后，系统平均10多分钟就宕机一次，系统日志无报错，只在vcenter控制台上，提示kernel BUG at       drivers/net/vmxnet3/vmxnet3_drv.c:1441!。继续搜索，发现这是vmware的一个bug，在特定状况下出现：

       Linux VM is running kernel >= 4.8

       HW version of VM is >=13

       ESXi version is 6.5

       解决办法：

              修改虚拟机vmx配置文件，添加vmxnet3.rev.30 = FALSE

              或者 设置ethtool -G ethX rx-mini 0，ethX为网卡名称