1.Elasticsearch 源码探究 001——故障探测和恢复机制
https://mp.weixin.qq.com/s/h1sZYtyLIJr__Akv0YMC0w
2.Elastic 可观测解决方案 8.9：发布可观测 AI 助手
https://mp.weixin.qq.com/s/XcACwf_ysTcYUxXgQiMP6A
3.奇怪！我的 java 程序只能扛住高并发却扛不住低并发
https://mp.weixin.qq.com/s/Yo8jgxkRO-EKOn4T7IqQCA

编辑：Se7en
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup
B站： https://ela.st/bilibili

1.Elasticsearch：通过动态修剪实现更快的基数聚合
https://blog.csdn.net/UbuntuTo ... .5501
2.lucene-forcemerge源码解读（一）
https://www.amazingkoala.com.c ... .html
3.lucene-forcemerge源码解读（二）
https://www.amazingkoala.com.c ... .html

编辑：kin122
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup
B站：https://ela.st/bilibili

1. 两分钟计算7KW个价格数据，你会吗？（I）（需要梯子）
https://medium.com/trendyol-te ... b8c3f
2. 两分钟计算7KW个价格数据，不会我教你啊（II）（需要梯子）
https://medium.com/trendyol-te ... ee292
3. Elastic Watcher 冒险：揭开有效错误日志和 API 监控的秘密（需要梯子）
https://medium.com/%40soniyogi ... 462ac
编辑：斯蒂文
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup
B站： https://ela.st/bilibili
 

1. Elasticsearch：从搜索中获取选定的字段 fields
   https://blog.csdn.net/UbuntuTo ... 53365
2. Elasticsearch 字段field参数
   https://blog.csdn.net/qq_18218 ... 28857
3. Elasticsearch：分片如何影响 Elasticsearch 中的相关性评分
   https://elasticstack.blog.csdn ... 26968
编辑：yuebancanghai
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup
B站：https://ela.st/bilibili

1.使用 Elastic Watcher 对错误日志和 API 调用进行监控（需要梯子）
https://medium.com/%40soniyogi ... 462ac
2.如何将整个 Elasticsearch 索引导出到文件（需要梯子）
https://medium.com/%40disorgan ... 803a0
3.Elasticsearch 和竞争对手的性能基准测试对比（需要梯子）
https://medium.com/gigasearch/ ... 75639

编辑：Se7en
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup
B站： https://ela.st/bilibili

1.改进 Elastic Stack 中的信息检索：提高搜索相关性的步骤
https://cloud.tencent.com/deve ... 03563
2.改进 Elastic Stack 中的信息检索：对段落检索进行基准测试
https://cloud.tencent.com/deve ... 03595
3.改进 Elastic Stack 中的信息检索：引入 Elastic Learned Sparse Encoder，我们的新检索模型原创
https://cloud.tencent.com/deve ... 03829

编辑：kin122
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup
B站：https://ela.st/bilibili

1. 我们在pelago这样做搜索（需要梯子）
https://medium.com/%40amans.rl ... 3ea3e
2. 担心系统不安全？ES来帮你搭建安全体系（需要梯子）
https://infosecwriteups.com/en ... ba803
3. 安全专家手里的新工具包——ELK（需要梯子）
https://medium.com/%40wenray/t ... d8013

编辑：斯蒂文
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup
B站： https://ela.st/bilibili
 

问题背景

今天早上，接到开发那边一个特殊的查询需求，在 Kibana 中搜索一个 json 类型日志中值为一个空大括号的键值对， 具体的日志示例如下：

aidl<br /> {<br /> "clientIp": "10.111.121.51",<br /> "query": "{}",<br /> "serviceUrl": "/aaa/bbb/cc",<br /> }<br />

也就是说针对这个类型的日志过滤出 query 值为空的请求 "query": "{}", 开发同学测试了直接在 kibana 中查询这个字符串 "query": "{}" 根本查不到我们想要的结果。
我们使用的是 ELK 8.3 的全家桶， 这个日志数据使用的默认 standard analyzer 的分词器。

初步分析

我们先对这个要查询的字符串进行下分词测试：

aidl<br /> GET /_analyze<br /> {<br /> "analyzer" : "standard",<br /> "text": "\"query\":\"{}\""<br /> }<br /> <br />

结果不出所料，我们想要空大括号在分词的时候直接就被干掉了，仅保留了 query 这一个 token：

aidl<br /> {<br /> "tokens": [{<br /> "token": "query",<br /> "start_offset": 1,<br /> "end_offset": 6,<br /> "type": "<ALPHANUM>",<br /> "position": 0<br /> }]<br /> }<br />

我们使用的 standard analyzer 在数据写入分词时直接抛弃掉{}等特殊字符，看来直接搜索 "query": "{}" 关键词这条路肯定是走不通。

换个思路

在网上搜索了一下解决的办法，有些搜索特殊字符的办法,但需要修改分词器，我们已经写入的日志数据量比较大，不太愿意因为这个搜索请求来修改分词器再 reindex。 但是我们的日志格式是固定的，serviceUrl 这个键值对总是在 query 后面的，那么我们可以结合前后文实现相同的
搜索效果：

aidl<br /> GET /_analyze<br /> {<br /> "analyzer" : "standard",<br /> "text": "\"query\":\"{}\",\"serviceUrl\""<br /> }<br /> <br />

可以看到这段被分为 2 个相邻的单词

aidl<br /> {<br /> "tokens": [{<br /> "token": "query",<br /> "start_offset": 1,<br /> "end_offset": 6,<br /> "type": "<ALPHANUM>",<br /> "position": 0<br /> },<br /> {<br /> "token": "serviceurl",<br /> "start_offset": 14,<br /> "end_offset": 24,<br /> "type": "<ALPHANUM>",<br /> "position": 1<br /> }<br /> ]<br /> }<br /> <br />

那么通过搜索 query 和 serviceUrl 为相邻的 2 个字是完全可以实现 query 的值为空的同样的查询效果。
为了确认在我们已经写入的数据中 query 和 serviceurl 也是相邻的，我们通过 ES termvectors API 确认了已经在 es 中的数据和我们这里测试的情况相同：

aidl<br /> GET /<index>/_termvectors/<_id>?fields=message<br /> <br /> "query" : {<br /> "term_freq" : 1,<br /> "tokens" : [<br /> {<br /> "position" : 198,<br /> "start_offset" : 2138,<br /> "end_offset" : 2143<br /> }<br /> ]<br /> },<br /> "serviceurl" : {<br /> "term_freq" : 1,<br /> "tokens" : [<br /> {<br /> "position" : 199,<br /> "start_offset" : 2151,<br /> "end_offset" : 2161<br /> }<br /> ]<br /> },<br />

这里我们可以看到 query 在 message 字段里面出现一次，其 end_offset 和 serviceurl 的 start_offset 之前也是相差 8， 和我们测试的结果相同。
这个时候我们就将原来的查询需求，转化为了对 "query serviceurl" 进行按顺序的精准查询就行了， 使用 match_phrase 可以达到我们的目的。

aidl<br /> GET /_search<br /> "query": {<br /> "match_phrase": {<br /> "message": {<br /> "query": "query serviceurl",<br /> "slop" : 0<br /> <br /> }<br /> }<br /> }<br />

这里顺便说一下，slop 这个参数，slop=n 表示，表示可以隔 n 个字(英文词)进行匹配, 这里设置为 0 就强制要求 query 和 serviceurl 这 2 个单词必须相邻，0 也是 slop 的默认值，在这个请求中是可以省略的，这是为什么 match_phrase 是会获得精准查询的原因之一。
好了，我们通过 console 确定了有效的 query 之后，对于开发同学查看日志只需要在 Kibana 的搜索栏中直接使用双引号引起来的精确搜索 "query serviceurl" 就可以了。

继续深挖一下，ngram 分词器

虽然开发同学搜索的问题解决了，但我仍然不太满意，毕竟这次的问题我们的日志格式是固定的，如果我们一定要搜索到 "query": "{}" 这个应该怎么办呢？ 首先很明确，使用我们默认的 standard analyzer 不修改任何参数肯定是不行的，"{}" 这些特殊字符都直接被干掉了，
参考了网上找到的这篇文章，https://blog.csdn.net/fox_233/ ... 88058 按照这个 ngram 分词器的思路，我动手对我们的需求进行了下测试

首先先看看我们使用 ngram 分词器的分词效果， 我们这里简化了一下，去掉了原来的双引号，以避免过多 \:

aidl<br /> GET _analyze<br /> {<br /> "tokenizer": "ngram",<br /> "text": "query:{}"<br /> }<br /> <br /> {<br /> "tokens" : [<br /> {<br /> "token" : "q",<br /> "start_offset" : 0,<br /> "end_offset" : 1,<br /> "type" : "word",<br /> "position" : 0<br /> },<br /> ...<br /> {<br /> "token" : "{",<br /> "start_offset" : 6,<br /> "end_offset" : 7,<br /> "type" : "word",<br /> "position" : 12<br /> },<br /> {<br /> "token" : "{}",<br /> "start_offset" : 6,<br /> "end_offset" : 8,<br /> "type" : "word",<br /> "position" : 13<br /> },<br /> {<br /> "token" : "}",<br /> "start_offset" : 7,<br /> "end_offset" : 8,<br /> "type" : "word",<br /> "position" : 14<br /> }<br /> ]<br /> }<br />

可以很明显的看到大括号被成功的分词了，果然是有戏。 直接定义一个 index 实战一下搜索效果

aidl<br /> PUT specialchar_debug<br /> {<br /> "settings": {<br /> "analysis": {<br /> "analyzer": {<br /> "specialchar_analyzer": {<br /> "tokenizer": "specialchar_tokenizer"<br /> }<br /> },<br /> "tokenizer": {<br /> "specialchar_tokenizer": {<br /> "type": "ngram",<br /> "min_gram": 1,<br /> "max_gram": 2<br /> }<br /> }<br /> }<br /> },<br /> "mappings": {<br /> "properties": {<br /> "text": {<br /> "analyzer": "specialchar_analyzer",<br /> "type": "text"<br /> }<br /> }<br /> }<br /> }<br />

插入几条测试数据：

aidl<br /> PUT specialchar_debug/_doc/1<br /> { "text": "query:{},serviceUrl"<br /> }<br /> <br /> PUT specialchar_debug/_doc/2<br /> { "text": "query:{aaa},serviceUrl"<br /> }<br /> <br /> PUT specialchar_debug/_doc/3<br /> { "text": "query:{bbb}, ccc, serviceUrl"<br /> }<br />

我们再测试一下搜索效果，

aidl<br /> GET specialchar_debug/_search<br /> {<br /> "query": {<br /> "match_phrase": {<br /> "text": "query:{}"<br /> }<br /> }<br /> }<br />

结果完全是我们想要的，看来这个方案可行

aidl<br /> "hits" : [<br /> {<br /> "_index" : "specialchar_debug",<br /> "_id" : "1",<br /> "_score" : 2.402917,<br /> "_source" : {<br /> "text" : "query:{},serviceUrl"<br /> }<br /> }<br /> ]<br />

小结

对于日志系统，我们一直在使用 ES 默认的 standard analyzer 的分词器， 基本上满足我们生产遇到的 99% 的需求，但面对特殊字符的这种搜索请求，确实比较无奈。这次遇到的空键值对的需求，我们通过搜索 2 个相邻的键绕过了问题。
如果一定要搜索这个字符串的话，我们也可以使用 ngram 分词器重新进行分词再进行处理， 条条大路通罗马。

作者介绍

卞弘智，研发工程师，10 多年的 SRE 经验，工作经历涵盖 DevOps，日志处理系统，监控和告警系统研发，WAF 和网关等系统基础架构领域，致力于通过优秀的开源软件推动自动化和智能化基础架构平台的演进。