现象

清晨，当运维刚躺下，就被业务研发的电话叫醒，"哥们！kafka服务又意外了？影响到业务了，快看看"，业务研发给出的意外日志如下：

基本剖析

抓包剖析

基本确定意外和集群有关后，接上去就是要排查网络关系的疑问，网络和系统（内核参数设定）是息息关系的，网络疑问是复杂而奥秘的，前期会依据场景给大家分享，当天，咱们关键剖析网络链路疑问

#抓一切和kafka节点通讯的网络数据包（由于数据量很大，在意外时抓取了几分钟的包）nohuptcpdumpport9092-wkafka.pcap&

2022-09-3000:08:53.470kafka/consumer.go:128kafka_util,error,consume,group:cop.inke_owt.inno_pdl.user_pushmsg.server,from:user.msg.push.consume,topic:inno_phxyuyin_user_pushmsg_push_msg,err:kafka:errorwhileconsuminginno_phxyuyin_user_pushmsg_push_msg/1:writetcp10.226.11.15:38742->10.226.5.4:9092:write:brokenpipe

剖析结果

常识裁减

1、TCPKeepAlive机制是什么？

在TCP长衔接下，客户端和主机若长时期有数据交互状况下，若一方产生意外状况封锁衔接，另一方无法感知到，引入KeepAlive，当长衔接有数据交互必定时时期隔时，衔接的一方会向对方发送保活探测包，如衔接仍反常，对方将对此确认回应。

2、系统下KeepAlive内核参数性能

#准许的继续闲暇时长，或许说每次反常发送心跳的周期net.ipv4.tcp_keepalive_time#在tcp_keepalive_time之后，最大准许发送保活探测包的次数，抵达此次数后间接丢弃尝试，并封锁衔接net.ipv4.tcp_keepalive_probes#在tcp_keepalive_time之后，没有接纳到对方确认，继续发送保活探测包的发送频率net.ipv4.tcp_keepalive_intvl

“根本就不需要 Kafka 这样的大型分布式系统！”

作者 | Normcore Tech

译者 | 弯月，责编 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下为译文：

可能有人没有听说过Kafka，这是一个非常复杂的分布式软件，可协调多台计算机之间的数据传输。更具体地说，该软件的功能是“展平”数据，然后快速地将数据从一个地方移动到另一个地方。一般来讲，如果你有很多数据需要快速处理并发送到其他地方，那么就可以考虑一下Kafka。Kafka还可以在一定期限内保留数据，比如设置数据保存2天、3天或7天，如果你的下游流程失败，那么你还可以利用存储在Kafka中的数据重新处理。

许多处理汇总数据的公司（比如Facebook和Twitter等社交网络数据，以及每晚需要处理大量星体运动的天文学家，或需要快速了解车辆周围环境数据的自动驾驶车辆公司等）都在使用Kafka，将任意地方生产的数据（即用户通过键盘输入的数据，通过望远镜读取的数据，通过车辆遥测读取的数据等）移动至下游流程进行处理和分析。

最近，WeWork更为名The We Company，他们在共享工作间领域取得了成功，其官网宣称公司的使命为：

“提升世界的意识。”其核心业务是从房地产出租公司那里租下办公室，然后转租给无法按照传统流程租赁办公室的个人和小公司。

为了“提升世界的意识”，该公司致力于为世界各地的个人和公司的团队打造独特却又不完全相同的办公空间。最近，该公司还开始涉足教育。

最近，因为上市，WeWork曝光了一些财务信息：

从好的方面来看，根据A xi os的数据，2018年WeWork的入住率为90%，且会员总数在不断增加。

有人常常将WeWork视为硅谷地区的公司过高估值的完美例子。作为一家房地产企业，WeWork烧钱的速度非常快，毫无疑问他们必须努力让公众市场投资者相信公司有长远的发展，同时和还要维护其作为 科技 公司的地位。

这家公司再三强调说它不是一家房地产公司（毕竟它在不断烧钱对吧？），那么一家消息中介技术公司究竟能提供什么？WeWork曾宣布，它使用Kafka来实现“内部部署的物联网需求”。这是什么意思？

“我们的产品是物理空间，”WeWork的首席开发负责人David Fano说，他在会议期间穿着一件印有“bldgs = data”字样的T恤。

每个办公室都有10个环境传感器——小巧的壁挂式绿色盒子，这些传感器可跟踪室内温度、湿度、空气质量、气压和环境光线水平。还有20个白色的壁挂式信标，呈三角形分布在公共空间（开放式办公区和会议室），用于测量WeWork成员的室内位置（数据是匿名的）。顶部四分之一的传感器通过计算机视觉观察成员的活动。

换句话说，WeWork会跟踪WeWork的多个物理事件并记录所有这些数据。但是......他们真的有必要这样做吗？记录Keith Harring壁画周围开放区域的环境温度能给他们带来怎样的竞争优势？更重要的是，他们能否将这些信息用到重要的项目中？

对于公司而言，重要的是要了解办公室的“单位组合” ——私人办公室、会议空间和开放式办公桌——的比例，我们可以利用这些信息对下一个办公间作出调整。

我觉得这家新闻报道机构需要建立一种思考技术的心理模型。Ben Thompson为Stratechery提供了出色的服务，他建立了聚合理论（ /concepts/），我在努力为这些理论建立一个网站，如果必须从中选择一个的话，那便是：

大多数创业公司（以及大公司）现有的技术栈都没有必要。

在此，我想挑战一下那些自认为可以在一个周末期间独自建立Facebook的Hacker News上的开发人员，我认为WeWork的实际业务和架构问题在于：

WeWork需要的只不过是清点进出的人数，然后对容量规划做优化而已，追踪“气压”有什么用？只要你有WeWork的ID，那你肯定是个人或公司。那么，在大堂里安装一个登记系统，并要求会议系统发放名牌，不是更简单吗？

第一项要求根本就不需要Kafka：

目前WeWork有280个办公间。假设每个办公间平均每天有1000个（有这么多吗？）成员出入。那么每天会产生280,000个事务。我们假设每个人在早餐时间进来一次，在午餐时间出入各一次，然后离开。那么每个人会产生4个事务。那么每天大约是100万个事务，这点数据量存储在最常用的开源关系数据库Postgres中就可以了。保守地说，Postgres每秒可以提供10,000次写入（如果设置得当，其写入次数会更高）。每天100万个事件，也就是每秒11次。根本就不是问题。

至于第二项要求，受预订会议室人数的影响，产生的数据量可能更高，但你不需要实时传输数据。你完全可以等到一天结束时批量处理或收集，这同样可以利用司空见惯的关系数据库。

与大型Postgres（或者是BigQuery，或选择其他关系数据库连接到接收JSON传感器数据的Web服务）相比，Kafka的日常开销要高出很多，因为分布式系统非常非常复杂，比传统的系统复杂得多。

Kafka是一个非常优秀的强大的工具，但各个公司在采用该软件时，需要三思而后行。杀鸡焉用牛刀，WeWork用Kafka来记录开放办公间的气压，实属大材小用。

虽然很多时候我们都不需要Kafka，但开发人员很喜欢推荐这个工具，因为他们可以借机积攒经验和谈资。开发人员喜欢用最尖端的技术来完成工作，有时甚至他们自己都没意识到这一点。

过度架构真实存在。 Nemil在一篇文章中说：

在职业生涯的早期，你遇到的大量设计不良的软件系统都要归咎于那些传播错误观点的工程媒体。

在大学和培训班中，你对工程的了解主要来自工程媒体，例如 Hacker News、聚会、会议、Free Code Camp和Hacker Noon等。这些网站广泛讨论的技术（比如微服务、前端框架或区块链）自然会现在你的技术栈中，虽然不是很必要。

使用这些技术栈会导致各个公司承担不必要的债务，导致他们不得不在风险投资周期中寻求更多的资金，无法迈向精益或从别人的资金中解脱出来。

这种不幸的趋势只会持续下去，我们唯一能做的就是公之于众。

原文 /p/you-dont-need-kafka

PB级大规模Elasticsearch集群运维与调优实践

某中型互联网公司的游戏业务，使用了腾讯云的Elasticsearch产品，采用ELK架构存储业务日志。 因为游戏业务本身的日志数据量非常大(写入峰值在100w qps)，在服务客户的几个月中，踩了不少坑，经过数次优化与调整，把客户的ES集群调整的比较稳定，避免了在业务高峰时客户集群的读写异常，并且降低了客户的资金成本和使用成本。 下面把服务客户过程中遇到的典型问题进行梳理，总结经验，避免再次踩坑。 解决方案架构师A: bellen, XX要上线一款新游戏，日志存储决定用ELK架构，他们决定在XX云和我们之间二选一，我们首先去他们公司和他们交流一下，争取拿下！ bellen: 好，随时有空！ 。 。 。 和架构师一起前往该公司，跟负责底层组件的运维部门的负责人进行沟通。 XX公司运维老大：不要讲你们的PPT了，先告诉我你们能给我们带来什么！ bellen: 。 。 。 呃，我们有很多优势。 。 。 比如灵活地扩容缩容集群，还可以一键平滑升级集群版本，并且提供有跨机房容灾的集群从而实现高可用。 。 XX公司运维老大：你说的这些别的厂商也有，我就问一个问题，我们现在要存储一年的游戏日志，不能删除数据，每天就按10TB的数据量算，一年也得有个3PB多的数据，这么大的数量，都放在SSD云盘上，我们的成本太高了，你们有什么方案既能够满足我们存储这么大数据量的需求，同时能够降低我们的成本吗？ bellen: 我们本身提供的有冷热模式的集群，热节点采用SSD云硬盘，冷节点采用SATA盘，采用ES自带的ILM索引生命周期管理功能定期把较老的索引从热节点迁移到冷节点上，这样从整体上可以降低成本。 另外一方面，也可以定期把更老的索引通过snapshot快照备份到COS对象存储中，然后删除索引，这样成本就更低了。 XX公司运维老大：存储到COS就是冷存储呗，我们需要查询COS里的数据时，还得再把数据恢复到ES里？这样不行，速度太慢了，业务等不了那么长时间，我们的数据不能删除，只能放在ES里！你们能不能给我们提供一个API, 让老的索引数据虽然存储在COS里，但是通过这个API依然可以查询到数据，而不是先恢复到ES， 再进行查询？ bellen: 。 。 。 呃，这个可以做，但是需要时间。 是否可以采用hadoop on COS的架构，把存量的老的索引数据通过工具导入到COS，通过hive去查询，这样成本会非常低，数据依然是随时可查的。 XX公司运维老大：那不行，我们只想用成熟的ELK架构来做，再增加hadoop那一套东西，我们没那么多人力搞这个事! bellen: 好吧，那可以先搞一个集群测试起来，看看性能怎么样。 关于存量数据放在COS里但是也需要查询的问题，我们可以先制定方案，尽快实施起来。 XX公司运维老大：行吧，我们现在按每天10TB数据量预估，先购买一个集群，能撑3个月的数据量就行，能给一个集群配置的建议吗？ bellen: 目前支持单节点磁盘最大6TB, cpu和内存的话可以放到8核32G单节点，单节点跑2w qps写入没有问题，后面也可以进行纵向扩容和横向扩容。 XX公司运维老大：好，我们先测试一下。 N 天后，架构师A直接在微信群里反馈：bellen, 客户反馈这边的ES集群性能不行啊，使用logstash消费kafka中的日志数据，跑了快一天了数据还没追平，这是线上的集群，麻烦紧急看一下吧。 。 我一看，一脸懵, 什么时候已经上线了啊，不是还在测试中吗？ XX公司运维小B: 我们购买了8核32G*10节点的集群，单节点磁盘6TB, 索引设置的10分片1副本，现在使用logstash消费kafka中的数据，一直没有追平，kafka中还有很多数据积压，感觉是ES的写入性能有问题。 随后我立即查看了集群的监控数据，发现cpu和load都很高，jvm堆内存使用率平均都到了90%，节点jvm gc非常频繁了，部分节点因为响应缓慢，不停的离线又上线。 。 经过沟通，发现用户的使用姿势是filebeat+kafka+logstash+elasticsearch, 当前已经在kafka中存储了有10天的日志数据，启动了20台logstash进行消费，logstash的batch size也调到了5000，性能瓶颈是在ES这一侧。 客户8核32G*10节点的集群，理论上跑10w qps没有问题，但是logstash消费积压的数据往ES写入的qps远不止10w，所以是ES扛不住写入压力了，所以只能对ES集群进行扩容，为了加快存量数据的消费速度，先纵向扩容单节点的配置到32核64GB，之后再横向增加节点，以保证ES集群能够最大支持100w qps的写入(这里需要注意的是，增加节点后索引的分片数量也需要调整)。 所以一般新客户接入使用ES时，必须要事先评估好节点配置和集群规模，可以从以下几个方面进行评估： 上述场景2遇到的问题是业务上线前没有对集群配置和规模进行合理的评估，导致上线后ES集群负载就很高，通过合理的扩容处理，集群最终抗住了写入压力。 但是又有新的问题出现了。 因为kafka积压的数据比较多，客户使用logstash消费kafka数据时，反馈有两个问题： 经过分析客户logstash的配置文件，发现问题出现的原因主要是： 分析后，对kafka和logstash进行了如下优化： 通过上述优化，最终使得logstash机器资源都被充分利用上，很快消费完堆积的kafka数据，待消费速度追平生成速度后，logstash消费kafka一直稳定运行，没有出现积压。 另外，客户一开始使用的是5.6.4版本的logstash，版本较老，使用过程中出现因为单个消息体过长导致logstash抛异常后直接退出的问题: 通过把logstash升级至高版本6.8避免了这个问题(6.x版本的logstash修复了这个问题，避免了crash)。 客户的游戏上线有一个月了，原先预估每天最多有10TB的数据量，实际则是在运营活动期间每天产生20TB的数据，原先6TB*60=360TB总量的数据盘使用率也达到了80%。 针对这种情况，我们建议客户使用冷热分离的集群架构，在原先60个热节点的基础上，增加一批warm节点存储冷数据，利用ILM(索引生命周期管理)功能定期迁移热节点上的索引到warm节点上。 通过增加warm节点的方式，客户的集群磁盘总量达到了780TB， 可以满足最多三个月的存储需求。 但是客户的需求还没有满足： XX公司运维老大：给我们一个能存放一年数据的方案吧，总是通过加节点扩容磁盘的方式不是长久之计，我们得天天盯着这个集群，运维成本很高！并且一直加节点，ES会扛不住吧？ bellen: 可以尝试使用我们新上线的支持本地盘的机型，热节点最大支持7.2TB的本地SSD盘，warm节点最大支持48TB的本地SATA盘。 一方面热节点的性能相比云盘提高了，另外warm节点可以支持更大的磁盘容量。 单节点可以支持的磁盘容量增大了，节点数量就不用太多了，可以避免踩到因为节点数量太多而触发的坑。 XX公司运维老大：现在用的是云盘，能替换成本地盘吗，怎么替换？ bellen: 不能直接替换，需要在集群中新加入带本地盘的节点，把数据从老的云盘节点迁移到新的节点上，迁移完成后再剔除掉旧的节点，这样可以保证服务不会中断，读写都可以正常进行。 XX公司运维老大：好，可以实施，尽快搞起来！ 云盘切换为本地盘，是通过调用云服务后台的API自动实施的。 在实施之后，触发了数据从旧节点迁移到新节点的流程，但是大约半个小时候，问题又出现了： XX公司运维小B: bellen, 快看一下，ES的写入快掉0了。 bellen: 。 。 。 通过查看集群监控，发现写入qps直接由50w降到1w，写入拒绝率猛增，通过查看集群日志，发现是因为当前小时的索引没有创建成功导致写入失败。 紧急情况下，执行了以下操作定位到了原因： 经过了这次扩容操作，总结了如下经验： 在稳定运行了一阵后，集群又出问题了。 。 XX公司运维小B: bellen, 昨晚凌晨1点钟之后，集群就没有写入了，现在kafka里有大量的数据堆积，麻烦尽快看一下？ bellen: 。 。 。 通过cerebro查看集群，发现集群处于yellow状态，然后发现集群有大量的错误日志： 然后再进一步查看集群日志，发现有master not discovered yet...之类的错误日志，检查三个master节点，发现有两个master挂掉，只剩一个了，集群无法选主。 登陆到挂了了master节点机器上，发现保活程序无法启动es进程，第一直觉是es进程oom了；此时也发现master节点磁盘使用率100%， 检查了JVM堆内存快照文件目录，发现有大量的快照文件，于是删除了一部分文件，重启es进程，进程正常启动了；但是问题是堆内存使用率太高，gc非常频繁，master节点响应非常慢，大量的创建索引的任务都超时，阻塞在任务队列中，集群还是无法恢复正常。 看到集群master节点的配置是16核32GB内存，JVM实际只分配了16GB内存，此时只好通过对master节点原地增加内存到64GB(虚拟机，使用的腾讯云CVM， 可以调整机器规格，需要重启)，master节点机器重启之后，修改了es目录文件，调整了堆内存大小，重新启动了es进程。 3个master节点都恢复正常了，但是分片还需要进行恢复，通过GET _cluster/health看到集群当前有超过10w个分片，而这些分片恢复还需要一段时间，通过调大_concurrent_recoveries， 增大分片恢复的并发数量。 实际上5w个主分片恢复的是比较快的了，但是副本分片的恢复就相对慢很多，因为部分副本分片需要从主分片上同步数据才能恢复。 此时可以采取的方式是把部分旧的索引副本数量调为0， 让大量副本分片恢复的任务尽快结束，保证新索引能够正常创建，从而使得集群能够正常写入。 总结这次故障的根本原因是集群的索引和分片数量太多，集群元数据占用了大量的堆内存，而master节点本身的JVM内存只有16GB(数据节点有32GB)， master节点频繁full gc导致master节点异常，从而最终导致整个集群异常。 所以要解决这个问题，还是得从根本上解决集群的分片数量过多的问题。 目前日志索引是按照小时创建，60分片1副本，每天有24*60*2=2880个分片，每个月就产生个分片，这么多的分片可能会带来严重的问题。 有以下几种方式解决分片数量过多的问题： 和客户沟通过后，客户表示可以接受方式1和方式2，但是方式3和4不能接受，因为考虑到存在磁盘故障的可能性，必须保留一个副本来保证数据的可靠性；另外还必须保证所有数据都是随时可查询的，不能关闭。 在场景5中，虽然通过临时给master节点增加内存，抗住了10w分片，但是不能从根本上解决问题。 客户的数据是计划保留一年的，如果不进行优化，集群必然扛不住数十万个分片。 所以接下来需要着重解决集群整体分片数量过多的问题，在场景5的最后提到了，用户可以接受开启shrink以及降低索引创建粒度(经过调整后，每两个小时创建一个索引)，这在一定程度上减少了分片的数量，能够使集群暂时稳定一阵。 辅助客户在kibana上配置了如下的ILM策略： 在warm phase, 把创建时间超过360小时的索引从hot节点迁移到warm节点上，保持索引的副本数量为1，之所以使用360小时作为条件，而不是15天作为条件，是因为客户的索引是按小时创建的，如果以15天作为迁移条件，则在每天凌晨都会同时触发15天前的24个索引一共24*120=2880个分片同时开始迁移索引，容易引发场景4中介绍的由于迁移分片数量过多导致创建索引被阻塞的问题，所以以360小时作为条件，则在每个小时只会执行一个索引的迁移，这样把24个索引的迁移任务打平，避免其它任务被阻塞的情况发生。 同时，也在warm phase阶段，设置索引shrink，把索引的分片数缩成5个，因为老的索引已经不执行写入了，所以也可以执行force merge, 强制把segment文件合并为1个，可以获得更好的查询性能。 另外，设置了ILM策略后，可以在索引模板里增加配置，使得所有新创建的索引都可以和新添加的ILM策略关联，从而使得ILM能够正常运行。 客户使用的ES版本是6.8.2， 在运行ILM的过程中， 也发现一些问题： 这是因为shrink操作需要新把索引完整的一份数据都迁移到一个节点上，然后在内存中构建新的分片元数据，把新的分片通过软链接指向到几个老的分片的数据，在ILM中执行shrink时，ILM会对索引进行如下配置： 问题是索引包含副本，而主分片和副本分片又不能在同一个节点上，所以会出现部分分片无法分配的情况(不是全部，只有一部分)，这里应该是触发了6.8版本的ILM的bug，需要查看源码才能定位解决这个bug，目前还在研究中。 当前的workaround是通过脚本定期扫描出现unassigned shards的索引，修改其settings: 优先保证分片先从hot节点迁移到warm节点，这样后续的shrink才能顺利执行(也可能执行失败，因为60个分片都在一个节点上，可能会触发rebalance, 导致分片迁移走，shrink的前置条件又不满足，导致执行失败)。 要完全规避这个问题，还得在ILM策略中设置，满足创建时间超过360个小时的索引，副本直接调整为0，但是客户又不接受，没办法。 在场景5和6中，介绍了10w个分片会给集群带来的影响和通过开启shrink来降低分片数量，但是仍然有两个需要重点解决的问题： 可以估算一下，按小时建索引，60分片1副本，一年的分片数为24*120*365=个分片，执行shrink后分片数量24*10*350 + 24*120*15 = (15天内的新索引为了保障写入性能和数据可靠性，仍然保持60分片1副本，旧的索引shrink为5分片1副本), 仍然有超过10w个分片。 结合集群一年总的存储量和单个分片可以支持的数据量大小进行评估，我们期望集群总体的分片数量可以稳定为6w~8w，怎么优化？ 可以想到的方案是执行数据冷备份，把比较老的索引都冷备到其它的存储介质上比如HDFS，S3，腾讯云的COS对象存储等，但是问题是这些冷备的数据如果也要查询，需要先恢复到ES中才可查，恢复速度比较慢，客户无法接受。 由此也产生了新的想法，目前老的索引仍然是1副本，可以把老索引先进行冷备份，再把副本调为0，这样做有以下几点好处： 经过和客户沟通，客户接受了上述方案，计划把老索引冷备到腾讯云的对象存储COS中，实施步骤为： 其中步骤1的实施可以通过脚本实现，本案例中采用腾讯云SCF云函数进行实施，方便快捷可监控。 实施要点有： 在实施完步骤1之后，就可以批量把对索引进行过备份的索引副本数都调为0， 这样一次性释放了很多磁盘空间，并且显著降低了集群整体的分片数量。 接下来实施步骤2，需要每天执行一次快照，多创建时间较久的索引进行备份，实施比较简单，可以通过crontab定时执行脚本或者使用腾讯云SCF执行。 步骤2实施之后，就可以修改ILM策略，开启cold phase, 修改索引副本数量为0: 此处的timing是创建时间20天后，需要保证步骤2中对过去老索引数据备份先执行完成才可以进入到cold phase. 通过老索引数据冷备并且降低索引副本，我们可以把集群整体的分片数量维持在一个较低的水位，但是还有另外一个问题待解决，也即shrink失败的问题。 刚好，我们可以利用对老索引数据冷备并且降低索引副本的方案，来彻底解决shrink失败的问题。 在场景5中有提到，shrink失败归根接地是因为索引的副本数量为1， 现在我们可以吧数据备份和降低副本提前，让老索引进入到ILM的warm phase中时已经是0副本，之后再执行shrink操作就不会有问题了；同时，因为副本降低了，索引从hot节点迁移到warm节点迁移的数据量也减少了一半，从而降低了集群负载，一举两得。 因此，我们需要修改ILM策略，在warm phase就把索引的副本数量调整为0， 然后去除cold phase。 另外一个可选的优化项是，对老的索引进行冻结，冻结索引是指把索引常驻内存的一些数据从内存中清理掉(比如FST, 元数据等)， 从而降低内存使用量，而在查询已经冻结的索引时，会重新构建出临时的索引数据结构存放在内存中，查询完毕再清理掉；需要注意的是，默认情况下是无法查询已经冻结的索引的，需要在查询时显式的增加ignore_throttled=false参数。 经过上述优化，我们最终解决了集群整体分片数量过多和shrink失败的问题。 在实施过程中引入了额外的定时任务脚本实施自动化快照，实际上在7.4版本的ES中，已经有这个功能了，特性名称为 SLM (快照生命周期管理)，并且可以结合ILM使用，在ILM中增加了wait_for_snapshot的ACTION, 但是却只能在delete phase中使用，不满足我们的场景。 在上述的场景4-7中，我们花费大量的精力去解决问题和优化使用方式，保证ES集群能够稳定运行，支持PB级别的存储。 溯本回原，如果我们能有一个方案使得客户只需要把热数据放在SSD盘上，然后冷数据存储到COS/S3上，但同时又使冷数据能够支持按需随时可查，那我们前面碰到的所有问题都迎刃而解了。 可以想象得到的好处有： 而这正是目前es开源社区正在开发中的Searchable Snapshots功能，从 Searchable Snapshots API 的官方文档上可以看到，我们可以创建一个索引，将其挂载到一个指定的快照中，这个新的索引是可查询的，虽然查询时间可能会慢点，但是在日志场景中，对一些较老的索引进行查询时，延迟大点一般都是可以接受的。 所以我认为，Searchable Snapshots解决了很多痛点，将会给ES带了新的繁荣！ 经历过上述运维和优化ES集群的实践，我们总结到的经验有： 从一开始和客户进行接触，了解客户诉求，逐步解决ES集群的问题，最终使得ES集群能够保持稳定，这中间的经历让我真真正正的领悟到实践出真知，只有不断实践，才能对异常情况迅速做出反应，以及对客户提的优化需求迅速反馈。