由Elasticsearch的API命令，引发的金融业生产故障

作者介绍

图示：Elasticsearch目前在DB-Engine综合排名第8

Elasticsearch博大精深，提供了非常丰富的应用场景功能，也提供了丰富的API命令操作，有些API非常好用，有的API用一用就要出大事，防不胜防。

以下围绕某客户一次客户端应用程序生产事故错用Cluster State命令展开，从问题定位到问题解决，记录自己的过程与方法，还有一些心得总结（注：具体客户信息不便透漏，以下部分图片信息仅为示意图）。

客户属于传统型金融行业，ES用来解决日常的数据查询与存储，利用ES非常好的横向扩展特性，满足多种场景应用。

ES集群版本属于5.6.x，已经超出Elastic官方支持的版本，集群节点数不到10个，节点硬件配置属于均衡一致性，标准的性能型合理范围硬件配置，应用于业务系统提供查询或者更新等，日常都有提供定期巡检，基本正常稳定，不过一直侧重的是集群运维本身，很少会深入到应用端程序去巡检分析，业务线太多，经费有限。

ES集群设置并未采用Master与Data分离设计，所有节点均是同等角色权限。ES集群数据量也是属于正常支撑能力范围，集群索引的分片数量在2w以上，注意这个数字，后面会基于此来突破寻找问题。

客户端应用程序基于Spring data elasticsearch开发框架，引用Trasnport-client直连模式，中间未采用任何代理Proxy负载产品。

客户端应用程序部署了多个实例，按照2的倍数增加，需要做一些“大量”数据的写入与查询，瞬间并发的操作ES集群，无论怎么操作，ES的并发数并不高，但应用端程序就是运行不快，这很不合常理也不合事宜，常识告诉我这不正常。

图示：客户公司的应用项目架构示意图，客户端采用Transport-client直连模式

客户端应用程序只要开始运行，ES集群立刻会慢起来，但查看ES集群整体资源消耗，ES所在节点CPU/MEM/硬盘IO并不高，其数据节点甚至非常低，远远没有达到节点的瓶颈。

经过细细观察发现，集群的Master节点流量特别高，其余节点数据流量都传给Master节点，超出了Master单节点网络IO的极限，这显然不正常。但在生产环境上并不容易排查。后面经过在本地开发环境模拟压测，终于确定了问题来源，是客户端的某个集群管理操作 API引起的。

最终，找到了 Cluster State Api 统计命令引起的，客户端应用程序每次做实际业务前，都会调用这个API命令获取集群一些索引与Mapping信息，由于客户端是采用多线程设计，且部署多个实例，只要并发数高，所有流量必然打到Master节点，造成整个集群响应慢。由于整个集群有近2w个分片，执行一次State 命令，需要统计汇总集群所有索引分片信息，并最终汇总到Master节点，造成实际Master节点网络IO超过极限。

图示：cluster state api返回内容，索引越多，返回内容越大。

以上我们快速讲了一下问题现象与事故原因， 下面重点聊一下问题排查过程以及采用的工具方法思维等。

特别说明，由于是远程协作分析排查以及客户公司的行业特性，外部不能直接操作远程任何节点，必须通过客户公司运维人员间接指导操作排查，过程稍微有点曲折。

首先是ES集群问题排查，这是很正常直接的思维，在问题爆发点排查（ps：类似警察先赶到案发现场，采集证据）。由于集群版本是5.6.x，一些原因并未启用官方的XPack功能，所以也就没有自带的Kibana监控可视化报表，国内早期多数用户都是采用开源免费版本搭建集群，客户公司基于Zabbix搭建有集群节点的基础指标监控，总算是有一个，非常难得。

1）zabbix监控分析

很快基于Zabbix展开各个ES机器节点指标监控分析，按照常规套路，分析了CPU、内存、磁盘IO等一切正常，并不高。这就非常令人困惑，明明集群响应很慢，客户端应用程序开发人员也如实反应，部署的实例非常少，所以初次分析下来，并未发现明显定位到问题。

接着分析节点网络IO，貌似发现了问题点，其中Master节点流量特别高，超出了网卡的极限；按照此套路，继续查看了其它数据节点网络IO，也比较高，然后观察发现，数据节点的网络IO流量累计起来刚好等于Master节点网络IO流量，终于算是找到了一个突破口。

注意，基于Zabbix虽然能监控各个独立节点的网络流量，但并不能看到节点之间网络流量，以及应用客户端与服务端之间，这很不友好，若有一张全网络流量图，将会更容易定位分析问题。

图示：Zabbix 网络流量示意图，仅仅能快速查看单独节点

2）iftop监控分析

借助Zabbix算是找到了突破口，接下来就需要一张网络流量关联图。此时第一个想到的是 Elastic Stack Packetbeat 网络IO流量包可视化监控监控，瞬间与客户公司讨论，能否安装配置，显然这个过程太慢，需要申请更多资源等麻烦，时间预计来不及。后面客户公司运维工程师临时安装 Linux 络指令iftop，终于能够分析ES所有节点网络IO流量的流进流出方向，但是观察分析相对来说比较痛苦，而且并不能绘制一个网络图谱，所以观察起来还是不够全面。

iftop仅仅在单机节点执行，所以只能看到单个节点的网络流量进与出，不过这已经非常好了，只是时间长一点。

基于网络IO流量进出初步分析观察，很快做出了决策，先是重启了现有Master节点，让ES集群重新选举新的Master，结果发现依然新选举的Master节点流量依然巨大；接着也临时申请增加2个新的ES节点，以为可以分散客户端访问的压力，事实上并未从根本上排查解决。此时的判断是认为某些业务索引查询，造成流量比较大，刚好在Master节点中转汇总，这里其实还没有分析到客户端的流量，所以做了一些无用的紧急服务端调整，但也证明了问题不在ES服务端。

图示：iftop网络流量示意图，能分析到单节点的流量进出，也是不错了

3）packetbeat监控分析

由于一些原因，并未部署Elastic Stack 监控分析产品，特别推荐Packetbeat网络流量监控分析产品，官方默认提供的网络流量图，非常有用，可以更快速定位流量走向，相比ittop，更加全面一些，可以总结为iftop的网络版本。Packetbeat内置官方一些可视化报表，如果觉得不够，可以基于ES提供的分析能力自行设计。

图示： packetbeta网络IO流量监控分析图，输入与输出

其次是从客户端应用排查。但实际上，客户公司运维人员第一时间发现问题，联系到我，我的第一个问题就是客户端应用在做什么业务，业务类型是什么。运维人员也如实告知正在做的业务类型以及应用情况，其实只能概要说明一下，详细的业务操作流程与影响的是不知道的，对于我来说，反正就知道了有个业务操作在影响着集群，具体怎么影响，还得继续排查。必须说明一下，这个可能是国内IT运维界的通病，看起来运维属于末端支持，本质更应该参与到业务系统的前沿阵地，从业务开始了解背后的运维问题。

然后通过ES服务端排查，掌握了一些信息，但远远不足以定位到问题，客户端排查就任重道远，必须要找出问题所在。ES集群响应慢有很多，但服务端只能发现问题，并不能从根本上解决，于是通过在服务端运行 thread_pool 与 task 命令，发现了集群的管理线程池特别多，任务一直爆满，这不正常，这就更加肯定一定是客户端的某些应用在恶意操作这些命令。

1）thread_pool 监控分析

集群响应慢，集群线程池是一个必须考虑的点，其中会查看到累计的任务量，经过打开指令观察，其中的 management 线程池特别高，由此判断客户端正在做一些任务，且属于management 线程池的，目前具体的依然不能确定，因为没有看到客户端应用具体的代码调用方式。

图示：thread_pool示意图，可以监控ES节点任务数

2）task监控分析

借助thread_pool分析，可以定位到 management 线程池正在大规模做任务，同理借助task 查看分析 具体做的任务是什么。（ps：实际客户环境中，发现是大量的state、stats任务，其中state任务数明显要高，且非常不正常，这里不方便透漏，后面会详细列出如何压测出来此结果）

图示：task示意图，可以查看到具体的任务类型

3）stats监控分析

借助 task 监控分析，发现有大量的stats指令，接着在服务端执行一次，看看情况如何，实际发现响应也比较慢，但按理是正常的，产生的队列次数并不高，只是执行慢，基于以上判断应该是别的任务阻塞导致。

stats 负责集群监控检查响应，常规的集群yellow,red,green就来自与此；另外也收集索引的统计信息，节点的统计信息，返回的数据量不多，常规下可以忽略不记，不过注意后面transport-client 访问需要。

图示：stats命令执行示意图

4）state监控分析

借助 task 监控分析，发现有大量的state指令，接着在服务端执行一次，发现了问题点，执行一次时间很长，且响应返回的内容超过70mb，这是问题，可以回答为什么之前的master节点流量如此之高。终于问题越来越清晰了，也越来越确定了。

图示：state命令执行示意图

5）transport-client应用访问

借助前面服务端现象分析，越来越确定问题出在客户端应用代码，大概率是操作不正确。

首先与客户交流，询问客户端应用代码访问ES的方式与程序版本，客户端开发团队很好配合，很快了解到应用客户端基于spring data elasticsearch框架，采用transport-client机制访问操作ES，但此时是不能定位是客户端造成的，也不能匆忙要求客户端提供源码。接下来很快在本地编写相应的测试程序源码。

Transport-client客户端绑定代码

/*模拟spring data elasticsearch配置transport-client，示例来自官方文档*/@Configurationpublic class TransportClientConfig extends ElasticsearchConfigurationSupport {
    @Bean    public Client elasticsearchClient() throws UnknownHostException {        Settings settings = Settings.builder().put("cluster.name", "elasticsearch").build();                TransportClient client = new PreBuiltTransportClient(settings);        client.addTransportAddress(new TransportAddress(InetAddress.getByName("127.0.0.1"), 9300));         return client;    }
    @Bean(name = { "elasticsearchOperations", "elasticsearchTemplate" })    public ElasticsearchTemplate elasticsearchTemplate() throws UnknownHostException {
                ElasticsearchTemplate template = new ElasticsearchTemplate(elasticsearchClient, elasticsearchConverter);                template.setRefreshPolicy(refreshPolicy());                                                 
                return template;    }}

6）jmeter压测模拟

因为某些原因，我们只能提供间接性的服务方式，所以为了彻底解决上面的问题，需要在本地模拟测试，必须要模拟出生产的问题，才能要求客户端给出到源码。基于前面服务端与客户端应用了解到的信息，接下来就是要做压测，特别选择了jmeter工具，很快配置好本地集群，附加客户端应用访问代码。压测进行时，同步观察ES服务端threadpool与task，能够复现生产的问题，很快就得到了想要的结果。

图示：jmeter压测示例，开启更多线程数，超过ES测试服务器线程数

图示：jmeter压测示例，一次state命令执行需要消耗非常多的资源

既然在本地环境，借助jmeter压测出来生产上同样的问题，那么最后一步就是与客户应用开发团队一起review代码，这一步非常快，很快就定位到 客户应用端代码在具体业务操作前，会调用Cluster State API，进行业务逻辑判断，判断索引是否存在，判断索引字段是否存在等。

最终问题定位到了，产生原因也知道了，事情也算告一段落。

/*     客户应用端的某个访问代码    借助state来判断索引的mapping信息     */    public Map<String, Object> getMappingByField(String indexName, String type) throws IOException {        ImmutableOpenMap<String, MappingMetaData> mappings = getClient().admin().cluster().prepareState().execute()                .actionGet().getState().getMetaData().getIndices().get(indexName).getMappings();        if(mappings.isEmpty()) {            return null;        }        Map<String, Object> mapping = mappings.get(type).getSourceAsMap();        Map<String, Object> properties = (Map<String, Object


    
>) mapping.get(ES_PROPERTIES);        return properties;    }