随着单个 Elasticsearch 集群规模的越来越大，大家要么在拆集群的路上，要么是已经是多套集群了， 据路边社消息，一个公司超过5个集群的情况已经变得非常普遍，而管理多个集群着实是有点痛苦，比如常规的玩法可能是一套集群一个 Kibana，集群一多，切换来切换去就有点懵圈了有木有？

作为一个优雅的程序员或者运维管理员，是可忍孰不可忍啊。

另外，多个集群的监控也是一个麻烦事，目前常见的几种监控如：

• 使用 Kibana 自带的监控
• 使用 Prometheus + Grafana
• 使用 Zabbix

Kibana 自带的监控可以很好的满足单个集群的监控场景，不过集群规模大了之后，经常会出现指标丢失的问题，如果使用单独的监控集群，需要修改每个节点的配置，集群都需要重启，对于已经上了生产的集群，有点不方便，另外多集群监控需要商业授权。

那 Prometheus 呢， 一个 Elasticsearch 集群如果要监控起来，首先需要部署一个 Exporter 来暴露集群指标，然后部署一套Prometheus 来采集 Elasticsearch 指标，采集完了之后再部署一套 Grafana 来进行报表分析，不同的集群要做好切换，简单的事情，搞复杂了，整个监控体系偏重，维护成本高。

Zabbix 和 Prometheus 的场景差不多，就不赘述了。

那么问题来了，有没有一个更加简单方便的多集群监控和管理方案呢，并且要支持不同版本的集群，最好是 v2、v5、v6、v7 以及最新的 v8 都能统统接管，哈哈，没错了，这里给大家介绍一个我们极限实验室团队最近开发出来的一款免费的多集群监控和管理工具-极限数据平台，目前版本 v0.1，新鲜出炉。

废话不多少，咱们直接看图说话：

首先是多集群的纳管，目前从 1.0 到最新的 8.0 统统都可以接进来。

然后就是集群的监控拉，要多简单有多简单，就是一个开关的事情，注册集群的时候，启用即开启监控，目标集群啥都不用动，费那劲干啥。

监控界面如图：

集群概览，总体情况一目了然。

各个节点信息，分门别类。

各个索引级别的信息，挨个查看。

多个集群之间的监控查看一键切换，非常方便。

查看监控的时候，发现不对劲，要操作一下集群，直接调出控制台，如下图：

常用的操作命令，可以保存起来，方便下次使用。

别再保存在记事本里面了，下次又找不到，直接加载执行就好了。

好了，你要是用 Elasticsearch 不知道这个工具，那就 out 了，赶快耍起来吧。

下载地址：

http://release.elasticsearch.cn/console/snapshot/

安装巨简单，简直懒得说，一个二进制可执行文件，一个 yml 配置文件，里面修改 Elasticsearch 地址，结束。

可以在这里查看 介绍和 Demo 演示视频

最后，欢迎关注极限实验室，获取更多 Elasticsearch 免费工具及业界资讯的第一手消息。

Elastic 中国开发者大会 2021 是由 Elastic 官方、Elastic 中文社区和极限科技联合主办的开发者大会，作为中国国内唯一一个专门讨论 Elasticsearch 开源技术的大会，是中国最权威和最具实力干货的技术大会，其专业性和内容的质量一直以来在业内都是有口皆碑，大会最早发起于 2013 年初一个很小的线下聚会，之后每年迅速成长，往年大会的演讲嘉宾有来自 Elastic 官方、百度、腾讯、阿里巴巴、360、微博、美团、58、苏宁等众多公司的技术专家，带来过众多精彩的分享，与会听众大多为大数据领域相关的架构师、技术经理与一线开发工程师和运维工程师。 我们本着非盈利目的来举办大会，今年的大会将于2022年1月8号在深圳举行，举办开发者大会的目的是为中国广大的 Elasticsearch 开发者提供一个技术交流和学习切磋的地方，汇集业界众多的成功案例，集思广益，发散思维，促进社区和行业的进步。   大会官网：https://conf.elasticsearch.cn Elasticsearch铁粉福利： 预热-铁粉票(79元/张)， 共计100张，数量有限，赶紧去报名抢购吧！ 购票地址：https://www.bagevent.com/event/7899116   同时大会也在公开征集演讲议题与合作赞助商，欢迎各位Elastic相关技术大咖报名参与分享，欢迎有兴趣的赞助商金主大大前来合作。 演讲报名申请：http://elasticsearch.mikecrm.com/uXH61JL 赞助合作申请：http://elasticsearch.mikecrm.com/6LGkKK0    

活动介绍

本次Meetup杭州站由阿里云和Elastic联合举办，邀请来自滴滴、安恒信息、阿里云的资深技术专家探讨在搜索、安全、内核优化等方向的实践与创新，以及发布由数十位优秀技术开发者共创而成的实战指南，共同分享 Elasticsearch技术大咖的一线经验与深度思考。

报名方式

链接：https://www.bagevent.com/event/7449056
扫码:

活动时间

2021年06月05日 13:00-17:30

活动地址

浙江省杭州市余杭区阿里巴巴西溪园区访客中心 206-S越秀书院

活动流程

13:00~13:15 签到入座
13:15~13:30 开发者共创书籍《Elastic Stack 实战手册V1.0》发布
13:30~14:30 滴滴Elasticsearch内核优化之路
            韩宝君 滴滴Elasticsearch资深开发工程师/ES社区Contributor
14:30~15:30 Elasticsearch在SIEM的应用与实践
            汤乐奇 安恒信息AiLPHA大数据资深研发经理
15:30~16:30 Elasticsearch Serverless 云原生时代的创新实践
            马华标(城破) 阿里巴巴高级技术专家/阿里云ES内核研发负责人
16:30~17:20 圆桌交流
17:20~17:30 抽奖合影

活动奖品

阿里云双肩包、T恤、Elastic定制礼物

阿里云ACE

阿里云ACE即全称 Alibaba Cloud Engineer，是意为阿里云的工程师、代表着云计算的建设者。同时“ACE”又是扑克牌中的“A”，因此阿里云ACE也寓意着是云计算领域王牌的一群人。在线上，ACE拥有专属的页面和29个社群，承载论坛及专栏等内容； 在线下，ACE通过组织丰富的活动，包括技术沙龙、TechDay、Meetup、官方互动等来形成本地化的开发者的学习、社交平台。

通过ACE组织的各种活动，ACE用户可以结识本地的开发者，收获前沿知识，积累行业经验，并加深对阿里云的了解。

活动交流及杭州ACE同城会钉群

活动海报

各位社区的小伙伴们大家好！过去一年多以来，疫情阻挡了我们聚会的脚步，但阻挡不了我们 ES 技术演进的脚步，ES 中文社区前期持续举办了多期线上 meetup 活动，输出了多个高质量的技术主题分享。如今在深圳，线下 meetup 活动重磅重启！6月26日我们将在深圳腾讯滨海大厦多功能厅，和大家欢聚一堂，畅谈 ES 各个领域最新的黑科技。目前讲师招募持续进行中，欢迎各路大佬扫码报名！ 活动链接：https://www.bagevent.com/event/7440283

今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈，由于时间关系，大家的问题没能及时答复，这里集中解答，大家如果还有其它疑问也可以持续提问。感谢大家的关注！ 另外腾讯云上有内核增强版的ES服务，包含了我们所有的内核优化项，欢迎大家体验！ 团队也在持续招聘，欢迎简历来砸：danielhuang@tencent.com; johngqjiang@tencent.com

1月16日 Elastic 中文社区深圳 Meetup 上，李猛将带来关于ES 实践方面的主题分享。借此机会，我们邀请到他聊聊作为ES深度用户在探索ES过程中的心得以及对ES社区、活动、未来生态发展等方面的看法。   李猛 架构师/Elastic认证工程师 Elastic Stack产品深度用户，2012/2013年接触Elasticsearch，对Elastic Stack开发、架构、运维等方面有深入体验，实践过多种ES项目，最暴力的大数据分析应用，最复杂的业务系统应用等。   Q1、作为深度用户，当初是基于什么样的动机和考量选择使用 ES 产品并持续深入探索的？ A：易用性与功能强大，个人平常比较爱好算法研究，选择任何数据产品本质上都是选择算法，算法的本质决定了产品的强大。 架构是个宏观问题，ES的设计是标准的分布式，架构的优秀设计带来的是易用性； 算法是个微观问题，ES集成了很多优秀的算法，这样在很多业务场景下都可满足，而不用更换不同的数据产品，这样也会带来产品运维方面的便利性，保障应用的技术栈不至于过多复杂。 Q2、在探索 DB 与 ES 的互通方面，有遇到什么难题吗？最后是如何解决的呢？ A：数据一致性与实时性问题。应用架构思维变化，业务调整变化与技术方案变化。 Q3、结合您的实践经历，对 ES 目前的生态发展、应用以及未来有什么样的看法？ A：ES目前主要应用是在单索引条件下查询，附带有简单的聚合分析能力。复杂的分析能力不具备，ES未来会增强复杂的分析能力，比如有条件的支持２个索引的关联分析。 Q4、您对本次技术沙龙活动的主题分享有什么期待？ A：期望更多人参加探讨更多的业务应用场景，比如传统应用方面、大数据方面、机器学习方面；帮助大家以后项目实战有更多的案例参考。 Q5、您对 Elastic 中文社区发展有什么意见或建议呢？ A：ES目前在国内的热度几乎超过任何数据库，几乎大大小小的公司，都在使用；从开始入门到成熟运用多多少少都会遇到很多问题，　　希望社区活动更加多一点，业余的交流更多一点。比如可以办一些，走进某些企业的活动。 11月16日 Elastic 中文社区深圳 Meetup 火热报名中 分享主题：《DB到ES数据实时同步之路》 李猛  主题摘要：关系型数据库天然具备最严格的事务特性，有效的保证数据库一致性，但在高效查询方面显得很无力；Elasticsearch天然具备高效的查询算法，但在数据一致性方面却是先天缺陷；如何将DB与ES的优点结合，是任何一个企业公司业务系统实践都值得探讨的事。  

身为 IT 人士，大伙身边的各种系统肯定不少吧。系统虽多，但最最最重要的那套、那几套，大伙肯定是捧在手心，关怀备至。如此重要的系统，万一发生故障了且短期无法恢复，该如何保障业务持续运行？ 有过这方面思考或经验的同学，肯定脱口而出--切灾备啊。 是的，接下来我来介绍下我们的 ES 灾备方案。当然如果你有更好的，请使用各种可用的渠道联系我们。

总体设计

通过极限网关将应用对主集群的写操作，复制到灾备集群。应用发送的读请求则直接转发到主集群，并将响应结果转发给应用。应用对网关无感知，访问方式与访问 ES 集群一样。

方案优势

• 轻量级

极限网关使用 Golang 编写，安装包很小，只有 10MB 左右，没有任何外部环境依赖，部署安装都非常简单，只需要下载对应平台的二进制可执行文件，启动网关程序的二进制程序文件执行即可。

• 跨版本支持

极限网关针对不同的 Elasticsearch 版本做了兼容和针对性处理，能够让业务代码无缝的进行适配，后端 Elasticsearch 集群版本升级能够做到无缝过渡，降低版本升级和数据迁移的复杂度。

• 高可用

极限网关内置多种高可用解决方案，前端请求入口支持基于虚拟 IP 的双机热备，后端集群支持集群拓扑的自动感知，节点上下线能自动发现，自动处理后端故障，自动进行请求的重试和迁移。

• 灵活性

主备集群都是可读可写，切换迅速，只需切换网关到另一套配置即可。回切灵活，恢复使用原配置即可。

架构图

网关程序部署

下载

根据操作系统和平台选择下面相应的安装包： 解压到指定目录：

mkdir gateway
tar -zxf xxx.gz -C gateway

修改网关配置

在此 下载 网关配置，默认网关会加载配置文件 gateway.yml ，如果要指定其他配置文件使用 -config 选项指定。 网关配置文件内容较多，下面展示必要部分。

  #primary
  PRIMARY_ENDPOINT: http://192.168.56.3:7171
  PRIMARY_USERNAME: elastic
  PRIMARY_PASSWORD: password
  PRIMARY_MAX_QPS_PER_NODE: 10000
  PRIMARY_MAX_BYTES_PER_NODE: 104857600 #100MB/s
  PRIMARY_MAX_CONNECTION_PER_NODE: 200
  PRIMARY_DISCOVERY_ENABLED: false
  PRIMARY_DISCOVERY_REFRESH_ENABLED: false
  #backup
  BACKUP_ENDPOINT: http://192.168.56.3:9200
  BACKUP_USERNAME: admin
  BACKUP_PASSWORD: admin
  BACKUP_MAX_QPS_PER_NODE: 10000
  BACKUP_MAX_BYTES_PER_NODE: 104857600 #100MB/s
  BACKUP_MAX_CONNECTION_PER_NODE: 200
  BACKUP_DISCOVERY_ENABLED: false
  BACKUP_DISCOVERY_REFRESH_ENABLED: false

PRIMARY_ENDPOINT：配置主集群地址和端口
PRIMARY_USERNAME、PRIMARY_PASSWORD: 访问主集群的用户信息
BACKUP_ENDPOINT：配置备集群地址和端口
BACKUP_USERNAME、BACKUP_PASSWORD: 访问备集群的用户信息

运行网关

前台运行 直接运行网关程序即可启动极限网关了，如下：

./gateway-linux-amd64

后台运行

./gateway-linux-amd64 -service install
Success
./gateway-linux-amd64 -service start
Success

卸载服务

./gateway-linux-amd64 -service stop
Success
./gateway-linux-amd64 -service uninstall
Success

灾备功能测试

在灾备场景下，为保证数据一致性，对集群的访问操作都通过网关进行。注意只有 bulk API 的操作才会被复制到备集群。 在此次测试中，网关灾备配置功能为：

• 主备集群正常时

读写请求正常执行； 写请求被记录到队列，备集群实时消费队列数据。

• 当主集群故障时

写入请求报错，主备集群都不写入数据； 查询请求转到备集群执行，并返回结果给客户端。

• 当备集群故障时

读写请求都正常执行； 写操作记录到磁盘队列，待备集群恢复后，自动消费队列数据直到两个集群一致。

主备集群正常时写入、查询测试

写入数据

# 通过网关写入数据
curl -X POST "localhost:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "create" : { "_index" : "test", "_id" : "2" } }
{ "field2" : "value2" }
'

查询数据

# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password

# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

# 查询网关，网关转发给主集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

主备集群都已写入数据，且数据一致。通过网关查询，也正常返回。

删除和更新文档

# 通过网关删除和更新文档
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "delete" : { "_index" : "test", "_id" : "1" } }
{ "update" : {"_id" : "2", "_index" : "test"} }
{ "doc" : {"field2" : "value2-updated"} }
'

查询数据

# 查询主集群
curl 192.168.56.3:7171/test/_search?pretty -uelastic:password

# 查询备集群
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

两个集群都已执行删除和更新操作，数据一致。

主集群故障时写入、查询测试

为模拟主集群故障，直接关闭主集群。

写入数据

# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "3" } }
{ "field3" : "value3" }
{ "create" : { "_index" : "test", "_id" : "4" } }
{ "field4" : "value4" }
'

写入数据报错

查询数据

# 通过网关查询，因为主集群不可用，网关将查询转发到备集群执行
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

正常查询到数据，说明请求被转发到了备集群执行。

备集群故障时写入、查询测试

为模拟备集群故障，直接关闭备集群。

写入数据

# 通过网关写入数据
curl -X POST "192.168.56.3:18000/_bulk?pretty" -H 'Content-Type: application/json' -uelastic:password -d'
{ "index" : { "_index" : "test", "_id" : "5" } }
{ "field5" : "value5" }
{ "create" : { "_index" : "test", "_id" : "6" } }
{ "field6" : "value6" }
'

数据正常写入。

查询数据

# 通过网关查询
curl 192.168.56.3:18000/test/_search?pretty -uelastic:password

查询成功返回。主集群成功写入了两条新数据。同时此数据会被记录到备集群的队列中，待备集群恢复后，会消费此队列追数据。

恢复备集群

启动备集群。

查询数据

等待片刻或通过 INFINI Console 确定网关队列消费完毕后，查询备集群的数据。 (生产和消费 offset 相同，说明消费完毕。)

# 查询备集群的数据
curl 192.168.56.3:9200/test/_search?pretty -uadmin:admin

备集群启动后自动消费队列数据，消费完后备集群数据达到与主集群数据一致。

灾备切换

测试了这么多，终于到切换的时刻了。切换前我们判断下主系统是否短期无法修复。

如果我们判断主用系统无法短时间恢复，要执行切换。非常简单，我们直接将配置文件中定义的主备集群互换，然后重启网关程序就行了。但我们推荐在相同主机上另部署一套网关程序--网关B，先前那套用网关A指代。网关B中的配置文件把原备集群定义为主集群，原主集群定义为备集群。若要执行切换，我们先停止网关A，然后启动网关B，此时应用连接到网关(端口不变)，就把原备系统当作主系统使用，把原主系统当作备系统，也就完成了主备系统的切换。

灾备回切

当原主集群修复后，正常启动，就会从消费队列追写修复期间产生数据直到主备数据一致，同样我们可通过 INFINI Console 查看消费的进度。如果大家还是担心数据的一致性，INFINI Console 还能帮大家做[校验数据]()任务，做到数据完全一致后(文档数量及文档内容一致)，才进行回切。

回切也非常简单，停止网关B，启动网关A即可。

网关高可用

网关自带浮动 IP 模块，可进行双机热备。客户端通过 VIP 连接网关，网关出现故障时，VIP 漂移到备网关。 视频教程戳这里。

这样的优点是简单，不足是只有一个网关在线提供服务。如果想多个网关在线提供服务，则需搭配分布式消息系统一起工作，架构如下。

前端通过负载均衡将流量分散到多个在线网关，网关将消息存入分布式消息系统。此时，网关可看作无状态应用，可根据需要扩缩规模。

以上就是我介绍的ES灾备方案，是不是相当灵活了。有问题还是那句话 Call me 。

关于极限网关

INFINI Gateway 是一个面向搜索场景的高性能数据网关，所有请求都经过网关处理后再转发到后端的搜索业务集群。基于 INFINI Gateway，可以实现索引级别的限速限流、常见查询的缓存加速、查询请求的审计、查询结果的动态修改等等。

官网文档：https://www.infinilabs.com/docs/latest/gateway

近日，由 DataFun 主办的 DataFunSummit 2023 数据基础架构峰会 圆满落下帷幕，本次峰会邀请了腾讯、百度、字节、极限科技、Zilliz 等众多企业技术专家为大家带来分布式存储以及向量数据库的架构原理、性能优化与实践解析分享。

在 向量数据库架构与实践论坛 中，极限科技搜索引擎研发工程师张磊受邀出席做了《给 ES 插上向量检索的翅膀》的主题演讲。据介绍，本次演讲主要介绍了 Elasticsearch（ES）与向量技术的融合，展示其在不同行业中的应用场景和优势，同时也对 ES 与向量的技术细节进行详细讨论，并通过具体案例演示如何利用向量提升搜索能力。

讲师介绍

张磊，极限科技 Easysearch 引擎研发工程师，2013 年开始接触 Elasticsearch，10 余年搜索相关经验，之前主要做一些围绕 Elasticsearch 在日志检索和公安大数据相关业务的开发，对 Elasticsearch 和 Lucene 源码比较熟悉，目前专注于公司内部搜索产品的开发。

《给 ES 插上向量检索的翅膀》PPT 内容

更多 PPT 内容参见 https://elasticsearch.cn/slides/322

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎，核心引擎基于开源的 Apache Lucene。Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。与 Elasticsearch 相比，Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档：https://www.infinilabs.com/docs/latest/easysearch

下载地址：https://www.infinilabs.com/download

本文主要测试验证 Elasticsearch 各版本快照在 Easysearch 中进行数据恢复。

准备测试数据

索引

别名

模版

生命周期策略

创建快照

PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/infini/test/es_backup"
  }
}

PUT /_snapshot/my_backup/snapshot_1
{
  "indices": "*",
  "ignore_unavailable": false,
  "include_global_state": false
}

GET /_snapshot/my_backup/snapshot_1

• ignore_unavailable：如果 indices 列表中的索引不存在，则是否忽略该索引而不是使快照失败。默认值为 false 。
• include_global_state：是否在快照中包含集群状态（包括索引模版、生命周期配置、持久化配置等）。默认值为 true ，建议设为 false。

恢复快照

POST /_snapshot/my_backup/snapshot_1/_restore
{
  "indices": "*",
  "ignore_unavailable": false,
  "include_global_state": false,
  "include_aliases": true,
  "ignore_index_settings": [
    "index.lifecycle.indexing_complete"
  ]
}

• ignore_unavailable：如果 indices 列表中的索引不存在，则是否忽略该索引而不是使还原操作失败。默认值为 false 。
• include_global_state：是否还原群集状态。默认值为 false 。
• include_aliases：是否恢复别名及其关联索引。默认值为 true 。
• index.lifecycle.indexing_complete 配置不支持，忽略掉。

数据验证

索引

通过 gateway 进行数据比对

path.data: data
path.logs: log

#show progress bar
#progress_bar.enabled: true

elasticsearch:
  - name: source
    enabled: true
    endpoints:
      - http://192.168.3.185:29200
  - name: target
    enabled: true
    endpoints:
      - https://192.168.3.185:9205
    basic_auth:
      username: admin
      password: admin

pipeline:
  - name: index_diff_service
    auto_start: true
    processor:
      - dag:
          mode: wait_all
          parallel:
            - dump_hash: #dump es1's doc
                sort_document_fields: true
                indices: ".infini_activities-000004"   ##需要比对的索引名
                scroll_time: "10m"
                elasticsearch: "source"
                #              query_string: "_id:c8es70pu46lgfdgmja9g-1646117763293610802-2"
                #              fields: "doc_hash"
                output_queue: "source_docs"
                batch_size: 5000
                slice_size: 1
            #              hash_func: "xxhash64"
            - dump_hash: #dump es2's doc
                indices: ".infini_activities-000004"
                scroll_time: "10m"
                #              fields: "doc_hash"
                #              query_string: "_id:c8es70pu46lgfdgmja9g-1646117763293610802-2"
                batch_size: 5000
                slice_size: 1
                #              hash_func: "xxhash64"
                elasticsearch: "target"
                output_queue: "target_docs"
          end:
            - index_diff:
                diff_queue: "diff_result"
                buffer_size: 10
                text_report: true #如果要存 es，这个开关关闭，开启 pipeline 的 diff_result_ingest 任务
                source_queue: "source_docs"
                target_queue: "target_docs"
#pipeline:
#  - name: diff_result_ingest
#    processor:
#      - json_indexing:
#          index_name: "diff_result"
#          elasticsearch: "source"
#          input_queue: "diff_result"

./gateway-linux-amd64 -config data_check.yml

别名

模版

PUT _template/.infini_activities-rollover
{
  "order": 100000,
  "index_patterns": [
    ".infini_activities*"
  ],
  "settings": {
    "index": {
      "format": "7",
      "lifecycle": {
        "name": "ilm_.infini_metrics-30days-retention",
        "rollover_alias": ".infini_activities"
      },
      "codec": "best_compression",
      "number_of_shards": "1",
      "translog": {
        "durability": "async"
      }
    }
  },
  "mappings": {
    "dynamic_templates": [
      {
        "strings": {
          "mapping": {
            "ignore_above": 256,
            "type": "keyword"
          },
          "match_mapping_type": "string"
        }
      }
    ]
  },
  "aliases": {}
}

PUT _template/.infini
{
  "order": 0,
  "index_patterns": [
    ".infini_*"
  ],
  "settings": {
    "index": {
      "max_result_window": "10000000",
      "mapping": {
        "total_fields": {
          "limit": "20000"
        }
      },
      "analysis": {
        "analyzer": {
          "suggest_text_search": {
            "filter": [
              "word_delimiter"
            ],
            "tokenizer": "classic"
          }
        }
      },
      "number_of_shards": "1"
    }
  },
  "mappings": {
    "dynamic_templates": [
      {
        "strings": {
          "mapping": {
            "ignore_above": 256,
            "type": "keyword"
          },
          "match_mapping_type": "string"
        }
      }
    ]
  },
  "aliases": {}
}

生命周期策略

PUT _ilm/policy/ilm_.infini_metrics-30days-retention
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_size": "50gb",
            "max_age": "30d"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {
          }
        }
      }
    }
  }
}

注：不支持 "delete_searchable_snapshot": true 配置

测试结果

源集群（Elasticsearch）	目标集群（Easysearch）	测试结果
7.10.2	1.0.0	索引文档一致，别名恢复成功
7.10.1	1.0.0	索引文档一致，别名恢复成功
7.10.0	1.0.0	索引文档一致，别名恢复成功
7.9.2	1.0.0	索引文档一致，别名恢复成功
7.9.0	1.0.0	索引文档一致，别名恢复成功
7.8.1	1.0.0	索引文档一致，别名恢复成功
7.5.2	1.0.0	索引文档一致，别名恢复成功
6.8.12	1.0.0	索引文档一致，别名恢复成功
6.5.4	1.0.0	索引文档一致，别名恢复成功

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎，核心引擎基于开源的 Apache Lucene。 Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。 Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。 与 Elasticsearch 相比，Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

详情参见：官方文档

近日，2023 移动云大会“数据库&云原生创新”论坛 在苏州隆重召开。现场精英荟萃、专家云集，共同探讨数据库与云原生技术发展及应用落地方案，为助力推动云原生数据库产业发展建言献策。极限科技创始人兼 CEO 曾勇受邀出席论坛。

会上，极限科技创始人兼 CEO 曾勇针对《Elasticsearch 国产化在移动云的演进之路》主题进行演讲，演讲围绕了什么是 Elasticsearch 以及 Elasticsearch 在移动云上的国产化演进过程。

Elasticsearch 在移动云的演进

随着数字化转型的不断深化，非结构化数据日益成为各类组织数据的增长主力，但其在管理和应用方面仍面临模态多样、管理复杂、检索挖掘难度大等挑战。为此，极限科技与移动云共同研发出搜索型数据库软件 Easysearch。

“Easysearch” 是极限科技在 Elasticsearch 软件原版本基础上，立足中国企业需求，助力移动云打造更符合其需求，独具 8 大特色功能的自有开源平替版本系统。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

移动云版本 “Easysearch” 精简 Kernel ，只保留开源核心能力，回归轻量化；增强内核后，可更稳定可靠地支持万亿级数据规模；为进一步增强安全能力，系统支持字段内容脱敏的同时对字段级别采取权限控制；可降低灾难恢复时间，系统具备完整的备份与容灾能力，可实时切换；为更好地服务业务场景，此版本更关注搜索场景的优化；增强型中文分词，提供本地化的词库与拼音支持；增强数据压缩能力后，最高可降低 40%存储空间；信创兼容的系统，支持适配国产操作系统和 CPU 芯片。

目前 Elasticsearch 为移动云提供的后端架构，已由基于 Docker 容器的“移动云 ES v1.0”升级为基于 K8s 架构的“移动云 ES v2.0”版本。其优势可以体现在：

• 新版本更具自主可控性，应对新需求更具灵活性；
• 基于 K8s 架构的系统，能支持更大规模的集群服务；
• 在支持全链路 IPv6 和本地磁盘（IO 隔离）的基础上，实现了更优性能的升级。

Elasticsearch 在中国已有近十万+开发者，上万家企业已经在生产环境大规模运行 Elasticsearch，服务客户包括知名互联网公司及大型企事业单位，覆盖全国范围内生活消费、金融投资、娱乐学习、软件应用与安全等领域知名企业。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

极限科技创始成员多来自 Elasticsearch 中国团队，深耕搜索及 Elasticsearch 十多年，且运营有国内最大的开源搜索技术社区，极限科技团队具备雄厚的技术实力和丰富的相关行业经验技术积累。

国产化替代的首选方案“Easysearch”

目前实时大数据搜索分析，尤其是结构化和非结构化数据结合的场景和需求非常大。针对海量数据，搜索技术成为核心，大多数企业都有不止部署一套搜索后端服务来满足各个场景的搜索业务需求。-- 极限科技创始人兼 CEO 曾勇在会上介绍道

Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本，并继续完善和支持更多的企业级功能。该软件衍生自开源的搜索引擎软件 Elasticsearch，具备相当的接口兼容能力，对于目前国内广大的 Elasticsearch 用户来说切换和接入的成本非常低。

与 Elasticsearch 相比，Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。基于团队在搜索和 Elasticsearch 生态的多年深耕，极限科技已具备完全自主自研可控能力，Easysearch 因更符合国产搜索技术生态需求，目前逐渐成为 Elasticsearch 国产化替代的首选方案。

作为一款具备自主可控的分布式近实时搜索型数据库产品 Easysearch 具备高性能、高可用、弹性伸缩、高安全性等特性，支持丰富的个性化搜索及聚合分析，且能承载 PB 级别的海量业务数据，可部署在物理机、虚拟机、容器、私有云和公有云，为金融核心系统、运营商、制造业和政企业务系统提供安全、稳定、可靠的快速检索和实时数据探索分析能力，满足不同业务场景的各项复杂需求。

持续丰富完善企业级服务能力

随着国内搜索型数据库的迅速发展，关键技术逐渐突破，应用场景和数据规模也逐年上升，已经成为企业必不可少的核心基础设施，产业生态日益繁荣。

截至目前，极限科技与移动云合作共建的 Easysearch 系统，已在无锡、呼和浩特、南基这 3 个城市上线，此外还有北京、上海、重庆、宁波、海南等 9 个城市的资源池正在上线中。-- 极限科技创始人兼 CEO 曾勇介绍道。

作为全球领先的近实时搜索数据库技术提供商，极限科技始终致力于搜索核心技术的研发与创新，基于国内搜索型数据库行业生态需求，在产品研发创新上，着力提升产品易用性、实时性、降低 IT 成本等，为推动国内搜索行业技术水平及相关技术社区的发展，建设数据强国提供强有力的基础技术支撑。

极限科技自成立起始终致力于提供本地化配套产品及解决方案，帮助客户解决在使用 Elasticsearch 时遇到的各种挑战。未来，极限科技将基于更多的真实客户场景提供个性化服务，持续丰富并完善更多维度、更高需求的企业级服务能力，与移动云等众多行业平台一起构建更“简单”的搜索服务。

关于极限科技

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。让搜索更简单是我们追求的目标。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

更多详情参见官网 (https://infinilabs.com) 。

本次 INFINI Labs 产品更新主要包括 Gateway v1.12.1、Console v1.0.0，其中 Console v1.0.0 是一个重要里程碑版本，该版本做了很多UI交互优化；集成了Github SSO 单点登录功能；新增了数据迁移功能，支持跨搜索引擎、跨版本的数据迁移；新增了数据看板，支持自定义可视化报表；以及修复已知Bug等。值得一提的是，Console 非常轻量级，安装包只有16MB，架构简洁，除了使用 Elasticsearch 当作数据存储外无任何外部依赖，包含监控、告警、安全、可视化分析等日常管理功能，欢迎下载使用。在线体验DEMO：https://play.infinilabs.com:64443，用户名密码 readonly/readonly。

INFINI Gateway v1.12.1

极限网关本次更新如下：

Bug fix

• Elasticsearch 修复偶现连接断开的问题。
• Elasticsearch 修复连接超时未返回错误信息的问题。

更多 Gateway 更新可参考【Gateway 版本历史】。

INFINI Console v1.0.0

Console 本次主要更新如下：

1、集成 Github 单点登录，方便快速登录，减少用户名和密码登录经常忘记带来的烦恼。详情查看教程

2、新增了工作台界面，作为 Console 登录后的入口页面，可以快速预览整个系统的集群资源概要信息、集群动态、常用功能快捷入口等。

3、新增了数据迁移功能，支持 Elasticsearch、Opensearch、Easysearch 等搜索引擎的所有版本之间相互迁移。需要搭配 最新版本极限网关（INFINI Gateway） 使用，详情查看教程

4、新增了数据看板功能，支持多标签页，支持折线图、柱状图、饼图等图表，支持用户自定义可视化数据报表，详情查看教程

5、数据探索 Discover 添加搜索关键词高亮功能。

除了以上主要功能外还做了很多优化和Bug fix，如下：

Features

• 数据迁移添加初始化索引 settings, mappings 可选步骤
• 数据迁移添加删除功能

Improvements

• 添加 Opening scroll context 监控指标
• 数据迁移分区设置优化
• 优化数据迁移错误日志和异常情况处理
• 迁移后目标集群和源集群文档数量不匹配，标记迁移任务为失败状态

Bug fix

• 修复新注册集群状态不同步更新的问题
• 修复低版本 ES 多 type 分区查询时没有根据 doctype 过滤的问题
• 修复特殊情况下迁移任务没有被释放的问题
• 修复迁移任务结束，队列磁盘文件未释放的问题
• 修复bulk写入失败导致迁移任务卡住的问题

更多 Console 更新可参考【Console 版本历史】。

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs） 中的对应项目中提交 Feature Request 或提交 Bug。

• INFINI Gateway： https://github.com/infinilabs/gateway/issues
• INFINI Console： https://github.com/infinilabs/console/issues
• 官网： https://www.infinilabs.com
• 下载地址： https://www.infinilabs.com/download

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

也欢迎大家微信扫码添加小助手（INFINI-Labs），加入用户群讨论，或者扫码加入我们的知识星球一起学习交流。

最后祝大家周末愉快！

关于极限科技（INFINI Labs）

极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。

Web Scraper + Elasticsearch + Kibana + SearchKit 打造的豆瓣电影top250 搜索演示系统

作者：小森同学

声明：电影数据来源于“豆瓣电影”，如有侵权，请联系删除

Web Scraper

{
    "_id": "top250",
    "startUrl": ["https://movie.douban.com/top250?start=[0-225:25]&filter="],
    "selectors": [{
        "id": "container",
        "multiple": true,
        "parentSelectors": ["_root"],
        "selector": ".grid_view li",
        "type": "SelectorElement"
    }, {
        "id": "name",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.title:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "number",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "em",
        "type": "SelectorText"
    }, {
        "id": "score",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.rating_num",
        "type": "SelectorText"
    }, {
        "id": "review",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "",
        "selector": "span.inq",
        "type": "SelectorText"
    }, {
        "id": "year",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "\\d{4}",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "tour_guide",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "^导演: \\S*",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "type",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^/]+$",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "area",
        "multiple": false,
        "parentSelectors": ["container"],
        "regex": "[^\\/]+(?=\\/[^\\/]*$)",
        "selector": "p:nth-of-type(1)",
        "type": "SelectorText"
    }, {
        "id": "detail_link",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": ".hd a",
        "type": "SelectorLink"
    }, {
        "id": "director",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "",
        "selector": "span:nth-of-type(1) .attrs a",
        "type": "SelectorText"
    }, {
        "id": "screenwriter",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=编剧: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\·\\s]+(?=主演)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "film_length",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "\\d+",
        "selector": "span[property='v:runtime']",
        "type": "SelectorText"
    }, {
        "id": "IMDb",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=[IMDb:\\s+])\\S*(?=\\d*$)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "language",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=语言: )\\S+",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "alias",
        "multiple": false,
        "parentSelectors": ["detail_link"],
        "regex": "(?<=又名: )[\\u4e00-\\u9fa5A-Za-z0-9/()\\s]+(?=IMDb)",
        "selector": "div#info",
        "type": "SelectorText"
    }, {
        "id": "pic",
        "multiple": false,
        "parentSelectors": ["container"],
        "selector": "img",
        "type": "SelectorImage"
    }]
}

elasticsearch

{
    "mappings": {
      "properties": {
        "IMDb": {
          "type": "keyword",
          "copy_to": [
            "all"
          ]
        },
        "alias": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "all": {
          "type": "text",
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "area": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "director": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "film_length": {
          "type": "long"
        },
        "id": {
          "type": "keyword"
        },
        "language": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "link": {
          "type": "keyword"
        },
        "name": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "number": {
          "type": "long"
        },
        "photo": {
          "type": "keyword"
        },
        "review": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "score": {
          "type": "double"
        },
        "screenwriter": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "type": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          },
          "copy_to": [
            "all"
          ],
          "analyzer": "ik_max_word",
          "search_analyzer": "ik_smart"
        },
        "year": {
          "type": "long"
        }
      }
    }
  }

kibana

需要使用pipeline对索引字段进行处理，如对type 通过空格进行分割为数组等，可以参照官方文档或其他博客。

制作仪表板省略, 请自行搜索

SearchKit

参考 https://github.com/searchkit/searchkit-starter-app

岗位职责： 1. 参与ElasticSearch平台建设，赋能公司业务。 2. 参与ElasticSearch的集群管理维护与业务支持。 任职要求： 1. 编程能力扎实，熟练Java编程，具有良好的数据结构和算法的基本知识 2. 熟悉Elasticsearch架构和DSL 3. 熟悉倒排索引、中文分词排序等相关技术 4. 熟悉搜索引擎相关知识，如：建模、分词、索引、关联词等 5. 熟悉MySQL、java框架和组件(SpringMVC/SpringBoot/MyBatis) 6. 具有良好的沟通能力、职业稳定性，工作积极主动，学习能力强 加分项： 拥有ES集群运维经验，并优化, 对集群备份有研究 月薪18~23k，工作地点在上海杨浦，五险一金，法定节假日 不出差，双休日基本不加班，工作日最多加班到8点，工作氛围不鸡血 有兴趣的请发简历到邮箱： 876451600#qq.com VX： wowcat60

会议信息同步

1. 关于讲师议题：少部分讲师和议题有变化，组委会近期会与讲师沟通确认是否需要更换新的演讲议题。
2. 已经报名参会者无需再次报名。

其他说明

1. 目前大会报名购票通道已重新开启，欢迎推荐有兴趣的朋友报名参会，可享受八折购票优惠，折扣报名链接：https://www.bagevent.com/event/7899116?discountCode=80OFF
2. 由于部分议题陈旧，我们重新开放了演讲议题申请，欢迎大家提交和推荐。议题提交链接：http://elasticsearch.mikecrm.com/2gQNDKh
3. 赞助合作申请：http://elasticsearch.mikecrm.com/6gxTHs4
4. 如需要加入大会微信交流群，请加微信(lsy965145175)拉群。
5. 更多大会信息请关注官网：https://conf.elasticsearch.cn

感谢

这次的 Elastic 中国开发者大会虽然遇到了很多的困难与波折，但因为您们的理解和支持，一直鼓励着我们，给了我们信心与动力，我们会本着办好中国开发者大会的初心继续前行，再次感谢大家的大力支持！

在2023年新春到来之际，Elastic 中国开发者大会组委会祝大家新春快乐、身体健康、工作顺利、阖家幸福！

背景

1.ES PAAS管理的集群升级了100+，从7.5升级到7.17 （保证每个大版本最终仅维护一个小版本集群）

2.由于业务使用差异大，也出了不少问题，前面的文章也有提到过Integer类型字段使用terms查询效率低的情况

3.这里再分析一个CPU、IO飙升的场景

现象

1.用户报障：“ES集群写入吞吐量变小了”

2.观察下来发现确实CPU高了，IO也有明显抖动

排查与分析

1.发现YoungGC频率变高了一些，猜测可能是G1GC的问题（我们使用JDK11重新打了ES镜像），经过版本替换，没有明显变化。

参考issue：https://github.com/elastic/elasticsearch/pull/46169

这可能是另一个场景的case，经过测试，不属于我们的场景。

2.多次执行hot_threads API观察， 发现时不时会出现 update相关函数 消耗的 CPU多。

3.继续使用arthas抓取一段时间的数据，发现是 FST、DocID 读取慢

从图中可以看到Bulk请求执行过程中的getDocID方法占有大量CPU。

4.集群写多读少，使用的是niofs。可知，7.5版本的FST是在堆外，但是_id字段是在堆内。升级到7.17版本后，FST在堆外，该字段也放到了堆外（官方版本应该是7.9就开始放到堆外了）。数据放到堆外，其实也就是文件放到磁盘，读一次之后放到pagecache。

这样也就可以解释了，在upsert类请求多的时候会频繁查询docId，此时如果_id字段没有进入pageCache或者被踢出pageCache，那么就会出现响应慢，并且CPU高、IO高的情况。

5.mmapfs、hybridfs实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障。

测试验证

将FST、BKD等全部改成放到堆内（开源版需要改造）

可以看到，CPU有显著下降，也相对均衡。（之前蓝色线高，是因为该节点有大量的主分片）

结论

1.update、upsert、get等请求如果十分频繁，_id使用offheap将不会是个好的选择，除非给足够的堆外内存，并且保证尽可能常驻内存。

2.不同的业务场景下使用ES的同一版本也会有不一样的效果。

3.mmapfs、hybridfs在频繁update情况下，实测是什么情况暂时不明确，目前没有收到搜索类集群CPU、IO方面的报障，可能不会有这么明显的差距。（官方描述写入速度仅降低了1.8%）

4.最后吐槽一下，写入不停的情况下，translog的恢复实在是太慢了，由于大分片恢复/rebalance时，translog不会被清理，导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。

背景

1.对于7版本（大版本）集群希望只维护一个版本，最终选择7.17，对同大版本的7.5版本集群进行升级

2.根据官方描述，_id放到堆外性能损失非常小可以忽略，且对BKD进行了优化

3.升级完成，一段时间之后，收到用户报障

4.抽样检查了下部分升级的集群，其中部分受到影响，部分不受影响。且每个集群内存均有一定优化（预期内）

调查&分析

1.发现is_deleted文档特别多，怀疑是7.17版本对于碎片过于敏感。做forcemerge，没什么效果。

2.GET _nodes/hot_threads 查看耗时部分，结果展示笼统，没得到关键信息。

3.给语句加上profile，查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}

从脱敏的简化结果中可以看出来，主要是 status、pId 字段耗时高，这两个字段都是integer类型，并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题，进一步排查：使用arthas工具获取一段时间内的火焰图

可以看到主要就是BKD数据结构占用的CPU。

5.参考官方论坛相似问题：https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3

6.integer类型的terms查询性能较差，看起来官方描述的BKD相关优化指的是range

7.测试验证，将字段改成keyword，查看结果，CPU查询耗时恢复到正常范围

今天 INFINI Labs 为大家又带来了一波产品更新，请查阅。

INFINI Gateway v1.8.0

极限网关本次迭代更新如下：

• 修复上下文条件 consumer_has_lag参数和 配置、文档不一致的 Bug。
• 修改备集群故障，主集群不能正常写数据的 Bug。
• 修复 Bulk 请求处理异常造成数据复制不一致的问题。
• 修复请求日志里面关于 Bulk 统计数据丢失的问题。
• 修复大并发情况下，请求体为空的异常。

INFINI Console v0.6.0

口碑爆棚的 Elasticsearch 多集群管控平台 INFINI Console 更新如下：

• 新增主机概览。

• 新增主机监控。

• 节点概览新增日志查看功能（需安装 Agent）。

• Insight 配置框新增 Search 配置。
• 优化 Discover 时间范围 Auto Fit，设为15分钟。
• 优化 Discover 保存搜索，会保存当前的字段过滤和 Insight 图表配置。
• 优化本地列表搜索查找，支持通配符过滤。
• 优化告警规则必填字段标记显示。
• 修复了 Discover 字段过滤白屏问题。
• 修复了 Discover 表格添加字段后排序失效问题。(感谢@卢宝贤反馈)
• 修复了 Elasticsearch 8.x 删除文档报错不兼容的问题。(感谢@卢宝贤反馈)
• 修复了创建新索引不成功时，异常处理的问题。
• 修复了低版本浏览器js不兼容导致集群注册不成功的问题。
• 修复了开发工具中使用加载命令失败报错的问题。

INFINI Agent v0.2.0

数据采集工具探针（INFINI Agent）更新如下：

• 新增按节点读日志文件列表的API
• 新增读具体日志文件内容的API
• 新增 Elasticsearch 节点掉线后的基础信息保存
• 新增主机在线状态的采集
• 新增基于 Centos 的 Docker 镜像
• 新增主机配置信息采集: 操作系统信息、磁盘大小、内存大小、CPU配置等
• 新增主机指标的采集: CPU使用率、磁盘使用率、磁盘IO、内存使用率、swap 使用率、网络IO等
• 新增 Elasticsearch 进程信息采集
• 修复发现 Elasticsearch 进程时频繁提示端口访问错误的Bug
• 修复 Elasticsearch 节点地址为 0.0.0.0 时无法获取节点信息的Bug
• 修复 CPU 指标数据显示异常的Bug
• 修复 stats API 在 Windows 平台的兼容性

INFINI Framework 2000923

INFINI Framework 也带来了很多改进：

• 重构了磁盘队列压缩相关配置，支持段文件的压缩。
• 当集群不可用的情况下，跳过集群节点元数据的获取。
• 完善节点可用性检测，避免频繁的不可用状态切换。
• 修复 Elasticsearch 主机地址为空的异常。
• 完善本地磁盘队列文件的清理，避免删除正在使用的文件。

期待反馈

如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（https://github.com/infinilabs）中的对应项目中提交 Feature Request 或提交 Bug。

• INFINI Gateway： https://github.com/infinilabs/gateway
• INFINI Console： https://github.com/infinilabs/console/issues
• 下载地址： https://www.infinilabs.com/#/download

您还可以通过邮件联系我们：hello@infini.ltd

或者拨打我们的热线电话：(+86) 400-139-9200

也欢迎大家微信扫码添加小助手，加入用户群讨论，或者扫码加入我们的知识星球一起学习交流。

感谢大家的围观，祝大家周末愉快。

本文将为你介绍 Apache APISIX 的 elasticsearch-logger 插件的相关信息，以及如何通过此插件获取 APISIX 的实时日志。

背景信息

Apache APISIX 是一个动态、实时、高性能的 API 网关，提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。作为 API 网关，Apache APISIX 不仅拥有丰富的插件，而且支持插件的热加载。

Elasticsearch 是一个基于 Lucene 库的搜索引擎。它提供了分布式、RESTful 风格的搜索和数据分析引擎，具有可扩展性、可分布式部署和可进行相关度搜索等特点，能够解决不断涌现出的各种用例。同时还可以集中存储用户数据，帮助用户发现意料之中以及意料之外的情况。

插件介绍

APISIX 以 HTTP 请求的方式向 Elasticsearch 发送 APISIX 的 Runtime 日志。插件 elasticsearch-logger 采用 bulk 的格式进行日志上报，这允许 APISIX 可以将多条日志合并后再进行上报，这使得 APISIX 在对 Elasticsearch 进行日志上报方面更加灵活并且具有较好的性能。你可以参考文档 APISIX 批处理器 对日志合进行更加细致的配置。

配置步骤

首先，你需要安装完成 APISIX，本文所有步骤基于 Centos 7.5 系统进行。详细的安装步骤参考 APISIX 安装指南。

步骤1：启动 Elasticsearch

本示例只演示了通过 docker-compose 启动 Elasticsearch 单节点的方式，其它启动方式可参考 Elasticsearch 官方文档。

# 使用 docker-compose 启动 1 个 Elasticsearch 节点, 1 个 kibana
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.1
    container_name: elasticsearch
    environment:
      ES_JAVA_OPTS: -Xms512m -Xmx512m
      discovery.type: single-node
      xpack.security.enabled: 'false'
    networks:
      - es-net
    ports:
      - "9200:9200"
      - "9300:9300"

  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.1
    container_name: kibana
    environment:
      ELASTICSEARCH_HOSTS: http://elasticsearch:9200
      I18N_LOCALE: zh-CN
    networks:
      - es-net
    depends_on:
      - elasticsearch
    ports:
      - "5601:5601"

networks:
  es-net:
    driver: bridge

步骤2：创建路由并配置插件

APISIX 默认配置文件中已启用 elasticsearch-logger 插件，所以你只需要通过下方命令创建路由并配置 elasticsearch-logger 插件就可以在 APISIX 中正常使用了。

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins":{
        "elasticsearch-logger":{
            "endpoint_addr":"http://127.0.0.1:9200",
            "field":{
                "index":"services",
                "type":"collector"
            },
            "ssl_verify":false,
            "retry_delay":1,
            "buffer_duration":60,
            "max_retry_count":0,
            "batch_max_size":1000,
            "inactive_timeout":5,
            "name":"elasticsearch-logger"
        }
    },
    "upstream":{
        "type":"roundrobin",
        "nodes":{
            "127.0.0.1:1980":1
        }
    },
    "uri":"/elasticsearch.do"
}'

上述代码中配置了 Elasticsearch 地址、目标 field，用户名与密码。

通过上述设置，就可以实现将 /elasticsearch.do 路径的 API 请求日志发送至 Elasticsearch 的功能。

步骤3：发送请求

接下来我们通过 API 发送一些请求。

curl -i http://127.0.0.1:9080/elasticsearch.do\?q\=hello
HTTP/1.1 200 OK
...
hello, world

此时你可以登录 Kibana 控制台检索查看相关日志：

自定义日志结构

当然，在使用过程中我们也可以通过 elasticsearch-logger 插件提供的元数据配置，来设置发送至 Elasticsearch 的日志数据结构。通过设置 log_format 数据，可以控制发送的数据类型。

比如以下数据中的 $host、$time_iso8601 等，都是来自于 NGINX 提供的内置变量；也支持如 $route_id 和 $service_id 等 Apache APISIX 提供的变量配置。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "log_format": {
        "host": "$host",
        "@timestamp": "$time_iso8601",
        "client_ip": "$remote_addr"
    }
}'

通过发送请求进行简单测试，可以看到上述日志结构设置已生效。目前 Apache APISIX 提供多种日志格式模板，在配置上具有极大的灵活性，更多日志格式细节可参考 Apache APISIX 官方文档。

此时你可以登录 Kibana 控制台检索查看相关自定义日志：

如需关闭自定义日志结构，可参考下方操作。

curl http://127.0.0.1:9180/apisix/admin/plugin_metadata/elasticsearch-logger \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X DELETE

此时，插件 elasticsearch-logger 将使用默认格式上报日志。

关闭插件

如使用完毕，只需移除路由配置中 elasticsearch-logger 插件相关的配置并保存，即可关闭路由上的插件。得益于 Apache APISIX 的动态化优势，开启和关闭插件的过程都不需要重启 Apache APISIX。

curl http://127.0.0.1:9080/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "methods": ["GET"],
    "uri": "/hello",
    "plugins": {},
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "127.0.0.1:1980": 1
        }
    }
}'

总结

本文为大家介绍了关于 elasticsearch-logger 插件的功能与使用步骤，更多关于 elasticsearch-logger 插件说明和完整配置列表，可以参考官方文档。

也欢迎随时在 GitHub Discussions 中发起讨论，或通过邮件列表进行交流。

背景

Elasticsearch CPU很高的场景很常见，优化读写以及扩容即可解决问题。

如果只有一个节点CPU高，那可能的情况就比较多了，节点机器异常？读写不均匀？GC过高？forcemerge？

这里描述一个极具迷惑性的case。

问题

收到用户报障碍，突然有写入被reject，并且有一个节点的CPU突然增高。

分析、验证与结论

1.常用套路，先大致了解集群、索引。

集群层面：6.8.5 版本，18个节点（冷热分离）

索引层面：近3000个索引，大多数小索引（mb、1～10gb级别），template（设置1主分片、1副本分片）

用户行为：写多读少的OLAP场景

2.检查节点（pod）监控、宿主机监控、ES集群监控。没有很明显的异常行为。只能观测到异常节点CPU高、出现reject。用户的读写流量也没有观测到明显变化。

3.集群GC、merge等行为都很正常，并且只有一个节点CPU高（刚好用户索引都是1主1副），开始认为和热点相关。可能是某个索引的读写导致了节点CPU的上升。

4.使用 GET _nodes/hot_threads 查看CPU使用情况，果然抓到了异常节点占用CPU的主要是 write 线程。

5.由于hot_threads只能抓取瞬时的数据，不一定准确。准备进入容器，使用arthas工具抓取perf信息（arthas是阿里的开源工具、已经被我们集成到ES镜像里）。

通过arthas简要的获取热点线程：可以看到主要是write线程在执行bulk请求，然后还有日志打印的堆栈。

继续抓取2min内的统计信息：可以看到主要是search在使用CPU。和之前获取的信息不符。

6.分析到底是读还是写影响的CPU。

a.如果是写热点导致，应该会有2个节点CPU高；

b.写入一般很难长时间打高CPU，而一个拉全量/大量数据的大请求很可能拉高CPU，由于index设置1主1副本，刚好可以解释只有一个节点CPU高；

c.考虑到抓取的数据perf结果，2min内的抓取结果比瞬时的可信；

综合来看，大查询导致的CPU高的概率很大。

7.继续走排障流程，查看日志信息

看到异常节点日志里大多都是这类异常。

elasticsearch org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream /usr/share/elasticsearch/logs/e100024741.log org.apache.logging.log4j.core.appender.AppenderLoggingException: Error writing to stream....

由于节点已经跑了很长时间，log盘写满也是有可能的，而且不太可能瞬间拉高CPU，暂时忽略。

8.进一步验证，将异常节点重启。

果然异常节点CPU下去了，另一个节点CPU起来了，进一步证明了是查询导致的，1主1副的case下，一个节点挂了，另一个承载流量。

继续观察异常节点的流量：outgoing的流量比较高，又进一步佐证了是查询带来的异常。

继续查看IO，write/read都相对比较高。

9.考虑到查询无法被阻断、且该节点异常带来的影响并不大，准备等“拉数据的大请求”执行完毕自动恢复。

10.开始关注其他问题。等待一段时间，发现依然没有恢复，且CPU完全没有下降的趋势。考虑到一个大请求不会执行这么长时间，如果多个大请求，至少reject、cpu曲线会有些波动，不会如此稳定。准备继续排查。再次执行多次hot_thread API，依然有很多次都只抓到了write线程占用大量CPU，如果大请求存在，不会一直抓不到search请求。

11.考虑其他思路。找到重启前异常节点和重启异常节点后才异常的节点共有的index（互为主备），在众多index中发现了一个较大的index（800G）。看了下文档数：2147483519，至此，找到了问题的答案。

12.结论：使用了同一template的大量索引（1 primary 1 replica），存在一个index写了大量doc数，超过了lucene的最大限制（integer的最大值），疯狂报错reject，并且记录大量异常日志，日志不断的rotate、清理造成了CPU的大幅上升。

仔细检查异常开始时间节点的日志，可以发现如下异常信息：

[2022-07-22T12:00:36,376][DEBUG][o.e.a.b.TransportShardBulkAction] [e100024741-es-default-1][cp0006014_2022_07][0] failed to execute bulk item (index) index {[cp0006014_2022_07][event_cp][Ir_HJYIBi3-VIQ2V8GIT], source[{"rowkey":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column01":"BatchValidateRecevieCouponRealTime","column02":"1","column03":"289358095","column04":"100009826","column05":"nkryj","column06":"32001052810269459246","column08":"fff5e48f-13d9-4f68-b9c9-8cfc1f0fefa3","column09":"[34m~L[34m~A34m~O~Q34m~H[34m~D34m| "column11":"2022-07-22 20:00:29.703","column12":"1","column20":"0","datachangelasttime":1658491229707,"rules":[],"rulesh":[],"scenes":[]}]}
java.lang.IllegalArgumentException: number of documents in the index cannot exceed 2147483519
        at org.apache.lucene.index.DocumentsWriterPerThread.reserveOneDoc(DocumentsWriterPerThread.java:226) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:494) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1616) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1235) ~[lucene-core-7.7.2.jar:7.7.2 d4c30fc2856154f2c1fefc589eb7cd070a415b94 - janhoy - 2019-05-28 23:30:25]
        at org.elasticsearch.index.engine.InternalEngine.addDocs(InternalEngine.java:1175) ~[elasticsearch-6.8.5.jar:6.8.5]
        at org.elasticsearch.index.engine.InternalEngine.indexIntoLucene(InternalEngine.java:1120) ~[elasticsearch-6.8.5.jar:6.8.5]

进一步验证：进入容器清理日志文件，会立刻生成并rotate出多个日志文件。

最终处理：清理掉异常索引立刻恢复正常：

解释前面的坑

1.arthas采集2min内的CPU信息，得到的search结论是正确的，该集群确实存在search大请求。虽然频率不高，但是采集到的概率很大。

2.异常节点的out流量很大。这个逻辑也是正确的，只是并不是导致异常的根本原因。

确实有拉数据的请求存在；节点存在大量索引的分片，无法确认流量来源是否是其他index；该异常情况下用户收到异常ack之后会有重试，影响到流量的统计。

3.重启后另一个节点CPU就开始激增，是因为副本分片成为了主分片，然后开始reject，并疯狂打印日志、进行rotate和清理。

4.为什么只有一个节点CPU高。写入流程是主分片写入成功后，异步转发请求给所有副本（此处只有1），由于主分片写入失败，直接异常，副本也就不会受到影响。

思考

1.经验流大多情况有效，有时却不可取。时刻根据事实排障，避免先入为主。

2.相似的现象以及采集排障数据的巧合进入思维误区，集群业务复杂度增加了排障难度：

大量的日志难以查找（被AppenderLoggingException淹没），且都被判定为和本次异常无关，如 bulk reject 被认为是CPU高的场景下正常的表现，AppenderLoggingException 被认为无法快速消耗CPU，number of documents in the index cannot exceed 2147483519 刚看到时也被认为无法导致CPU增高（仅仅是无法写入）；

index太多，无法从单个index层面获取更多信息。（没有明确目标的情况下难以发现那一个异常index）。

3.arthas write线程的堆栈信息中有体现，bulk之后就在打印日志，这两点之间的关联被忽略。

4.优化方向：需要更细粒度的监控和巡检能力，快速发现异常index可大大加快排障进程，不再强依赖OPS的知识体系与推理。

INFINI Console v0.3 正式发布

极限实验室上新啦，期待已久的 INFINI Console 最新的 0.3 版本正式发布！

01 产品名称的变化

还记得最开始的极限数据平台么，现在已经升级成为 INFINI Console 了。

与极限实验室的其它产品保持一致，家族 Logo 一览如下：

接下来，将为大家隆重介绍一下本次产品更新都有哪些亮点吧。

02 统一的监控

作为目前最方便的 Elasticsearch 管理工具，跨版本、跨集群的监控自然是必不可少的一个基础能力啦。

除了使用方便，颜值自然也是高高的，多套集群的监控终于在一起了。

INFINI Console 提供了市面上最全面的各项统计指标的监控，帮助您快速掌握集群内部运行状态，快速定位集群问题，提高诊断效率，缩短故障时间。

03 统一的安全

相信您的 Elasticsearch 集群不止一个，INFINI Console v0.3 新增了平台级统一的安全管控能力。

多个集群可以统一实现基于角色的用户权限管理，数据和 UI 的权限也可以分别进行设置，可以做到不同的部门看到的集群各不一样，不同的人员看到的索引各不一样，不同的角色读写权限各不一样。

在一个平台里面统一的进行管理，再也不用割裂的维护 N 套安全配置了。

04 统一的告警

平台层的监控还是空白么？还在一套集群一套集群的配置告警规则么？Elasticsearch 内的业务数据还在被动响应么？

INFINI Console v0.3 新增了强大的告警规则引擎，通过配置告警规则，将业务关注点自动化、流程化、主动化，引擎支持常见的统计函数，使用起来简单且灵活，支持 Webhook 方式灵活对接钉钉、微信、Slack 或是内部通知系统。

只要是在 Elasticsearch 的数据，都可以借助告警引擎“活”起来。

05 统一的探索

还在不同 Kibana 之间来回跳转么？还在傻傻创建 IndexPattern 才能分析数据么？

拒绝复杂，回归简单，INFINI Console 新增了跨集群的数据探索功能，不需要提前创建 IndexPattern，想要探索数据一键直达，切换不同集群、切换不同索引、切换不同时间维度，都只在一步完成。

让数据分析和探索的体验尽可能简单是我们努力在做的事情。

06 更多细节

当然本次更新也新增了不少细节特性和修复了不少 Bug，具体的细节请访问产品的 Release Notes 页面：

• http://console.infinilabs.com/zh/docs/release-notes/

欢迎大家下载体验，下载安装及文档地址：

• http://console.infinilabs.com/

背景

1.有个向量搜索相关需求，选择使用ES8版本，并且在k8s环境中容器化部署； 2.考虑核心程度以及成本问题，不需要准备多数据中心的备份集群，为了保证数据可靠性，预期使用snapshot备份能力；

选型

ES支持将snapshot存储到各种存储产品，例如 fs(本地)、S3（或者ceph）、hdfs等。 1.OSS，考虑到已经和阿里云OSS有合作，且支持S3接口 -----> 测试 2.ceph，私有云部署，不好控制容量，成本偏高 --------> 暂不考虑 3.hdfs，私有云部署，不好控制容量，成本偏高，需要安装插件 -----> 暂不考虑 4.fs，本地，由于团队还在做juicefs产品，可以juicefs挂载到本地目录，ES snapshot 存到本地目录即可完成上传到公有云OSS ------> 测试

snapshot直接从ES传到OSS

1.创建账号、bucket，获取ak/sk；

略

2.ES容器实例如何加载密钥库

通过官方文档可知需要执行如下命令：将密钥设置到ES密钥库 https://www.elastic.co/guide/en/elasticsearch/reference/current/repository-s3.html

bin/elasticsearch-keystore add s3.client.default.access_key
bin/elasticsearch-keystore add s3.client.default.secret_key

考虑到容器环境不允许直接进入pod执行命令，secret也不允许直接写死到镜像中，则需要在entrypoint.sh中设置完成该命令。 最终方案如下：

1.在k8s环境中创建secret，记录ak/sk信息 2.pod创建时候mount到指定目录 3.container（ES）启动的时候读取指定目录信息，并执行elasticsearch-keystore命令

3.具体操作

0.安装 repository-s3 插件 略（ES8版本内置了该插件，无需安装）

1.创建secret

kubectl apply -f secret.yml

# cat secret.yml
apiVersion: v1
kind: Secret
metadata:
  namespace: uat-es
  name: es-snapshot-oss-secret
type: Opaque
data:
  access_key: xxx(注意base64编码)
  secret_key: xxx(注意base64编码)

2.修改crd的yaml，将该secret mount到指定目录

# 定义secret
  volumes:  
  - name: "oss-secret"
    secret: 
      secretName: "es-snapshot-oss-secret"

# 指定容器挂载选项
containers:
    ...
  volumeMounts:
  - mountPath: "/mnt/secret/oss"
    name: "oss-secret"
    readOnly: true

3.镜像修改 注：Dockerfile中最后是通过docker-entrypoint.sh完成ES实例的启动 ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]

# docker-entrypoint.sh 增加如下内容
/usr/share/elasticsearch/bin/elasticsearch-keystore create
chown root:root /usr/share/elasticsearch/config/elasticsearch.keystore
echo "$(</mnt/secret/oss/access_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.access_key
echo "$(</mnt/secret/oss/secret_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.secret_key
chown elasticsearch:elasticsearch /usr/share/elasticsearch/config/elasticsearch.keystore

1.可以看到先执行了 bin/elasticsearch-keystore create 命令，因为发行版的ES中config目录并没有elasticsearch.keystore文件，需要通过 bin/elasticsearch-keystore create 命令生成密钥库（即 config/elasticsearch.keystore 文件）；

注：如果不create，可以发现pod中最后也会生成密钥库，并且含有一个 seed 的密钥信息。该部分是ES启动时创建的，所以在启动之前必须create，否则执行bin/elasticsearch-keystore add 会触发一个密钥库不存在的异常； 2.可以看到先通过 chown root:root xxx 命令将config/elasticsearch.keystore文件的用户和group都设置成了root，执行完成命令后将其改回elasticsearch，因为bin/elasticsearch-keystore命令执行时对密钥库的权限有要求，pod启动是root用户，所以必须将该文件改成root权限，后续改成elasticsearch用户是为了保证container（ES）启动时的权限，ES的启动是使用elasticsearch用户； 注：该方式是在ES启动之前先将密钥加载到密钥库，ES提供另一个方式，允许在ES启动后执行 elasticsearch-keystore add 命令后再 reload，也能生效，这里不讨论。

4.测试创建repository、snapshot命令

# 创建repository
# 注：对象存储OSS不允许出现对象name中带 “/” ，所以 base_path 中 “-” 表示层级
PUT _snapshot/zmc_test_oss_repository
{
  "type": "s3",
  "settings": {
    "bucket": "es-snapshot",
    "endpoint": "http://dataplatform.xxxx.com",
    "base_path":"user-elasticsearch-uat-1067"
  }
}

# 创建snapshot
PUT /_snapshot/zmc_test_oss_repository/snapshot_1?wait_for_completion=true
{
  "indices": "zmc",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "zmc",
    "taken_because": "backup test"
  }
}
# 该命令异常：
amazon_s3_exception: Aws MultiChunkedEncoding is not supported. (Service: Amazon S3; Status Code: 400; Error Code: NotImplemented; Request ID: xxxxx; S3 Extended Request ID: es-snapshot.dataplatform.xxx.com

5.测试结果

很不幸，OSS暂时不支持MultiChunkedEncoding；（和OSS同学沟通后发现是 主集群暂时不支持，海外小集群已经支持该接口，后续会推到主集群） 这条路无法走通，继续测试其他方案；

snapshot存本地后通过juicefs上传OSS

juicefs是一个分布式文件系统，简言之就是通过juicefs程序可以将远程对象存储与本地目录关联，将文件写入本地即可上传到对象存储。该产品对ES而言比较适合作为snapshot的存储以及ES冷热分离架构中的冷数据存储。 juicefs有一定的维护成本，这里仅提供一种snapshot备份设计的新思路。对ES8而言更简要的方案可以考虑hdfs、ceph以及亚马逊的s3对象存储，弊端主要在成本和容量规划，体量较小或者公司支持较好则可以忽略。

预期架构如下：

可以看到从使用层面看ES只需将snapshot存在本地目录即可完成上公有云操作； juicefs部分只需从运维层面考虑，将进程打到镜像中、或者通过CSI、静态PVC的方式均可实现。图中元数据引擎是juicefs架构中的一环，从ES使用的角度看可以忽略； 此处juicefs可以替换成任何分布式共享存储。 ----------------------------end---------------------------------