点击上方“IT那活儿”公众号，关注后了解更多内容，不管IT什么活儿，干就完了！！！Elasticsearch（以下简称ES） 是一个分布式、高扩展、高实时的搜索与数据分析引擎。它能很方便的使大量数据具有搜索、分析和探索的能力。充分利用ES的水平伸缩性，能使数据在生产环境变得更有价值。ES可以用于搜索各种文档。它提供可扩展的搜索，具有接近实时的搜索，并支持多租户。ES是分布式的，这意味着索引可以被分成分片，每个分片可以有0个或多个副本。每个节点托管一个或多个分片，并充当协调器将操作委托给正确的分片。再平衡和路由是自动完成的。相关数据通常存储在同一个索引中，该索引由一个或多个主分片和零个或多个复制分片组成。一旦创建了索引，就不能更改主分片的数量。
在某运营商上云业务中，依照统一的上云规范，大量的上云应用服务日志均需要接入了ES集群，用来存储日志或者中间数据，保证异常时候可以查询并追溯问题。但因前期对ES集群使用的经验不足，导致了较多的问题。主要有如下几个方面：2.1 前期为了方便业务上云，对申请ES资源的业务及相关人员台账统计的不够明确，有些仅有应用厂家联系人甚至有些联系人都没有，导致后续集群调整或改造时，较难通知到对应的业务。2.2 各种业务不用应用人员开发人员，对ES的熟悉程度良莠不齐，导致了许多使用不规范的问题，比如索引创建不带时间，一个索引一个分片一直写，最大的索引一个分片写到有接近1T的数据，对集群维护和读写性能方面带来了很大的挑战和问题，经常一个大的查询就导致节点GC宕机。2.3 很多业务存在小数据量的索引，创建也使用了按天创建索引，一个索引至少是一个主分片，直接导致了集群索引分片浪费，一个分片只存放了几兆甚至几百KB的数据，导致集群的分片数量增速过快，甚至超过了单节点3000分片的默认阈值，引起集群异常。2.4 因前期的硬件资源紧张，但上云速度较快，直接导致出现存放日志数据和存放业务数据的索引均集中在一个集群混用，彼此之间也存在较大的影响。
针对以上的这些问题，我们在逐步的使用和摸索中，逐一进行了分析，对以上的问题我们也逐步解决，详细如下：3.1 针对半路接手维护信息，台账信息统计不全问题，我们首先是对所有后续新申请的业务进行了申请单制度，将原有的ES使用申请进行台账重新统计，必须包含局方项目经理、厂家接口人、客户端IP、保留周期等信息，方便后续集群调整时或异常时及时通知厂家。3.2 针对ES使用方法存在不合理的方面，比如无日期索引，按日创建的小索引，我们都逐一要求业务进行整改，小索引至少保证采用按月建立，以满足ES使用单分片30~50G的最佳实践值。同时在申请单上反复进行强调索引创建的要求和规则，避免业务出错。3.3 考虑前期ES集群负载长期过高经常出问题的情况，我们对ES进行了改造和升级，首先是安装了业务专用的ES集群，将日志和业务数据进行拆分，将前期的业务数据相关业务迁移至了业务专用集群，同时对性能不足的日志集群进行了扩容，减轻集群负载。3.4 在保证了业务使用ES创建索引都进行了合理的分日和分月后，我们对其索引的保留周期同样进行了统计，然后依据不同业务不同周期，进行索引的定期offline和delete，保证ES集群的分片管理数量维持在一个良好的数据区间，保障集群的运行高效稳定。3.5 为了满足业务的测试需求，我们又单独为业务提供了同环境的测试集群，在上线流程上我们规定所有业务均必须先进入测试环境使用，并统计测试环境台账，保证ES的规范合规，待业务正式上线时，检测业务的索引模板和设置满足要求后，才允许进入生产环境使用，从流程上杜绝乱建索引和乱配置索引的问题。
经过以上从流程上、配置上进行的一些规范操作和扩容迁移操作等，原有ES集群内存使用率高经常GC问题得以解决。内存使用率最高从91%下降至目前稳定在50%左右，且可保证长期稳定运行，再无节点出现高负载或频繁GC导致宕机的情况出现。
