背景

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不会被清理，导致恢复/迁移速度急剧下降...目前各个版本也没什么好的解决方式。

• 一次使用多台计算机（形成一个集群），以便它可以并行处理数据，从而更快地完成工作。我们可以这样想。如果一台服务器需要处理 100 TB 的数据，它可能会在 500 小时内完成。但是如果我们有 100 台服务器，每台只能取一部分数据，例如 server1 可以取第一个 TB，server2 可以取第二个 TB，以此类推。现在他们每个人都只有 1 TB 的数据要处理，而且他们都可以同时处理自己的数据部分。这样，工作可以在 5 小时内完成，而不是 500 小时。当然，这是理论上的和想象的，因为在实践中我们不会减少 100 倍所需的时间，但我们可以非常接近如果条件理想。
• 在需要时可以很容易地调整计算能力。有更多的数据要处理，而问题要复杂得多？将更多计算机添加到集群。从某种意义上说，这就像在超级计算机上增加了更多的 CPU 内核。
• 数据不断增长，因此 Hadoop 也必须能够轻松灵活地扩展其存储容量，以满足需求。我们添加到集群的每台计算机都会扩展 Hadoop 分布式文件系统 (HDFS) 的可用总存储空间。
• 与其他软件不同，它不仅会在硬件故障发生时尝试从硬件故障中恢复。设计理念实际上假设某些硬件肯定会失败。当有数千台计算机并行工作时，可以保证某处某处会不时出现故障。因此，默认情况下，Hadoop 创建数据块的副本并将它们分布在单独的硬件上，因此当偶尔的服务器起火或硬盘或 SSD 死机时，不会丢失任何内容。

• 当我们需要从数十亿个网站中提取数据时，就像谷歌这样的搜索引擎所做的那样，我们会发现像 Elasticsearch 及 Hadoop 这样的工具非常有用和高效。
• 当我们需要以这样一种方式存储数据并对其进行索引以便以后可以快速有效地搜索时，我们会发现像 Elasticsearch 这样的东西非常有用。
• 最后，当我们想要收集实时数据时，例如来自互联网上许多交易所的美元/欧元价格，我们会发现像 Logstash 这样的工具非常适合这项工作。

1. 目前大会报名购票通道已重新开启，欢迎有兴趣的朋友报名参会，已经报名参会者无需再次报名。报名链接：https://www.bagevent.com/event/7899116
2. 如需要加入本次大会微信交流群，请加微信(lsy965145175)拉群。
3. 更多大会资讯请关注官网：https://conf.elasticsearch.cn

2022国际开源节（IOSF）由OSTech联合中国信息通信研究院、Linux基金会亚太区发起策划，在ELEXCON深圳国际电子展暨嵌入式系统展落地，并聚集了包括中国科学院软件研究所、CNCF、LF AI & Data、LFOSSA、LF Edge、O3DF、OpenSSF、Hyperledger基金会等国际一流开源基金会和机构，GDG、开源中国等全球知名开发者社区，以及上海开源信息技术协会等权威开源机构的共建支持。
国际开源节旨在汇聚全球开源技术与项目，融合国际文化、开源社区生态和开源产业发展，构建“共创共赢”的开源文化，打造中国开源新生态。
2022国际开源节（IOSF）将同期举办前沿技术峰会，主题涵盖“国际开源教育与人才培养论坛”、“OpenSSF开源安全中国峰会”、“Kubernetes on AI & Edge ”、“Hyperledger超级账本峰会” 、“CNCF云原生论坛”、“开源投融资论坛 ”、“高校学术开源峰会”、“O3DF元宇宙论坛”，敬请期待！

合作联系

参展合作（微信同步）
Tony,13713437040；
Friday，17612060999；
宣传合作（微信同步）
Cindy,13553827402；
Katharine,13512772116；

背景

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 中发起讨论，或通过邮件列表进行交流。