INFINI Labs 为大家又带来一波产品更新，包括 Gateway v1.10.0、Console v0.8.0、Loadgen v1.5.0、Loadrun v0.1.0，其中 Loadrun 是本次产品更新中首发亮相，它是一个用来批量运行 Loadgen 测试用例的工具。欢迎大家下载体验。

INFINI Gateway v1.10.0

极限网关本次更新如下：

Features

• 配置文件中支持环境变量
• 添加 ratio filter 选项操作，允许立即丢弃请求
• 添加 context_parser filter
• 添加 context_switch filter
• 添加 _sys.* 到请求上下文

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

INFINI Console v0.8.0

本次极限 Console 版本更新主要新增了凭据管理功能，凭据敏感信息使用加密存储。凭据管理可以帮助我们将身份验证信息集中管理，需要用的地方直接引用，提高了身份验证信息的存储安全性。

需要注意的是，如果您是初次安装部署，凭据敏感信息加密密钥在 INFINI Console 安装初始化是自动生成或用户自定义设置。该密钥需要用户妥善保存，如果密钥丢失，当升级 INFINI Console 并且重新初始化系统后，先前保存的凭据信息将无法解密。

在【系统管理】-【凭据管理】列表中可以查询已创建的凭据信息，支持增删查改等基本操作。

更多详情可参考文档（https://www.infinilabs.com/docs/latest/console/reference/system/credential）。

Console 其他功能优化如下：

Improvements

• KV 内存占用优化

Bug fix

• 修复了网关实例列表 CPU 数值显示问题
• 修复了系统服务健康监控错误提示

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

INFINI Loadgen v1.5.0

Elasticsearch 性能压测工具 Loadgen 本次更新如下：

Features

• 新增assert功能，支持对请求返回进行判断
• 新增register功能，支持测试过程中动态注册全局变量
• 新增环境变量功能，配置文件可以动态加载环境变量
• 请求头配置支持访问动态变量

Improvements

• 优化 -l 参数的准确性
• 支持可选跳过 warm-up 阶段

下载地址：https://release.infinilabs.com/loadgen

INFINI Loadrun v0.1.0

Loadrun 是一个用来批量运行 Loadgen 测试用例的工具，不需要重复编写测试用例，通过切换套件配置来快速测试不同的环境配置。

Features

• 支持配置测试套件，批量运行 Loadgen 测试样例并输出测试结果
• 支持测试套件配置 Loadgen 环境变量，快速切换测试环境
• 支持自动启动 INFINI Gateway，方便测试不同配置

下载地址：https://release.infinilabs.com/loadrun

期待反馈

欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 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）致力于打造极致易用的数据探索与分析体验。

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

大会简介

大会亮点

• 专家主题演讲
• 北京智源人工智能研究院、北京大学、百度等启智社区核心成员单位各自的优秀开源项目分享
• 2022年度优秀开源项目团队及社区优秀开发者颁奖
• 设立八个国家级开放创新平台合作签约
• 启智社区分中心授牌
• 《中国城市人工智能发展指数报告》发布
• 为开发者分享各类前沿动态与实践学习的机会
• 直面各厂商技术专家，获取一线面试经验/机会，还可进入招聘内推面试群
• 有望于行业大咖合影
• 结识志同道合的行业伙伴，组织头脑风暴，产生更多思想碰撞

大会主题

• 算网筑基、开源启智、AI赋能

大会信息

日程安排

组织架构

展望未来

原文地址 elasticstack.blog.csdn.net

路由文件

当应用程序需要向 Elasticsearch 添加文档时，它们首先要知道目标索引是什么。在很多的应用案例中，特别是针对时序数据，我们想把每个月的数据写入到一个特定的索引中。一方面便于管理索引，另外一方面在将来搜索的时候可以按照每个月的索引来进行搜索，这样速度更快，更便捷。

当你处于某种类型的文档总是转到特定索引的琐碎情况时，这似乎很明显，但当你的索引名称可能根据杂项参数（无论它们是否在你的系统外部 - 当前例如日期 - 或者你尝试存储的文档的固有属性 - 大多数时候是文档字段之一的值）。

当发生最后一种情况时（我们指的是索引名称可以变化的情况），在向 Elasticsearch 发出索引命令之前，你的应用程序需要计算目标索引的名称。

此外 —— 即使一开始这看起来像是一种反模式 —— 你可以有多个应用程序需要在索引中索引相同类型的文档，这些文档的名称可能会发生变化。 现在你必须维护跨多个组件重复的索引名称计算逻辑：就可维护性和敏捷性而言，这不是好消息。

Logstash —— Elastic Stack 的一个知名成员 —— 可以帮助集中这样的逻辑，但代价是维护另一个正在运行的软件，这需要配置、知识等。

我们想要在本文中展示的是通过将索引名称计算委托给 Elasticsearch 而不是我们的应用程序来解决此问题的解决方案。

Date index name processor 介绍

该处理器的目的是通过使用日期数学索引名称支持，根据文档中的日期或时间戳字段将文档指向基于正确时间的索引。

处理器根据提供的索引名称前缀、正在处理的文档中的日期或时间戳字段以及提供的日期舍入，使用日期数学索引名称表达式设置 _index 元数据字段。

首先，此处理器从正在处理的文档中的字段中获取日期或时间戳。 或者，可以根据字段值应如何解析为日期来配置日期格式。 然后这个日期、提供的索引名称前缀和提供的日期舍入被格式化为日期数学索引名称表达式。 此处还可以选择日期格式指定日期应如何格式化为日期数学索引名称表达式。

将文档指向每月索引的示例管道，该索引以基于 date1 字段中的日期的 my-index-prefix 开头：

1.  PUT _ingest/pipeline/monthlyindex
2.  {
3.    "description": "monthly date-time index naming",
4.    "processors" : [
5.      {
6.        "date_index_name" : {
7.          "field" : "date1",
8.          "index_name_prefix" : "my-",
9.          "date_rounding" : "M"
10.        }
11.      }
12.    ]
13.  }

使用该管道进行索引请求：

1.  PUT /my-index/_doc/1?pipeline=monthlyindex
2.  {
3.    "date1" : "2016-04-25T12:02:01.789Z"
4.  }

上面命令运行的结果是：

1.  {
2.    "_index": "my-index-2016-04-01",
3.    "_id": "1",
4.    "_version": 1,
5.    "result": "created",
6.    "_shards": {
7.      "total": 2,
8.      "successful": 1,
9.      "failed": 0
10.    },
11.    "_seq_no": 0,
12.    "_primary_term": 1
13.  }

上面的请求不会将这个文档索引到 my-index 索引中，而是索引到 my-index-2016-04-01 索引中，因为它是按月取整的。 这是因为 date-index-name-processor 覆盖了文档的 _index 属性。

要查看导致上述文档被索引到 my-index-2016-04-01 中的实际索引请求中提供的索引的日期数学（date-math）值，我们可以使用模拟请求检查处理器的效果。

1.  POST _ingest/pipeline/_simulate
2.  {
3.    "pipeline" :
4.    {
5.      "description": "monthly date-time index naming",
6.      "processors" : [
7.        {
8.          "date_index_name" : {
9.            "field" : "date1",
10.            "index_name_prefix" : "my-",
11.            "date_rounding" : "M"
12.          }
13.        }
14.      ]
15.    },
16.    "docs": [
17.      {
18.        "_source": {
19.          "date1": "2016-04-25T12:02:01.789Z"
20.        }
21.      }
22.    ]
23.  }

上面命令返回结果：

`

1.  {
2.    "docs": [
3.      {
4.        "doc": {
5.          "_index": "<my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>",
6.          "_id": "_id",
7.          "_version": "-3",
8.          "_source": {
9.            "date1": "2016-04-25T12:02:01.789Z"
10.          },
11.          "_ingest": {
12.            "timestamp": "2023-02-23T01:15:52.214364Z"
13.          }
14.        }
15.      }
16.    ]
17.  }

`![](https://csdnimg.cn/release/blogv2/dist/pc/img/newCodeMoreWhite.png)

以上示例显示 _index 设置为 <my-index-{2016-04-25||/M{yyyy-MM-dd|UTC}}>。 Elasticsearch 将其理解为 2016-04-01，如日期数学索引名称文档中所述。

日期索引名称选项

以下是使用 date index name 的一些选项

使用案例 - 基于时间的时序索引

这是一个众所周知的用例，通常在您要处理日志时发现。这个想法是索引文档，索引的名称由根名称和根据日志事件的日期计算的值组成。 该日期实际上是你要索引的文档的一个字段。

这不是本文的重点，但以这种方式索引文档有几个优点，包括更容易的数据管理、启用冷/暖架构等。让我们举个例子。

假设我们必须处理来自多个来源的数据 —— 例如物联网。 我们的每个对象每分钟都会向不同的后端发送一些数据（是的，这真的很可悲，但我们的对象不通过相同的网络进行通信，因此选择通过多个系统来处理这个问题）。

对象发送的数据被转换成如下所示的 JSON 文档：

1.  POST data/_doc?pipeline=compute-index-name
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

我们有一个用于传输数据的对象的 UID、一个制造商 ID、一个有效负载部分和一个日期字段。

索引名称计算

假设我们要将对象的数据存储在名为 data-{YYYYMMDD} 的索引中，其中根名称是数据后跟日期模式。基于上面的例子，后端收到这个文档应该怎么办呢？

首先它必须解析它以提取日期字段的值，然后它必须根据它在文档中找到的日期计算目标索引名称。 最后，它向 Elasticsearch 向刚刚计算出名称的索引发出索引请求。

1.  document.date = "2019-04-01T12:10:30Z"
2.  index.name = "" + "20190401"

在我们的例子中，我们有几个后端必须知道如何计算索引名称，因此必须知道索引的命名逻辑。

如果索引名的计算直接由 Elasticsearch 进行，岂不是更聪明？

Ingest pipeline 的力量

从 Elasticsearch 的第 5 版开始，我们现在有了一种称为摄取的节点。默认情况下，集群的所有节点都具有 ingest 类型。这些节点有权在索引文档之前执行所谓的管道。 管道是一组处理器，每个处理器都可以以某种特定方式转换输入文档。当一个文档被摄入到 Elasticsearch 集群时，它的工作流是这样的。

从上面，我们可以看出来，在文档被写入之前，它必须经过 ingest node 进行处理。我们可以通过 date index name processor 来获得我们想要的 index 名称，进而写入到我们想要的索引中去。 这里有用的是，管道不仅可以转换文档的固有数据，还可以修改文档元数据，特别是它的 _index 属性。

现在让我们回到我们的例子。我们建议定义一个管道来完成这项工作，而不是将索引名称计算委托给应用程序。根据文档，此处理器允许你定义包含日期的字段名称、索引的根名称（前缀）以及计算附加到此前缀的日期的舍入方法。

如果我们想将 IoT 数据添加到模式为 data-{YYYYMMDD} 的索引中，我们只需创建如下所示的管道：

1.  PUT _ingest/pipeline/compute-index-name
2.  {
3.    "description": "Set the document destination index by appending a prefix and its 'date' field",
4.    "processors": [
5.      {
6.        "date_index_name": {
7.          "field": "date",
8.          "index_name_prefix": "",
9.          "date_rounding": "d",
10.          "index_name_format": "yyyyMMdd"
11.        }
12.      }
13.    ]
14.  }

一个索引 = 一个管道？

好的，现在我们知道如何定义一个管道来为特定的目标索引建立一个名称。 但是我们可以通过操纵文档元数据来做更多的事情！

假设我们有不同类型的文档，每个文档都有一个日期字段，但需要在不同的索引中进行索引。计算目标索引名称的逻辑对于每种文档类型都是相同的，但使用上述策略将导致创建多个管道。

让我们试着做一些更简单和可重用的东西。

回到我们的示例，我们现在有两种文档类型：一种需要在 adata-{YYYYMMDD} 索引（和以前一样）中建立索引，另一种其目的地是名为 new_data-{YYYYMMDD} 的索引。

目标为 new_data 的文档具有以下结构：

1.  {
2.    "newObjectId": 1234,
3.    "source": "HYDRA",
4.    "payload": "some_data",
5.    "date": "2019-04-02T13:10:30.000Z"
6.  }

该结构与标准 IoT 文档略有不同，但重要的是日期字段存在于两个映射中。

现在我们要定义一个管道来计算我们两种文档类型的目标索引。 我们所要做的就是通过分析通过索引 API 发出的请求目的地来构建目的地索引名称。

1.  PUT _ingest/pipeline/compute-index-name
2.  {
3.    "description": "Set the document destination index by appending the requested index and its 'date' field",
4.    "processors": [
5.      {
6.        "date_index_name": {
7.          "field": "date",
8.          "index_name_prefix": "{{ _index }}-",
9.          "date_rounding": "d",
10.          "index_name_format": "yyyyMMdd"
11.        }
12.      }
13.    ]
14.  }

请注意，索引名称前缀现在位于名为_index 的索引元数据字段中。 通过使用这个字段，我们的管道现在是通用的并且可以与任何索引一起使用 —— 假设目标索引是根据相同的规则计算的。

使用我们的 “路由” 管道

现在我们有了一个能够根据文档的日期字段计算目标索引名称的通用管道，让我们看看如何让 Elasticsearch 使用它。

我们可以通过两种方式告诉 Elasticsearch 使用管道，让我们评估一下。

Index API 调用

第一个 —— 也是直接的解决方案——是使用 Index API 的管道参数。

换句话说：每次你想索引一个文档，你必须告诉 Elasticsearch 要使用的管道。

1.  POST data/_doc?pipeline=compute-index-name
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

现在，每次我们通过指示 compute-index-name 管道将文档添加到索引中时，该文档将被添加到正确的基于时间的索引中。 在此示例中，目标索引将为 data-20190401 。

我们提供给 Index API 的 data 索引名称呢？ 它可以被看作是一个假索引：它只是用来执行 API 调用并且是真正目标索引的根，它不一定存在！

默认管道：引入 “虚拟索引”

索引默认管道（default pipeline）是使用管道的另一种有用方式：当你创建索引时，有一个名为 index.default_pipeline 的设置可以设置为管道的名称，只要你将文档添加到相应的索引就会执行该管道并且没有管道被添加到 API 调用中。 你还可以在索引文档时使用特殊管道名称 _none 来绕过此默认索引。 通过使用此功能，你可以定义我称之为 “虚拟索引” 的内容，并将其与默认管道相关联，该默认管道将充当我们上面看到的路由管道。

让我们将其应用到我们的示例中。

我们假设我们的通用路由管道 compute-index-name 已经创建。 我们现在可以创建一个名为 data 的索引，它将使用此管道作为其默认管道。

1.  PUT data
2.  {
3.    "settings" : {
4.      "index" : {
5.        "number_of_shards" : 3, 
6.        "number_of_replicas" : 1,
7.        "default_pipeline" : "compute-index-name"
8.      }
9.    }
10.  }

现在，每次我们要求 Elasticsearch 为数据索引中的文档编制索引时，计算索引名称管道将负责该文档的实际路由。 因此，数据索引中永远不会有单个文档被索引，但我们将调用管道的责任完全委托给 Elasticsearch。

运行完上面的命令后，我们来尝试写入一个文档：

1.  POST data/_doc
2.  {
3.    "objectId": 1234,
4.    "manufacturer": "SHIELD",
5.    "payload": "some_data",
6.    "date": "2019-04-01T12:10:30.000Z"
7.  }

上面的命令返回的结果是：

1.  {
2.    "_index": "data-20190401",
3.    "_id": "2DMGfIYBaog4blQ55Qr7",
4.    "_version": 1,
5.    "result": "created",
6.    "_shards": {
7.      "total": 2,
8.      "successful": 1,
9.      "failed": 0
10.    },
11.    "_seq_no": 1,
12.    "_primary_term": 1
13.  }

结论

我们刚刚在这里看到了如何利用 Elasticsearch 中的管道功能根据文档的固有属性来路由文档。Ingest pipeline 不仅仅可以替代 Logstash 过滤器：你可以定义复杂的管道，使用多个处理器（一个特定的处理器甚至允许你调用另一个管道）、条件等。有关 ingest pipeline 的更多文章，请参阅 “Elastic：开发者上手指南” 文章中的 “Ingest pipeline” 章节。

在我看来，本文末尾看到的 “虚拟索引” 非常有趣。 包含创建这样一个并非真正的索引的索引只是为了创建路由管道的入口点的功能甚至可以成为 Elasticsearch 的一个新的和有用的功能，为什么不呢？