使用 ElasticSearch 踩过的坑 | 掘金技术征文

4,519 阅读11分钟

版权申明:
此文章首发于公众号程序员在深圳,搜索 studycode 即可关注
本文无需授权即可转载,转载时请务必注明作者

使用ElasticSearch将近3个月了,在使用过程中,陆陆续续踩了不少坑,每次觉得无法逾越时,心里都想放弃,一是因为这东西要完全掌握不是那么容易,需要花很多时间;二是如果继续使用曾经用过的zabbix,说不定可以很快满足眼前的需求,从而可以抽身做其他事情。但坚持下来,就一定能从坑里爬起来,从而对这个系统更加了解,并利用这头”猛兽”帮助我做更多事情。原因很简单,ElasticSearch除了是一个分布式数据库,还是一个扩展性和可用性都很强的近实时搜索引擎。

目前为止,踩过以下几个坑:

  1. 集群搭建不成功
  2. 未使用内网IP,导致恢复缓慢
  3. 未使用队列及logstash,导致数据丢失
  4. Master和DataNode未分离,导致集群不稳定
  5. Logstash吞吐量问题
  6. Logstash如何创建Mapping
  7. head插件安装错误

犯了这么多错误基本上都是使用不当、以偏概全的原因,以为看了一点文档,就凭直觉可以猜测到系统的所有内容,造成了后续问题的不断涌现,下面就逐一说一下淌坑过程

集群搭建不成功

一开始是在单机上玩ElasticSearch的,上生产环境肯定要使用它的集群功能,但文档说只需要在elasticsearch.yml中设置cluster.namenode.name即可,ElasticSearch节点启动时会自动发现集群并加入到集群,但全部设置完毕后,竟无法使各个节点组成集群,最后发现这种方法只在一台机器上有效,而要组成集群,需要在每台节点做以下配置:

discovery.zen.ping.unicast.hosts: ["Node1_IP:9300", "Node2_IP:9300", "Node3_IP:9300"]

ElasticSearch一般会开两个端口,一个是集群维护端口,如上面的9300; 一个是对外提供的端口,默认是9200。

未使用内网IP,导致恢复缓慢

在部署集群时,我挑选了几台配置相近的同网段机器,但当时其中一台机器操作系统没有加载内网网卡,为了偷一下懒,便直接使用了外网IP,集群是跑起来了,运行了一段时间也没有什么问题,但随着流量越来也大,终于有一天Master突然down掉了,我当时心想,ElasticSearch集群本身具有故障转移功能,马上会分配一个Master节点,然后我只需要把原先的Master节点重启即可,然而重启了之后,通过head页面查看恢复情况,发现集群长时间处于黄色状态(有replica shard丢失),而丢失的shard一直处于未分配状态,并没有如我预期的:启动后,该节点可以重用在磁盘上的shard数据,上报给Master,不需要数据拷贝,立马恢复为绿色状态。过了几分钟后,我发现恢复的shard数正以缓慢的速度增加,便推导出这样的错误结论:ElasticSearch在某一台机器挂掉后,只会从primary shard复制数据,即便节点迅速恢复,也不会复用该节点上的数据,如果是这种实现方式,我认为这种恢复速度是无法接受的,顿时产生了无法继续使用下去的念头,当时的心情是无比失落的。

而ElasticSearch的使用是相当广泛的,我们熟知的世界最大同性交友网站也是使用它来实现搜索功能的,所以可以断定是我的使用方法有问题,要么是我选的版本不稳定,要么是其他的原因,而稳定版一般出问题的几率不大,因此在换版本之前,需要找其他方面的原因,很久之前看过一篇google的slide,上面有一页介绍了不同介质数据的传输速度:外网的传输速度在10ms级别,而内网却在20微秒级,这种速度的差异便会造成以下几个方面的影响

  • 集群无法提供正常服务:因为每个请求,ElasticSearch节点都会经过转发和收集两个过程,如果使用外网网卡,便会造成延迟大,访问量上不去,而流量到达一定程度后,集群很快便无法提供正常服务
  • 由于ES集群已经无法正常服务,所以down机、恢复困难一系列综合症的情况便会陆续发生

后续我将集群切到了内网中,再测试重启某一个节点,便不会再出现恢复一个节点需要半天的情况了。


slide

未使用队列或logstash,导致数据丢失

最初用到的架构非常简单: 使用ES(ElasticSearch缩写)集群作为存储,beats和rsyslog作为shipper向ES集群发送数据,使用这种架构的主要原因是配置简单,ES本身是一个高可用集群,直接把数据发过去就好。而自己心里还产生了为什么会有ELK架构,感觉Logstash是多余的想法,在发生了几次down机之后,才发现之前的想法很傻很天真,之前的架构也有明显的问题


old

  • 在某一个节点down掉后,如果不马上恢复,在不了解beats负载均衡机制的前提之下,很难判断数据还会不会发送给down掉的节点,而新增一个节点,需要修改所有beat的配置,即这里至少要使用一个负载均衡器给所有ES节点做负载均衡
  • ES是一个高可用集群,但目前还没有足够的使用经验,所以可能今后还会出现集群故障的问题,而出故障,很可能造成数据的丢失,为了避免这种情况发生,需要在beats和ES集群之间构建一套可持久化的队列,最简单的队列是redis,而logstash放在redis两边分别作为生产者和消费者。想到的方案便是beats->logstash->redis->logstash->ES,这样便解决了丢数据的问题,当然最新版的logstash可以将数据持久化到磁盘上,也许可以对此模型进行简化

Logstash和Redis的使用都非常简单,这里就不一一介绍,值得注意的是,如果要使用redis做持久化,需要使用Redis的List的方式,而不是Sub-Pub的方式,以下是具体的架构图,箭头的方向是数据流动的方向。


new

Master和DataNode未分离,导致集群不稳定

在ES集群中,节点分为Master、DataNode、Client等几种角色,任何一个节点都可以同时具备以上所有角色,其中比较重要的角色为Master和DataNode:

  • Master主要管理集群信息、primary分片和replica分片信息、维护index信息。
  • DataNode用来存储数据,维护倒排索引,提供数据检索等。

可以看到元信息都在Master上面,如果Master挂掉了,该Master含有的所有Index都无法访问,文档中说,为了保证Master稳定,需要将Master和Node分离。而构建master集群可能会产生一种叫做脑裂的问题,为了防止脑裂,需要设置最小master的节点数为eligible_master_number/2 + 1

脑裂的概念:
如果你有2个Master候选节点,并设置最小Master节点数为1,则当网络抖动或偶然断开时,2个Master都会认为另一个Master挂掉了,他们都被选举为主Master,则此时集群中存在两个主Master,即物理上1个集群变成了逻辑上的2个集群,而当其中一个Master再次挂掉时,即便它恢复后回到了原有的集群,在它作为主Master期间写入的数据都会丢失,因为它上面维护了Index信息。

根据以上理论,我对集群做了如下更改,额外选取3个独立的机器作为Master节点,修改elasticsearch.yml配置

node.master = true
node.data = false
discovery.zen.minimum_master_nodes = 2

修改其他节点配置,将其设置为DataNode,最后挨个重启

node.master = false
node.data = true

Logstash吞吐量问题

在使用了新的架构后,我发现了当流量上来后,Redis的队列会持续增长,消费速度跟不上生产速度,造成的问题是数据在Redis中堆积,图表展示有大量的延迟。解决这个问题有以下几个思路

  1. 可能是ES插入速度太慢,需要调整参数提升插入性能
  2. 可能是Logstash吞吐量低,需要增加每次向Redis拿数据的缓存、增加向ES输出的缓存、增加线程数、增加每次批量操作的content length

对于ES调优中,我调整了线程数,增加线程队列,增大shard数,但都没有解决问题。

而Logstash调优,我首先调整了LS_HEAP_SIZE参数,让Logstash可以同时处理大量的数据,然后主要专注在调整Logstash的Input和Output插件参数上,插件中可以设置线程数、batch_count数值等,而当我将Redis插件参数改为batch_count=>10000后,发现队列不再一直增长了,它会涨到一定程度后,瞬间减少到2-3位数,即队列的长度在一定范围内浮动,当时欣喜若狂,以为自己解决了,但跑了大概5个小时候,发现队列又开始不断增长了,问题并没有得到解决。而产生解决了的假象应该是我增加了Logstash内存的原因,数据只是先把Logstash内存填满,再开始填队列,而填满Logstash内存花了几个小时,关键的Logstash到ES的吞吐量还是没有上去,在access日志中,无论如何也无法让bulk API的content length增加,如下图中的长度一直维持在2K左右。


accesslog

最后,我采用了替换Logstash版本的策略,更新了时下最新的5.1.1版本,由于新版的配置和旧版配置不一样,所以认真研究了一下配置,在这个过程中,我发现了一个-b参数可以修改批量插入的大小,也许就是我需要的。果然,将这个参数由默认的125改为了1000,顺利的解决了这个难题,同时也证明了并不是版本问题,还是使用问题,而这个参数也正是修改content length的方法,顺便说一下,如果你使用nginx作为负载均衡器,你需要同时增加client_max_body_size参数,避免产生content length过大而返回413错误码。

Logstash如何创建Mapping

当使用Logstash进行转发时,有可能你的数据都在一个Index中,当然你也可以设置不同的Index,这篇文章中就有根据type来划分Index的方法,不管划不划分Index,都会默认生成一个或多个mapping结构,mapping结和不同的type即对应MySQL中的数据库和表结构信息,当然我这里不是为了说明它们的区别,而是我们无法自定义字段的类型。

这会产生各种各样的问题,比如它会默认产生analyzed类型的string字段,会自动将带有连接符的字符串分为两个字符串输出,即"idc-1"这样的字符串会输出为"idc"和"1",这并不是我想要的,让我相当困扰,而Mapping在生成后是无法修改字段的,除非你换一个新的字段。

解决这个问题的方法并不在mapping上,而我却花了很多时间在这个上面,最终答案却是使用template,在template中可以定义你需要的mapping,这样便解决以上问题。到此,我还是不能完全理解里面的机制,以后抽空了解后再补上。

head插件安装失败

上文有介绍head插件,它是一个可以显示集群状态及操作ES集群的UI,可以取代官方的X-Pack,后者只有30天的试用期,因为创业公司,能用免费的尽量采用免费的。在集群中,有几个节点安装该插件会失败,提示:Unable to veryfy checksum for download plugin ...,google上查了一圈仍然没有找到解决办法,最后试着手动将该插件下载然后解压到/usr/share/elasticsearch/plugins/目录下,并将目录改为head即可解决该问题。

以上问题是我这段时间来碰到的坑,每个都花了不少时间去解决,自己也比较幸运,花在上面的时间没有白费。因为个人觉得这个技术栈实在是比较好,而资料主要以英文的为主,把自己的经历写下来,希望今后不再犯同样的错误,也希望可以帮助其他使用该技术的同学。

本文参与了掘金技术征文活动:juejin.cn/post/684490…


欢迎您扫一扫上面的微信公众号,订阅我的博客!