绊脚石乃是进身之阶。

社区日报 第 1238 期 (2021-11-02)

1. Solr VS Elasticsearch:最有名的开源搜索引擎之二的battle
https://sematext.com/blog/solr ... nces/

2. Elastic beats 介绍以及他们在ELK中的适用场景
https://www.instaclustr.com/el ... tack/

3. Elasticsearch 词频统计的四种方案
https://mp.weixin.qq.com/s/S4AMVWIoNT4ZFKGs1biNnQ

编辑:斯蒂文
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. Solr VS Elasticsearch:最有名的开源搜索引擎之二的battle
https://sematext.com/blog/solr ... nces/

2. Elastic beats 介绍以及他们在ELK中的适用场景
https://www.instaclustr.com/el ... tack/

3. Elasticsearch 词频统计的四种方案
https://mp.weixin.qq.com/s/S4AMVWIoNT4ZFKGs1biNnQ

编辑:斯蒂文
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1236期 (2021-10-31)



1. Elastic 社区大会2021: Elasticsearch和GraphQL的一封情书-哔哩哔哩
https://b23.tv/aQvRUK
2.使用 Elastic Stack 构建 Kubernetes 全栈监控
https://mp.weixin.qq.com/s/4GAIYiEQocayDFPHAOuU1A
3.Elastic APM监控Springboot程序
https://mp.weixin.qq.com/s/h95uxsVxs6ybTorsfzmF-w

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »


1. Elastic 社区大会2021: Elasticsearch和GraphQL的一封情书-哔哩哔哩
https://b23.tv/aQvRUK
2.使用 Elastic Stack 构建 Kubernetes 全栈监控
https://mp.weixin.qq.com/s/4GAIYiEQocayDFPHAOuU1A
3.Elastic APM监控Springboot程序
https://mp.weixin.qq.com/s/h95uxsVxs6ybTorsfzmF-w

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

社区日报 第1235期 (2021-10-30)

1.基于elasticsearch的KBQA实现及示例

http://openkg.cn/tool/elasticsearch-kbqa

2.ElasticSearch 处理自然语言流程

https://www.cnblogs.com/yisany/p/10292049.html

3.一周热点:新冠疫苗加强针开打,你关心的五个问题都有回应了

https://www.thepaper.cn/newsDetail_forward_15049026

继续阅读 »

1.基于elasticsearch的KBQA实现及示例

http://openkg.cn/tool/elasticsearch-kbqa

2.ElasticSearch 处理自然语言流程

https://www.cnblogs.com/yisany/p/10292049.html

3.一周热点:新冠疫苗加强针开打,你关心的五个问题都有回应了

https://www.thepaper.cn/newsDetail_forward_15049026

收起阅读 »

ES容灾技术探讨和测试

ES灾备技术调研

早就听说极限网关了,最近有个ES要做灾备,就搜集了下技术方案:

  1. 应用双写两个集群

  2. 跨集群复制CCR

  3. 极限网关

三个方案的优缺点我也简单整理了下:

  1. 优点:自主研发,想怎样就怎样;缺点:难,水平、时间都是成本

  2. 优点:实施简单;缺点:需要license

  3. 优点:部署灵活,功能齐全;缺点:不熟悉,没用过

貌似方案 3,比较理想。不熟悉,那就多用用,测试测试找找感觉。

测试环境 笔记本

主集群:A 7.14.1 10.0.2.15:9214 Rbac+tls 节点数:1
备集群:B 7.13.2 10.0.2.15:9213 Rbac+tls 节点数:2
极限网关 1.3.0 0.0.0.0:8000 tls 实例数:1

wpsF088.tmp_.jpg

wpsF089.tmp_.jpg

网关下载

先下载极限网关:http://release.elasticsearch.cn/gateway/snapshot/

解压后,可看到有几个预定义的配置,方便大家快速上车。

wpsF08A.tmp_.jpg

网关配置

这次是做灾备,应该就是在 dc-replica.yml的基础上改比较妥当,配置还是比较多的 300多行,很多都是为了保证两个集群数据一致性,解耦啥的做的判断和写队列之类的设置。我只修改了 elasticsearch资源的定义信息,还有网关也可选择tls,不用手工生成证书,非常方便。

贴下我修改的地方

wpsF08B.tmp_.jpg

wpsF08C.tmp_.jpg

启动网关

wpsF08D.tmp_.jpg

两个集群都是 available ,说明连接应该ok

测试场景:围绕主备集群之间数据复制展开

1. 主备集群间复制创建、写入、删除索引操作

目的:对网关(A集群)创建索引test,对test索引写文档,能自动同步到B集群

初始情况A、B无test

wpsF09E.tmp_.jpg
wpsF09F.tmp_.jpg

手工put test索引到网关

wpsF0A0.tmp_.jpg
wpsF0A1.tmp_.jpg
wpsF0A2.tmp_.jpg
A,B集群都创建成功

用loadgen写点文档进去吧,loadgen直接写网关

wpsF0A3.tmp_.jpg

wpsF0A4.tmp_.jpg

wpsF0A5.tmp_.jpg

都10000条写入成功,如果查看是0的话,先refresh下索引

看下文档

wpsF0A6.tmp_.jpg

简单校验一下

wpsF0A7.tmp_.jpg

wpsF0A8.tmp_.jpg

感觉没问题,删点文档看看,把那23个删了吧

wpsF0A9.tmp_.jpg

再看看

wpsF0AA.tmp_.jpg

wpsF0BA.tmp_.jpg

更新524个文档看看

wpsF0BB.tmp_.jpg

wpsF0BC.tmp_.jpg

wpsF0BD.tmp_.jpg

增、删、改 完事

2. 主集群故障的处理和恢复

目的:主集群故障后,网关如何处理收到的请求:读、写

Kill 掉 A 集群,模拟主集群故障

网关直接有报错说连不上A集群

此时对网关查询、写入数据都会报错

wpsF0BE.tmp_.jpg

重新启动主集群后,一切正常

3. 备集群故障的处理和恢复

目的:备集群故障,读、写主集群不受影响,备集群恢复后,自动追数据直到两边数据一致

Kill 掉B集群,网关报错,B集群无法连接

wpsF0BF.tmp_.jpg

对A集群进行写入一个新文档,并查询下

wpsF0C0.tmp_.jpg

wpsF0C1.tmp_.jpg

启动B集群,查看,已自动添加了新的文档

wpsF0C2.tmp_.jpg

4. 主集群容灾切换

目的:主集群故障,短时间不可用,网关切换指向备集群作为主集群,A集群作为备集群;待A集群恢复后,自动追数据

KILL A 集群 模拟A集群故障

Kill 网关,切换配置:

wpsF0C3.tmp_.jpg

启动网关,B是主了,available

wpsF0C4.tmp_.jpg

写B集群,删除前面创建的 test 索引,新建test2索引,并插入文档

wpsF0C5.tmp_.jpg

wpsF0D6.tmp_.jpg

启动A集群,检查数据,有test2索引,且文档一致

wpsF0D7.tmp_.jpg

5. 主集群故障恢复后,网关回切

目的:假设A集群已经完全恢复,网关回切,A集群为主,B集群为备

Kill网关,恢复配置,再启动网关

再次测试写入test2 检查能否同步成功

写网关

wpsF0D8.tmp_.jpg

查看A集群

wpsF0D9.tmp_.jpg

查看B集群

wpsF0DA.tmp_.jpg

两个集群数据一致,主备角色也恢复到最初了

**测试环境变更

中间工作比较忙,中断了测试,也就十来天吧

不成想 网关更新了,我就下了新版本的gateway和ES-7.15.1 继续捣鼓

环境 笔记本

主集群:es-751primary 7.15.1 10.0.2.15:7151 No:Rbac、tls 节点数:1
备集群:es-751backup 7.15.1 10.0.2.15:7152 No:Rbac、tls 节点数:1
极限网关 场景6:1.4.0场景7:1.5.0 0.0.0.0:8000 No:tls 实例数:1

wpsF0DB.tmp_.jpg

网关不光版本升级了,配置文件也稍稍有些变化,新版本示例配置如下

wpsF0DC.tmp_.jpg

本着不会就猜的原则,我还是能做到见名之知意的

我仅仅对 cross-cluster-replication.yml 做了简单的修改,就是和前面一样

6. ES由代理暴露的能否正常工作

目的:检验,比如由nginx代理ES的时候,网关能否正常工作

使用 nginx 代理后端的ES

80-->primary

81-->backup

wpsF0DD.tmp_.jpg

测试下反向代理工作是否正常

wpsF0DE.tmp_.jpg

启动网关,网关里elasticsearch资源指向nginx,没错就改了下 url

wpsF0DF.tmp_.jpg

开始测试,增删改查 once more,还是对着网关操作

创建索引

wpsF0E0.tmp_.jpg

PUT 文档

wpsF0F0.tmp_.jpg

抄家伙

wpsF0F1.tmp_.jpg

看看数量

wpsF0F2.tmp_.jpg

简单对比下

wpsF0F3.tmp_.jpg
给 code为500的文档增加一个字段 new_field

wpsF0F4.tmp_.jpg

直接通过代理查询,检验数据

wpsF0F5.tmp_.jpg

没问题,测试删除

删除单条

wpsF0F6.tmp_.jpg

wpsF0F7.tmp_.jpg

wpsF0F8.tmp_.jpg

批量删除

wpsF0F9.tmp_.jpg

看看结果

wpsF0FA.tmp_.jpg

删除索引,并确认真的删除

wpsF10B.tmp_.jpg

关调backup集群,然后primary集群创建索引后,再启动backup集群,看能否自动追平

wpsF10C.tmp_.jpg

创建test2索引

wpsF10D.tmp_.jpg

顺手put个文档

wpsF10E.tmp_.jpg

Primary上查看

wpsF10F.tmp_.jpg

OK 启动backup

wpsF110.tmp_.jpg

妈的 奇迹

7. 请求压缩功能如何

目的:看看客户端和网关分别在不同的请求压缩配置下,是否工作正常

在网关的配置中,看到了 compress 压缩,也设计几个场景测试下

网关配置里面有个压缩的配置,意思是消费线程往ES发送请求的时候是否启用gzip压缩。

默认是 true

wpsF111.tmp_.jpg

7.1 用压缩的方式写网关,但网关不启用压缩

我们把网关配置中的true改成false

wpsF112.tmp_.jpg

启动网关

wpsF113.tmp_.jpg

开始写数据,写的过程中,随机停止backup集群,等待一会儿后再启动

wpsF114.tmp_.jpg

网关可看到 backup集群,从不可用到可用

wpsF115.tmp_.jpg

看看网关的队列情况,这时候backup队列应该堆积了不少请求

wpsF116.tmp_.jpg

等待队列被消费完后,我们对比数据。

wpsF117.tmp_.jpg

简单看看文档条数

wpsF128.tmp_.jpg

wpsF129.tmp_.jpg

用网关对比下数据看看

wpsF12A.tmp_.jpg

妥妥的一致

7.2 用压缩的方式写网关,网关也启用压缩

就把前面网关贴图的false改成true

启动网关

wpsF12B.tmp_.jpg

压缩写入

wpsF12C.tmp_.jpg

写入过程中,随机重启backup集群

网关日志

wpsF12D.tmp_.jpg

等待网关backup队列消费完毕,后对比数据

wpsF12E.tmp_.jpg

wpsF12F.tmp_.jpg

没得问题,下一场

7.3 用不压缩的方式写网关,网关也不启用压缩

网关配置compress: false,后启动网关

wpsF130.tmp_.jpg

不压缩请求

wpsF131.tmp_.jpg

中途随机重启backup集群

wpsF132.tmp_.jpg

队列消费完后对比数据

wpsF133.tmp_.jpg

数据一致

7.4 用不压缩的方式写网关,网关backup队列的消费线程使用压缩

wpsF134.tmp_.jpg

写入过程中,停止backup集群,稍等一会儿后启动backup集群

wpsF135.tmp_.jpg

观察网关的backup 队列情况

wpsF145.tmp_.jpg

等消费完之后,我们对比数据

数量一致

wpsF146.tmp_.jpg

wpsF147.tmp_.jpg

用网关来对比下两个集群的test索引的数据

wpsF148.tmp_.jpg

至此,关于跨集群复制的场景测试可以告一段落了,功能大家也看到了确实强大,部署也很灵活,对环境无侵入,直接把应用连接ES的地址、端口改下就行。或者网关直接监听9200端口,替换原有的协调节点,应用无感知。

此外,极限网关还有很多别的使用场景和激动人心的功能,像在线修改查询、请求限流、请求流量分析,这都是保障ES集群稳定运行的手段。

看到一款国产软件如此强大很欣慰,很激动。希望各位感兴趣的小伙伴也下载测试下自己的场景,我们ES圈(论坛)多交流交流。让我也看看你们的场景和测试是怎样的。

最后一个图,我也不知道咋回事,请忽略。

继续阅读 »

ES灾备技术调研

早就听说极限网关了,最近有个ES要做灾备,就搜集了下技术方案:

  1. 应用双写两个集群

  2. 跨集群复制CCR

  3. 极限网关

三个方案的优缺点我也简单整理了下:

  1. 优点:自主研发,想怎样就怎样;缺点:难,水平、时间都是成本

  2. 优点:实施简单;缺点:需要license

  3. 优点:部署灵活,功能齐全;缺点:不熟悉,没用过

貌似方案 3,比较理想。不熟悉,那就多用用,测试测试找找感觉。

测试环境 笔记本

主集群:A 7.14.1 10.0.2.15:9214 Rbac+tls 节点数:1
备集群:B 7.13.2 10.0.2.15:9213 Rbac+tls 节点数:2
极限网关 1.3.0 0.0.0.0:8000 tls 实例数:1

wpsF088.tmp_.jpg

wpsF089.tmp_.jpg

网关下载

先下载极限网关:http://release.elasticsearch.cn/gateway/snapshot/

解压后,可看到有几个预定义的配置,方便大家快速上车。

wpsF08A.tmp_.jpg

网关配置

这次是做灾备,应该就是在 dc-replica.yml的基础上改比较妥当,配置还是比较多的 300多行,很多都是为了保证两个集群数据一致性,解耦啥的做的判断和写队列之类的设置。我只修改了 elasticsearch资源的定义信息,还有网关也可选择tls,不用手工生成证书,非常方便。

贴下我修改的地方

wpsF08B.tmp_.jpg

wpsF08C.tmp_.jpg

启动网关

wpsF08D.tmp_.jpg

两个集群都是 available ,说明连接应该ok

测试场景:围绕主备集群之间数据复制展开

1. 主备集群间复制创建、写入、删除索引操作

目的:对网关(A集群)创建索引test,对test索引写文档,能自动同步到B集群

初始情况A、B无test

wpsF09E.tmp_.jpg
wpsF09F.tmp_.jpg

手工put test索引到网关

wpsF0A0.tmp_.jpg
wpsF0A1.tmp_.jpg
wpsF0A2.tmp_.jpg
A,B集群都创建成功

用loadgen写点文档进去吧,loadgen直接写网关

wpsF0A3.tmp_.jpg

wpsF0A4.tmp_.jpg

wpsF0A5.tmp_.jpg

都10000条写入成功,如果查看是0的话,先refresh下索引

看下文档

wpsF0A6.tmp_.jpg

简单校验一下

wpsF0A7.tmp_.jpg

wpsF0A8.tmp_.jpg

感觉没问题,删点文档看看,把那23个删了吧

wpsF0A9.tmp_.jpg

再看看

wpsF0AA.tmp_.jpg

wpsF0BA.tmp_.jpg

更新524个文档看看

wpsF0BB.tmp_.jpg

wpsF0BC.tmp_.jpg

wpsF0BD.tmp_.jpg

增、删、改 完事

2. 主集群故障的处理和恢复

目的:主集群故障后,网关如何处理收到的请求:读、写

Kill 掉 A 集群,模拟主集群故障

网关直接有报错说连不上A集群

此时对网关查询、写入数据都会报错

wpsF0BE.tmp_.jpg

重新启动主集群后,一切正常

3. 备集群故障的处理和恢复

目的:备集群故障,读、写主集群不受影响,备集群恢复后,自动追数据直到两边数据一致

Kill 掉B集群,网关报错,B集群无法连接

wpsF0BF.tmp_.jpg

对A集群进行写入一个新文档,并查询下

wpsF0C0.tmp_.jpg

wpsF0C1.tmp_.jpg

启动B集群,查看,已自动添加了新的文档

wpsF0C2.tmp_.jpg

4. 主集群容灾切换

目的:主集群故障,短时间不可用,网关切换指向备集群作为主集群,A集群作为备集群;待A集群恢复后,自动追数据

KILL A 集群 模拟A集群故障

Kill 网关,切换配置:

wpsF0C3.tmp_.jpg

启动网关,B是主了,available

wpsF0C4.tmp_.jpg

写B集群,删除前面创建的 test 索引,新建test2索引,并插入文档

wpsF0C5.tmp_.jpg

wpsF0D6.tmp_.jpg

启动A集群,检查数据,有test2索引,且文档一致

wpsF0D7.tmp_.jpg

5. 主集群故障恢复后,网关回切

目的:假设A集群已经完全恢复,网关回切,A集群为主,B集群为备

Kill网关,恢复配置,再启动网关

再次测试写入test2 检查能否同步成功

写网关

wpsF0D8.tmp_.jpg

查看A集群

wpsF0D9.tmp_.jpg

查看B集群

wpsF0DA.tmp_.jpg

两个集群数据一致,主备角色也恢复到最初了

**测试环境变更

中间工作比较忙,中断了测试,也就十来天吧

不成想 网关更新了,我就下了新版本的gateway和ES-7.15.1 继续捣鼓

环境 笔记本

主集群:es-751primary 7.15.1 10.0.2.15:7151 No:Rbac、tls 节点数:1
备集群:es-751backup 7.15.1 10.0.2.15:7152 No:Rbac、tls 节点数:1
极限网关 场景6:1.4.0场景7:1.5.0 0.0.0.0:8000 No:tls 实例数:1

wpsF0DB.tmp_.jpg

网关不光版本升级了,配置文件也稍稍有些变化,新版本示例配置如下

wpsF0DC.tmp_.jpg

本着不会就猜的原则,我还是能做到见名之知意的

我仅仅对 cross-cluster-replication.yml 做了简单的修改,就是和前面一样

6. ES由代理暴露的能否正常工作

目的:检验,比如由nginx代理ES的时候,网关能否正常工作

使用 nginx 代理后端的ES

80-->primary

81-->backup

wpsF0DD.tmp_.jpg

测试下反向代理工作是否正常

wpsF0DE.tmp_.jpg

启动网关,网关里elasticsearch资源指向nginx,没错就改了下 url

wpsF0DF.tmp_.jpg

开始测试,增删改查 once more,还是对着网关操作

创建索引

wpsF0E0.tmp_.jpg

PUT 文档

wpsF0F0.tmp_.jpg

抄家伙

wpsF0F1.tmp_.jpg

看看数量

wpsF0F2.tmp_.jpg

简单对比下

wpsF0F3.tmp_.jpg
给 code为500的文档增加一个字段 new_field

wpsF0F4.tmp_.jpg

直接通过代理查询,检验数据

wpsF0F5.tmp_.jpg

没问题,测试删除

删除单条

wpsF0F6.tmp_.jpg

wpsF0F7.tmp_.jpg

wpsF0F8.tmp_.jpg

批量删除

wpsF0F9.tmp_.jpg

看看结果

wpsF0FA.tmp_.jpg

删除索引,并确认真的删除

wpsF10B.tmp_.jpg

关调backup集群,然后primary集群创建索引后,再启动backup集群,看能否自动追平

wpsF10C.tmp_.jpg

创建test2索引

wpsF10D.tmp_.jpg

顺手put个文档

wpsF10E.tmp_.jpg

Primary上查看

wpsF10F.tmp_.jpg

OK 启动backup

wpsF110.tmp_.jpg

妈的 奇迹

7. 请求压缩功能如何

目的:看看客户端和网关分别在不同的请求压缩配置下,是否工作正常

在网关的配置中,看到了 compress 压缩,也设计几个场景测试下

网关配置里面有个压缩的配置,意思是消费线程往ES发送请求的时候是否启用gzip压缩。

默认是 true

wpsF111.tmp_.jpg

7.1 用压缩的方式写网关,但网关不启用压缩

我们把网关配置中的true改成false

wpsF112.tmp_.jpg

启动网关

wpsF113.tmp_.jpg

开始写数据,写的过程中,随机停止backup集群,等待一会儿后再启动

wpsF114.tmp_.jpg

网关可看到 backup集群,从不可用到可用

wpsF115.tmp_.jpg

看看网关的队列情况,这时候backup队列应该堆积了不少请求

wpsF116.tmp_.jpg

等待队列被消费完后,我们对比数据。

wpsF117.tmp_.jpg

简单看看文档条数

wpsF128.tmp_.jpg

wpsF129.tmp_.jpg

用网关对比下数据看看

wpsF12A.tmp_.jpg

妥妥的一致

7.2 用压缩的方式写网关,网关也启用压缩

就把前面网关贴图的false改成true

启动网关

wpsF12B.tmp_.jpg

压缩写入

wpsF12C.tmp_.jpg

写入过程中,随机重启backup集群

网关日志

wpsF12D.tmp_.jpg

等待网关backup队列消费完毕,后对比数据

wpsF12E.tmp_.jpg

wpsF12F.tmp_.jpg

没得问题,下一场

7.3 用不压缩的方式写网关,网关也不启用压缩

网关配置compress: false,后启动网关

wpsF130.tmp_.jpg

不压缩请求

wpsF131.tmp_.jpg

中途随机重启backup集群

wpsF132.tmp_.jpg

队列消费完后对比数据

wpsF133.tmp_.jpg

数据一致

7.4 用不压缩的方式写网关,网关backup队列的消费线程使用压缩

wpsF134.tmp_.jpg

写入过程中,停止backup集群,稍等一会儿后启动backup集群

wpsF135.tmp_.jpg

观察网关的backup 队列情况

wpsF145.tmp_.jpg

等消费完之后,我们对比数据

数量一致

wpsF146.tmp_.jpg

wpsF147.tmp_.jpg

用网关来对比下两个集群的test索引的数据

wpsF148.tmp_.jpg

至此,关于跨集群复制的场景测试可以告一段落了,功能大家也看到了确实强大,部署也很灵活,对环境无侵入,直接把应用连接ES的地址、端口改下就行。或者网关直接监听9200端口,替换原有的协调节点,应用无感知。

此外,极限网关还有很多别的使用场景和激动人心的功能,像在线修改查询、请求限流、请求流量分析,这都是保障ES集群稳定运行的手段。

看到一款国产软件如此强大很欣慰,很激动。希望各位感兴趣的小伙伴也下载测试下自己的场景,我们ES圈(论坛)多交流交流。让我也看看你们的场景和测试是怎样的。

最后一个图,我也不知道咋回事,请忽略。

收起阅读 »

Elasticsearch:从 Spring Boot 应用中连接 Elasticsearch

我将使用库 spring-boot-starter-data-elasticsearch  来和 Elasticsearch 进行连接。这种方法非常简单直接。 https://elasticstack.blog.csdn ... 58680
继续阅读 »
我将使用库 spring-boot-starter-data-elasticsearch  来和 Elasticsearch 进行连接。这种方法非常简单直接。 https://elasticstack.blog.csdn ... 58680 收起阅读 »

社区日报 第1233期 (2021-10-24)

1. 使用Elastic Stack 称为可观测性专家
https://blog.csdn.net/UbuntuTo ... 50836

2. ElasticSearch从0到集群高可用实战
https://www.jianshu.com/p/dd877bc6cacb

3. Elasticsearch 高基数聚合性能提升3倍,改动了什么?
https://mp.weixin.qq.com/s/scLGwTj_zlOPtWZCtDJtRQ

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. 使用Elastic Stack 称为可观测性专家
https://blog.csdn.net/UbuntuTo ... 50836

2. ElasticSearch从0到集群高可用实战
https://www.jianshu.com/p/dd877bc6cacb

3. Elasticsearch 高基数聚合性能提升3倍,改动了什么?
https://mp.weixin.qq.com/s/scLGwTj_zlOPtWZCtDJtRQ

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

Elastic中文社区网站新增文章投稿功能

Elastic中文社区网站新增文章投稿功能。

如果您有Elastic技术栈相关的文章想分享,可以在本站发表原创文章,或者以站外投稿(已在其他站点发表过)的方式进行发布,站外投稿就无需再重复编辑整个文章内容了,仅需要提供文章标题、摘要、稿源、链接基本信息即可。

怎么发布站外投稿文章呢?

1.入口
注册登录本站后,鼠标移动到网站右上角的“发起”按钮会弹出下拉选项,选中“文章”点击即可。如下图示例:
WechatIMG318.png

2.编辑&发布
文章类型选择站外投稿,填写文章来源、文章链接、文章标题、文章内容摘要等稿源信息后提交即可。如下图示例:
WechatIMG320.png

3.修改更新
如发布之后需要修改,可在文章详情界面点击编辑进行内容更新。如下图示例:
WechatIMG319.png

本站Elastic中文社区将持续整合Elastic相关最新的技术文章和资讯供大家阅览,欢迎大家在本站发布原创文章或投稿。
如有疑问或建议,欢迎在评论区留言反馈。
继续阅读 »
Elastic中文社区网站新增文章投稿功能。

如果您有Elastic技术栈相关的文章想分享,可以在本站发表原创文章,或者以站外投稿(已在其他站点发表过)的方式进行发布,站外投稿就无需再重复编辑整个文章内容了,仅需要提供文章标题、摘要、稿源、链接基本信息即可。

怎么发布站外投稿文章呢?

1.入口
注册登录本站后,鼠标移动到网站右上角的“发起”按钮会弹出下拉选项,选中“文章”点击即可。如下图示例:
WechatIMG318.png

2.编辑&发布
文章类型选择站外投稿,填写文章来源、文章链接、文章标题、文章内容摘要等稿源信息后提交即可。如下图示例:
WechatIMG320.png

3.修改更新
如发布之后需要修改,可在文章详情界面点击编辑进行内容更新。如下图示例:
WechatIMG319.png

本站Elastic中文社区将持续整合Elastic相关最新的技术文章和资讯供大家阅览,欢迎大家在本站发布原创文章或投稿。
如有疑问或建议,欢迎在评论区留言反馈。 收起阅读 »

社区日报 第1231期 (2021-10-15)

1、使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求
https://elasticsearch.cn/article/14390
 
2、给Zblogphp插上Elasticsearch的翅膀
https://elasticsearch.cn/article/14389
 
3、Elasticsearch more like this 案例解读
https://qbox.io/blog/mlt-simil ... uery/
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1、使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求
https://elasticsearch.cn/article/14390
 
2、给Zblogphp插上Elasticsearch的翅膀
https://elasticsearch.cn/article/14389
 
3、Elasticsearch more like this 案例解读
https://qbox.io/blog/mlt-simil ... uery/
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求

使用场景

如果你的业务需要用到有多个集群,并且版本还不一样,是不是管理起来很麻烦,如果能够通过一个 API 来进行查询就方便了,聪明的你相信已经想到了 CCS,没错用 CCS 可以实现跨集群的查询,不过 Elasticsearch 提供的 CCS 对版本有一点的限制,并且需要提前做好 mTLS,也就是需要提前配置好两个集群之间的证书互信,这个免不了要重启维护,好像有点麻烦,那么问题来咯,有没有更好的方案呢?

😁 有办法,今天我就给大家介绍一个基于极限网关的方案,极限网关的网址:http://极限网关.com/

假设现在有两个集群,一个集群是 v2.4.6,有不少业务数据,舍不得删,里面有很多好东西 :)还有一个集群是 v7.14.0,版本还算比较新,业务正在做的一个新的试点,没什么好东西,但是也得用 :(,现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据,程序员懒得很,懂得都懂。

集群信息

  • v2.4.6 集群的访问入口地址:192.168.3.188:9202
  • v7.14.0 集群的访问入口地址:192.168.3.188:9206

这两个集群都是 http 协议的。

实现步骤

今天用到的是极限网关的 switch 过滤器:https://极限网关.com/docs/references/filters/switch/

网关下载下来就两个文件,一个主程序,一个配置文件,记得下载对应操作系统的包。

定义两个集群资源

elasticsearch:
  - name: v2
    enabled: true
    endpoint: http://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: http://192.168.3.188:9206

上面定义了两个集群,分别命名为 v2v7,待会会用到这些资源。

定义一个服务入口

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 1000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

这里定义了一个名为 my_es_entry 的资源入口,并引用了一个名为 my_router 的请求转发路由,同时绑定了网卡的 0.0.0.0:8000 也就是所有本地网卡监听 IP 的 8000 端口,访问任意 IP 的 8000 端口就能访问到这个网关了。

另外老板也说了,Elasticsearch 用 HTTP 协议简直就是裸奔,通过这里开启 tls,可以让网关对外提供的是 HTTPS 协议,这样用户连接的 Elasticsearch 服务就自带 buffer 了,后端的 es 集群和网关直接可以做好网络流量隔离,集群不用动,简直完美。

为什么定义 TLS 不用指定证书,好用的软件不需要这么麻烦,就这样,不解释。

最后,通过设置 max_concurrency 为 1000,限制下并发数,避免野猴子把我们的后端的 Elasticsearch 给压挂了。

定义一个请求路由

router:
  - name: my_router
    default_flow: cross-cluster-search

这里的名称 my_router 就是表示上面的服务入口的router 参数指定的值。

另外设置一个 default_flow 来将所有的请求都转发给一个名为 cross-cluster-search 的请求处理流程,还没定义,别急,马上。

定义请求处理流程

来啦,来啦,先定义两个 flow,如下,分别名为 v2-flowv7-flow,每节配置的 filter 定义了一系列过滤器,用来对请求进行处理,这里就用了一个 elasticsearch 过滤器,也就是转发请求给指定的 Elasticsearch 后端服务器,了否?

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7

然后,在定义额外一个名为 cross-cluster-search 的 flow,如下:

  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow

这个 flow 就是通过请求的路径的前缀来进行路由的过滤器,如果是 v2:开头的请求,则转发给 v2-flow 继续处理,如果是 v7: 开头的请求,则转发给 v7-flow 来处理,使用的用法和 CCS 是一样的。so easy!

对了,那是不是每个请求都需要加前缀啊,费事啊,没事,在这个 cross-cluster-search 的 filter 最后再加上一个 elasticsearch filter,前面前缀匹配不上的都会走它,假设默认都走 v7,最后完整的 flow 配置如下:

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7              

然后就没有然后了,因为就配置这些就行了。

启动网关

假设配置文件的路径为 sample-configs/cross-cluster-search.yml,运行如下命令:

➜  gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd
[10-16 11:00:52] [INF] [app.go:228] initializing gateway.
[10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0
[10-16 11:00:52] [INF] [api.go:260] api listen at: http://0.0.0.0:2900
[10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]
[10-16 11:00:52] [INF] [entry.go:225] auto generating cert files
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available
[10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: https://0.0.0.0:8000
[10-16 11:00:53] [INF] [app.go:309] gateway is running now.

可以看到网关输出了启动成功的日志,网关服务监听在 https://0.0.0.0:8000

试试访问网关

直接访问网关的 8000 端口,因为是网关自签的证书,加上 -k 来跳过证书的校验,如下:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000  
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

正如前面配置所配置的一样,默认请求访问的就是 v7 集群。

访问 v2 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:/    
{
  "name" : "Solomon O'Sullivan",
  "cluster_name" : "es-v246",
  "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",
  "version" : {
    "number" : "2.4.6",
    "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",
    "build_timestamp" : "2017-07-18T12:17:44Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.4"
  },
  "tagline" : "You Know, for Search"
}

查看集群信息:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:_cluster/health\?pretty
{
  "cluster_name" : "es-v246",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 5,
  "active_shards" : 5,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 5,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

插入一条文档:

➜  loadgen git:(master) ✗ curl-json -k   https://localhost:8000/v2:medcl/doc/1 -d '{"name":"hello world"}'
{"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}%  

执行一个查询

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:medcl/_search\?q\=name:hello                
{"took":78,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":0.19178301,"hits":[{"_index":"medcl","_type":"doc","_id":"1","_score":0.19178301,"_source":{"name":"hello world"}}]}}% 

可以看到,所有的请求,不管是集群的操作,还是索引的增删改查都可以,而 Elasticsearch 自带的 CCS 是只读的,只能进行查询。

访问 v7 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v7:/
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Kibana 里面访问

完全没问题,有图有真相:

Jietu20211016-114041.jpg

其他操作也类似,就不重复了。

完整的配置

path.data: data
path.logs: log

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7

router:
  - name: my_router
    default_flow: cross-cluster-search

elasticsearch:
  - name: v2
    enabled: true
    endpoint: http://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: http://192.168.3.188:9206

小结

好了,今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了,希望大家周末玩的开心。😁

继续阅读 »

使用场景

如果你的业务需要用到有多个集群,并且版本还不一样,是不是管理起来很麻烦,如果能够通过一个 API 来进行查询就方便了,聪明的你相信已经想到了 CCS,没错用 CCS 可以实现跨集群的查询,不过 Elasticsearch 提供的 CCS 对版本有一点的限制,并且需要提前做好 mTLS,也就是需要提前配置好两个集群之间的证书互信,这个免不了要重启维护,好像有点麻烦,那么问题来咯,有没有更好的方案呢?

😁 有办法,今天我就给大家介绍一个基于极限网关的方案,极限网关的网址:http://极限网关.com/

假设现在有两个集群,一个集群是 v2.4.6,有不少业务数据,舍不得删,里面有很多好东西 :)还有一个集群是 v7.14.0,版本还算比较新,业务正在做的一个新的试点,没什么好东西,但是也得用 :(,现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据,程序员懒得很,懂得都懂。

集群信息

  • v2.4.6 集群的访问入口地址:192.168.3.188:9202
  • v7.14.0 集群的访问入口地址:192.168.3.188:9206

这两个集群都是 http 协议的。

实现步骤

今天用到的是极限网关的 switch 过滤器:https://极限网关.com/docs/references/filters/switch/

网关下载下来就两个文件,一个主程序,一个配置文件,记得下载对应操作系统的包。

定义两个集群资源

elasticsearch:
  - name: v2
    enabled: true
    endpoint: http://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: http://192.168.3.188:9206

上面定义了两个集群,分别命名为 v2v7,待会会用到这些资源。

定义一个服务入口

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 1000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

这里定义了一个名为 my_es_entry 的资源入口,并引用了一个名为 my_router 的请求转发路由,同时绑定了网卡的 0.0.0.0:8000 也就是所有本地网卡监听 IP 的 8000 端口,访问任意 IP 的 8000 端口就能访问到这个网关了。

另外老板也说了,Elasticsearch 用 HTTP 协议简直就是裸奔,通过这里开启 tls,可以让网关对外提供的是 HTTPS 协议,这样用户连接的 Elasticsearch 服务就自带 buffer 了,后端的 es 集群和网关直接可以做好网络流量隔离,集群不用动,简直完美。

为什么定义 TLS 不用指定证书,好用的软件不需要这么麻烦,就这样,不解释。

最后,通过设置 max_concurrency 为 1000,限制下并发数,避免野猴子把我们的后端的 Elasticsearch 给压挂了。

定义一个请求路由

router:
  - name: my_router
    default_flow: cross-cluster-search

这里的名称 my_router 就是表示上面的服务入口的router 参数指定的值。

另外设置一个 default_flow 来将所有的请求都转发给一个名为 cross-cluster-search 的请求处理流程,还没定义,别急,马上。

定义请求处理流程

来啦,来啦,先定义两个 flow,如下,分别名为 v2-flowv7-flow,每节配置的 filter 定义了一系列过滤器,用来对请求进行处理,这里就用了一个 elasticsearch 过滤器,也就是转发请求给指定的 Elasticsearch 后端服务器,了否?

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7

然后,在定义额外一个名为 cross-cluster-search 的 flow,如下:

  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow

这个 flow 就是通过请求的路径的前缀来进行路由的过滤器,如果是 v2:开头的请求,则转发给 v2-flow 继续处理,如果是 v7: 开头的请求,则转发给 v7-flow 来处理,使用的用法和 CCS 是一样的。so easy!

对了,那是不是每个请求都需要加前缀啊,费事啊,没事,在这个 cross-cluster-search 的 filter 最后再加上一个 elasticsearch filter,前面前缀匹配不上的都会走它,假设默认都走 v7,最后完整的 flow 配置如下:

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7              

然后就没有然后了,因为就配置这些就行了。

启动网关

假设配置文件的路径为 sample-configs/cross-cluster-search.yml,运行如下命令:

➜  gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml
   ___   _   _____  __  __    __  _       
  / _ \ /_\ /__   \/__\/ / /\ \ \/_\ /\_/\
 / /_\///_\\  / /\/_\  \ \/  \/ //_\\\_ _/
/ /_\\/  _  \/ / //__   \  /\  /  _  \/ \ 
\____/\_/ \_/\/  \__/    \/  \/\_/ \_/\_/ 

[GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
[GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd
[10-16 11:00:52] [INF] [app.go:228] initializing gateway.
[10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0
[10-16 11:00:52] [INF] [api.go:260] api listen at: http://0.0.0.0:2900
[10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]
[10-16 11:00:52] [INF] [entry.go:225] auto generating cert files
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available
[10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available
[10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: https://0.0.0.0:8000
[10-16 11:00:53] [INF] [app.go:309] gateway is running now.

可以看到网关输出了启动成功的日志,网关服务监听在 https://0.0.0.0:8000

试试访问网关

直接访问网关的 8000 端口,因为是网关自签的证书,加上 -k 来跳过证书的校验,如下:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000  
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

正如前面配置所配置的一样,默认请求访问的就是 v7 集群。

访问 v2 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:/    
{
  "name" : "Solomon O'Sullivan",
  "cluster_name" : "es-v246",
  "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",
  "version" : {
    "number" : "2.4.6",
    "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",
    "build_timestamp" : "2017-07-18T12:17:44Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.4"
  },
  "tagline" : "You Know, for Search"
}

查看集群信息:

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:_cluster/health\?pretty
{
  "cluster_name" : "es-v246",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 5,
  "active_shards" : 5,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 5,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

插入一条文档:

➜  loadgen git:(master) ✗ curl-json -k   https://localhost:8000/v2:medcl/doc/1 -d '{"name":"hello world"}'
{"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}%  

执行一个查询

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v2:medcl/_search\?q\=name:hello                
{"took":78,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max_score":0.19178301,"hits":[{"_index":"medcl","_type":"doc","_id":"1","_score":0.19178301,"_source":{"name":"hello world"}}]}}% 

可以看到,所有的请求,不管是集群的操作,还是索引的增删改查都可以,而 Elasticsearch 自带的 CCS 是只读的,只能进行查询。

访问 v7 集群

➜  loadgen git:(master) ✗ curl -k   https://localhost:8000/v7:/
{
  "name" : "LENOVO",
  "cluster_name" : "es-v7140",
  "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",
  "version" : {
    "number" : "7.14.0",
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",
    "build_date" : "2021-07-29T20:49:32.864135063Z",
    "build_snapshot" : false,
    "lucene_version" : "8.9.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

Kibana 里面访问

完全没问题,有图有真相:

Jietu20211016-114041.jpg

其他操作也类似,就不重复了。

完整的配置

path.data: data
path.logs: log

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: 0.0.0.0:8000
    tls:
      enabled: true

flow:
  - name: v2-flow
    filter:
      - elasticsearch:
          elasticsearch: v2
  - name: v7-flow
    filter:
      - elasticsearch:
          elasticsearch: v7
  - name: cross-cluster-search
    filter:
      - switch:
          path_rules:
            - prefix: "v2:"
              flow: v2-flow
            - prefix: "v7:"
              flow: v7-flow
      - elasticsearch:
          elasticsearch: v7

router:
  - name: my_router
    default_flow: cross-cluster-search

elasticsearch:
  - name: v2
    enabled: true
    endpoint: http://192.168.3.188:9202
  - name: v7
    enabled: true
    endpoint: http://192.168.3.188:9206

小结

好了,今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了,希望大家周末玩的开心。😁

收起阅读 »

给Zblogphp插上Elasticsearch的翅膀

# 给Zblogphp插上Elasticsearch的翅膀



找遍了zblog的应用中心,未发现有使用Elasticsearch搜索引擎的插件。国庆闲来无事,根据zblogphp的机制,开发了一个基于Elasticsearch的插件。

本插件使用简单,需要有一个Elasticsearch7.x的环境(基于7.x版本开发),Elasticsearch 安装[IK](https://github.com/medcl/elasticsearch-analysis-ik)、[pinyin](https://github.com/medcl/elast ... pinyin),[中文简繁體转换](https://github.com/medcl/elast ... onvert) 插件。安装好该插件后,只需要配置好账号密码,点击创建索引模板即可。发布和编辑文章时,会自动根据索引模板,创建post索引,同步文章数据。搜索时,直接接管原有的搜索逻辑,无需调整程序和模板。

后台配置截图:


123.jpg



配置好连接,端口,账号和密码,点击“测试连接”,弹出连接成功,展示版本号,即可点击保存配置,如果这4项错误,连接不上Elasticsearch,获取不到ES的版本号,将无法保存配置。



Dingtalk_20211009115321.jpg




看到这个提示,便可以点击“保持配置”。这里有一项“切换搜索 Elasticsearch”,开启,前端搜索即切换到了Elastisearch搜索引擎。


234.jpg



在配置好了基本设置以后,点击索引模板,可以预览到索引模板,点击“创建索引模板”,即可在Elasticsearch服务器创建好索引模板,成功后,会在说明栏展示绿色的“已创建”,如果未创建,展示红色的“未创建”。发布和编辑文章时,会根据该索引模板,自动创建好索引,同步文章。



以下是搜索效果截图:

345.jpg

继续阅读 »
# 给Zblogphp插上Elasticsearch的翅膀



找遍了zblog的应用中心,未发现有使用Elasticsearch搜索引擎的插件。国庆闲来无事,根据zblogphp的机制,开发了一个基于Elasticsearch的插件。

本插件使用简单,需要有一个Elasticsearch7.x的环境(基于7.x版本开发),Elasticsearch 安装[IK](https://github.com/medcl/elasticsearch-analysis-ik)、[pinyin](https://github.com/medcl/elast ... pinyin),[中文简繁體转换](https://github.com/medcl/elast ... onvert) 插件。安装好该插件后,只需要配置好账号密码,点击创建索引模板即可。发布和编辑文章时,会自动根据索引模板,创建post索引,同步文章数据。搜索时,直接接管原有的搜索逻辑,无需调整程序和模板。

后台配置截图:


123.jpg



配置好连接,端口,账号和密码,点击“测试连接”,弹出连接成功,展示版本号,即可点击保存配置,如果这4项错误,连接不上Elasticsearch,获取不到ES的版本号,将无法保存配置。



Dingtalk_20211009115321.jpg




看到这个提示,便可以点击“保持配置”。这里有一项“切换搜索 Elasticsearch”,开启,前端搜索即切换到了Elastisearch搜索引擎。


234.jpg



在配置好了基本设置以后,点击索引模板,可以预览到索引模板,点击“创建索引模板”,即可在Elasticsearch服务器创建好索引模板,成功后,会在说明栏展示绿色的“已创建”,如果未创建,展示红色的“未创建”。发布和编辑文章时,会根据该索引模板,自动创建好索引,同步文章。



以下是搜索效果截图:

345.jpg

收起阅读 »

@wt 社区日报 第1230期 (2021-10-11)

1. elastic stack uptime 监控功能实践
https://mp.weixin.qq.com/s/6Lt7YTotrlkyVuFJKR2l_g

2. Filebeat 实现剖析
https://mp.weixin.qq.com/s/RJed7ZBzvHdH0hFkWZekBw

3.从分布式一致性算法到区块链共识机制
https://mp.weixin.qq.com/s/LOUDWn7evcePCPGWar8vEA

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. elastic stack uptime 监控功能实践
https://mp.weixin.qq.com/s/6Lt7YTotrlkyVuFJKR2l_g

2. Filebeat 实现剖析
https://mp.weixin.qq.com/s/RJed7ZBzvHdH0hFkWZekBw

3.从分布式一致性算法到区块链共识机制
https://mp.weixin.qq.com/s/LOUDWn7evcePCPGWar8vEA

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

通过python脚本迁移ES的template模板

通过python脚本迁移ES的template模板

通过python脚本迁移ES的template模板,从192.168.0.1 迁移到 192.168.0.2

import base64
import json

import requests

def putTemplate(templateName, templateDslJson):
    print("{0} 索引模板正在迁移中".format(templateName))

    res = requests.put("http://192.168.0.2:9200/_template/{0}".format(templateName), json=templateDslJson)
    print(res.status_code)
    print(res.content)

def getTemplateDslJson():
    username = "elastic"
    password = "123456"
    user_info_str = username + ":" + password
    user_info = base64.b64encode(user_info_str.encode())  # 这个得到是个字节类型的数据
    headers = {
        "Authorization": "Basic {0}".format(user_info.decode())  # 这个就是需要验证的信息
    }
    url = "http://192.168.0.1:9200/_template/*_template"
    res = requests.get(url, headers=headers)
    print(res.status_code)
    return json.loads(res.content)

if __name__ == '__main__':
    jsonTemplate = getTemplateDslJson()
    if isinstance(jsonTemplate, dict):
        for templateName in jsonTemplate:
            templateDslJson = jsonTemplate[templateName]
            putTemplate(templateName, templateDslJson)
继续阅读 »

通过python脚本迁移ES的template模板

通过python脚本迁移ES的template模板,从192.168.0.1 迁移到 192.168.0.2

import base64
import json

import requests

def putTemplate(templateName, templateDslJson):
    print("{0} 索引模板正在迁移中".format(templateName))

    res = requests.put("http://192.168.0.2:9200/_template/{0}".format(templateName), json=templateDslJson)
    print(res.status_code)
    print(res.content)

def getTemplateDslJson():
    username = "elastic"
    password = "123456"
    user_info_str = username + ":" + password
    user_info = base64.b64encode(user_info_str.encode())  # 这个得到是个字节类型的数据
    headers = {
        "Authorization": "Basic {0}".format(user_info.decode())  # 这个就是需要验证的信息
    }
    url = "http://192.168.0.1:9200/_template/*_template"
    res = requests.get(url, headers=headers)
    print(res.status_code)
    return json.loads(res.content)

if __name__ == '__main__':
    jsonTemplate = getTemplateDslJson()
    if isinstance(jsonTemplate, dict):
        for templateName in jsonTemplate:
            templateDslJson = jsonTemplate[templateName]
            putTemplate(templateName, templateDslJson)
收起阅读 »

Elastic:使用 docker 来安装 Elastic Stack 8.0-alpha2

Elastic Stack 8.0.0-alpha2 刚刚发布,这是一个快速(非官方)的启动和运行指南。 更多功能、文档和公告即将发布,但冒险者已经开始:在几分钟内启动并运行 Docker 上的 Elasticsearch、Kibana 和 Agent。

请注意:

这是一个 alpha 发布版。 仅将其用于测试,不要指望最终能够升级到 8.0.0 版本最终版本。
期待将会有一些这样或者那样的 bug。 这就是我们再次运行 Elastic Pioneer Program  的原因,以便我们可以解决尽可能多的问题。
这是保持简单的最小示例,例如跳过 TLS 证书(尽管这可能会改变)。 请不要将其用作生产环境。
在今天的文章中,我将详细地介绍如何安装 Elastic Stack 8.0-alpha2 版本。

原文链接:https://blog.csdn.net/UbuntuTo ... 24770
继续阅读 »
Elastic Stack 8.0.0-alpha2 刚刚发布,这是一个快速(非官方)的启动和运行指南。 更多功能、文档和公告即将发布,但冒险者已经开始:在几分钟内启动并运行 Docker 上的 Elasticsearch、Kibana 和 Agent。

请注意:

这是一个 alpha 发布版。 仅将其用于测试,不要指望最终能够升级到 8.0.0 版本最终版本。
期待将会有一些这样或者那样的 bug。 这就是我们再次运行 Elastic Pioneer Program  的原因,以便我们可以解决尽可能多的问题。
这是保持简单的最小示例,例如跳过 TLS 证书(尽管这可能会改变)。 请不要将其用作生产环境。
在今天的文章中,我将详细地介绍如何安装 Elastic Stack 8.0-alpha2 版本。

原文链接:https://blog.csdn.net/UbuntuTo ... 24770 收起阅读 »