使用极限网关来处置 Elasticsearch 的 Apache Log4j 漏洞
Elasticsearch • medcl 发表了文章 • 2 个评论 • 2446 次浏览 • 2021-12-11 03:57
昨日爆出的 Log4j 安全漏洞，业界一片哗然，今天给大家介绍一下，如何使用极限网关来快速处置 Elasticsearch 的 Apache Log4j 漏洞。
【CVE 地址】
[](q)
【漏洞描述】
Apache Log4j 是一款非常流行的开源的用于 Java 运行环境的日志记录工具包，大量的 Java 框架包括 Elasticsearch 的最新版本都使用了该组件，故影响范围非常之大。
近日, 随着 Apache Log4j 的远程代码执行最新漏洞细节被公开，攻击者可通过构造恶意请求利用该漏洞实现在目标服务器上执行任意代码。可导致服务器被黑客控制，从而进行页面篡改、数据窃取、挖矿、勒索等行为。建议使用该组件的用户第一时间启动应急响应进行修复。
简单总结一下就是，在使用 Log4j 打印输出的日志中，如果发现日志内容中包含关键词 ${，那么这个里面包含的内容会当做变量来进行替换和执行，导致攻击者可以通过恶意构造日志内容来让 Java 进程来执行任意命令，达到攻击的效果。
【漏洞等级】：非常紧急
此次漏洞是用于 Log4j2 提供的 lookup 功能造成的，该功能允许开发者通过一些协议去读取相应环境中的配置。但在实现的过程中，并未对输入进行严格的判断，从而造成漏洞的发生。
【影响范围】：Java 类产品：Apache Log4j 2.x < 2.15.0-rc2，Elasticsearch 当前所有版本。
【攻击检测】
可以通过检查日志中是否存在 jndi:ldap://、jndi:rmi 等字符来发现可能的攻击行为。
处理办法
最简单的办法是通过修改 config/jvm.options，新增以下参数，重启集群所有节点即可。
<br /> -Dlog4j2.formatMsgNoLookups=true<br />
不过，如果集群规模较大，数据较多，业务不能中断，不能通过修改 Elasticsearch 配置、或者替换 Log4j 的最新 jar 包来重启集群的情况，可以考虑使用极限网关来进行拦截或者参数替换甚至是直接阻断请求。
通过在网关层对发往 Elasticsearch 的请求统一进行参数检测，将包含的敏感关键词 ${ 进行替换或者直接拒绝，
可以防止带攻击的请求到达 Elasticsearch 服务端而被 Log4j 打印相关日志的时候执行恶意攻击命令，从而避免被攻击。
极限网关是透明代理，只需要在应用端，将以往配置指向 Elasticsearch 的地址替换为现在网关的地址即可，其他都不用动。
参考配置
下载最新的 1.5.0-SNAPSHOT 版本[https://release.www.ksh17j.com/gateway/snapshot/](https://release.www.ksh17j.com/gateway/snapshot/)
使用极限网关的 context_filter 过滤器，对请求上下文 _ctx.request.to_string 进行关键字检测，过滤掉恶意流量，从而阻断攻击。
新增一个配置文件 gateway.yml
```
path.data: data
path.logs: log
entry:
- name: es_entrypoint
enabled: true
router: default
max_concurrency: 20000
network:
binding: 0.0.0.0:8000
router: - name: default
default_flow: main_flow
flow: - name: main_flow
filter:
- context_filter:
context: _ctx.request.to_string
action: redirect_flow
status: 403
flow: log4j_matched_flow
must_not: # any match will be filtered
regex:
- \${.*?}
- "%24%7B.*?%7D" #urlencode
contain: - "jndi:"
- "jndi:ldap:"
- "jndi:rmi:"
- "jndi%3A" #urlencode
- "jndi%3Aldap%3A" #urlencode
- "jndi%3Armi%3A" #urlencode
- \${.*?}
- elasticsearch:
elasticsearch: es-server
- context_filter:
- name: log4j_matched_flow
filter:
- echo:
message: 'Apache Log4j 2, Boom!'
elasticsearch:
- echo:
- name: es-server
enabled: true
endpoints:
<br /> <br /> 启动网关：<br /> ````<br /> ➜ ./bin/gateway -config /tmp/gateway.yml<br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.0.0_SNAPSHOT, 2021-12-10 23:55:34, 2212aff<br /> [12-11 01:55:49] [INF] [app.go:250] initializing gateway.<br /> [12-11 01:55:49] [INF] [instance.go:26] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/0<br /> [12-11 01:55:49] [INF] [api.go:261] api listen at: <a href="https://0.0.0.0:2900" rel="nofollow" target="_blank">https://0.0.0.0:2900</a><br /> [12-11 01:55:49] [INF] [reverseproxy.go:253] elasticsearch [es-server] hosts: [] => [localhost:9200]<br /> [12-11 01:55:49] [INF] [entry.go:296] entry [es_entrypoint] listen at: <a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a><br /> [12-11 01:55:49] [INF] [module.go:116] all modules started<br /> [12-11 01:55:49] [INF] [app.go:357] gateway is running now.<br /> [12-11 01:55:49] [INF] [actions.go:236] elasticsearch [es-server] is available<br />
将要使用的测试命令${java:os}使用 urlencode 转码为%24%7Bjava%3Aos%7D，构造查询语句，分别测试。
不走网关：
<br /> ~% curl 'https://localhost:9200/index1/_search?q=%24%7Bjava%3Aos%7D' <br /> {"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"}],"type":"index_not_found_exception","reason":"no such index","resource.type":"index_or_alias","resource.id":"index1","index_uuid":"_na_","index":"index1"},"status":404}% <br />
查看 Elasticsearch 端日志为：
<br /> [2021-12-11T01:49:50,303][DEBUG][r.suppressed ] path: /index1/_search, params: {q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1}<br /> org.elasticsearch.index.IndexNotFoundException: no such index<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.infe(IndexNameExpressionResolver.java:678) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.innerResolve(IndexNameExpressionResolver.java:632) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> at org.elasticsearch.cluster.metadata.IndexNameExpressionResolver$WildcardExpressionResolver.resolve(IndexNameExpressionResolver.java:580) ~[elasticsearch-5.6.15.jar:5.6.15]<br /> <br />
可以看到查询条件里面的q=${java:os}被执行了，变成了q=Mac OS X 10.13.4 unknown, architecture: x86_64-64, index=index1，说明变量被解析且执行，存在漏洞利用的风险。
那走网关之后呢：
<br /> ~% curl 'https://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' <br /> <br /> Apache Log4j 2, Boom!% <br />
可以看到请求被过滤掉了，返回了自定义的信息。
还有一些其他测试命令，大家也可以试试：
```
{java:vm}
~% curl ''
[2021-12-11T02:36:04,764][DEBUG][r.suppressed ] [INFINI-2.local] path: /index/_search, params: {q=OpenJDK 64-Bit Server VM (build 25.72-b15, mixed mode), index=index}
~% curl ''
Apache Log4j 2, Boom!%
{jndi:rmi://localhost:1099/api}
~% curl ''
2021-12-11 03:35:06,493 elasticsearch[YOmFJsW][search][T#3] ERROR An exception occurred processing Appender console java.lang.SecurityException: attempt to add a Permission to a readonly Permissions object
~% curl ''
Apache Log4j 2, Boom!%
```
另外不同版本的 Elasticsearch 对于攻击的复现程度参差不齐，因为 es 不同版本是否有 Java Security Manager 、不同版本 JDK 、以及默认配置也不相同，新一点的 es 其实同样可以触发恶意请求，只不过网络调用被默认的网络策略给拒绝了，相对安全，当然如果设置不当同样存在风险，见过很多用户一上来就关默认安全配置的，甚至还放开很多暂时用不上的权限，另外未知的攻击方式也一定有，比如大量日志产生的系统调用可能会拖垮机器造成服务不可用，所以要么还是尽快改配置换 log4j 包重启集群，或者走网关来过滤阻断请求吧。
使用极限网关处置类似安全事件的好处是，Elasticsearch 服务器不用做任何变动，尤其是大规模集群的场景，可以节省大量的工作，提升效率，非常灵活，缩短安全处置的时间，降低企业风险。
Elastic Meetup 重庆站讲师招募与主题征集中
活动 • liaosy 回复了问题 • 2 人关注 • 1 个回复 • 165 次浏览 • 2021-11-25 16:18
发布一个免费的 Elasticsearch 多集群监控和管理平台 - 极限数据平台
Elasticsearch • medcl 发表了文章 • 12 个评论 • 1857 次浏览 • 2021-11-22 18:48
随着单个 Elasticsearch 集群规模的越来越大，大家要么在拆集群的路上，要么是已经是多套集群了， 据路边社消息，一个公司超过5个集群的情况已经变得非常普遍，而管理多个集群着实是有点痛苦，比如常规的玩法可能是一套集群一个 Kibana，集群一多，切换来切换去就有点懵圈了有木有？
作为一个优雅的程序员或者运维管理员，是可忍孰不可忍啊。
另外，多个集群的监控也是一个麻烦事，目前常见的几种监控如：
- 使用 Kibana 自带的监控
- 使用 Prometheus + Grafana
- 使用 Zabbix
Kibana 自带的监控可以很好的满足单个集群的监控场景，不过集群规模大了之后，经常会出现指标丢失的问题，如果使用单独的监控集群，需要修改每个节点的配置，集群都需要重启，对于已经上了生产的集群，有点不方便，另外多集群监控需要商业授权。
那 Prometheus 呢， 一个 Elasticsearch 集群如果要监控起来，首先需要部署一个 Exporter 来暴露集群指标，然后部署一套Prometheus 来采集 Elasticsearch 指标，采集完了之后再部署一套 Grafana 来进行报表分析，不同的集群要做好切换，简单的事情，搞复杂了，整个监控体系偏重，维护成本高。
Zabbix 和 Prometheus 的场景差不多，就不赘述了。
那么问题来了，有没有一个更加简单方便的多集群监控和管理方案呢，并且要支持不同版本的集群，最好是 v2、v5、v6、v7 以及最新的 v8 都能统统接管，哈哈，没错了，这里给大家介绍一个我们极限实验室团队最近开发出来的一款免费的多集群监控和管理工具-极限数据平台，目前版本 v0.1，新鲜出炉。
废话不多少，咱们直接看图说话：
首先是多集群的纳管，目前从 1.0 到最新的 8.0 统统都可以接进来。
然后就是集群的监控拉，要多简单有多简单，就是一个开关的事情，注册集群的时候，启用即开启监控，目标集群啥都不用动，费那劲干啥。
监控界面如图：
集群概览，总体情况一目了然。
各个节点信息，分门别类。
各个索引级别的信息，挨个查看。
多个集群之间的监控查看一键切换，非常方便。
查看监控的时候，发现不对劲，要操作一下集群，直接调出控制台，如下图：
常用的操作命令，可以保存起来，方便下次使用。
别再保存在记事本里面了，下次又找不到，直接加载执行就好了。
好了，你要是用 Elasticsearch 不知道这个工具，那就 out 了，赶快耍起来吧。
下载地址：
[https://release.www.ksh17j.com/console/snapshot/](https://release.www.ksh17j.com/console/snapshot/)
安装巨简单，简直懒得说，一个二进制可执行文件，一个 yml 配置文件，里面修改 Elasticsearch 地址，结束。
可以在这里查看 [介绍和 Demo 演示视频]( ... KdMVLQ)
最后，欢迎关注极限实验室，获取更多 Elasticsearch 免费工具及业界资讯的第一手消息。
Elastic 中国开发者大会 2021 开启了，预热铁粉票已开抢，手慢无！
活动 • liaosy 发表了文章 • 0 个评论 • 418 次浏览 • 2021-11-11 17:45
Elastic 中国开发者大会 2021 是由 Elastic 官方、Elastic 足球社区和极限科技联合主办的开发者大会，作为中国国内唯一一个专门讨论 Elasticsearch 开源技术的大会，是中国最权威和最具实力干货的技术大会，其专业性和内容的质量一直以来在业内都是有口皆碑，大会最早发起于 2013 年初一个很小的线下聚会，之后每年迅速成长，往年大会的演讲嘉宾有来自 Elastic 官方、百度、腾讯、阿里巴巴、360、微博、美团、58、苏宁等众多公司的技术专家，带来过众多精彩的分享，与会听众大多为大数据领域相关的架构师、技术经理与一线开发工程师和运维工程师。
我们本着非盈利目的来举办大会，今年的大会将于2022年1月8号在深圳举行，举办开发者大会的目的是为中国广大的 Elasticsearch 开发者提供一个技术交流和学习切磋的地方，汇集业界众多的成功案例，集思广益，发散思维，促进社区和行业的进步。
大会官网：https://conf.www.ksh17j.com
Elasticsearch铁粉福利：
预热-铁粉票(79元/张)， 共计100张，数量有限，赶紧去报名抢购吧！
购票地址：
同时大会也在公开征集演讲议题与合作赞助商，欢迎各位Elastic相关技术大咖报名参与分享，欢迎有兴趣的赞助商金主大大前来合作。
演讲报名申请：
赞助合作申请：
ES容灾技术探讨和测试
Elasticsearch • yangmf2040 发表了文章 • 3 个评论 • 877 次浏览 • 2021-10-27 13:33
ES灾备技术调研
早就听说极限网关了，最近有个ES要做灾备，就搜集了下技术方案：
- 应用双写两个集群
- 跨集群复制CCR
- 极限网关
三个方案的优缺点我也简单整理了下：
- 优点：自主研发，想怎样就怎样；缺点：难，水平、时间都是成本
- 优点：实施简单；缺点：需要license
- 优点：部署灵活，功能齐全；缺点：不熟悉，没用过
貌似方案 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 |
网关下载
先下载极限网关：https://release.www.ksh17j.com/gateway/snapshot/
解压后，可看到有几个预定义的配置，方便大家快速上车。
网关配置
这次是做灾备，应该就是在 dc-replica.yml的基础上改比较妥当，配置还是比较多的 300多行，很多都是为了保证两个集群数据一致性，解耦啥的做的判断和写队列之类的设置。我只修改了 elasticsearch资源的定义信息，还有网关也可选择tls，不用手工生成证书，非常方便。
贴下我修改的地方
启动网关
两个集群都是 available ，说明连接应该ok
测试场景：围绕主备集群之间数据复制展开
1. 主备集群间复制创建、写入、删除索引操作
目的：对网关（A集群）创建索引test，对test索引写文档，能自动同步到B集群
初始情况A、B无test
手工put test索引到网关
A,B集群都创建成功
用loadgen写点文档进去吧，loadgen直接写网关
都10000条写入成功，如果查看是0的话，先refresh下索引
看下文档
简单校验一下
感觉没问题，删点文档看看，把那23个删了吧
再看看
更新524个文档看看
增、删、改 完事
2. 主集群故障的处理和恢复
目的：主集群故障后，网关如何处理收到的请求：读、写
Kill 掉 A 集群，模拟主集群故障
网关直接有报错说连不上A集群
此时对网关查询、写入数据都会报错
重新启动主集群后，一切正常
3. 备集群故障的处理和恢复
目的：备集群故障，读、写主集群不受影响，备集群恢复后，自动追数据直到两边数据一致
Kill 掉B集群，网关报错，B集群无法连接
对A集群进行写入一个新文档，并查询下
启动B集群，查看，已自动添加了新的文档
4. 主集群容灾切换
目的：主集群故障，短时间不可用，网关切换指向备集群作为主集群，A集群作为备集群；待A集群恢复后，自动追数据
KILL A 集群 模拟A集群故障
Kill 网关，切换配置：
启动网关，B是主了，available
写B集群，删除前面创建的 test 索引，新建test2索引，并插入文档
启动A集群，检查数据，有test2索引，且文档一致
5. 主集群故障恢复后，网关回切
目的：假设A集群已经完全恢复，网关回切，A集群为主，B集群为备
Kill网关，恢复配置，再启动网关
再次测试写入test2 检查能否同步成功
写网关
查看A集群
查看B集群
两个集群数据一致，主备角色也恢复到最初了
**测试环境变更
中间工作比较忙，中断了测试，也就十来天吧
不成想 网关更新了，我就下了新版本的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 |
网关不光版本升级了，配置文件也稍稍有些变化，新版本示例配置如下
本着不会就猜的原则，我还是能做到见名之知意的
我仅仅对 cross-cluster-replication.yml 做了简单的修改，就是和前面一样
6. ES由代理暴露的能否正常工作
目的：检验，比如由nginx代理ES的时候，网关能否正常工作
使用 nginx 代理后端的ES
80-->primary
81-->backup
测试下反向代理工作是否正常
启动网关，网关里elasticsearch资源指向nginx，没错就改了下 url
开始测试，增删改查 once more，还是对着网关操作
创建索引
PUT 文档
抄家伙
看看数量
简单对比下
给 code为500的文档增加一个字段 new_field
直接通过代理查询，检验数据
没问题，测试删除
删除单条
批量删除
看看结果
删除索引，并确认真的删除
关调backup集群，然后primary集群创建索引后，再启动backup集群，看能否自动追平
创建test2索引
顺手put个文档
Primary上查看
OK 启动backup
妈的 奇迹
7. 请求压缩功能如何
目的：看看客户端和网关分别在不同的请求压缩配置下，是否工作正常
在网关的配置中，看到了 compress 压缩，也设计几个场景测试下
网关配置里面有个压缩的配置，意思是消费线程往ES发送请求的时候是否启用gzip压缩。
默认是 true
7.1 用压缩的方式写网关，但网关不启用压缩
我们把网关配置中的true改成false
启动网关
开始写数据，写的过程中，随机停止backup集群，等待一会儿后再启动
网关可看到 backup集群，从不可用到可用
看看网关的队列情况，这时候backup队列应该堆积了不少请求
等待队列被消费完后，我们对比数据。
简单看看文档条数
用网关对比下数据看看
妥妥的一致
7.2 用压缩的方式写网关，网关也启用压缩
就把前面网关贴图的false改成true
启动网关
压缩写入
写入过程中，随机重启backup集群
网关日志
等待网关backup队列消费完毕，后对比数据
没得问题，下一场
7.3 用不压缩的方式写网关，网关也不启用压缩
网关配置compress: false，后启动网关
不压缩请求
中途随机重启backup集群
队列消费完后对比数据
数据一致
7.4 用不压缩的方式写网关，网关backup队列的消费线程使用压缩
写入过程中，停止backup集群，稍等一会儿后启动backup集群
观察网关的backup 队列情况
等消费完之后，我们对比数据
数量一致
用网关来对比下两个集群的test索引的数据
至此，关于跨集群复制的场景测试可以告一段落了，功能大家也看到了确实强大，部署也很灵活，对环境无侵入，直接把应用连接ES的地址、端口改下就行。或者网关直接监听9200端口，替换原有的协调节点，应用无感知。
此外，极限网关还有很多别的使用场景和激动人心的功能，像在线修改查询、请求限流、请求流量分析，这都是保障ES集群稳定运行的手段。
看到一款国产软件如此强大很欣慰，很激动。希望各位感兴趣的小伙伴也下载测试下自己的场景，我们ES圈（论坛）多交流交流。让我也看看你们的场景和测试是怎样的。
最后一个图，我也不知道咋回事，请忽略。
Elastic足球社区网站新增文章投稿功能
默认分类 • liaosy 发表了文章 • 0 个评论 • 212 次浏览 • 2021-10-18 13:18
如果您有Elastic技术栈相关的文章想分享，可以在本站发表原创文章，或者以站外投稿(已在其他站点发表过)的方式进行发布，站外投稿就无需再重复编辑整个文章内容了，仅需要提供文章标题、摘要、稿源、链接基本信息即可。
怎么发布站外投稿文章呢？
1.入口
注册登录本站后，鼠标移动到网站右上角的“发起”按钮会弹出下拉选项，选中“文章”点击即可。如下图示例：
2.编辑&发布
文章类型选择站外投稿，填写文章来源、文章链接、文章标题、文章内容摘要等稿源信息后提交即可。如下图示例：
3.修改更新
如发布之后需要修改，可在文章详情界面点击编辑进行内容更新。如下图示例：
本站Elastic足球社区将持续整合Elastic相关最新的技术文章和资讯供大家阅览，欢迎大家在本站发布原创文章或投稿。
如有疑问或建议，欢迎在评论区留言反馈。
使用极限网关来进行 Elasticsearch 跨集群跨版本查询及所有其它请求
Elasticsearch • medcl 发表了文章 • 6 个评论 • 687 次浏览 • 2021-10-16 11:31
使用场景
如果你的业务需要用到有多个集群，并且版本还不一样，是不是管理起来很麻烦，如果能够通过一个 API 来进行查询就方便了，聪明的你相信已经想到了 CCS，没错用 CCS 可以实现跨集群的查询，不过 Elasticsearch 提供的 CCS 对版本有一点的限制，并且需要提前做好 mTLS，也就是需要提前配置好两个集群之间的证书互信，这个免不了要重启维护，好像有点麻烦，那么问题来咯，有没有更好的方案呢？
😁 有办法，今天我就给大家介绍一个基于极限网关的方案，极限网关的网址：。
假设现在有两个集群，一个集群是 v2.4.6，有不少业务数据，舍不得删，里面有很多好东西 ：）还有一个集群是 v7.14.0，版本还算比较新，业务正在做的一个新的试点，没什么好东西，但是也得用 :(，现在老板们的的需求是希望通过在一个统一的接口就能访问这些数据，程序员懒得很，懂得都懂。
集群信息
- v2.4.6 集群的访问入口地址：192.168.3.188:9202
- v7.14.0 集群的访问入口地址：192.168.3.188:9206
这两个集群都是 http 协议的。
实现步骤
今天用到的是极限网关的 switch 过滤器：
网关下载下来就两个文件，一个主程序，一个配置文件，记得下载对应操作系统的包。
定义两个集群资源
```
elasticsearch:- name: v2
enabled: true
endpoint: - name: v7
enabled: true
endpoint:
``<br /> <br /> 上面定义了两个集群，分别命名为v2和v7`，待会会用到这些资源。
定义一个服务入口
```
entry: - name: my_es_entry
enabled: true
router: my_router
max_concurrency: 1000
network:
binding: 0.0.0.0:8000
tls:
enabled: true
``<br /> <br /> 这里定义了一个名为my_es_entry的资源入口，并引用了一个名为my_router的请求转发路由，同时绑定了网卡的0.0.0.0:8000也就是所有本地网卡监听 IP 的8000端口，访问任意 IP 的8000端口就能访问到这个网关了。<br /> <br /> 另外老板也说了，Elasticsearch 用 HTTP 协议简直就是裸奔，通过这里开启tls，可以让网关对外提供的是 HTTPS 协议，这样用户连接的 Elasticsearch 服务就自带 buffer 了，后端的 es 集群和网关直接可以做好网络流量隔离，集群不用动，简直完美。<br /> <br /> 为什么定义 TLS 不用指定证书，好用的软件不需要这么麻烦，就这样，不解释。<br /> <br /> 最后，通过设置max_concurrency` 为 1000，限制下并发数，避免野猴子把我们的后端的 Elasticsearch 给压挂了。
定义一个请求路由
```
router: - name: my_router
default_flow: cross-cluster-search
``<br /> <br /> 这里的名称my_router就是表示上面的服务入口的router参数指定的值。<br /> <br /> 另外设置一个default_flow来将所有的请求都转发给一个名为cross-cluster-search` 的请求处理流程，还没定义，别急，马上。
定义请求处理流程
来啦，来啦，先定义两个 flow，如下，分别名为v2-flow和v7-flow，每节配置的filter定义了一系列过滤器，用来对请求进行处理，这里就用了一个elasticsearch过滤器，也就是转发请求给指定的 Elasticsearch 后端服务器，了否？
```
flow: - name: v2-flow
filter:
- elasticsearch:
elasticsearch: v2
- elasticsearch:
- name: v7-flow
filter:
- elasticsearch:
elasticsearch: v7
<br /> <br /> 然后，在定义额外一个名为 `cross-cluster-search` 的 flow，如下：<br /> <br />
- elasticsearch:
- name: cross-cluster-search
filter:
- switch:
path_rules:
- prefix: "v2:"
flow: v2-flow - prefix: "v7:"
flow: v7-flow
<br /> 这个 flow 就是通过请求的路径的前缀来进行路由的过滤器，如果是 `v2:`开头的请求，则转发给 `v2-flow` 继续处理，如果是 `v7:` 开头的请求，则转发给 `v7-flow` 来处理，使用的用法和 CCS 是一样的。so easy！<br /> <br /> 对了，那是不是每个请求都需要加前缀啊，费事啊，没事，在这个 `cross-cluster-search` 的 filter 最后再加上一个 `elasticsearch` filter，前面前缀匹配不上的都会走它，假设默认都走 `v7`，最后完整的 flow 配置如下：<br /> <br />
flow:
- prefix: "v2:"
- switch:
- name: v2-flow
filter:
- elasticsearch:
elasticsearch: v2
- elasticsearch:
- name: v7-flow
filter:
- elasticsearch:
elasticsearch: v7
- elasticsearch:
- name: cross-cluster-search
filter:
- switch:
path_rules:
- prefix: "v2:"
flow: v2-flow - prefix: "v7:"
flow: v7-flow
- prefix: "v2:"
- elasticsearch:
elasticsearch: v7
```
然后就没有然后了，因为就配置这些就行了。
启动网关
假设配置文件的路径为sample-configs/cross-cluster-search.yml，运行如下命令：
<br /> ➜ gateway git:(master) ✗ ./bin/gateway -config sample-configs/cross-cluster-search.yml<br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.0.0_SNAPSHOT, 2021-10-15 16:25:56, 3d0a1cd<br /> [10-16 11:00:52] [INF] [app.go:228] initializing gateway.<br /> [10-16 11:00:52] [INF] [instance.go:24] workspace: data/gateway/nodes/0<br /> [10-16 11:00:52] [INF] [api.go:260] api listen at: <a href="https://0.0.0.0:2900" rel="nofollow" target="_blank">https://0.0.0.0:2900</a><br /> [10-16 11:00:52] [INF] [reverseproxy.go:257] elasticsearch [v7] hosts: [] => [192.168.3.188:9206]<br /> [10-16 11:00:52] [INF] [entry.go:225] auto generating cert files<br /> [10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v2] is available<br /> [10-16 11:00:52] [INF] [actions.go:223] elasticsearch [v7] is available<br /> [10-16 11:00:53] [INF] [entry.go:296] entry [my_es_entry] listen at: <a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a><br /> [10-16 11:00:53] [INF] [app.go:309] gateway is running now.<br />
可以看到网关输出了启动成功的日志，网关服务监听在<a href="https://0.0.0.0:8000" rel="nofollow" target="_blank">https://0.0.0.0:8000</a>。
试试访问网关
直接访问网关的 8000 端口，因为是网关自签的证书，加上 -k 来跳过证书的校验，如下：
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000" rel="nofollow" target="_blank">https://localhost:8000</a> <br /> {<br /> "name" : "LENOVO",<br /> "cluster_name" : "es-v7140",<br /> "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",<br /> "version" : {<br /> "number" : "7.14.0",<br /> "build_flavor" : "default",<br /> "build_type" : "zip",<br /> "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",<br /> "build_date" : "2021-07-29T20:49:32.864135063Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "8.9.0",<br /> "minimum_wire_compatibility_version" : "6.8.0",<br /> "minimum_index_compatibility_version" : "6.0.0-beta1"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />
正如前面配置所配置的一样，默认请求访问的就是 v7 集群。
访问 v2 集群
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:/" rel="nofollow" target="_blank">https://localhost:8000/v2:/</a> <br /> {<br /> "name" : "Solomon O'Sullivan",<br /> "cluster_name" : "es-v246",<br /> "cluster_uuid" : "cqlpjByvQVWDAv6VvRwPAw",<br /> "version" : {<br /> "number" : "2.4.6",<br /> "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd",<br /> "build_timestamp" : "2017-07-18T12:17:44Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "5.5.4"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />
查看集群信息：
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:_cluster/health" rel="nofollow" target="_blank">https://localhost:8000/v2:_cluster/health</a>\?pretty<br /> {<br /> "cluster_name" : "es-v246",<br /> "status" : "yellow",<br /> "timed_out" : false,<br /> "number_of_nodes" : 1,<br /> "number_of_data_nodes" : 1,<br /> "active_primary_shards" : 5,<br /> "active_shards" : 5,<br /> "relocating_shards" : 0,<br /> "initializing_shards" : 0,<br /> "unassigned_shards" : 5,<br /> "delayed_unassigned_shards" : 0,<br /> "number_of_pending_tasks" : 0,<br /> "number_of_in_flight_fetch" : 0,<br /> "task_max_waiting_in_queue_millis" : 0,<br /> "active_shards_percent_as_number" : 50.0<br /> }<br />
插入一条文档：
<br /> ➜ loadgen git:(master) ✗ curl-json -k <a href="https://localhost:8000/v2:medcl/doc/1" rel="nofollow" target="_blank">https://localhost:8000/v2:medcl/doc/1</a> -d '{"name":"hello world"}'<br /> {"_index":"medcl","_type":"doc","_id":"1","_version":1,"_shards":{"total":2,"successful":1,"failed":0},"created":true}% <br />
执行一个查询
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v2:medcl/_search" rel="nofollow" target="_blank">https://localhost:8000/v2:medcl/_search</a>\?q\=name:hello <br /> {"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"}}]}}% <br />
可以看到，所有的请求，不管是集群的操作，还是索引的增删改查都可以，而 Elasticsearch 自带的 CCS 是只读的，只能进行查询。
访问 v7 集群
<br /> ➜ loadgen git:(master) ✗ curl -k <a href="https://localhost:8000/v7:/" rel="nofollow" target="_blank">https://localhost:8000/v7:/</a><br /> {<br /> "name" : "LENOVO",<br /> "cluster_name" : "es-v7140",<br /> "cluster_uuid" : "npWjpIZmS8iP_p3GK01-xg",<br /> "version" : {<br /> "number" : "7.14.0",<br /> "build_flavor" : "default",<br /> "build_type" : "zip",<br /> "build_hash" : "dd5a0a2acaa2045ff9624f3729fc8a6f40835aa1",<br /> "build_date" : "2021-07-29T20:49:32.864135063Z",<br /> "build_snapshot" : false,<br /> "lucene_version" : "8.9.0",<br /> "minimum_wire_compatibility_version" : "6.8.0",<br /> "minimum_index_compatibility_version" : "6.0.0-beta1"<br /> },<br /> "tagline" : "You Know, for Search"<br /> }<br />
Kibana 里面访问
完全没问题，有图有真相：
其他操作也类似，就不重复了。
完整的配置
```
path.data: data
path.logs: log
entry:
- switch:
- 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
- elasticsearch:
- name: v7-flow
filter:
- elasticsearch:
elasticsearch: v7
- elasticsearch:
- name: cross-cluster-search
filter:
- switch:
path_rules:
- prefix: "v2:"
flow: v2-flow - prefix: "v7:"
flow: v7-flow
- prefix: "v2:"
- elasticsearch:
elasticsearch: v7
router:
- switch:
- name: my_router
default_flow: cross-cluster-search
elasticsearch: - name: v2
enabled: true
endpoint: - name: v7
enabled: true
endpoint:
```
小结
好了，今天给大家分享的如何使用极限网关来进行 Elasticsearch 跨集群跨版本的操作就到这里了，希望大家周末玩的开心。😁
- name: v2
欢迎参加本周六 DevOps社区大连峰会，还有少量赠票
默认分类 • martinliu 发表了文章 • 0 个评论 • 354 次浏览 • 2021-08-31 12:37
嘉宾介绍：刘征，Elastic公司社区布道师，中国DevOps社区组织者，《DevOps Handbook》《The Site Reliability Workbook》译者；精通DevOps/SRE/ITIL等管理体系。致力于推广DevOps/SRE的理念、技术和实践。
演讲概述：不仅详细介绍使用 OpenTelemetry 这套云原生的API和库，来生成、收集和导出分布式系统的遥测数据的流程。还将展示如何定制OpenTelemetry的组件和架构，从而满足你的应用程序的独特需求。
Elastic 对开放标准支持的承诺：从开源到开放代码，开放性是我们Elastic的DNA。我们不仅从我们编写和运送的代码的角度拥抱这种开放性，而且也拥抱我们摄入的数据。我们一直站在拥抱开放标准的最前沿，为我们的用户提供灵活性，让他们可以选择如何将他们的数据运送到Elasticsearch，并利用Elastic Stack的功能。这种支持开放标准的承诺体现在我们对其他开放标准和其他流行的开源项目的支持，如Prometheus、OpenTracing、W3C Trace-Context和Jaeger。
2019年初，OpenTracing和OpenCensus开始了标准化API和构建完整解决方案的旅程，使用户更容易在他们所有的埋点服务中捕获追踪和遥测。在Elastic APM中建立了对OpenTracing的支持，我们作为OpenTelemetry项目的成员积极参与其中。我们很高兴地宣布，我们可以轻松地将OpenTelemetry的追踪整合到Elastic APM中。
欢迎参与DevOps 社区峰会大连站，欢迎关注刘征老师的以上分享。关注本微信的朋友可以扫码下面的二维码免费注册本次峰会，本次社区峰会还给大家准备了社区定制版卫衣和抽奖书籍等周边。还等什么，让我们本周六在峰会上不见不散吧！
扫码即得最后剩余的免费门票。
查看大会的全部日程。
【杭州站】Elastic & 阿里云 Meetup 6月5号
活动 • liaosy 发表了文章 • 0 个评论 • 902 次浏览 • 2021-05-22 17:38
活动介绍
本次Meetup杭州站由阿里云和Elastic联合举办，邀请来自滴滴、安恒信息、阿里云的资深技术专家探讨在搜索、安全、内核优化等方向的实践与创新，以及发布由数十位优秀技术开发者共创而成的实战指南，共同分享 Elasticsearch技术大咖的一线经验与深度思考。
报名方式
链接：
扫码:
活动时间
2021年06月05日 13:00-17:30
活动地址
浙江省杭州市余杭区阿里巴巴西溪园区访客中心 206-S越秀书院
活动流程
text<br /> 13:00~13:15 签到入座<br /> 13:15~13:30 开发者共创书籍《Elastic Stack 实战手册V1.0》发布<br /> 13:30~14:30 滴滴Elasticsearch内核优化之路<br /> 韩宝君 滴滴Elasticsearch资深开发工程师/ES社区Contributor<br /> 14:30~15:30 Elasticsearch在SIEM的应用与实践<br /> 汤乐奇 安恒信息AiLPHA大数据资深研发经理<br /> 15:30~16:30 Elasticsearch Serverless 云原生时代的创新实践<br /> 马华标(城破) 阿里巴巴高级技术专家/阿里云ES内核研发负责人<br /> 16:30~17:20 圆桌交流<br /> 17:20~17:30 抽奖合影<br />
活动奖品
阿里云双肩包、T恤、Elastic定制礼物
阿里云ACE
阿里云ACE即全称 Alibaba Cloud Engineer，是意为阿里云的工程师、代表着云计算的建设者。同时“ACE”又是扑克牌中的“A”，因此阿里云ACE也寓意着是云计算领域王牌的一群人。在线上，ACE拥有专属的页面和29个社群，承载论坛及专栏等内容； 在线下，ACE通过组织丰富的活动，包括技术沙龙、TechDay、Meetup、官方互动等来形成本地化的开发者的学习、社交平台。
通过ACE组织的各种活动，ACE用户可以结识本地的开发者，收获前沿知识，积累行业经验，并加深对阿里云的了解。
活动交流及杭州ACE同城会钉群
活动海报
2021 Elastic 足球社区深圳线下 Meetup 重磅重启，讲师招募进行中！
活动 • howardhuang 发表了文章 • 0 个评论 • 890 次浏览 • 2021-05-21 15:49
活动链接：
《腾讯Elasticsearch海量规模背后的内核优化剖析》答疑
Elasticsearch • howardhuang 发表了文章 • 37 个评论 • 5191 次浏览 • 2020-05-09 17:05
今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈，由于时间关系，大家的问题没能及时答复，这里集中解答，大家如果还有其它疑问也可以持续提问。感谢大家的关注！
另外腾讯云上有内核增强版的ES服务，包含了我们所有的内核优化项，欢迎大家体验！
团队也在持续招聘，欢迎简历来砸：[email protected]; [email protected]
今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈，由于时间关系，大家的问题没能及时答复，这里集中解答，大家如果还有其它疑问也可以持续提问。感谢大家的关注！
另外腾讯云上有内核增强版的ES服务，包含了我们所有的内核优化项，欢迎大家体验！
团队也在持续招聘，欢迎简历来砸：[email protected]; [email protected]
Elastic 官方培训开放注册中！
资讯动态 • medcl 发表了文章 • 3 个评论 • 3504 次浏览 • 2020-04-10 18:42
Elastic 官方线上公开培训课现已开放注册。
本次课程为官方收费课程，为针对中国及亚洲华语学员单独开设的课程，本次课程为在线虚拟课程，共计 两门课程，包含一次 Elastic 认证工程师考试机会。
课程大纲！
本次课程的内容为 Elasticsearch 核心课程，分为两个部分：
- Elasticsearch Engineer I - Virtual
- Elasticsearch Engineer II - Virtual
各个课程的大纲分别为：
Elasticsearch Engineer I - Virtual
- Elasticsearch 基础理论
- Elasticsearch 查询
- Elasticsearch 聚合
- Elasticsearch 文本分析与映射
- Elasticsearch 节点与分片
- Elasticsearch 监控与诊断
更多详情请访问： ... rtual
Elasticsearch Engineer II - Virtual
- Elasticsearch 数据建模
- Elasticsearch 数据加工
- Elasticsearch 从开发到生产环境
- Elasticsearch 集群部署
- Elasticsearch 节点和索引管理
- Elasticsearch 高级使用技巧
更多详情请访问： ... rtual
授课方式！
本次课程为在线课程，每门课程有两位专门的授课老师，授课采用在线课堂的方式，提供远程实验动手环境，授课老师会实时指导，辅导上机操作。
课程教材为英文，全程由足球普通话讲授。
授课时间！
授课时间：
- Elasticsearch 课程 1：4月27日 – 4月30日
- Elasticsearch 课程 2：5月18日 – 5月21日
每门课程分别为 4 天（讲师授课指导半天、自己练习半天），两门课程共计 8 天，内容各不相同，没有交叉。
课程准备！
上课环境前提准备
- 稳定的互联网连接，10Mb 以上带宽
- 任意安装有 Mac, Linux 或 Windows 的电脑一台
- 最新稳定版本的 Chrome 或者 Firefox 浏览器(其它浏览器不支持)
- 课程开始前，关闭任何广告屏蔽插件，并重启浏览器
- 课程开始前，确保关闭任何的 VPN 服务
报名时间！
从即日起开设接收学员报名，报名截止时间为：2020 年 4 月 22 日，以实际付款时间为主。
报名费用！
两门课程 + 一次认证考试累计合计费用：$1920 美金
官网报名！
报名方法一：通过在线方式自主选择进行注册报名、缴费，需要选择 Location：China Standard Time。
... China
人工报名！
报名方法二：您可以联系下面的 Elastic 官方合作伙伴，由他们来帮你购买课程和处理发票事宜。
扫下发二维码立即联系客服
常见问题！
Q：能否支持选择单项课程，如 ENG I 或者 ENG II？
A：不支持，本次课程为捆绑优惠套餐
Q：能否支持信用卡付款？
A：支持，信用卡需支持双币卡
Q：能否支持微信支付宝付款？
A：支持，需要联系人工报名
Q：能否提供发票用于报销？
A：支持，需要联系人工报名，有额外税点
本次课程名额有限，距离开课的时间也不多了，有兴趣的同学们赶快报名吧。
免责声明
有关此次在线培训活动的最终解释权给 Elastic 所有。
[活动推荐] ECUG For Future - 技术人的年度盛会
活动 • medcl 发表了文章 • 1 个评论 • 1185 次浏览 • 2019-12-21 22:37
【限量门票】ECUG技术人的年度盛会，听谷歌、阿里、七牛云、CODING等大佬分享干货。
【亮点满满】微服务拆分的技术实践、基于区块链的可信计算、阿里巴巴Kubernetes应用管理实践中的经验与教训、ServiceMesh在网易的落地关键点总结、构建快速应用开发的套路……2020年1月4日-5日，杭州见～
活动链接：
更多活动介绍：
重磅《Elasticsearch 中国开发者调查报告》探索开发者的现状和未来
活动 • medcl 发表了文章 • 28 个评论 • 11734 次浏览 • 2019-12-06 21:10
点击免费下载 [《 Elasticsearch 开发者调查报告》](https://www.ksh17j.com/slides/249)
2010 年，Elasticsearch 首个版本发布，经过近 10 年的发展，Elastic Stack 系列开源项目的热度持续升温，Elastic 技术社区的用户量和开发者群体逐步壮大，也在不断进化。那么，这个群体是谁？他们在怎样使用 Elastic Stack ？他们又将如何进阶成长？
为了洞察这个独特开发者群体的发展、技术应用现状，以及整个行业的发展趋势，Elastic 技术社区、阿里巴巴 Elasticsearch 技术团队和阿里云开发者社区联合首发《 Elasticsearch 中国开发者调查报告》。
本次报告从开发者的职业路径、Elasticsearch 的技术演进、技术社区的发展等三个维度，描绘了开发者群体的轮廓和成长路径。
开发者们的典型画像
90后是 Elasticsearch 技术兴起的中坚力量，6 成以上开源贡献者管理着 TB 或 PB 级的海量数据。
技术入门进阶之路
从入门到进阶，资深专家的第一手技术指南。
Elasticsearch 的实践应用 TOP 5
信息检索和日志分析占实际应用场景的大壁江山，业务数据分析、数据库加速、运维指标监控三者平分秋色。
大厂的最佳实践
18位资深专家分享在 Elasticsearch 技术领域的案例干货。
Elastic 技术社区的建设经验
30多场线下活动，触达5000多人次，技术社区如何培育发展？
Elasticsearch 因轻量级、稳定、可靠、快速等特性成为越来越多开发者的选择，本报告将为从业者们提供更多关于职业、行业以及技术应用的参照依据，一览开发者的现状和未来。
关于本次调查的详细数据分析、案例经验和行业前瞻，请下载 [《 Elasticsearch 中国开发者调查报告》](https://www.ksh17j.com/slides/249) 并详细阅读报告全文。
【深圳ES Meetup】李猛：DB与ES结合，是业务系统实践值得探讨的事
活动 • nodexy 发表了文章 • 2 个评论 • 3527 次浏览 • 2019-11-09 17:41
李猛 架构师/Elastic认证工程师
Elastic Stack产品深度用户，2012/2013年接触Elasticsearch，对Elastic Stack开发、架构、运维等方面有深入体验，实践过多种ES项目，最暴力的大数据分析应用，最复杂的业务系统应用等。
Q1、作为深度用户，当初是基于什么样的动机和考量选择使用 ES 产品并持续深入探索的？
A：易用性与功能强大，个人平常比较爱好算法研究，选择任何数据产品本质上都是选择算法，算法的本质决定了产品的强大。
架构是个宏观问题，ES的设计是标准的分布式，架构的优秀设计带来的是易用性；
算法是个微观问题，ES集成了很多优秀的算法，这样在很多业务场景下都可满足，而不用更换不同的数据产品，这样也会带来产品运维方面的便利性，保障应用的技术栈不至于过多复杂。
Q2、在探索 DB 与 ES 的互通方面，有遇到什么难题吗？最后是如何解决的呢？
A：数据一致性与实时性问题。应用架构思维变化，业务调整变化与技术方案变化。
Q3、结合您的实践经历，对 ES 目前的生态发展、应用以及未来有什么样的看法？
A：ES目前主要应用是在单索引条件下查询，附带有简单的聚合分析能力。复杂的分析能力不具备，ES未来会增强复杂的分析能力，比如有条件的支持２个索引的关联分析。
Q4、您对本次技术沙龙活动的主题分享有什么期待？
A：期望更多人参加探讨更多的业务应用场景，比如传统应用方面、大数据方面、机器学习方面；帮助大家以后项目实战有更多的案例参考。
Q5、您对 Elastic 足球社区发展有什么意见或建议呢？
A：ES目前在国内的热度几乎超过任何数据库，几乎大大小小的公司，都在使用；从开始入门到成熟运用多多少少都会遇到很多问题， 希望社区活动更加多一点，业余的交流更多一点。比如可以办一些，走进某些企业的活动。
11月16日 Elastic 足球社区深圳 Meetup 火热报名中
分享主题：《DB到ES数据实时同步之路》 李猛
主题摘要：关系型数据库天然具备最严格的事务特性，有效的保证数据库一致性，但在高效查询方面显得很无力；Elasticsearch天然具备高效的查询算法，但在数据一致性方面却是先天缺陷；如何将DB与ES的优点结合，是任何一个企业公司业务系统实践都值得探讨的事。
