Elasticsearch 填坑记

Posted 2020-11-20 wishma

前言

        技术的发展日新月异，传统企业数据库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为网卡名称