搜索客，搜索人自己的社区

【搜索客社区日报】第2044期 (2025-05-27）

社区日报 • God_lockin 发表了文章 • 0 个评论 • 4040 次浏览 • 2025-05-27 13:37 • 来自相关话题

【搜索客社区日报】第2043期 (2025-05-22）

社区日报 • Se7en 发表了文章 • 0 个评论 • 4750 次浏览 • 2025-05-22 16:32 • 来自相关话题

【搜索客社区日报】第2042期 (2025-05-21）

社区日报 • kin122 发表了文章 • 0 个评论 • 4873 次浏览 • 2025-05-21 14:34 • 来自相关话题

【直播活动】全面解析 Coco AI，一款完全开源、跨平台的企业级智能搜索与助手系统

活动 • INFINI Labs 小助手发表了文章 • 0 个评论 • 5375 次浏览 • 2025-05-20 23:46 • 来自相关话题

在 AI 浪潮中，如何高效管理海量信息、实现智能搜索与知识共享，已成为个人与企业共同面临的挑战。Coco AI —— 一款完全开源、跨平台的企业级智能搜索与助手系统，成为面对这一挑战的利器。

Coco AI 能够轻松连接本地文件数据源、S3 对象存储、Google Workspace、Dropbox、GitHub、Notion、Yuque、Hugo 等多种数据源，实现本地与云端数据的统一搜索与管理。无论是文档、代码、项目管理工具，还是团队协作平台，Coco AI 都能一键整合，让企业数据 “化零为整”，彻底打破信息孤岛的束缚。

Coco AI 采用了 RAG 技术，结合传统检索和生成模型的优势，提供基于内容检索的生成式答案。它不仅能够精准匹配关键词，还能基于实际内容生成详细且高质量的回答。

这个开源搜索工具背后的公司，是国内一家初创企业 —— 极限科技 / INFINI Labs。其创始人兼 CEO 曾勇现正带领团队专注于下一代实时搜索引擎与 AI 智能搜索相关技术的研发与创新。

5 月 23 日，极限科技 / INFINI Labs 创始人兼 CEO 曾勇、高级解决方案架构师杨帆将做客开源中国《技术领航》栏目直播间，全面解析 Coco AI ，探索其核心功能、技术架构及实际应用场景。

值得期待的是，直播中还将详解如何用 Coco AI 打造 Elasticsearch 智能助手，解决版本查询、问题排查、DSL/API 支持等痛点问题。

🔥 微信扫码，预约直播：

![](https://infinilabs.cn/img/blog ... er.jpg)

🔥 直播亮点：

功能与价值解析

如何通过 Coco AI 实现多源数据（本地文件、云端存储、Notion、语雀等）的智能化统一搜索与知识管理。
开源架构与 AI 技术（RAG、大模型集成）如何提升搜索精度与知识管理效率。

应用场景实战
Demo 演示：展示 Coco AI 如何快速构建企业级知识库，打破信息孤岛。
ES 智能助手案例：详解如何用 Coco AI 打造 Elasticsearch 智能助手，解决版本查询、问题排查、DSL/API 支持等痛点。

开源生态与未来展望
社区驱动的开源生态如何推动 Coco AI 持续创新。
下一代 AI 搜索工具的发展趋势与 Coco AI 的长期规划。

本次直播中的另一名分享嘉宾杨帆，技术十分过硬，拥有十余年金融行业服务工作经验，是《[老杨玩搜索](https://space.bilibili.com/117 ... season)》栏目 B 站 UP 主，熟悉 Linux、数据库、网络等领域。目前主要从事 Easysearch、Elasticsearch 等搜索引擎的技术支持工作，服务国内私有化部署的客户。

大家有什么问题，可以在直播间互动提问～

关于开源中国

[OSCHINA（开源中国）](https://www.oschina.net/) 成立于 2008 年 8 月，经过 17 年的深耕，已发展成为中国最大的开源与 AI 技术社区之一，拥有超过 1100 万的注册用户。自成立以来，OSCHINA 始终致力于为开发者提供专业服务，推动中国开源领域的快速发展。在早期，OSCHINA 建立了完善的开源软件分类数据库，收录了全球超过 12 万个知名项目，涵盖数百个不同的分类。社区为中国开发者提供最新的开源资讯、软件更新信息，以及技术分享和交流的平台，成为国内领先的开源技术交流社区。

关于 INFINI Labs

极限科技，专业的开源搜索与实时数据分析整体解决方案提供商。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。

官网：<https://infinilabs.cn>;

关于 Coco AI

Coco AI 是一个完全开源、跨平台的统一搜索与效率工具，能够连接并搜索多种数据源，包括应用程序、文件、谷歌网盘、Notion、语雀、Hugo 等本地与云端数据。通过接入 DeepSeek 等大模型，Coco AI 实现了智能化的个人知识库管理，注重隐私，支持私有部署，帮助用户快速、智能地访问信息。

项目主页：<https://coco.rs>;

Gitee：<https://gitee.com/infinilabs/coco-app>;
GitCode：<https://gitcode.com/infinilabs/coco-app>;
Github：<https://github.com/infinilabs/coco-app>;

快来 ⭐️ Star 支持 Coco AI 吧 ~

原文：https://my.oschina.net/u/3859945/blog/18434727

【搜索客社区日报】第2040期 (2025-05-20）

社区日报 • God_lockin 发表了文章 • 0 个评论 • 4786 次浏览 • 2025-05-20 14:01 • 来自相关话题

ES 调优帖：关于索引合并参数 index.merge.policy.deletePctAllowed 的取值优化

Elasticsearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 5593 次浏览 • 2025-05-18 22:08 • 来自相关话题

最近发现了 lucene 9.5 版本把 merge 策略的默认参数改了。

```

GITHUB#11761: TieredMergePolicy now allowed a maximum allowable deletes percentage of down to 5%, and the default
maximum allowable deletes percentage is changed from 33% to 20%. (Marc D'Mello)
`` 也就是index.merge.policy.deletePctAllowed` 最小值可以取 5%（原来是 20%），而默认值为 20%（原来是 33%）。

这是一个控制索引中已删除文档的占比的参数，简单来说，调低这个参数能够降低存储大小，同时也需要更多的 cpu 和内存资源来完成这个调优。

通过这个[帖子](https://github.com/apache/lucene/issues/11761)的讨论，大家可以发现，“实践出真知”，这次的参数调整是 lucene 社区对于用户积极反馈的采纳。因此，对于老版本的用户，也可以在 deletepct 比较高的场景下，调优这个参数，当然一切生产调整都需要经过测试。

对于 ES 的新用户来说，这时候可能冒出了下面这些问题
这个参数反馈的已删除文档占比 deletepct 是什么？
它怎么计算的呢？较高的 deletepct 会有什么影响？
较低的 deletepct 为什么会有更多的资源消耗？
除了调优这个参数还有什么优化办法么？

伴随这些问题，来探讨一下这个参数的来源和作用。

deletePctAllowed：软删除的遗留

在 Lucene 中，软删除是一种标记文档以便后续逻辑删除的机制，而不是立即从索引中物理删除文档。

但是这些软删除文档又不是永久存在的，deletePctAllowed 表示索引中允许存在的软删除文档占总文档数的最大百分比。

当软删除文档的比例达到或超过 deletePctAllowed 所设定的阈值时，Lucene 会触发索引合并操作。这是因为在合并过程中，那些被软删除的文档会被物理地从索引中移除，从而减少索引的存储空间占用。

当 deletePctAllowed 设置过低时，会频繁触发索引合并，因合并操作需大量磁盘 I/O、CPU 和内存资源，会使写入性能显著下降，磁盘 I/O 压力增大。假设 deletePctAllowed 为 0，则每次写入都需要消耗额外的资源来做 segment 的合并。

deletePctAllowed 过高，索引会容纳大量软删除文档，占用过多磁盘空间，增加存储成本且可能导致磁盘空间不足。查询时要过滤大量软删除文档，使查询响应时间变长、性能下降。同时也观察到，在使用 soft-deleted 特性后，文档更新和 refresh 也会受到影响，deletePctAllowed 过高，文档更新/refresh 操作耗时也会明显上升。

deletePctAllowed 的实际效果

从上面的解释看，index.merge.policy.deletePctAllowed 这个参数仿佛并不难理解，但实际上这个参数是应用到各个 segment 级别的，并且 segment 对这个参数的触发条件也是有限制（过小的 segment 并不会因为这个参数触发合并操作）。在多分片多 segment 的条件下，索引对 deletePctAllowed 参数实际的应用效果并不完全一致。因此，可以做个实际测试来看 deletePctAllowed 对索引产生的效果。

这里创建一个一千万文档的索引，然后全量更新一遍，看最后 deletePctAllowed 会保留多少的被删除文档。

```
GET test_del/_count
{
"count": 10000000,
"_shards": {
"total": 1,
"successful": 1,
"skipped": 0,
"failed": 0
}
}

查看 delete 文档数量

GET test_del/_stats
···
"primaries": {
"docs": {
"count": 10000000,
"deleted": 0
},
···

 这里的 deletePctAllowed 还是使用的 33%。 ![](<a href="https://infinilabs.cn/img/blog/2025/index-merge-policy-deletepctallowed/delpct-1.pn" rel="nofollow" target="_blank">https://infinilabs.cn/img/blog ... -1.pn</a>g) 更新任务命令： 
POST test_del/_update_by_query?wait_for_completion=false
{
"query": {
"match_all": {}
},
"script": {
"source": "ctx._source.field_name = 'new_value'",
"lang": "painless"
}
}
 完成后， 

任务状态

···
"task": {
"node": "28HymM3xTESGMPRD3LvtCg",
"id": 10385666,
"type": "transport",
"action": "indices:data/write/update/byquery",
"status": {
"total": 10000000,
"updated": 10000000,# 这里可以看到全量更新
"created": 0,
"deleted": 0,
"batches": 10000,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1,
"throttled_until_millis": 0
}
···

索引的状态

GET test_del/_stats
···
"_all": {
"primaries": {
"docs": {
"count": 10000000,
"deleted": 809782
},
···
 实际删除文档与非删除文档的比例为 8.09%。 现在尝试调低 `index.merge.policy.deletes_pct_allowed`到 20%。 
PUT test_del/_settings
{"index.merge.policy.deletes_pct_allowed":20}

 由于之前删除文档占比过低，调整参数并不会触发新的 merge，因此需要重新全量更新数据查看一下是否有改变。 最终得到的索引状态如下： 
GET test_del/_stats
···
"primaries": {
"docs": {
"count": 10000000,
"deleted": 190458
}
···
```

这次得到的实际删除文档与非删除文档的比例为 1.9%

deletes_pct_allowed 默认值的调整

上面提到 deletePctAllowed 设置过低时，会频繁触发索引合并，而合并任务的线程使用线程类型是 SCALING 的，是一种动态扩展使用 cpu 的策略。

![](https://infinilabs.cn/img/blog ... -2.png)

那么，当 deletePctAllowed 设置过低时，merge 任务增加，cpu 线程使用增加。集群的 cpu 和磁盘的使用会随着写入增加，deletePctAllowed 降低产生了放大效果。

所以，在没有大量数据支撑的条件下，ES 的使用者们往往会选择业务低峰期使用 forcemerge 来降低文档删除比，因为 forcemerge 的线程类型是 fixed，并且为 1，对 cpu 和磁盘的压力更加可控，同时 forcemerge 的 deletePctAllowed 默认阈值是 10%，更加低。

而社区中，大家的实际反馈则更倾向使用较低的 deletePctAllowed 阈值，特别是小索引小写入的情况下。

![](https://infinilabs.cn/img/blog ... -3.png)

并且提供了相应的[测试结果](https://github.com/opensearch- ... s/7360)

```

RUN 1

Test config:
Single node domain
Instance type: EC2 m5.4xlarge
Updates: 50% of the total request

Baseline:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "33.0"
Target:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "20.0"

| Metrics | Baseline | Target |
------------------------------------
| Store size | 39gb | 37gb |
| Deleted docs percent | 22% | 18% |
| Avg. CPU | (42 - 53)% | (43 - 55)% |
| Write throughput | 11 - 15 mbps | 11 - 17 mbps |
| Indexing latency | 0.15 - 0.36 ms | 0.15 - 0.39 ms |
| P90 search latency | 14.9 ms | 13.2 ms |
| P90 term query latency | 13.7 ms | 13.5 ms |

RUN 2

Test config:
Single node domain
Instance type: EC2 m5.4xlarge
Updates: 75% of the total request

Baseline:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "33.0"
Target:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "20.0"

| Metrics | Baseline | Target |
------------------------------------
| Store size | 19.4gb | 17.7gb |
| Deleted docs percent | 22.8% | 15% |
| Avg. CPU | (43 - 53)% | (46 - 53)% |
| Write throughput | 9 - 14.5 mbps | 10 - 15.9 mbps |
| Indexing latency | 0.14 - 0.33 ms | 0.14 - 0.28 ms |
| P90 search latency | 15.9 ms | 13.5 ms |
| P90 term query latency | 15.7 ms | 13.9 ms |

RUN 3

Test config:
Single node domain
Instance type: EC2 m5.4xlarge
Updates: 80% of the total request

Baseline:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "33.0"
Target:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "20.0"

| Metrics | Baseline | Target |
------------------------------------
| Store size | 15.9gb | 14.6gb |
| Deleted docs percent | 24% | 18% |
| Avg. CPU | (46 - 52)% | (47 - 52)% |
| Write throughput | 9 - 13 mbps | 10 - 15 mbps |
| Indexing latency | 0.14 - 0.28 ms | 0.13 - 0.26 ms |
| P90 search latency | 15.3 ms | 13.6 ms |
| P90 term query latency | 15.2 ms | 13.4 ms |

RUN 4

Test config:
Single node domain
Instance type: EC2 m5.2xlarge
Updates: 80% of the total request

Baseline:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "33.0"
Target:
OS_2.3
"index.merge.policy.deletes_pct_allowed" : "20.0"

| Metrics | Baseline | Target |
------------------------------------
| Store size | 21.6gb | 17.8gb |
| Deleted docs percent | 30% | 18% |
| Avg. CPU | (71 - 89)% | (83 - 90)% |
| Write throughput | 6 - 12 mbps | 10 - 15 mbps |
| indexing latency | 0.21 - 0.30 ms | 0.20 - 0.31 ms |
| P90 search latency | 15.4 ms | 16.3 ms |
| P90 term query latency | 15.4 ms | 14.8 ms |

```

在测试中给出的结论是：
1. CPU 和 IO 吞吐量没有明显增加。
2. 由于索引中删除的文档数量较少，搜索延迟更少。
3. 减少被删除文档占用的磁盘空间浪费
 
 但是也需要注意，这里的测试索引和消耗资源并不大，有些业务量较大的索引还是需要重新做相关压力测试。
 
 另一种调优思路
 
 那除了降低 deletePctAllowed 和使用 forcemerge，还有其他方法么？
 
 这里一个[pr](https://github.com/apache/lucene/pull/92)，提供一个综合性的解决方案，作者把两个 merge 策略进行了合并，在主动合并的间隙添加 forcemerge 检测方法，遇到可执行的时间段（资源使用率低），主动发起对单个 segment 的 forcemerge，这里 segment 得删选大小更加低，这样对 forcemerge 的任务耗时也更低，最终减少索引的删除文档占比。
 
 简单的理解就是，利用了集群资源的“碎片时间”去完成主动的 forcemerge。也是一种可控且优质的调优方式。
 
 关于极限科技（INFINI Labs）
 
 ![INFINI Labs](https://infinilabs.cn/img/blog ... bs.png)
 
 极限科技，全称极限数据（北京）科技有限公司，是一家专注于实时搜索与数据分析的软件公司。旗下品牌极限实验室（INFINI Labs）致力于打造极致易用的数据探索与分析体验。
 
 极限科技是一支年轻的团队，采用天然分布式的方式来进行远程协作，员工分布在全球各地，希望通过努力成为中国乃至全球企业大数据实时搜索分析产品的首选，为中国技术品牌输出添砖加瓦。
 
 官网：<https://infinilabs.cn>;
 
 作者：金多安，极限科技（INFINI Labs）搜索运维专家，Elastic 认证专家，搜索客社区日报责任编辑。一直从事与搜索运维相关的工作，日常会去挖掘 ES / Lucene 方向的搜索技术原理，保持搜索相关技术发展的关注。
 原文：https://infinilabs.cn/blog/202 ... owed/

面对refresh_interval，ES 的更新机制应该期待怎么的行为？

贡献

Elasticsearch • kin122 回复了问题 • 2 人关注 • 1 个回复 • 5595 次浏览 • 2025-05-21 14:40 • 来自相关话题

【搜索客社区日报】第2039期 (2025-05-16）

社区日报 • Fred2000 发表了文章 • 0 个评论 • 5007 次浏览 • 2025-05-16 11:24 • 来自相关话题

【搜索客社区日报】第2038期 (2025-05-15）

社区日报 • Se7en 发表了文章 • 0 个评论 • 4633 次浏览 • 2025-05-15 17:40 • 来自相关话题

【搜索客社区日报】第2037期 (2025-05-14）

社区日报 • kin122 发表了文章 • 0 个评论 • 4781 次浏览 • 2025-05-14 10:25 • 来自相关话题

【搜索客社区日报】第2036期 (2025-05-13）

社区日报 • God_lockin 发表了文章 • 0 个评论 • 4228 次浏览 • 2025-05-14 08:40 • 来自相关话题

谈谈 ES 6.8 到 7.10 的功能变迁（6）- 其他

Elasticsearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 5369 次浏览 • 2025-05-13 19:01 • 来自相关话题

![](https://infinilabs.cn/img/blog ... er.png)

这是 ES 7.10 相较于 ES 6.8 新增内容的最后一篇，主要涉及算分方法和同义词加载的部分。

自定义算分：script_score 2.0

Elasticsearch 7.0 引入了新一代的函数分数功能，称为 script_score 查询。这一新功能提供了一种更简单、更灵活的方式来为每条记录生成排名分数。script_score 查询由一组函数构成，包括算术函数和距离函数，用户可以根据需要混合和匹配这些函数，以构建任意的分数计算逻辑。这种模块化的结构使得使用更加简便，同时也为更多用户提供了这一重要功能的访问权限。通过 script_score，用户可以根据复杂的业务逻辑自定义评分，而不仅仅依赖于传统的 TF-IDF 或 BM25 算法。例如，可以根据文档的地理位置、时间戳、或其他自定义字段的值来调整评分，从而更精确地控制搜索结果的排序。

script_score 是 ES 对 function score 功能的一个迭代替换。

常用函数

基本函数

用于对字段值或评分进行基本的数学运算。
doc[<field>].value 获取文档中某个字段的值。

 "script": { "source": "doc['price'].value * 1.2" } 

算术运算

支持加 (+)、减 (-)、乘 (*)、除 (/)、取模 (%) 等操作。

 "script": { "source": "doc['price'].value + (doc['discount'].value * 0.5)" } 

Saturation 函数

saturation 函数用于对字段值进行饱和处理，限制字段值对评分的影响范围。

 "script": { "source": "saturation(doc['<field_name>'].value, <pivot>)" } 

<field_name>: 需要处理的字段。
<pivot>: 饱和点（pivot），当字段值达到该值时，评分增益趋于饱和。

 //在这个示例中，`likes` 字段的值在达到 `100` 后，对评分的影响会趋于饱和。 { "query": { "script_score": { "query": { "match_all": {} }, "script": { "source": "saturation(doc['likes'].value, 100)" } } } } 

Sigmoid 函数

sigmoid 函数用于对字段值进行 S 形曲线变换，平滑地调整字段值对评分的影响。

 "script": { "source": "sigmoid(doc['<field_name>'].value, <pivot>, <exponent>)" } 
需要处理的字段。
中心点（pivot），S 形曲线的中点。
指数，控制曲线的陡峭程度。

```
//在这个示例中，`likes` 字段的值在 `50` 附近对评分的影响最为显著，而随着值远离 `50`，影响会逐渐平滑。
{
"query": {
"script_score": {
"query": {
"match_all": {}
},
"script": {
"source": "sigmoid(doc['likes'].value, 50, 0.5)"
}
}
}
}
```

#### 距离衰减函数

用于衰减计算地理位置的函数。

```
//相关函数
double decayGeoLinear(String originStr, String scaleStr, String offsetStr, double decay, GeoPoint docValue)
double decayGeoExp(String originStr, String scaleStr, String offsetStr, double decay, GeoPoint docValue)
double decayGeoGauss(String originStr, String scaleStr, String offsetStr, double decay, GeoPoint docValue)

"script" : {
"source" : "decayGeoExp(params.origin, params.scale, params.offset, params.decay, doc['location'].value)",
"params": {
"origin": "40, -70.12",
"scale": "200km",
"offset": "0km",
"decay" : 0.2
}
}
```

#### 数值衰减函数

用于衰减计算数值的函数。

```
//相关函数
double decayNumericLinear(double origin, double scale, double offset, double decay, double docValue)
double decayNumericExp(double origin, double scale, double offset, double decay, double docValue)
double decayNumericGauss(double origin, double scale, double offset, double decay, double docValue)

"script" : {
"source" : "decayNumericLinear(params.origin, params.scale, params.offset, params.decay, doc['dval'].value)",
"params": {
"origin": 20,
"scale": 10,
"decay" : 0.5,
"offset" : 0
}
}
```

#### 日期衰减函数

用于衰减计算日期的函数。

```
//相关函数
double decayDateLinear(String originStr, String scaleStr, String offsetStr, double decay, JodaCompatibleZonedDateTime docValueDate)
double decayDateExp(String originStr, String scaleStr, String offsetStr, double decay, JodaCompatibleZonedDateTime docValueDate)
double decayDateGauss(String originStr, String scaleStr, String offsetStr, double decay, JodaCompatibleZonedDateTime docValueDate)

"script" : {
"source" : "decayDateGauss(params.origin, params.scale, params.offset, params.decay, doc['date'].value)",
"params": {
"origin": "2008-01-01T01:00:00Z",
"scale": "1h",
"offset" : "0",
"decay" : 0.5
}
}
```

#### 随机函数

用于生成随机评分。
_randomNotReproducible`_ 生成一个随机评分。

```
"script" : {
"source" : "randomNotReproducible()"
}
```

_randomReproducible_ 使用种子值生成可重复的随机评分。

```
"script" : {
"source" : "randomReproducible(Long.toString(doc['_seq_no'].value), 100)"
}
```

#### 字段值因子

用于根据字段值调整评分。
_field_value_factor`_ 根据字段值调整评分。

```
"script" : {
"source" : "Math.log10(doc['field'].value * params.factor)",
params" : {
"factor" : 5
}
}
```

#### 其他实用函数
Math.log：计算对数，Math.log(doc['price'].value)
Math.sqrt：计算平方根，Math.sqrt(doc['popularity'].value)
Math.pow：计算幂次，Math.pow(doc['score'].value, 2)

同义词字段重加载

Elasticsearch 7.3 引入了同义词字段重加载功能，允许用户在更新同义词文件后，无需重新索引即可使更改生效。
这一功能极大地简化了同义词管理的流程，尤其是在需要频繁更新同义词的场景下。通过 _reload_search_analyzers API，用户可以重新加载指定索引的分词器，从而使新的同义词规则立即生效。
注意，虽然同义词词典能被热加载，但是已经生成的索引数据不会被修改。

测试代码

 PUT /my_index { "settings": { "index" : { "analysis" : { "analyzer" : { "my_synonyms" : { "tokenizer" : "whitespace", "filter" : ["synonym"] } }, "filter" : { "synonym" : { "type" : "synonym_graph", "synonyms_path" : "analysis/synonym.txt", "updateable" : true } } } } }, "mappings": { "properties": { "text": { "type": "text", "analyzer" : "standard", "search_analyzer": "my_synonyms" } } } } POST /my_index/_reload_search_analyzers 

执行上述请求后，Elasticsearch 会重新加载 my_index 索引的分析器，使最新的同义词规则生效。

case insensitive 参数

case_insensitive 参数允许用户在执行精确匹配查询时忽略大小写。
这一功能特别适用于需要处理大小写不敏感数据的场景，例如用户名、标签或分类代码等。通过设置 case_insensitive 为 true，用户可以在不修改数据的情况下，实现对大小写不敏感的查询，从而简化查询逻辑并提高搜索的准确性。

测试代码

 //在这个示例中，`term` 查询会匹配 `user` 字段值为 `JohnDoe`、`johndoe` 或 `JOHNDOE` 的文档，而忽略大小写差异。 { "query": { "term": { "user": { "value": "JohnDoe", "case_insensitive": true } } } } 

小结

Elasticsearch 作为一款强大的开源搜索和分析引擎，其版本的不断迭代带来了诸多显著的改进与优化。对比 Elasticsearch 6.8，Elasticsearch 7.10 在多个方面展现出了新的功能和特性，极大地提升了用户体验和系统性能。这系列文章简短的介绍了各个方面的新功能和优化，希望能给大家一定的帮助。

推荐阅读
[谈谈 ES 6.8 到 7.10 的功能变迁（1）- 性能优化篇](https://infinilabs.cn/blog/202 ... part-1)
[谈谈 ES 6.8 到 7.10 的功能变迁（2）- 字段类型篇](https://infinilabs.cn/blog/202 ... part-2)
[谈谈 ES 6.8 到 7.10 的功能变迁（3）- 查询方法篇](https://infinilabs.cn/blog/202 ... part-3)
[谈谈 ES 6.8 到 7.10 的功能变迁（4）- 聚合功能篇](https://infinilabs.cn/blog/202 ... part-4)
[谈谈 ES 6.8 到 7.10 的功能变迁（5）- 任务和集群管理](https://infinilabs.cn/blog/202 ... part-5)

关于极限科技（INFINI Labs）

![INFINI Labs](https://infinilabs.cn/img/blog ... bs.png)

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

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

官网：<https://infinilabs.cn>;

作者：金多安，极限科技（INFINI Labs）搜索运维专家，Elastic 认证专家，搜索客社区日报责任编辑。一直从事与搜索运维相关的工作，日常会去挖掘 ES / Lucene 方向的搜索技术原理，保持搜索相关技术发展的关注。
原文：https://infinilabs.cn/blog/202 ... rt-6/

谈谈 ES 6.8 到 7.10 的功能变迁（5）- 任务和集群管理

Elasticsearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 5176 次浏览 • 2025-05-13 18:57 • 来自相关话题

![](https://infinilabs.cn/img/blog ... ks.png)

这一篇我们继续了解 ES 7.10 相较于 ES 6.8 调优的集群管理和任务管理的方法，主要有断联查询的主动取消、投票节点角色、异步查询和可搜索快照四个功能。

Query 自动取消

对于一个完善的产品来说，当一个任务发起链接主动断联的时候，服务端与之相关的任务应该也都被回收。但是这个特性到了 elasticsearch 7.4 版本才有了明确的声明。

Elasticsearch now automatically terminates queries sent through the _search endpoint when the initiating connection is closed.

相关的 PR 和 issue 在这里，对源码有兴趣的同学可以挖掘一下。

PR：https://github.com/elastic/ela ... 43332
issue：https://github.com/elastic/ela ... 43105

简单来说，ES 接受在某个查询的 http 链接断掉的时候，与其相关的父子任务的自动取消。原来的场景下可能需要手工一个个关闭。

实际测试

利用 painless 模拟复杂查询，下面这个查询在测试集群上能维持 5s 左右

 GET /_search?max_concurrent_shard_requests=1 { "query": { "bool": { "must": [ { "script": { "script": { "lang": "painless", "source": """ long sum = 0; for (int i = 0; i < 100000; i++) { sum += i; } return true; """ } } }, { "script": { "script": { "lang": "painless", "source": """ long product = 1; for (int i = 1; i < 100000; i++) { product *= i; } return true; """ } } }, { "script": { "script": { "lang": "painless", "source": """ long factorial = 1; for (int i = 1; i < 100000; i++) { factorial *= i; } long squareSum = 0; for (int j = 0; j < 100000; j++) { squareSum += j * j; } return true; """ } } }, { "script": { "script": { "lang": "painless", "source": """ long fib1 = 0; long fib2 = 1; long next; for (int i = 0; i < 100000; i++) { next = fib1 + fib2; fib1 = fib2; fib2 = next; } return true; """ } } } ] } } } 

查看任务被终止的状态

 GET /_tasks?detailed=true&actions=*search* 

测试脚本，判断上面该查询被取消后是否还可以查到任务

```python
import requests
import multiprocessing
import time
from requests.exceptions import RequestException
from datetime import datetime

Elasticsearch 地址

ES_URL = "<a href="http://localhost:9210"" rel="nofollow" target="_blank">http://localhost:9210" # 6.8版本地址

ES_URL = "<a href="http://localhost:9201"" rel="nofollow" target="_blank">http://localhost:9201"

耗时查询的 DSL

LONG_RUNNING_QUERY = {"size":0,
"query": {
"bool": {
"must": [
{
"script": {
"script": {
"lang": "painless",
"source": """
long sum = 0;
for (int i = 0; i < 100000; i++) {
sum += i;
}
return true;
"""
}
}
},
{
"script": {
"script": {
"lang": "painless",
"source": """
long product = 1;
for (int i = 1; i < 100000; i++) {
product = i;
}
return true;
"""
}
}
},
{
"script": {
"script": {
"lang": "painless",
"source": """
long factorial = 1;
for (int i = 1; i < 100000; i++) {
factorial = i;
}
long squareSum = 0;
for (int j = 0; j < 100000; j++) {
squareSum += j * j;
}
return true;
"""
}
}
},
{
"script": {
"script": {
"lang": "painless",
"source": """
long fib1 = 0;
long fib2 = 1;
long next;
for (int i = 0; i < 100000; i++) {
next = fib1 + fib2;
fib1 = fib2;
fib2 = next;
}
return true;
"""
}
}
}
]
}
}
}

用于同步的事件对象

query_finished = multiprocessing.Event()

新增：进程终止标志位

process_terminated = multiprocessing.Event()

定义一个函数用于添加时间戳到日志

def log_with_timestamp(message,*message1):
timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
print(f"[{timestamp}] {message}+{message1}")

发起查询的函数

def run_query():
try:
log_with_timestamp("发起查询...")
session = requests.Session()
response = session.post(
f"{ES_URL}/_search",
json=LONG_RUNNING_QUERY,
stream=True # 启用流式请求，允许后续中断
)
try:

尝试读取响应内容（如果连接未被中断）

if response.status_code == 200:
log_with_timestamp("查询完成，结果:", response.json())
else:
log_with_timestamp("查询失败，错误信息:", response.text)
except RequestException as e:
log_with_timestamp("请求被中断:", e)
finally:

标记查询完成

query_finished.set()

中断连接的信号函数

def interrupt_signal():
time.sleep(1) # 等待 1 秒
log_with_timestamp("发出中断查询信号...")

标记可以中断查询了

query_finished.set()

检测任务是否存在的函数

def check_task_exists():

等待进程终止标志位

process_terminated.wait()
max_retries = 3
retries = 0
time.sleep(1) #1s后检查
while retries < max_retries:
log_with_timestamp("检查任务是否存在...")
tasks_url = f"{ES_URL}/_tasks?detailed=true&actions=search"
try:
tasks_response = requests.get(tasks_url)
if tasks_response.status_code == 200:
tasks = tasks_response.json().get("nodes")
if tasks:
log_with_timestamp("任务仍存在:", tasks)
else:
log_with_timestamp("任务已消失")
break
else:
log_with_timestamp("获取任务列表失败，错误信息:", tasks_response.text)
except RequestException as e:
log_with_timestamp(f"检测任务失败（第 {retries + 1} 次重试）: {e}")
retries += 1
time.sleep(1) # 等待 1 秒后重试
if retries == max_retries:
log_with_timestamp("达到最大重试次数，无法检测任务状态。")

主函数

def main():

启动查询进程

query_process = multiprocessing.Process(target=run_query)
query_process.start()

启动中断信号进程

interrupt_process = multiprocessing.Process(target=interrupt_signal)
interrupt_process.start()

等待中断信号

query_finished.wait()

检查查询进程是否还存活并终止它

if query_process.is_alive():
log_with_timestamp("尝试中断查询进程...")
query_process.terminate()
log_with_timestamp("查询进程已终止")

新增：设置进程终止标志位

process_terminated.set()

启动任务检测进程

check_process = multiprocessing.Process(target=check_task_exists)
check_process.start()

等待所有进程完成

query_process.join()
interrupt_process.join()
check_process.join()

if name == "main":
main()
 实际测试结果：  shell

6.8 版本

[2025-02-08 15:17:21] 发起查询...+()
[2025-02-08 15:17:22] 发出中断查询信号...+()
[2025-02-08 15:17:22] 尝试中断查询进程...+()
[2025-02-08 15:17:22] 查询进程已终止+()
[2025-02-08 15:17:23] 检查任务是否存在...+()
[2025-02-08 15:17:23] 任务仍存在:+({'fYMNv_KxQGCGzhgfMxPXuA': {......}},)
 可以看到在查询任务被终止后 1s 再去检查，任务仍然存在  shell

7.10 版本

[2025-02-08 15:18:16] 发起查询...+()
[2025-02-08 15:18:17] 发出中断查询信号...+()
[2025-02-08 15:18:17] 尝试中断查询进程...+()
[2025-02-08 15:18:17] 查询进程已终止+()
[2025-02-08 15:18:18] 检查任务是否存在...+()
[2025-02-08 15:18:18] 任务已消失+()
```

这里可以看到任务已经检测不到了。

关于 timeout 配置

这里展开讨论下，timeout 配置。超时回收处理是一个‘best effort’行为。

(Optional, time units) Specifies the period of time to wait for a response. If no response is received before the timeout expires, the request fails and returns an error. Defaults to no timeout.

the search request is more of a best effort and does not guarantee that the request will never last longer than the specified amount of time.

异步搜索

使用方法

可以让用户进行异步的搜索，可以通过相关参数进行检查维护该搜索的状态和结果。比较合适查询量较大但对延迟要求较低的查询，进行精细化的管理控制。

注意：这里的参数基本都是添加到 url 上的，并不是添加到 request body 上的。

 POST test_index/_async_search?keep_on_completion=true { "query": { "match_all": {} } } 

注：这里为了产生查询结果 id 使用了 keep_on_completion 参数，这个参数的使用见下面解释。

返回结果，和一般的查询结果不同的是，添加了结果 id 和查询的一些状态数据。

json { "id": "Fmk2b0VjM2FEVE9Dbk9TemVyOTlkMncbOFlwRGU2OWZTa2kxNEpoT0Q2bVZrZzozODIz",//结果id，可以用于后续的复查 "is_partial": false,//是否为部分完成结果 "is_running": false,//是否还在查询 "start_time_in_millis": 1738978637287,//查询产生时间戳 "expiration_time_in_millis": 1739410637287,//查询结果过期时间戳 "response": { "took": 1, "timed_out": false, "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }, "hits": { "total": { "value": 3, "relation": "eq" }, "max_score": 1, "hits": [······] } } } 

管理查询结果

 //查询结果和第一次返回的内容一致 GET /_async_search/Fmk2b0VjM2FEVE9Dbk9TemVyOTlkMncbOFlwRGU2OWZTa2kxNEpoT0Q2bVZrZzozODIz //主动删除查询结果 DELETE /_async_search/Fmk2b0VjM2FEVE9Dbk9TemVyOTlkMncbOFlwRGU2OWZTa2kxNEpoT0Q2bVZrZzozODIz 

关键参数

wait_for_completion_timeout：参数（默认为 1 秒），这个参数用来设置异步查询的等待时间。当异步搜索在此时间内完成时，响应将不包括 ID，结果也不会存储在集群中。

keep_on_completion：参数（默认为 false）可以设置为 true，可以强制存储查询结果，即便在 wait_for_completion_timeout 设置时间内完成搜索，该结果也能被查询到。

keep_alive：指定异步搜索结果可以被保存多长时间，默认为 5d（5 天）。在此期间之后，正在进行的异步搜索和任何保存的搜索结果将被删除。

batched_reduce_size：是 Elasticsearch 中的一个配置参数，默认值为 5。它的作用是控制分片结果的部分归并频率，具体来说，它决定了协调节点（coordinating node）在接收到多少个分片的响应后，会执行一次部分结果归并（partial reduction）。

pre_filter_shard_size：是 Elasticsearch 中与查询执行相关的一个参数，它的默认值为 1，并且不可更改。这个参数的作用是强制 Elasticsearch 在执行查询之前，先进行一轮预过滤（pre-filter），以确定哪些分片（shard）可能包含与查询匹配的文档，从而跳过那些肯定不包含匹配文档的分片。

查询结果存储位置

异步查询的结果部分存储在.async-search中，但是进行了程序加密，内容对使用者不可见。

 GET .async-search/_search // 返回的结果 ··· "hits": [ { "_index": ".async-search", "_type": "_doc", "_id": "bPNotcTCTV-gSIiZLuK0IA", "_score": 1, "_source": { "result": "i6+xAwFERm1KUVRtOTBZMVJEVkZZdFoxTkphVnBNZFVzd1NVRWJPRmx3UkdVMk9XWlRhMmt4TkVwb1QwUTJiVlpyWnpvek1EWTEAAQEDAD+AAAADP4AAAAAAABR0Sm9yNDVRQlQ3bzBsZTdsYmp0TgAAAARfZG9jAP//////////AwALeyJhIjoxMTExfQoAAAAAAAAAAQEAAAAWOFlwRGU2OWZTa2kxNEpoT0Q2bVZrZwp0ZXN0X2luZGV4Fk5fYmphNXM1UWtpcnU4RXdleVlGSUEAAAA/gAAAAAAAFHRab3I0NVFCVDdvMGxlN2xlVHNrAAAABF9kb2MA//////////8DAAt7ImEiOjExMTJ9CgAAAAAAAAABAQAAABY4WXBEZTY5ZlNraTE0SmhPRDZtVmtnCnRlc3RfaW5kZXgWTl9iamE1czVRa2lydThFd2V5WUZJQQAAAD+AAAAAAAAUdHBvcjQ1UUJUN28wbGU3bGZqc28AAAAEX2RvYwD//////////wMAC3siYSI6MTExM30KAAAAAAAAAAEBAAAAFjhZcERlNjlmU2tpMTRKaE9ENm1Wa2cKdGVzdF9pbmRleBZOX2JqYTVzNVFraXJ1OEV3ZXlZRklBAAAAAAAAAAAAAgABAQEAAAAAAAsAAAAAAAABlOMuvCQAAAGU/O6IJA==", "headers": {}, "expiration_time": 1739410278436, "response_headers": {} } }, ··· 

只投票候选节点

这是一个主候选节点角色的优化，能相对固定 master 节点的位置，减少了选举候选节点过多的问题。

作用

Voting - only master - eligible node（仅参与投票的具备主节点资格的节点）在 Elasticsearch 集群中有以下作用：

参与主节点选举：该节点参与主节点选举过程，但本身不会成为集群选出的主节点，主要作为选举中的决胜因素（打破平局）。

保障高可用性：在高可用性（HA）集群中，至少需要三个具备主节点资格的节点，其中至少两个不能是仅参与投票的节点，这样即使有一个节点故障，集群仍能选出主节点。

分担选举及状态发布任务：和普通具备主节点资格的节点一样，在集群状态发布期间承担特定任务。

灵活承担其他角色：可以同时承担集群中的其他角色，如数据节点；也可以作为专用节点，不承担其他角色。

配置

三个节点的集群：可以配置两个普通主节点资格节点和一个仅参与投票的节点。这样在一个普通主节点故障时，剩下的普通主节点和仅参与投票的节点一起可以完成主节点选举，保证集群的正常运行。
理论上，主候选节点数量能满足不同区域间的主备切换要求即可，其余可以都是投票节点。

可搜索快照

注意：这是一个收费功能

实现机制

可搜索快照让你能够通过使用快照来保障数据恢复能力，而非在集群内维护副本分片，从而降低运营成本。

当你将快照中的索引挂载为可搜索快照时，Elasticsearch 会将索引分片复制到集群内的本地存储中。这能确保搜索性能与搜索其他任何索引相当，并尽量减少对访问快照存储库的需求。如果某个节点发生故障，可搜索快照索引的分片会自动从快照存储库中恢复。

搜索可搜索快照索引与搜索其他任何索引的方式相同。搜索性能与常规索引相当，因为在挂载可搜索快照时，分片数据会被复制到集群中的节点上。

如果某个节点发生故障，且需要从快照中恢复可搜索快照分片，在 Elasticsearch 将分片分配到其他节点的短暂时间内，集群健康状态将不会显示为绿色。在这些分片重新分配完成之前，对这些分片的搜索将会失败或返回部分结果。

对于搜索频率较低的数据，这能显著节省成本。使用可搜索快照，不再需要额外的索引分片副本以避免数据丢失，这有可能将搜索该数据所需的节点本地存储容量减少一半。同时可搜索快照依赖于备份使用的快照，也不需要额外的空间。

使用建议

从含多索引的快照挂载单个索引时，建议进行使用分隔，创建仅含目标索引的快照副本并挂载，方便独立管理备份与可搜索快照生命周期。

挂载为可搜索快照索引前，建议将索引强制合并为每分片一个段，减少从存储库读取数据的操作和成本。

实际测试

基础配置

前提条件：需要一个镜像使用存储，这里使用 minIO 作为测试

安装 S3 插件，并注册快照库信息

```

在线安装插件

elasticsearch-plugin install repository-s3

设置访问minio的信息,elasticsearch的bin目录下，使用minIO中设置的用户名密码

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

重载安全设置，然后重启节点

POST _nodes/reload_secure_settings

注册快照库

PUT _snapshot/my-minio-repository
{
"type": "s3",
"settings": {
"bucket": "es-bucket",
"endpoint": "<a href="http://127.0.0.1:9002"" rel="nofollow" target="_blank">http://127.0.0.1:9002",
"compress": true
}
}
```

挂载需要的快照索引

 POST /_snapshot/my-minio-repository/snapshot_es_prp_cmain_20240829/_mount?wait_for_completion=true { "index": "es_prp_cmain_insured_itemkind_detail_formal_20240829", "renamed_index": "test_searchable_snapshot",//挂载时对索引进行重命名 "index_settings": { "index.number_of_replicas": 0 }, "ignore_index_settings": [ "index.refresh_interval" ] } 

检查空间占用

 GET _cat/indices/test_searchable_snapshot?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open test_searchable_snapshot qROj2flcRdiGOZaejeAmQQ 1 0 10000 0 21.3mb 21.3mb 

在系统上也看到了对应 uuid 的文件目录

 [root@hcss-ecs 0]# ls _state snapshot_cache translog [root@hcss-ecs 0]# pwd /data/elasticsearch-7.10.2/data/nodes/0/indices/qROj2flcRdiGOZaejeAmQQ/0 

小结

这篇的内容讲解测试的相对较细，对于查询的自动取消和异步查询增加了 ES 查询任务的灵活性；只投票节点也是加强了主节点选举的稳定性；可搜索快照是成本和功能的均衡方法，对于日志场景的使用是一个不错的选择。

推荐阅读

[谈谈 ES 6.8 到 7.10 的功能变迁（1）- 性能优化篇](https://infinilabs.cn/blog/202 ... part-1)

[谈谈 ES 6.8 到 7.10 的功能变迁（2）- 字段类型篇](https://infinilabs.cn/blog/202 ... part-2)

[谈谈 ES 6.8 到 7.10 的功能变迁（3）- 查询方法篇](https://infinilabs.cn/blog/202 ... part-3)

[谈谈 ES 6.8 到 7.10 的功能变迁（4）- 聚合功能篇](https://infinilabs.cn/blog/202 ... part-4)

[谈谈 ES 6.8 到 7.10 的功能变迁（6）- 其他](https://infinilabs.cn/blog/202 ... part-6)

关于极限科技（INFINI Labs）

![INFINI Labs](https://infinilabs.cn/img/blog ... bs.png)

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

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

官网：<https://infinilabs.cn>;

作者：金多安，极限科技（INFINI Labs）搜索运维专家，Elastic 认证专家，搜索客社区日报责任编辑。一直从事与搜索运维相关的工作，日常会去挖掘 ES / Lucene 方向的搜索技术原理，保持搜索相关技术发展的关注。
原文：https://infinilabs.cn/blog/202 ... rt-5/

【搜索客社区日报】第2035期 (2025-05-12）

社区日报 • Muses 发表了文章 • 0 个评论 • 4061 次浏览 • 2025-05-12 11:29 • 来自相关话题

INFINI Console 纳管 Elasticsearch 9（二）：日志监控

Elasticsearch • INFINI Labs 小助手发表了文章 • 0 个评论 • 4471 次浏览 • 2025-05-11 22:36 • 来自相关话题

前面介绍过 INFINI Console 纳管 Elasticsearch 9（一），进行指标监控、数据管理、DSL 语句执行，但日志监控功能需要结合 [Agent](https://docs.infinilabs.com/agent/main/zh/) 才能使用。现在来实现一下：

Agent 需要和 ES 部署到同一机器上，这里是在我本地电脑上进行安装。

安装 Elastisearch

bash curl -O <a href="https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.0.0-darwin-x86_64.tar.gz" rel="nofollow" target="_blank">https://artifacts.elastic.co/d ... ar.gz</a> curl <a href="https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.0.0-darwin-x86_64.tar.gz.sha512" rel="nofollow" target="_blank">https://artifacts.elastic.co/d ... ha512</a> | shasum -a 512 -c - tar -xzf elasticsearch-9.0.0-darwin-x86_64.tar.gz cd elasticsearch-9.0.0/ ./bin/elasticsearch 

![](https://infinilabs.cn/img/blog ... 01.png)

将 ES 注册到 Console 中。

![](https://infinilabs.cn/img/blog ... 02.png)

![](https://infinilabs.cn/img/blog ... 03.png)

安装 Agent

bash curl -O <a href="https://release.infinilabs.com/agent/stable/agent-1.29.2-2008-mac-amd64.zip" rel="nofollow" target="_blank">https://release.infinilabs.com ... 4.zip</a> mkdir agent unzip agent-1.29.2-2008-mac-amd64.zip -d agent/ cd agent 

修改配置文件 agent.yml，填写正确的 Console 地址。

![](https://infinilabs.cn/img/blog ... 04.png)

启动 Agent，成功注册到 Console，获取到相关配置，但连接 Console 系统集群出现异常，这是因为 Console 系统集群是 Docker 部署的（172.17.0.2 是 Docker 内部 IP）。

![](https://infinilabs.cn/img/blog ... 05.png)

通过 Console 修改 Agent 配置。

![](https://infinilabs.cn/img/blog ... 06.png)

![](https://infinilabs.cn/img/blog ... 07.png)

注：Console 系统集群地址需调整为 Agent 可以访问的地址；配置版本号需要增大。

Agent 运行无异常。

![](https://infinilabs.cn/img/blog ... 08.png)

Agent 注册 Console 成功后，在 Console 页面“资源管理”-“探针管理”中可以看到注册的 Agent 实例。

![](https://infinilabs.cn/img/blog ... 09.png)

关联操作

Agent 关联到需要采集数据的 ES 集群。

![](https://infinilabs.cn/img/blog ... 10.png)

![](https://infinilabs.cn/img/blog ... 11.png)

![](https://infinilabs.cn/img/blog ... 12.png)

![](https://infinilabs.cn/img/blog ... 13.png)

调整监控模式

关联成功后，将 ES 集群的监控模式改为 Agent。

![](https://infinilabs.cn/img/blog ... 14.png)

可在监控报表中，查看采集状态。

![](https://infinilabs.cn/img/blog ... 15.png)

查看日志

![](https://infinilabs.cn/img/blog ... 16.png)

至此日志功能已可以使用。

关于 INFINI Console

![](https://infinilabs.cn/img/blog ... 2x.png)

INFINI Console 是一款开源的非常轻量级的多集群、跨版本的搜索基础设施统一管控平台。通过对流行的搜索引擎基础设施进行跨版本、多集群的集中纳管，企业可以快速方便的统一管理企业内部的不同版本的多套搜索集群。INFINI Console 还可以对集群内的索引及数据进行操作管理，可以配置灵活的告警规则，可以指定统一的安全策略，可以查看各个维度的日志和审计信息，真正实现企业级的搜索服务平台化建设和运营。

官网文档：<https://docs.infinilabs.com/console>;
开源地址：<https://github.com/infinilabs/console>;

原文：https://infinilabs.cn/blog/202 ... arch/

通知设置 新通知

发现

🔥 微信扫码，预约直播：

🔥 直播亮点：

功能与价值解析

应用场景实战

开源生态与未来展望

关于开源中国

关于 INFINI Labs

关于 Coco AI

deletePctAllowed：软删除的遗留

deletePctAllowed 的实际效果

查看 delete 文档数量

任务状态

索引的状态

deletes_pct_allowed 默认值的调整

RUN 1

RUN 2

RUN 3

RUN 4

另一种调优思路

关于极限科技（INFINI Labs）

自定义算分：script_score 2.0

常用函数

基本函数

算术运算

Saturation 函数

Sigmoid 函数

同义词字段重加载

case insensitive 参数

小结

推荐阅读

关于极限科技（INFINI Labs）

Query 自动取消

实际测试

Elasticsearch 地址

ES_URL = "<a href="http://localhost:9210"" rel="nofollow" target="_blank">http://localhost:9210" # 6.8版本地址

耗时查询的 DSL

用于同步的事件对象

新增：进程终止标志位

定义一个函数用于添加时间戳到日志

发起查询的函数

尝试读取响应内容（如果连接未被中断）

标记查询完成

中断连接的信号函数

标记可以中断查询了

检测任务是否存在的函数

等待进程终止标志位

主函数

启动查询进程

启动中断信号进程

等待中断信号

检查查询进程是否还存活并终止它

新增：设置进程终止标志位

启动任务检测进程

等待所有进程完成

6.8 版本

7.10 版本

关于 timeout 配置

异步搜索

使用方法

关键参数

查询结果存储位置

只投票候选节点

作用

配置

可搜索快照

实现机制

使用建议

实际测试

基础配置

在线安装插件

设置访问minio的信息,elasticsearch的bin目录下，使用minIO中设置的用户名密码

重载安全设置，然后重启节点

注册快照库

小结

推荐阅读

关于极限科技（INFINI Labs）

安装 Elastisearch

安装 Agent

通知设置新通知