ElasticSearch 监控实战

作者：SUNNY
时间：2018-10-13

---

摘要：本文从运维角度，结合ElasticSearch（文中简称ES）运维实战经验，对ES服务监控进行总结。文中主要从监控工具选型、监控采集项筛选进行介绍，最后列举了几个通过监控发现的ES线上问题。

ES简介

Elasticsearch（下文简称ES） 是一个分布式的 RESTful 风格的搜索和数据分析引擎，能够解决不断涌现出的各种用例。作为 Elastic Stack 的核心，它集中存储您的数据，帮助您发现意料之中以及意料之外的情况。

ES作为基础组件在互联网公司中扮演着越来越重要的角色，因此运维开发人员必须要具备快速发现ES隐患、故障，迅速定位ES故障根因的能力。

ES监控概览

针对ES进行监控，主要期望解决这几种场景：

• ES日常服务巡检，帮助运维开发人员及时发现隐患；
• ES服务异常后，帮助运维开发人员及时发现故障；
• 采集的ES监控指标，帮助运维开发人员迅速定位问题根因。

能够及时发现ES服务异常，这是最主要目标。

监控工具选型

借助运维工具，在ES实际运维工作中会很大程度上提高运维开发人员的工作效率。目前ES可用的监控工具或插件又很多，对多种监控工具进行使用后，我们最终的监控工具选型为：

• X-Pack+kibana
  索引信息、集群整体信息很有帮助，尤其是各索引的索引、搜索速率，索引延迟数据等。其中，X-Pack是官方给出的插件（monitoring为开放特性，阿里云中充当商业插件），需要注意的是，ES集群上线前需要安装X-Pack插件。
  
• Jmxtrans-ES+influxdb
  主要进行核心数据采集、监控。ES本身提供的jmx信息有限，这里使用了Jmxtrans-ES（自研）工具，通过http接口获取信息后，写入到influxdb。ES与influxdb的结合，官方给出的方案是读取X-Pack中的索引信息，考虑到X-pack索引是存储在ES，保留时间有限，以及与本公司监控系统的对接，我们自己开发了Jmxtrans-ES工具进行核心信息采集。

• Elasticsearch-HQ
  这款工具属于清新风格。之前使用的head插件，在集群规模达到一定程度后，head插件信息展现很糟糕，因此使用了HQ代替head部分功能。如果很难记住管理API，可以使用ES-command工具。

告警系统对接本公司告警系统。

采集项筛选

实战中，ES集群部署使用5.x版本，区分协调（coordinating）、摄取（ingest）、主（master）、数据（data）等节点，独立部署，数据节点机器异构。

按照SRE黑盒监控和白盒监控（4项指标）进行分类：

黑盒监控

• 集群功能
  索引创建、删除、文档写入、查询等基本功能。实际监控中，创建索引时，需要控制好频率以及分片的分配情况。实战中，由于索引创建频率较高，并且分片数量设置不合理，导致集群pending任务堆积，导致正常业务创建索引出现大量延迟或失败。

• 集群整体状态
  理论上，集群正常状态为green，出现red时，集群肯定存在部分索引主备分片全部丢失情况。集群状态为yellow时，也不能完全代表集群没有问题，比如，创建索引时，如果分片没有完全分配完成，也会出现yellow状态，因此集群出现yellow时，也需要重点关注或排查集群可能存在的问题。

• 活跃分片数百分比

• Pending任务数
  Pending任务数99%时间均为0，如果出现长时间为非0情况，集群肯定出现了异常。

白盒监控

容量
作为存储组件，对于存储容量的监控至关重要。

• 总存储空间
  ES本身没有提供此方面监控数据，需要自行进行计算。

• 已用存储空间
  总存储空间是不能全部使用完，需要预留一部分空间。

• 最大分区使用
  在ES中，如果某数据节点单块数据目录使用率超过90%（默认值，可以通过cluster.routing.allocation.disk.watermark相关配置来调整），则会进行分片数据迁移。因此，在数据盘存在异构的集群中，为避免分片迁移，监控此值，至关重要。

• 机器（或实例）资源（cpu、load、disk、jvm）

• 分片数量
  最好不超过一万个分片。官方推荐，单个实例JVM内存不超过30GB，不超过600个分片。另外，分片是由Master来维护其状态的，而Master在任何集群规模下，有且仅有一个节点在工作，其余均为候选主节点，因此分片数量越高，Master常态的压力越大，故障后恢复的耗时也越长。合理的分片数量与集群节点数、写入数据量、磁盘读写性能等存在一定关系，具体可以参考官方说明。

• 线程池队列长度

流量

• 索引、搜索速率
  需要监控总量，但是需要采集主要index的数据，便于问题定位。例如哪个索引突增流量将集群压垮了？如果没有细化的index的相关数据采集，就只能通过index的体积来进行间接判断，延时也类似。

• 集群网络IO

• 集群数据节点IO
  实际部署中，会区分摄取（ingest）、主（master）、数据（data）等节点，这里重点监控数据节点IO。

延迟

• 索引、搜索延迟
• 慢查询

错误

• 集群异常节点数
• 索引、搜索拒绝数量
• 主节点错误日志

通过监控发现问题

场景1：

如果Elasticsearch集群出现问题，通过ES接口获取到的监控数据可能出现响应超时，无法响应情况，造成监控工具不可用。

发现方式：功能监控响应超时告警

优化建议：1）避免该场景出现：需要在日常巡检排查中，发现集群隐患，优化集群配置项，消除隐患；2）如果出现此问题：那么针对各实例的存活性，错误日志监控不可缺失，通过此监控信息快速定位。

场景2：

如果某数据节点任何一个数据目录不可用（比如磁盘故障，其他应用占满数据目录）则新建索引若有分片分配到上面之后，则会出现创建索引失败。

发现方式：功能监控告警、pending任务堆积告警

优化建议：为避免此问题出现，数据盘可以做raid5或raid10，避免多个服务共用同一数据目录等。当然数据目录的可用性，也需要有方法能够知道。:

场景3：

某索引因程序问题，出现大量创建type，导致集群异常。

发现方式：pending任务堆积告警。之后排查各索引写入速率，找到异常索引。

优化建议：定期排查重点索引的数据写入合理性，以及服务巡检。