你可以的，加油

INFINI Gateway和 Console 更新发布啦！

资讯动态 • liaosy 发表了文章 • 0 个评论 • 3818 次浏览 • 2023-02-10 23:12 • 来自相关话题

![INFINI Labs 产品更新发布](https://elasticsearch.cn/uploa ... 90.png)

Hi，大家好。今天 INFINI Labs 为大家带来 2023 春节后第一波产品更新发布，欢迎大家免费下载体验使用。

INFINI Gateway v1.9.0


极限网关本次迭代带来了大量的更新如下：

Breaking changes

  • Refactoring config for ip access control
  • Disable elasticsearch metadata refresh by default
  • Update default config path from configs to config
  • Remove sample-configs, moved to dedicated integrated-testing project
  • Remove field conntime, update field @timestamp to timestamp in logging filter
  • Rename disorder to fast

    Features

  • Support listen on IPv6 address
  • Add general health api
  • Add request_ip to context
  • Add badger filter plugin
  • Allow to split produce and consume messages from s3
  • Add bulk_request_throttle filter
  • Support access request context and more output options in echo filter
  • Add body_json to response context
  • Add cert config to API module, support mTLS
  • Add api to clear scroll context
  • Floating_ip support stick by priority
  • Add keystore util
  • Allow to save success bulk results in bulk_indexing processor
  • Enable watch and reload the major config file
  • Support run background job in one goroutine
  • Allow to handle async_bulk request logging
  • Add config to control cluster health check while cluster not available, set default to false
  • Allow to follow redirects in http filter, set default read and write timeout to 30s
  • Support collect instance metrics to monitoring gateway
  • Add json log format

    Bug fix

  • Fix user was removed in logging filter
  • Fix incorrect message size issue, reload when files changed in disk_queue
  • Fix issue that index_diff could not finished automatically
  • Fix hostname was not well updated in filter set_request_header or set_hostname
  • Fix to check consumer’s lag instead of queue’s lag in flow_runner processor
  • Fix file not found error for disk_queue
  • Fix the delete requests was not proper handled in filter bulk_reshuffle, bulk_request_mutate and bulk_indexing processor
  • Fix memory leak caused by misuse of bytes buffer
  • Fix to handle the last request in replay processor
  • Fix url args was not updated after change
  • Fix memory leak when serving high-concurrent requests
  • Fix nil id caused error when using sliced workers in bulk_indexing processor
  • Fix index name with dot
  • Refactoring time fields for orm, skip empty time
  • Refactoring stats, allow to register extended stats
  • Fix to restart gateway entrypoint on flow change
  • Update ratio filter, fix random number, add header to ratio filter
  • Fix query parameter no_cache was not well respected in get_cache filter
  • Fix single delete request was ignored in bulk requests
  • Fix request mutate filter

    Improvements

  • Remove newline in indexing_merge and json_indexing processor
  • Improve instance check, add config to disable
  • Add option skip_insecure_verify to s3 module
  • Improve instance check, enable config to disable
  • Update the way to get ctx process info, optimize memory usage
  • Improve indexing performance for bulk_indexing processor
  • Refactoring disk_queue, speedup message consumption
  • Enable segment compress for disk_queue by default
  • Skip download s3 files when s3 was not enabled
  • Add option to log warning messages for throttle filters
  • Optimize hash performance for getting primary shardID and partitionID
  • Add cache for get index routing table
  • Optimize performance for bulk response processing
  • Refactoring bulk_processor, pass meta info to payload func
  • Don’t call payload func for delete action
  • Improve queue consumer’s lag check
  • Enable prepare flat files ahead for read by default, skip unnecessary file
  • Add object pool for xxhash
  • Refactoring disk_queue, handle consumer in-flight segments in memory
  • Add config to remove duplicated newline for bulk_processor
  • Add metric timestamp in stats api
  • Improve error on routing table missing
  • Refactoring bytes buffer and object pool, expose metrics via API
  • Refactoring tasks pooling, support throttle and unified control
  • Optimize badger file size and memory usage
  • Refactoring time fields for orm, skip empty time
  • Refactoring stats, allow to register extended stats
  • Refactoring to handle bulk response results
  • Add client_session_cache_size to tls setting
  • Safety add newline to each bytes when handle bulk requests

    INFINI Console v0.7.0


    INFINI Console 本次迭代更新如下：

  • 新增初始化安装向导；
    image.png



  • 新增系统服务健康监控；
  • 新增 License 授权；
    image_(1).png



  • 新增索引和节点层面数据字节写入吞吐量指标(indexing bytes)；
  • 修复了 Discover 第一次加载未发起搜索请求的问题；
  • 修复了查看节点线程池指标时选择多个节点后指标不显示的问题；

    期待反馈


    欢迎下载体验使用，如果您在使用过程中遇到如何疑问或者问题，欢迎前往 INFINI Labs Github（[https://github.com/infinilabs](https://github.com/infinilabs)） 中的对应项目中提交 Feature Request 或提交 Bug。

  • INFINI Gateway： [https://github.com/infinilabs/gateway/issues](https://github.com/infinilabs/gateway/issues)
  • INFINI Console： [https://github.com/infinilabs/console/issues](https://github.com/infinilabs/console/issues)
  • 下载地址： [https://www.infinilabs.com/download/](https://www.infinilabs.com/download/)

    您还可以通过邮件联系我们：hello@infini.ltd

    或者拨打我们的热线电话：(+86) 400-139-9200

    也欢迎大家添加微信小助手(INFINI-Labs)拉群交流和学习。

    640.jpeg




    感谢大家的围观，祝大家周末愉快。

招聘搜索引擎内核研发工程师（Rust方向）

求职招聘 • medcl 发表了文章 • 0 个评论 • 4153 次浏览 • 2023-01-28 17:33 • 来自相关话题

Hello 大家好，开工大吉，兔年吉祥，站长来此招募小伙伴啦，加入我们一起打造下一代的实时搜索引擎。
 
岗位职责
  • 设计并开发下一代实时搜索引擎 ;
  • 持续优化实现方案，改进组件性能 ;
  • 保证工程质量和开发效率 。

 
岗位要求
  • 3 年以上搜索引擎开发经验，计算机相关专业，本科及以上学历 ;
  • 熟练掌握 Rust/C/C++/Golang 中的一种或多种语言，有 Rust 实际开发经验者优先 ;
  • 熟悉 Linux 操作系统，了解Linux系统常用操作命令, 能基于shell编写脚本 ;
  • 熟悉 Linux 下内存管理机制，低延迟、高并发无锁化编程 ;
  • 熟悉 TCP/IP、Socket、HTTP 等网络协议 ;
  • 具有良好的沟通、团队协作能力；
  • 熟悉常见分布式算法，有大规模分布式系统开发经验优先；
  • 较好的英文阅读和写作能力，具备比较强的逻辑思维能力；
  • 良好的编码习惯和技术文档能力，具备持续输出的能力;
  • 工作地点不限 。

 
加分项
  • 有自己的博客、Github、开源项目优先 ;
  • 具有相关搜索引擎开发工作经验者优先 ;
  • 熟悉各类索引结构；
  • 熟悉 LSM-Tree、B+Tree、RocksDB、LevelDB 优先 ;
  • 有较强的学习能力，愿意致力于新技术的研究 。

 
更多信息请访问极限实验室官网： https://www.infinilabs.com/career/

《Elastic Stack 实战手册》 介绍及下载

Elasticsearch • liuxg 发表了文章 • 1 个评论 • 1739 次浏览 • 2022-08-12 17:19 • 来自相关话题

本书由数十位 Elasticsearch 技术圈的优秀开发者共创而成，得到了许多资深业界精英，社区技术大咖，Elastic Stack 相关书籍作者的支持，凝聚了众多创作人的实践经验和创作能力。 书籍涵盖了一位 Elastic Stack 开发者所需的必要知识，尤其对于刚入门的开发者，从上篇基础的 Elastic Stack 产品能力到下篇的应用实践，提供了系统性学习参考的上手指南。

Elasticsearch 无疑是大数据搜索引擎中的王者，它以其开放及免费、易用、多语言接口、卓越性能及不断创新的优势，被许多 IT 企业所采用。当今的许多IT 企业很难绕过它。在中国，Elastic Stack 有一个很强大的生态圈。在本书的创作过程中，我非常高兴看到有数十位志愿者参与到本书的创作中。这本书集众技术大咖及专家们的无私奉献，是他们牺牲了自己宝贵的时间，利用业余时间共创完成，在一遍遍的修改中把内容做得更完善。在这里衷心感谢他们的无私付出和合作。

写书和做社区贡献，是需要情怀的。我一直坚信帮助别人，也会成就自己。分享自己的知识，也是一件很快乐的事，因为这样可以证明自己的人生价值。我有超过16 年的社区参与经历，也非常喜欢分享我学到的知识。从加入Elastic 公司以来，我在CSDN 上已经发表了将近660 篇关于Elastic Stack 方面的文章，涵盖了Elastic Stack 方方面面的知识。

作为本书主编，我投入了很多时间来策划、创作、校正及阅读这本书，尽力保证本书的完整性、正确性、一致性及每篇文章的独立性。尽管如此，里面可能有不尽之处，希望读者们海涵！这本书涵盖了Elastic Stack 的介绍、安装、实操、产品能力、方案及案例，特别适合初学者，

对有经验的开发者来说也是一本难得的参考书。在未来，希望有更多的开发者分享自己的知识，

让我们一起把Elastic 社区做得更好！

我强烈推荐想学 Elastic Stack 技术的开发者，下载这本书作为参考。下载连接为 Elastic Stack 实战手册-藏经阁-阿里云开发者社区 https://developer.aliyun.com/ebook/7687
 
https://elasticstack.blog.csdn ... 01982
 

alibaba_book.png

 
 

Open Source@Scale！2022年国际开源节（IOSF）全球首发！

默认分类 • OSTech 发表了文章 • 0 个评论 • 5 次浏览 • 2022-04-07 11:36 • 来自相关话题

2022国际开源节（IOSF）
由OSTech携手环球资源，联合中国信息通信研究院、Linux基金会亚太区发起策划，在CTIS消费者科技及创新展览会落地，并聚集了包括中国科学院软件研究所、CNCF、LF AI & Data、LFOSSA、LF Edge、OpenSSF、Hyperledger基金会等国际一流开源基金会和机构，GDG、开源中国等全球知名开发者社区，以及上海开源信息技术协会等本地开源力量的共建支持。国际开源节旨在汇聚全球开源技术与项目，融合国际文化、开源社区生态和开源产业发展，构建“共创共赢”的开源文化，打造中国开源新生态。
2022国际开源节（IOSF）
由OSTech携手环球资源，联合中国信息通信研究院、Linux基金会亚太区发起策划，在CTIS消费者科技及创新展览会落地，并聚集了包括中国科学院软件研究所、CNCF、LF AI & Data、LFOSSA、LF Edge、OpenSSF、Hyperledger基金会等国际一流开源基金会和机构，GDG、开源中国等全球知名开发者社区，以及上海开源信息技术协会等本地开源力量的共建支持。国际开源节旨在汇聚全球开源技术与项目，融合国际文化、开源社区生态和开源产业发展，构建“共创共赢”的开源文化，打造中国开源新生态。

极限网关初探（2）配置

Elasticsearch • xushuhui 发表了文章 • 0 个评论 • 1069 次浏览 • 2022-04-06 17:03 • 来自相关话题

配置

上一篇我们先学习了极限网关的安装和启动，今天学习配置。

读写分离



现在我们遇到读写分离的需求，用网关该怎么做呢？
假设服务端现在从 http://127.0.0.1:8000 写入数据，从 http://127.0.0.1:9000 读取数据，怎么设计呢？

首先查看文档[配置文档](https://xn--d6q905cs0q16u.com/zh/docs/overview/)

我们在 gateway.yml 中定义两个 entry，分别绑定不同的端口，配置不同的 router
```yaml
entry:

  • name: write_es
    enabled: true
    router: write_router
    network:
    binding: 0.0.0.0:8000
  • name: read_es
    enabled: true
    router: read_router
    network:
    binding: 0.0.0.0:9000

    router:
  • name: write_router
    default_flow: default_flow
    tracing_flow: logging
  • name: read_router
    default_flow: default_flow
    tracing_flow: logging
    <br /> 为了演示效果，只配置一个 Elasticsearch<br /> yaml
    elasticsearch:
  • name: hello_flow
    filter:
    • echo:
      message: "hello flow"

      router:
  • name: read_router
    default_flow: hello_flow
    ```
    修改配置后启动

    ![](https://cdn.guojiang.club/Fv9j ... 2neIuu)

    返回 json 数据

    返回字符串不符合标准的 restful 接口规范，怎么返回给调用方标准 json 数据？
    ```yaml
    filter:

  • set_response:
    content_type: application/json
    body: '{"message":"hello world"}'
    ```
    修改配置后启动

    ![](https://cdn.guojiang.club/FlUk ... tJalBC)

    修改路由

    我们已经新加了接口，返回 json 数据，但是接口是直接定义在 http://127.0.0.1:9000 中，之前网关的接口就无法使用，所以我们需要单独为自定义的接口指定单独的路由
    ```yaml
    router:

  • name: read_router
    default_flow: default_flow
    tracing_flow: logging
    rules:
    • method:
      • GET
        pattern:
      • "/hello"
        flow:
      • hello_flow
        ```
        default_flow: 默认的处理流，也就是业务处理的主流程，请求转发、过滤、缓存等操作都在这里面进行

        tracing_flow：用于追踪请求状态的流，用于记录请求日志、统计等

        如果我们有过开发经验，了解 MVC 模式，flow 就类似 MVC 中的 Controller，rules 中类似路由规则，当请求匹配到配置中的路由规则时，由配置的 flow 处理业务逻辑。

        数据整体流向，从服务端发到网关，网关为每个 Elasticsearch 绑定不同的 IP 地址，每个 Elasticsearch 都有唯一一个 router 和它对应，根据请求的 method 和 path 匹配到 router 中的一个 flow，flow 中包含多个 filter 处理对数据进行流式处理。

        如下图所示
        ![](https://cdn.guojiang.club/FqQE ... t66soy)

        流式处理是什么，假设水从一个管子里面流出来，管子旁边每一段依次站了几个人，第一个人往水里放点鱼，鱼和水到了第二个人，第二个人往水里放点草，鱼、水和草到了第三人等等，每个人对水做一定的操作，水经过这些操作后最后到达水池里。

        我们可以把数据当成水，filter 是管子旁边的人，水池就是 Elasticsearch

        总结

        在学习了router/flow/filter后，我们已经对极限网关的配置有了初步的了解，后续开发的时候直接查阅文档。

极限网关初探（1） 安装启动

Elasticsearch • xushuhui 发表了文章 • 0 个评论 • 1017 次浏览 • 2022-04-06 16:54 • 来自相关话题

产品介绍

极限网关（INFINI Gateway）是一个面向 Elasticsearch 的高性能应用网关。特性丰富，使用简单。

它和其他业务型网关最大的区别是业务网关把请求转发给各个底层微服务，而它把请求转发给 Elasticsearch，更多是类似 Mycat 的中间件的作用。

没有使用网关之前，服务端请求多个节点
![](https://cdn.guojiang.club/Fkfv ... j5rNgV)

使用网关后
![](https://cdn.guojiang.club/FllB ... JkCjFL)

下载地址

打开 [下载地址](http://release.infinilabs.com/gateway/stable/)，根据操作系统版本选择。

Windows 安装和启动

安装

下载 gateway-1.6.0_SNAPSHOT-597-windows-amd64.zip，解压如下。
![](https://cdn.guojiang.club/Furr ... N9rc3Y)
gateway-windows-amd64.exe 是启动文件，gateway.yml 是默认配置文件。

启动失败

当 gateway.yml 的 elasticsearch 选项中的 hosts 不能正常响应请求的时候，启动界面如下。
![](https://cdn.guojiang.club/FvYi ... Iw0r-T)

为什么 elasticsearch 不能访问的时候，网关还要继续提供服务呢，为什么不像业务接口启动时在基础业务组件如 MySQL/Redis 不能正常响应就直接 panic？

一方面网关作为 elasticsearch 抵挡流量冲击的城墙，在 elasticsearch 不能提供服务的时候，对之前成功的请求缓存结果，继续提供有限度的服务，为 elasticsearch 修复后上线争取时间。

另一方面业务接口和基础组件是强耦合关系，没有基础组件就完全无法对外提供数据读写服务，而网关与 elasticsearch 是松耦合关系，网关在没有 elasticsearch 的情况下也能对外提供有限度的服务。

在 gateway.yml 的 elasticsearch 选项中的 hosts 改成能够正常响应的 elasticsearch 请求地址。

启动成功

双击 gateway-windows-amd64.exe 文件，启动成功界面如下

![](https://cdn.guojiang.club/Figt ... intqJr)

访问

API 访问

由启动后终端显示可知，网关的 API 接口地址是 http://localhost:2900
sh<br /> [api.go:262] api listen at: <a href="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://0.0.0.0:2900</a><br />
打开浏览器输入 http://localhost:2900，显示所有可以对外提供的 API 接口
![](https://cdn.guojiang.club/FuRr ... paD-7Y)

我们选择其中一个，在浏览器中输入 http://localhost:2900/_framework/api/_version 从路由上看该接口是查询产品的版本信息，显示如下
![](https://cdn.guojiang.club/FkOZ ... eVBXkR)

gateway.yml 中可以看到有被注释掉的一段配置，看起来应该是配置 api 地址的地方。
```yaml

api:

enabled: true

network:

binding: 127.0.0.1:2900

<br /> 把注释去掉后尝试把端口改成 2901。<br /> yaml
api:
enabled: true
network:
binding: 127.0.0.1:2901
```
改完后启动
![](https://cdn.guojiang.club/FkDO ... x5XwQT)
打开浏览器先输入 http://localhost:2900，无法正常响应请求，再输入 http://localhost:2901，可以正常响应，界面和修改配置前访问 http://localhost:2900 的界面一样，说明 API 请求地址成功修改

Elasticsearch 访问

启动日志中显示监听 8000 端口，猜测应该是 elasticsearch 请求地址，打开浏览器输入 http://127.0.0.1:8000/
sh<br /> entry [my_es_entry] listen at: <a href="http://0.0.0.0:8000" rel="nofollow" target="_blank">http://0.0.0.0:8000</a><br />
![](https://cdn.guojiang.club/Foxm ... Dw9lzO)
gateway.yml 中可以看到 my_es_entry 的 network 绑定 8000 端口，显而易见的这部分就是配置代理转发给 elasticsearch 的地址，所以安装后只需要把以前请求 elasticsearch 的地址修改为该地址。
```yaml
entry:

  • name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
    binding: 0.0.0.0:8000
    ```

    总结

    我们成功安装和启动极限网关，接下来我们学习怎么根据需求修改配置。

【延期公告】Elastic 中国开发者大会 2021 举办日期延期至3月5日

活动 • liaosy 发表了文章 • 0 个评论 • 855 次浏览 • 2022-01-07 17:43 • 来自相关话题

【延期公告】
由于1月7日深圳疫情影响，为保障每位参会者健康和安全，Elastic中国开发者大会主办方经研究决定原计划于1月8日举办的大会延期至3月5日，对此延期主办方深表歉意，感谢大家的支持和理解。期待三月春暖花开和大家相聚！

 
elastic_delay_notice.png

 

使用极限网关来处置 Elasticsearch 的 Apache Log4j 漏洞

Elasticsearch • medcl 发表了文章 • 2 个评论 • 4003 次浏览 • 2021-12-11 03:57 • 来自相关话题

昨日爆出的 Log4j 安全漏洞，业界一片哗然，今天给大家介绍一下，如何使用极限网关来快速处置 Elasticsearch 的 Apache Log4j 漏洞。

【CVE 地址】

[https://github.com/advisories/GHSA-jfh8-c2jp-5v3q](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q)

【漏洞描述】

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 版本[http://release.elasticsearch.cn/gateway/snapshot/](http://release.elasticsearch.cn/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
  • name: log4j_matched_flow
    filter:
    • echo:
      message: 'Apache Log4j 2, Boom!'

      elasticsearch:
  • name: es-server
    enabled: true
    endpoints:
    • http://localhost:9200
      <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="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://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="http://0.0.0.0:8000" rel="nofollow" target="_blank">http://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 'http://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 'http://localhost:8000/index1/_search?q=%24%7Bjava%3Aos%7D' <br /> <br /> Apache Log4j 2, Boom!% <br />
      可以看到请求被过滤掉了，返回了自定义的信息。

      还有一些其他测试命令，大家也可以试试：

      ```

      {java:vm}

      ~% curl 'http://localhost:9200/index/_search?q=%24%7Bjava%3Avm%7D'
      [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 'http://localhost:8000/index/_search?q=%24%7Bjava%3Avm%7D'
      Apache Log4j 2, Boom!%

      {jndi:rmi://localhost:1099/api}

      ~% curl 'http://localhost:9200/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
      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 'http://localhost:8000/index/_search?q=%24%7Bjndi%3Armi%3A%2F%2Flocalhost%3A1099%2Fapi%7D'
      Apache Log4j 2, Boom!%
      ```

      另外不同版本的 Elasticsearch 对于攻击的复现程度参差不齐，因为 es 不同版本是否有 Java Security Manager 、不同版本 JDK 、以及默认配置也不相同，新一点的 es 其实同样可以触发恶意请求，只不过网络调用被默认的网络策略给拒绝了，相对安全，当然如果设置不当同样存在风险，见过很多用户一上来就关默认安全配置的，甚至还放开很多暂时用不上的权限，另外未知的攻击方式也一定有，比如大量日志产生的系统调用可能会拖垮机器造成服务不可用，所以要么还是尽快改配置换 log4j 包重启集群，或者走网关来过滤阻断请求吧。

      使用极限网关处置类似安全事件的好处是，Elasticsearch 服务器不用做任何变动，尤其是大规模集群的场景，可以节省大量的工作，提升效率，非常灵活，缩短安全处置的时间，降低企业风险。

Elastic Meetup 重庆站讲师招募与主题征集中

活动 • liaosy 回复了问题 • 2 人关注 • 1 个回复 • 885 次浏览 • 2021-11-25 16:18 • 来自相关话题

发布一个免费的 Elasticsearch 多集群监控和管理平台 - 极限数据平台

Elasticsearch • medcl 发表了文章 • 20 个评论 • 4624 次浏览 • 2021-11-22 18:48 • 来自相关话题

随着单个 Elasticsearch 集群规模的越来越大，大家要么在拆集群的路上，要么是已经是多套集群了， 据路边社消息，一个公司超过5个集群的情况已经变得非常普遍，而管理多个集群着实是有点痛苦，比如常规的玩法可能是一套集群一个 Kibana，集群一多，切换来切换去就有点懵圈了有木有？


fansile.gif




作为一个优雅的程序员或者运维管理员，是可忍孰不可忍啊。

另外，多个集群的监控也是一个麻烦事，目前常见的几种监控如：

  • 使用 Kibana 自带的监控
  • 使用 Prometheus + Grafana
  • 使用 Zabbix

    Kibana 自带的监控可以很好的满足单个集群的监控场景，不过集群规模大了之后，经常会出现指标丢失的问题，如果使用单独的监控集群，需要修改每个节点的配置，集群都需要重启，对于已经上了生产的集群，有点不方便，另外多集群监控需要商业授权。


    e82a31225ca28ed8029e0681f9346ee2.gif




    那 Prometheus 呢， 一个 Elasticsearch 集群如果要监控起来，首先需要部署一个 Exporter 来暴露集群指标，然后部署一套Prometheus 来采集 Elasticsearch 指标，采集完了之后再部署一套 Grafana 来进行报表分析，不同的集群要做好切换，简单的事情，搞复杂了，整个监控体系偏重，维护成本高。

    Zabbix 和 Prometheus 的场景差不多，就不赘述了。


    530a83558eabaa4ae4eb25501349a7a3_16590_250_187.jpeg




    那么问题来了，有没有一个更加简单方便的多集群监控和管理方案呢，并且要支持不同版本的集群，最好是 v2、v5、v6、v7 以及最新的 v8 都能统统接管，哈哈，没错了，这里给大家介绍一个我们极限实验室团队最近开发出来的一款免费的多集群监控和管理工具-极限数据平台，目前版本 v0.1，新鲜出炉。

    废话不多少，咱们直接看图说话：

    Jietu20211122-183111.jpg



    首先是多集群的纳管，目前从 1.0 到最新的 8.0 统统都可以接进来。

    Jietu20211122-183020.jpg



    然后就是集群的监控拉，要多简单有多简单，就是一个开关的事情，注册集群的时候，启用即开启监控，目标集群啥都不用动，费那劲干啥。

    监控界面如图：

    Jietu20211122-183309.jpg



    集群概览，总体情况一目了然。

    Jietu20211122-183438.jpg



    各个节点信息，分门别类。

    Jietu20211122-183504.jpg



    各个索引级别的信息，挨个查看。

    Jietu20211122-183558.jpg



    多个集群之间的监控查看一键切换，非常方便。

    查看监控的时候，发现不对劲，要操作一下集群，直接调出控制台，如下图：

    Jietu20211122-183717.jpg



    常用的操作命令，可以保存起来，方便下次使用。

    Jietu20211122-183815.jpg



    别再保存在记事本里面了，下次又找不到，直接加载执行就好了。

    Jietu20211122-183924.jpg



    好了，你要是用 Elasticsearch 不知道这个工具，那就 out 了，赶快耍起来吧。

    下载地址：

    [http://release.elasticsearch.cn/console/snapshot/](http://release.elasticsearch.cn/console/snapshot/)


    安装巨简单，简直懒得说，一个二进制可执行文件，一个 yml 配置文件，里面修改 Elasticsearch 地址，结束。

    可以在这里查看 [介绍和 Demo 演示视频](https://www.bilibili.com/video ... KdMVLQ)

    最后，欢迎关注极限实验室，获取更多 Elasticsearch 免费工具及业界资讯的第一手消息。

    WechatIMG700.jpeg


Elastic 中国开发者大会 2021 开启了，预热铁粉票已开抢，手慢无！

活动 • liaosy 发表了文章 • 0 个评论 • 2201 次浏览 • 2021-11-11 17:45 • 来自相关话题


banner-1080x640-infini.png

Elastic 中国开发者大会 2021 是由 Elastic 官方、Elastic 中文社区和极限科技联合主办的开发者大会，作为中国国内唯一一个专门讨论 Elasticsearch 开源技术的大会，是中国最权威和最具实力干货的技术大会，其专业性和内容的质量一直以来在业内都是有口皆碑，大会最早发起于 2013 年初一个很小的线下聚会，之后每年迅速成长，往年大会的演讲嘉宾有来自 Elastic 官方、百度、腾讯、阿里巴巴、360、微博、美团、58、苏宁等众多公司的技术专家，带来过众多精彩的分享，与会听众大多为大数据领域相关的架构师、技术经理与一线开发工程师和运维工程师。

我们本着非盈利目的来举办大会，今年的大会将于2022年1月8号在深圳举行，举办开发者大会的目的是为中国广大的 Elasticsearch 开发者提供一个技术交流和学习切磋的地方，汇集业界众多的成功案例，集思广益，发散思维，促进社区和行业的进步。
 
大会官网：https://conf.elasticsearch.cn

Elasticsearch铁粉福利：
预热-铁粉票(79元/张)， 共计100张，数量有限，赶紧去报名抢购吧！
购票地址：https://www.bagevent.com/event/7899116
 
同时大会也在公开征集演讲议题与合作赞助商，欢迎各位Elastic相关技术大咖报名参与分享，欢迎有兴趣的赞助商金主大大前来合作。

演讲报名申请：http://elasticsearch.mikecrm.com/uXH61JL
赞助合作申请：http://elasticsearch.mikecrm.com/6LGkKK0
 
 

ES容灾技术探讨和测试

Elasticsearch • yangmf2040 发表了文章 • 3 个评论 • 2665 次浏览 • 2021-10-27 13:33 • 来自相关话题

ES灾备技术调研


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

  1. 应用双写两个集群

  2. 跨集群复制CCR

  3. 极限网关

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

  4. 优点：自主研发，想怎样就怎样；缺点：难，水平、时间都是成本

  5. 优点：实施简单；缺点：需要license

  6. 优点：部署灵活，功能齐全；缺点：不熟悉，没用过



    貌似方案 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圈（论坛）多交流交流。让我也看看你们的场景和测试是怎样的。

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

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

默认分类 • liaosy 发表了文章 • 0 个评论 • 908 次浏览 • 2021-10-18 13:18 • 来自相关话题

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

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

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

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

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

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

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

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

Elasticsearch • medcl 发表了文章 • 7 个评论 • 2371 次浏览 • 2021-10-16 11:31 • 来自相关话题

使用场景

如果你的业务需要用到有多个集群，并且版本还不一样，是不是管理起来很麻烦，如果能够通过一个 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
      ``<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
    • name: v7-flow
      filter:
      • elasticsearch:
        elasticsearch: v7
        <br /> <br /> 然后，在定义额外一个名为 `cross-cluster-search` 的 flow，如下：<br /> <br />
    • 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:
    • 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，运行如下命令：

        <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="http://0.0.0.0:2900" rel="nofollow" target="_blank">http://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 里面访问


        完全没问题，有图有真相：

        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 跨集群跨版本的操作就到这里了，希望大家周末玩的开心。😁

欢迎参加本周六 DevOps社区大连峰会，还有少量赠票

默认分类 • martinliu 发表了文章 • 0 个评论 • 1022 次浏览 • 2021-08-31 12:37 • 来自相关话题

Elastic 作为金牌合作伙伴加盟 2021 中国DevOps社区峰会 ，下面是Elastic 公司开发者布道师刘征的分享话题简介

嘉宾介绍：刘征，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中。
 

2021-08-31_12-19-56.png


欢迎参与DevOps 社区峰会大连站，欢迎关注刘征老师的以上分享。关注本微信的朋友可以扫码下面的二维码免费注册本次峰会，本次社区峰会还给大家准备了社区定制版卫衣和抽奖书籍等周边。还等什么，让我们本周六在峰会上不见不散吧！
 

2021-08-31_12-20-07.png


扫码即得最后剩余的免费门票。
查看大会的全部日程。
 

WechatIMG1617.jpeg

 
 
Copyright © 2023· CC BY-NC-SA 3.0