随着单个 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的优点结合，是任何一个企业公司业务系统实践都值得探讨的事。  

背景

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---------------------------------

你是否遇到过新搭建一个 Elasticsearch 集群，但是却无法评估该集群的最大吞吐是多少，或者使用一些压测工具，比如 esrally，需要花费很大力气准备，但是却无法压测到极限速度，服务器资源跑不满，或者测试产生的数据和实际的业务有很多出入，又或者测试的请求太简单，比如查询，就是对单个固定的搜索请求进行查询，不仅测不准还可能浪费时间没有参考意义，so，有没有一个简单的工具可以支持灵活的自定义压测，并且足够快，答案是 Loadgen。

Loadgen

Elasticsearch 压测工具 Loadgen ，由极限实验室出品，基于 Elasticsearch 的开发运维需求而开发，久经实际客户环境的真实考验，简单好用速度快。

一个没有经过压测的 Elasticsearch 不是一个完整的 Elasticsearch。

Loadgen 具有以下主要特点：

• 性能强劲
• 轻量级无依赖
• 支持模板化参数随机
• 支持高并发
• 支持压测端均衡流量控制

只有模拟自己真实业务数据场景的压测才有意义，通过使用 Loadgen 定义写入文档或者查询模板，同时将里面的变量词典化，确保每次请求都是足够随机，变量可以灵活复用，支持多个请求混合压测，最大程度模拟真实环境。

• 下载地址：http://release.infinilabs.com/loadgen/
• Docker 地址：https://hub.docker.com/r/infinilabs/loadgen

Loadgen

Loadgen 使用非常简单，下载解压之后会得到两个文件，一个可执行程序和一个配置文件 loadgen.yml，配置文件样例如下：

variables:
  - name: ip
    type: file
    path: test/ip.txt
  - name: user
    type: file
    path: test/user.txt
  - name: id
    type: sequence
  - name: uuid
    type: uuid
  - name: now_local
    type: now_local
  - name: now_utc
    type: now_utc
  - name: now_unix
    type: now_unix
requests:
  - request:
      method: GET
      basic_auth:
        username: elastic
        password: pass
      url: http://localhost:8000/medcl/_search
      body: '{  "query": {"match": {    "name": "$[[user]]"  }}}'

变量的使用

上面的配置中，variables 用来定义变量参数，根据 name 来设置变量标识，在构造请求的使用 $[[变量名]] 即可访问该变量的值，变量目前支持的类型有：

类型	说明
file	文件型外部变量参数
sequence	自增数字类型的变量
range	数字范围类型的变量，支持参数 from 和 to 来限制范围
uuid	UUID 字符类型的变量
now_local	当前时间、本地时区
now_utc	当前时间、UTC 时区
now_unix	当前时间、Unix 时间戳

file 类型变量参数加载自外部文本文件，每行一个变量参数，访问该变量时每次随机取其中一个，变量里面的定义格式举例如下：

➜  loadgen git:(master) ✗ cat test/user.txt 
medcl
elastic

请求的定义

配置节点 requests 用来设置 Loadgen 将依次执行的请求，支持固定参数的请求，也可支持模板变量参数化构造请求，以下是一个普通的查询请求：

requests:
  - request:
      method: GET
      basic_auth:
        username: elastic
        password: pass
      url: http://localhost:8000/medcl/_search?q=name:$[[user]]

上面的查询对 medcl 索引进行了查询，并对 name 字段执行一个查询，每次请求的值来自随机变量 user。

命令行参数

Loadgen 会循环执行配置文件里面定义的请求，默认 Loadgen 只会运行 5s 就自动退出了，如果希望延长运行时间或者加大并发可以通过启动的时候设置参数来控制，通过查看帮助命令如下：

➜  loadgen git:(master) ✗ ./bin/loadgen --help
Usage of ./bin/loadgen:
  -c int
        Number of concurrent threads (default 1)
  -compress
        Compress requests with gzip
  -config string
        the location of config file, default: loadgen.yml (default "loadgen.yml")
  -d int
        Duration of tests in seconds (default 5)
  -debug
        run in debug mode, loadgen will quit with panic error
  -l int
        Limit total requests (default -1)
  -log string
        the log level,options:trace,debug,info,warn,error (default "info")
  -r int
        Max requests per second (fixed QPS) (default -1)
  -v    version

执行压测

执行 Loadgen 程序即可执行压测，如下:

➜  loadgen git:(master) ✗ ./bin/loadgen -d 30 -c 100 -compress
   __   ___  _      ___  ___   __    __
  / /  /___\/_\    /   \/ _ \ /__\/\ \ \
 / /  //  ///_\\  / /\ / /_\//_\ /  \/ /
/ /__/ \_//  _  \/ /_// /_\\//__/ /\  /
\____|___/\_/ \_/___,'\____/\__/\_\ \/

[LOADGEN] A http load generator and testing suit.
[LOADGEN] 1.0.0_SNAPSHOT, 83f2cb9, Sun Jul 4 13:52:42 2021 +0800, medcl, support single item in dict files
[07-19 16:15:00] [INF] [instance.go:24] workspace: data/loadgen/nodes/0
[07-19 16:15:00] [INF] [loader.go:312] warmup started
[07-19 16:15:00] [INF] [app.go:306] loadgen now started.
[07-19 16:15:00] [INF] [loader.go:316] [GET] http://localhost:8000/medcl/_search
[07-19 16:15:00] [INF] [loader.go:317] status: 200,<nil>,{"took":1,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}
[07-19 16:15:00] [INF] [loader.go:316] [GET] http://localhost:8000/medcl/_search?q=name:medcl
[07-19 16:15:00] [INF] [loader.go:317] status: 200,<nil>,{"took":1,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}
[07-19 16:15:01] [INF] [loader.go:316] [POST] http://localhost:8000/_bulk
[07-19 16:15:01] [INF] [loader.go:317] status: 200,<nil>,{"took":120,"errors":false,"items":[{"index":{"_index":"medcl-y4","_type":"doc","_id":"c3qj9123r0okahraiej0","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":5735852,"_primary_term":3,"status":201}}]}
[07-19 16:15:01] [INF] [loader.go:325] warmup finished

5253 requests in 32.756483336s, 524.61KB sent, 2.49MB received

[Loadgen Client Metrics]
Requests/sec:       175.10
Request Traffic/sec:    17.49KB
Total Transfer/sec: 102.34KB
Avg Req Time:       5.711022ms
Fastest Request:    440.448µs
Slowest Request:    3.624302658s
Number of Errors:   0
Number of Invalid:  0
Status 200:     5253

[Estimated Server Metrics]
Requests/sec:       160.37
Transfer/sec:       93.73KB
Avg Req Time:       623.576686ms

Loadgen 在正式压测之前会将所有的请求执行一次来进行预热，如果出现错误会提示是否继续，预热的请求结果也会输出到终端，执行完成之后会输出执行的摘要信息。

因为 Loadgen 最后的结果是所有请求全部执行完成之后的累计统计，可能存在不准的问题，建议通过打开 Kibana 或者 INFINI Console 的监控仪表板来实时查看 Elasticsearch 的各项运行指标。

模拟批量写入

使用 Loadgen 来模拟 bulk 批量写入也非常简单，在请求体里面配置一条索引操作，然后使用 body_repeat_times 参数来随机参数化复制若干条请求即可完成一批请求的准备，如下：

  - request:
      method: POST
      basic_auth:
        username: test
        password: testtest
      url: http://localhost:8000/_bulk
      body_repeat_times: 1000
      body: "{ \"index\" : { \"_index\" : \"medcl-y4\",\"_type\":\"doc\", \"_id\" : \"$[[uuid]]\" } }\n{ \"id\" : \"$[[id]]\",\"field1\" : \"$[[user]]\",\"ip\" : \"$[[ip]]\",\"now_local\" : \"$[[now_local]]\",\"now_unix\" : \"$[[now_unix]]\" }\n"

限制客户端压力

使用 Loadgen 并设置命令行参数 -r 可以限制客户端发送的每秒请求数，从而评估固定压力下 Elasticsearch 的响应时间和负载情况，如下：

➜  loadgen git:(master) ✗ ./bin/loadgen -d 30 -c 100 -r 100

注意，在大量并发下，此客户端吞吐限制可能不完全准确。

限制请求的总条数

通过设置参数 -l 可以控制客户端发送的请求总数，从而制造固定的文档，修改配置如下：

requests:
  - request:
      method: POST
      basic_auth:
        username: test
        password: testtest
      url: http://localhost:8000/medcl-test/doc2/_bulk
      body_repeat_times: 1
      body: "{ \"index\" : { \"_index\" : \"medcl-test\", \"_id\" : \"$[[uuid]]\" } }\n{ \"id\" : \"$[[id]]\",\"field1\" : \"$[[user]]\",\"ip\" : \"$[[ip]]\" }\n"

每次请求只有一个文档，然后执行 loadgen

./bin/loadgen -config loadgen-gw.yml -d 600 -c 100 -l 50000

执行完成之后，Elasticsearch 的索引 medcl-test 将增加 50000 条记录。

使用自增 ID 来确保文档的顺序性

如果希望生成的文档编号自增有规律，方便进行对比，可以使用 sequence 类型的自增 ID 来作为主键，内容也不要用随机数，如下：

requests:
  - request:
      method: POST
      basic_auth:
        username: test
        password: testtest
      url: http://localhost:8000/medcl-test/doc2/_bulk
      body_repeat_times: 1
      body: "{ \"index\" : { \"_index\" : \"medcl-test\", \"_id\" : \"$[[id]]\" } }\n{ \"id\" : \"$[[id]]\" }\n"

上下文复用变量

在一个请求中，我们可能希望有相同的参数出现，比如 routing 参数用来控制分片的路由，同时我们又希望该参数也保存在文档的 JSON 里面， 可以使用 runtime_variables 来设置请求级别的变量，或者 runtime_body_line_variables 定义请求体级别的变量，如果请求体复制 N 份，每份的参数是不同的，举例如下：

variables:
  - name: id
    type: sequence
  - name: uuid
    type: uuid
  - name: now_local
    type: now_local
  - name: now_utc
    type: now_utc
  - name: now_unix
    type: now_unix
  - name: suffix
    type: range
    from: 10
    to: 15
requests:
  - request:
      method: POST
      runtime_variables:
        batch_no: id
      runtime_body_line_variables:
        routing_no: uuid
      basic_auth:
        username: ingest
        password: password
      #url: http://localhost:8000/_search?q=$[[id]]
      url: http://192.168.3.188:9206/_bulk
      body_repeat_times: 10
      body: "{ \"create\" : { \"_index\" : \"test-$[[suffix]]\",\"_type\":\"doc\", \"_id\" : \"$[[uuid]]\" , \"routing\" : \"$[[routing_no]]\" } }\n{ \"id\" : \"$[[uuid]]\",\"routing_no\" : \"$[[routing_no]]\",\"batch_number\" : \"$[[batch_no]]\", \"random_no\" : \"$[[suffix]]\",\"ip\" : \"$[[ip]]\",\"now_local\" : \"$[[now_local]]\",\"now_unix\" : \"$[[now_unix]]\" }\n"

我们定义了 batch_no　变量来代表一批文档里面的相同批次号，同时又定义了　routing_no　变量来代表每个文档级别的 routing 值。

最后，欢迎大家反馈使用过程遇到的任何问题。

Elasticsearch 系列技术短视频分享持续更新中......   https://space.bilibili.com/471049389   不大不小的视频试水，欢迎大家留言和拍砖！    

在学习 ES 前一般都需要安装 ES，虽然 ES 可以开箱即用，但如果要学习分布式特性的时候，需要安装多个节点，这个时候还是有点工作量的。下面提供两个小脚本，一个是在 Ubuntu 中安装 3 节点的 ES 伪集群，一个是在 docker 中安装3节点 ES 集群。除了安装 ES 外，脚本还提供了对应版本的 Kibana、Cerebro 0.9.4 的安装。

1、在 Ubuntu 中安装 ES 7.13

这里我们采取下载 ES 安装包并且解压安装的方式，并没有走 Ubuntu apt 的方式。ES 的安装非常简单，这里先献上安装脚本。

下面介绍比较重要的配置项：

• discovery.seed_hosts 在开箱即用的情境下（本机环境）无需配置，ES 会自动扫描本机的 9300 到 9305 端口。一旦进行了网络环境配置，这个自动扫描操作就不会执行。discovery.seed_hosts 配置为 master 候选者节点即可。如果需要指定端口的话，其值可以为：["localhost:9300", "localhost:9301"]

• cluster.initial_master_nodes 指定新集群 master 候选者列表，其值为节点的名字列表。如果配置了 node.name: my_node_1，所以其值为 ["my_node_1"]，而不是 ip 列表 ！

• network.host 和 http.port 是 ES 提供服务的监听地址和端口，线上一定不能配置 ip 为 0.0.0.0，这是非常危险的行为！！！

怎么样来理解这个 discovery.seed_hosts 和 cluster.initial_master_nodes 呢？

cluster.initial_master_nodes 是候选者列表，一般我们线上环境候选者的数量比较少，毕竟是用来做备用的。而且这个配置只跟选举 master 有关，也就是跟其他类型的节点没有关系。就算你有100个数据节点，然后经常增加或者剔除都不需要动这个列表。

discovery.seed_hosts 这个可以理解为是做服务或者节点发现的，其他节点必须知道他们才能进入集群~ 一般配置为集群的master 候选者的列表。

但是这些 master 候选者（组织联系人）可能经常变化，那怎么办呢？这个配置项除了支持 ip 外还支持域名 ~所以可以用域名来解决这个问题，其他节点的配置上写的是域名，域名解析到对应的 ip，如果机器挂了，新的节点 ip 换了，就把域名解析到新的ip即可，这样其他节点的配就不用修改了。所以非 master 候选节点要配 discovery.seed_hosts （组织联系人）

除了修改 ES 服务配置外，还需要配置 JVM 的配置，我们主要配置服务占用的堆内存的大小。JVM 配置需要以下几点：

• 这两个 jvm 的配置必须配置一样的数值。启动时就分配好内存空间，避免运行时申请分配内存造成系统抖动。
• Xmx不要超过机器内存的 50%，留下些内存供 JVM 堆外内存使用
• 并且Xmx不要超过 32G。建议最大配置为 30G。接近 32G，JVM 会启用压缩对象指针的功能，导致性能下降。具体可以参考：a-heap-of-trouble。

安装成功后，可以访问： ES：localhost:9211

Kibana: localhost:5601

cerebro： localhost:9800

2、在docker 中安装 ES 7.13

在做一切工作之前，我们必须安装 docker。如果你已经安装好了 docker、docker-compose，可以访问我为你准备的 docker-compose.yaml 文件。

如果你没有安装 docker，完整的教程可以参考在 docker 中安装 ES 文档。

下载此文件，将文件保存为 docker-compose.yaml 后，进入这个文件的目录，执行以下指令即可：

docker-compose up

如果你没有下载镜像文件，docker-compose 会自动帮你下载镜像，并且启动容器。

如果 docker-compose 启动失败，说是无权限链接 docker 的话，其报错如下：

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: 

Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?all=1&filters=%7B%22label%22%3A%7B%22com.docker.compose.project%3Ddocker_es%22%3Atrue%7D%7D&limit=0": 

dial unix /var/run/docker.sock: connect: permission denied

可以运行以下指令临时修改：

sudo chmod 666 /var/run/docker.sock

其原因是因为你的 docker 用了 root 启动了。

最后可以访问：

cerebro：ip:9000

Kibana：ip:5601

Elasticsearch: ip:9200，ip:9202，ip:9203

其他学习资料

创建自己的 ES Docker Image

在 docker image 中安装 Elasticsearch 插件

一个开源的 ELK docker-compose 配置

docker 中安装 ES 7.13

docker 中安装 Kibana 7.13

最后附上我写的小册，欢迎刚入门的朋友来订阅~

本小册分为 4 个部分，将由浅入深为你介绍 Elasticsearch 7.x 中的核心技术。主要知识点包括基本概念、常用 API 的使用实践、核心特性的底层原理与思想、集群管理与调优、源码阅读等知识。整个小册的思维导图如下：

你会学到什么？

本小册将会从非常浅显的概念开始与你学习 Elasticsearch 7.x 中的常用 API，在熟悉使用 Elasticsearch 后，我们将会对 Elasticsearch 中部分重要的特性、概念的底层实现原理进行介绍。在了解这些原理后，我们将学习如何部署、运维线上小规模集群，并且与你一起搭建一个简单的 ELK 系统。最后我们会搭建源码阅读的环境并且与你一起阅读部分模块的源码。

所以，通过本小册 4 大部分的学习，你可以收获：

• 熟练使用 Elasticsearch 来解决搜索需求；
• 强化 Elasticsearch 集群运维、调优的能力；
• 通晓 Elasticsearch 核心技术的底层实现；
• 牢固掌握源码阅读与调试的技巧。

也就是说，学完本课程后，你不仅可以掌握 ElasticSearch 相关的技术，还可以帮助你根据业务的特点快速构建出相应的搜索业务、数据分析、日志系统。真正实现学以致用。

适宜人群

• 对 Elasticsearch 或搜索引擎感兴趣的同学。
• 有了解和使用过 Elasticsearch，现在想进一步了解 Elasticsearch 的同学。
• 准备从事数据搜索、分析相关工作的同学。
• 从事 Elasticsearch 集群运维的同学。

Elasticsearch 在 7.0 之后的版本中，为了优化性能，搜索结果的命中数默认不进行精确的计数统计，同时对搜索结果的响应体进行了调整， 这样势必会造成已有代码的不兼容，如何快速修复呢？

8.x 重要更新

• Rest API相比较7.x而言做了比较大的改动（比如彻底删除_type），为了降低用户的升级成本，8.x会暂时的兼容7.x的请求。兼容方式：

  REST API compatibility | Elasticsearch Guide [8.0] | Elastic

• 默认开启安全配置（三层安全），并极大简化了开启安全需要的工作量，可以这么说：7.x开启安全需要10步复杂的步骤比如CA、证书签发、yml添加多个配置等等，8.x只需要一步即可）。

  elasticsearch-create-enrollment-token | Elasticsearch Guide [8.0] | Elastic

• 存储空间优化：对倒排文件使用新的编码集，对于keyword、match_only_text、text类型字段有效，有3.5%的空间优化提升，对于新建索引和segment自动生效。
• 优化geo_point，geo_shape类型的索引（写入）效率：15%的提升。

• 新特性：支持上传pyTorch模型，在ingest的时候使用。比如在写入电影评论的时候，如果我们想要知道这个评论的感情正负得分，可以使用对应的AI感情模型对评论进行运算，将结果一并保存在ES中。

  Overview | Machine Learning in the Elastic Stack [8.0] | Elastic

• 技术预览版KNN API发布，（K邻近算法），跟推荐系统、自然语言排名相关。之前的KNN是精确搜索，在大数据集合的情况会比较慢，新的KNN提供近似KNN搜索，以提高速度。https://www.elastic.co/guide/en/elasticsearch/reference/8.0/knn-search.html
• 对ES内置索引的保护加强了：elastic用户默认只能读，如果需要写权限的时候，需有allow_restrict_access权限。

• 其他更新

  Elasticsearch breaking changes | Elastic Installation and Upgrade Guide [8.0] | Elastic

Elasticsearch 与SQL-style Join 前篇

1.上下文

Elasticsearch(后面简称ES)作为火热的开源&分布式&Json文档形式的搜索引擎在互联网行业被广泛应用. 作为一种NoSQL数据存储服务, ES的侧重点放在了扩展性(Scalability) 与可用性(Availability)上, 提供了极快的搜索与索引文档能力(省略各种对ES的赞美.....就如同你知道的.....主要提供搜索的能力!) 然而, 来自SQL世界的我们, 日常被各种关系性数据充斥着, 使用ES常常疑惑为什么大量MySql中适用的法则在ES中行不通: 不同于SQL的ES DSL语言风格, 搜到/搜不到想要的结果集, 复杂的聚合分析,众多正在不断演进的新功能与永远记不完的APIs....... 本文不会对ES的基本功能作太多的讲解, 侧重放在了对SQL中的join查询与ES提供的join方案的对比与分析上, 基于本人的实践经验, 提供了数种可行的跨索引关联查询方案

本文分为"前篇"与"后篇" ,分别覆盖了不同的ES中实现SQL-style join的技术方案

2.引子

2.1 建议

• 不要用Mysql上的规则去理解一款NoSql DB(Elastic search)
• Join查询与简单的"向多个索引查询数据"并不等价: join查询体现一个"数据关联",后文将重点描述
• 有时候, 为了达到某些效果, 可能意味着"pay some price" (e.g 空间换时间)

2.2 Join查询

开始正文前, 聊聊什么是join查询, join查询在绝大数情况下是SQL中的概念, SQL-style join查询是体现关系型数据库中"关系"的重要方式, 通过驱动表与被驱动表的字段关联, 表与表之间建立了联系方式, 并可以把多个表中的字段值一起返回到结果集:

• 表与表之间有关联性(由连接字段确定)
• 结果集中体现了这种关联性

看到这....或许你会疑惑为什么在解释join查询时反复强调"关联"二字, 相信你应该熟悉SQL中的笛卡尔积现象, 如果不通过连接字段对数据进行筛选, 那么表与表之间连接后产生的"宽表"的数据量会是一个很恐怖的数字(表A行数X表B行数X表C行数.....以此类推), 业务往往需要对产生的结果集进行二次数据筛选, 最后才能从大量的数据中找到少量感兴趣的信息. 而通过指定SQL-style中的join关联关系(e.g table A.字段1 =tableB.字段1)就能在SQL服务中就完成数据筛选, 并且返回的结果集中体现了这种关联性, 降低了业务上筛选相关的工作量.

作为一款 Nosql 且 Schemaless的数据存储, ElasticSearch没有对数据的结构进行强限制, 对客户端而言,返回的结果集都是由弱类型的json对象组成. ES没有像SQL DB那样做到对join查询的友好支持. 但是数据与数据之间的关联在ES中同样非常重要!(或许在任何数据存储服务中都重要). 本文前后篇通过对比讨论 "denormalization(反范式)" , "应用层join", "ES nested query" ,"ES has parent/child query", "ES服务层join(open distro开源生态下)"这些技术的方式(部分将在后篇描述), 探讨join查询在不同环境下的有效解决方案.

3. 方案

3.0 前言: 需解决的问题

如果需要在ES中实现一个SQL:

select * from tablea a  join tableb b 
on a.field1 =b.field1 order by a.create_time desc

等价查询效果, 并且应用层能通过分页的方式滚动查询到所有数据

3.1 方案一: denormalization(反范式)

这可能是最"直接"的方案了, 通过修改数据模型来“flatten”数据，每个ES文档在被index时就已经有了所需要的全部关联数据.

如果是搭建异构索引场景(可理解为RDS从库), 根据关联关系的不同(1 to N, N to M)索引的文档量最高将会是 2乘以 tablea行数乘以 tableb行数(有点笛卡尔积的感觉). Denormalization通过建立"超级宽"的索引维系了1 to N 或 N to M的关联关系, 应用层与ES不需要做任何join处理, 因为一个文档已经拥有了客户端需要的全部数据(数据层面上已经做到了聚合)

对于平时与关系型数据库打交道的童鞋而言, 建 "超级宽表" 映射的索引与数据冗余可能是一件"非正常"的行为, 第一反应就是数据的冗余与空间资源浪费. 但是这种方案的确是目前广泛使用的建立数据关联关系的解决方案(如同前文说的------不要用Mysql上的规则去理解ES).

3.1.1 优势

• 应用端 & ES端都不需要做任何join操作(一个ES文档有全部客户端想要的数据)
• 分布式环境下因聚合结果集相关操作产生的延迟问题得到有效解决
• 在空间资源足够下, 方案可行性高(至少有信心吼一句"能做到")

  3.1.2 挑战

• 数据的冗余与空间资源浪费(空间换时间)
• 如何梳理业务模型与flatten数据: 关系型数据中通过外键,schema约束, 查询语句(join)等方式建立的关联关系要被体现到ES的索引mapping中
• 应用层(访问ES的服务)需要的编码调整(有些工程会在dao层做统一适配处理)
• 更新操作涉及到的数据大幅度增加: 原本一个涉及单表单行update SQL可能会牵扯到多个文档中的某个字段, 且每个文档占用的空间资源更高
• 新增文档的频率会更高: 理由同上

总结: Denormation方案的通用性高, 并且能够满足快速搜索的需求(最快的查询关联数据的方式), 但是额外的存储资源使用带来的相应开销问题与数据模型梳理上的问题会带来挑战

3.2 方案二: ES SQL join(open distro开源生态)

xpack 增加了有限度的SQL支持

然而...不支持join语法....

安装扩展插件获取更强的SQL支持能力(open distro)

LINK 更为强大的SQL支持(包括join语法) 挑战:

• 额外的ES插件(第三方插件对ES不同版本的兼容性?)
• 业务方调整(语句改为SQL-style, 且要使用open distro提供的JDBC相关依赖)
• open distro是一整套ES工具集(AWS上自带集成)
• 对该产品特性的学习LINK

3.3 方案三: 应用层join

通过应用工程对不同索引的多次访问,在组装结果集的过程中建立数据的关联关系

3.3.1 实现方式

可以仿照MySQL的join实现方式: 例如为了实现

select * from tablea a  join tableb b 
on a.field1 =b.field1 where a.field2 in ('value1','value2','value3') order by a.create_time desc

这句SQL的等效查询

应用层可以:

• 1 选择 tablea 对应的异构索引作为驱动索引, 通过结构化查询, 获取field2 为'value1','value2','value3' 的文档中_id值(N个)
• 2 以文档field1作为连接条件, 从被驱动索引(tableb对应的异构索引)中找到字段field1满足条件( a.field1 =b.field1)的文档
• 3 用获取到的文档拼接结果集返回

如果配合ES terms-lookup 则为:

/**从tablea fetch符合条件的文档集**/
GET tablea/_search
{
  "query": {
    "terms": {
      "field2": [
        "value1",
        "value2",
        "value3"
      ]
    }
  }
}

/**假使仅获得一个文档且_id值为6666**/

GET tableb/_search
{
  "query": {
    "terms": {
      "field1": {
              "index" : "tablea",
                "type" : "_doc",
                "id" : "6666",
                "path" : "field1"
      }
    }
  }
}
/**利用ES terms-lookup进行连接查询**/

以上查询在应用层可用ES high-level-client实现, 数据的拼接,过滤, 循环查询等挑战都需要在应用层克服(难)

3.3.2 该方案面临几个挑战

• 如果文档数过多(被驱动表/驱动表中任意一张表获取的文档过多) -> 内存,网络等资源占用过高
• 应用层join引发的多次请求
• 应用层join引发的ES服务端压力
• 应用层代码的改动: 驱动表的选择, join的实现, 应用层缓存数据的压力...
• 一套稳定的join机制的实现会很复杂......

4. End

本文分为前篇与后篇, 我会在后篇文章中对这些技术进行进一步描述与对比, 并且引入可实践的方案.

原稿作者：Yukai糖在江湖
原稿链接：https://blog.csdn.net/fanduifandui/article/details/117264084

【年度盛会】2021 Elastic 中国开发者大会，来自Elastic、阿里、腾讯、谷歌、字节等业界专家带来的干货分享，精彩内容不容错过，八折购票火热进行中（折扣码: 80OFF），扫码即可报名购票。     【更多演讲嘉宾介绍】 https://conf.elasticsearch.cn/2021/speaker.html 【大会官网】 https://conf.elasticsearch.cn