使用netstat -lntp来看看有侦听在网络某端口的进程。当然,也可以使用 lsof。

发布一个轻量级的 Elasticsearch 压测工具 - Loadgen

medcl 发表了文章 • 0 个评论 • 4633 次浏览 • 2022-06-01 16:55 • 来自相关话题

你是否遇到过新搭建一个 Elasticsearch 集群,但是却无法评估该集群的最大吞吐是多少,或者使用一些压测工具,比如 esrally,需要花费很大力气准备,但是却无法压测到极限速度,服务器资源跑不满,或者测试产生的数据和实际的业务有很多出入,又或者测试的请求太简单,比如查询,就是对单个固定的搜索请求进行查询,不仅测不准还可能浪费时间没有参考意义,so,有没有一个简单的工具可以支持灵活的自定义压测,并且足够快,答案是 Loadgen。

Loadgen


Elasticsearch 压测工具 Loadgen ,由极限实验室出品,基于 Elasticsearch 的开发运维需求而开发,久经实际客户环境的真实考验,简单好用速度快。

一个没有经过压测的 Elasticsearch 不是一个完整的 Elasticsearch。

Loadgen 具有以下主要特点:

  • 性能强劲
  • 轻量级无依赖
  • 支持模板化参数随机
  • 支持高并发
  • 支持压测端均衡流量控制

    只有模拟自己真实业务数据场景的压测才有意义,通过使用 Loadgen 定义写入文档或者查询模板,同时将里面的变量词典化,确保每次请求都是足够随机,变量可以灵活复用,支持多个请求混合压测,最大程度模拟真实环境。

  • 下载地址:[http://release.infinilabs.com/loadgen/](http://release.infinilabs.com/loadgen/)
  • Docker 地址:[https://hub.docker.com/r/infinilabs/loadgen](https://hub.docker.com/r/infinilabs/loadgen)

    Loadgen


    Loadgen 使用非常简单,下载解压之后会得到两个文件,一个可执行程序和一个配置文件 loadgen.yml,配置文件样例如下:

    ```
    variables:

    • name: ip
      type: file
      path: test/ip.txt
    • name: user
      type: file
      path: test/user.txt
    • name: id
      type: sequence
    • name: uuid
      type: uuid
    • name: now_local
      type: now_local
    • name: now_utc
      type: now_utc
    • name: now_unix
      type: now_unix
      requests:
    • request:
      method: GET
      basic_auth:
      username: elastic
      password: pass
      url: http://localhost:8000/medcl/_search
      body: '{ "query": {"match": { "name": "$[[user]]" }}}'
      ```

      变量的使用


      上面的配置中,variables 用来定义变量参数,根据 name 来设置变量标识,在构造请求的使用 $[[变量名]] 即可访问该变量的值,变量目前支持的类型有:

      | 类型 | 说明 |
      | --------- |------------------------------------|
      | file | 文件型外部变量参数 |
      | sequence | 自增数字类型的变量 |
      | range | 数字范围类型的变量,支持参数 fromto 来限制范围 |
      | uuid | UUID 字符类型的变量 |
      | now_local | 当前时间、本地时区 |
      | now_utc | 当前时间、UTC 时区 |
      | now_unix | 当前时间、Unix 时间戳 |

      file 类型变量参数加载自外部文本文件,每行一个变量参数,访问该变量时每次随机取其中一个,变量里面的定义格式举例如下:

      <br /> ➜ loadgen git:(master) ✗ cat test/user.txt <br /> medcl<br /> elastic<br />

      请求的定义


      配置节点 requests 用来设置 Loadgen 将依次执行的请求,支持固定参数的请求,也可支持模板变量参数化构造请求,以下是一个普通的查询请求:

      ```
      requests:

    • request:
      method: GET
      basic_auth:
      username: elastic
      password: pass
      url: http://localhost:8000/medcl/_search?q=name:$[[user]]
      ``<br /> 上面的查询对medcl索引进行了查询,并对name字段执行一个查询,每次请求的值来自随机变量user`。

      命令行参数


      Loadgen 会循环执行配置文件里面定义的请求,默认 Loadgen 只会运行 5s 就自动退出了,如果希望延长运行时间或者加大并发可以通过启动的时候设置参数来控制,通过查看帮助命令如下:

      <br /> ➜ loadgen git:(master) ✗ ./bin/loadgen --help<br /> Usage of ./bin/loadgen:<br /> -c int<br /> Number of concurrent threads (default 1)<br /> -compress<br /> Compress requests with gzip<br /> -config string<br /> the location of config file, default: loadgen.yml (default "loadgen.yml")<br /> -d int<br /> Duration of tests in seconds (default 5)<br /> -debug<br /> run in debug mode, loadgen will quit with panic error<br /> -l int<br /> Limit total requests (default -1)<br /> -log string<br /> the log level,options:trace,debug,info,warn,error (default "info")<br /> -r int<br /> Max requests per second (fixed QPS) (default -1)<br /> -v version<br />

      执行压测


      执行 Loadgen 程序即可执行压测,如下:

      <br /> ➜ loadgen git:(master) ✗ ./bin/loadgen -d 30 -c 100 -compress<br /> __ ___ _ ___ ___ __ __<br /> / / /___\/_\ / \/ _ \ /__\/\ \ \<br /> / / // ///_\\ / /\ / /_\//_\ / \/ /<br /> / /__/ \_// _ \/ /_// /_\\//__/ /\ /<br /> \____|___/\_/ \_/___,'\____/\__/\_\ \/<br /> <br /> [LOADGEN] A http load generator and testing suit.<br /> [LOADGEN] 1.0.0_SNAPSHOT, 83f2cb9, Sun Jul 4 13:52:42 2021 +0800, medcl, support single item in dict files<br /> [07-19 16:15:00] [INF] [instance.go:24] workspace: data/loadgen/nodes/0<br /> [07-19 16:15:00] [INF] [loader.go:312] warmup started<br /> [07-19 16:15:00] [INF] [app.go:306] loadgen now started.<br /> [07-19 16:15:00] [INF] [loader.go:316] [GET] <a href="http://localhost:8000/medcl/_search" rel="nofollow" target="_blank">http://localhost:8000/medcl/_search</a><br /> [07-19 16:15:00] [INF] [loader.go:317] status: 200,<nil>,{"took":1,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}<br /> [07-19 16:15:00] [INF] [loader.go:316] [GET] <a href="http://localhost:8000/medcl/_search?q=name:medcl" rel="nofollow" target="_blank">http://localhost:8000/medcl/_search?q=name:medcl</a><br /> [07-19 16:15:00] [INF] [loader.go:317] status: 200,<nil>,{"took":1,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}<br /> [07-19 16:15:01] [INF] [loader.go:316] [POST] <a href="http://localhost:8000/_bulk" rel="nofollow" target="_blank">http://localhost:8000/_bulk</a><br /> [07-19 16:15:01] [INF] [loader.go:317] status: 200,<nil>,{"took":120,"errors":false,"items":[{"index":{"_index":"medcl-y4","_type":"doc","_id":"c3qj9123r0okahraiej0","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"_seq_no":5735852,"_primary_term":3,"status":201}}]}<br /> [07-19 16:15:01] [INF] [loader.go:325] warmup finished<br /> <br /> 5253 requests in 32.756483336s, 524.61KB sent, 2.49MB received<br /> <br /> [Loadgen Client Metrics]<br /> Requests/sec: 175.10<br /> Request Traffic/sec: 17.49KB<br /> Total Transfer/sec: 102.34KB<br /> Avg Req Time: 5.711022ms<br /> Fastest Request: 440.448µs<br /> Slowest Request: 3.624302658s<br /> Number of Errors: 0<br /> Number of Invalid: 0<br /> Status 200: 5253<br /> <br /> [Estimated Server Metrics]<br /> Requests/sec: 160.37<br /> Transfer/sec: 93.73KB<br /> Avg Req Time: 623.576686ms<br />

      Loadgen 在正式压测之前会将所有的请求执行一次来进行预热,如果出现错误会提示是否继续,预热的请求结果也会输出到终端,执行完成之后会输出执行的摘要信息。

      因为 Loadgen 最后的结果是所有请求全部执行完成之后的累计统计,可能存在不准的问题,建议通过打开 Kibana 或者 [INFINI Console](http://console.infinilabs.com/) 的监控仪表板来实时查看 Elasticsearch 的各项运行指标。

      模拟批量写入


      使用 Loadgen 来模拟 bulk 批量写入也非常简单,在请求体里面配置一条索引操作,然后使用 body_repeat_times 参数来随机参数化复制若干条请求即可完成一批请求的准备,如下:

      ```

    • request:
      method: POST
      basic_auth:
      username: test
      password: testtest
      url: http://localhost:8000/_bulk
      body_repeat_times: 1000
      body: "{ \"index\" : { \"_index\" : \"medcl-y4\",\"_type\":\"doc\", \"_id\" : \"$[[uuid]]\" } }\n{ \"id\" : \"$[[id]]\",\"field1\" : \"$[[user]]\",\"ip\" : \"$[[ip]]\",\"now_local\" : \"$[[now_local]]\",\"now_unix\" : \"$[[now_unix]]\" }\n"
      ```

      限制客户端压力


      使用 Loadgen 并设置命令行参数 -r 可以限制客户端发送的每秒请求数,从而评估固定压力下 Elasticsearch 的响应时间和负载情况,如下:

      <br /> ➜ loadgen git:(master) ✗ ./bin/loadgen -d 30 -c 100 -r 100<br />

      注意,在大量并发下,此客户端吞吐限制可能不完全准确。


      限制请求的总条数


      通过设置参数 -l 可以控制客户端发送的请求总数,从而制造固定的文档,修改配置如下:

      ```
      requests:

    • request:
      method: POST
      basic_auth:
      username: test
      password: testtest
      url: http://localhost:8000/medcl-test/doc2/_bulk
      body_repeat_times: 1
      body: "{ \"index\" : { \"_index\" : \"medcl-test\", \"_id\" : \"$[[uuid]]\" } }\n{ \"id\" : \"$[[id]]\",\"field1\" : \"$[[user]]\",\"ip\" : \"$[[ip]]\" }\n"
      <br /> 每次请求只有一个文档,然后执行 loadgen<br />
      ./bin/loadgen -config loadgen-gw.yml -d 600 -c 100 -l 50000
      ``<br /> 执行完成之后,Elasticsearch 的索引medcl-test将增加50000` 条记录。

      使用自增 ID 来确保文档的顺序性


      如果希望生成的文档编号自增有规律,方便进行对比,可以使用 sequence 类型的自增 ID 来作为主键,内容也不要用随机数,如下:

      ```
      requests:

    • request:
      method: POST
      basic_auth:
      username: test
      password: testtest
      url: http://localhost:8000/medcl-test/doc2/_bulk
      body_repeat_times: 1
      body: "{ \"index\" : { \"_index\" : \"medcl-test\", \"_id\" : \"$[[id]]\" } }\n{ \"id\" : \"$[[id]]\" }\n"
      ```

      上下文复用变量

      在一个请求中,我们可能希望有相同的参数出现,比如 routing 参数用来控制分片的路由,同时我们又希望该参数也保存在文档的 JSON 里面,
      可以使用 runtime_variables 来设置请求级别的变量,或者 runtime_body_line_variables 定义请求体级别的变量,如果请求体复制 N 份,每份的参数是不同的,举例如下:

      ```
      variables:

    • name: id
      type: sequence
    • name: uuid
      type: uuid
    • name: now_local
      type: now_local
    • name: now_utc
      type: now_utc
    • name: now_unix
      type: now_unix
    • name: suffix
      type: range
      from: 10
      to: 15
      requests:
    • request:
      method: POST
      runtime_variables:
      batch_no: id
      runtime_body_line_variables:
      routing_no: uuid
      basic_auth:
      username: ingest
      password: password

      url: http://localhost:8000/_search?q=$[[id]]

      url: http://192.168.3.188:9206/_bulk
      body_repeat_times: 10
      body: "{ \"create\" : { \"_index\" : \"test-$[[suffix]]\",\"_type\":\"doc\", \"_id\" : \"$[[uuid]]\" , \"routing\" : \"$[[routing_no]]\" } }\n{ \"id\" : \"$[[uuid]]\",\"routing_no\" : \"$[[routing_no]]\",\"batch_number\" : \"$[[batch_no]]\", \"random_no\" : \"$[[suffix]]\",\"ip\" : \"$[[ip]]\",\"now_local\" : \"$[[now_local]]\",\"now_unix\" : \"$[[now_unix]]\" }\n"
      ``<br /> <br /> 我们定义了batch_no 变量来代表一批文档里面的相同批次号,同时又定义了 routing_no` 变量来代表每个文档级别的 routing 值。

      最后,欢迎大家反馈使用过程遇到的任何问题。

在 Kibana 里统一访问来自不同集群的索引

medcl 发表了文章 • 0 个评论 • 3044 次浏览 • 2022-04-21 15:29 • 来自相关话题

在 Kibana 里统一访问来自不同集群的索引


现在有这么一个需求,客户根据需要将数据按照业务维度划分,将索引分别存放在了不同的三个集群,
将一个大集群拆分成多个小集群有很多好处,比如降低了耦合,带来了集群可用性和稳定性方面的好处,也避免了单个业务的热点访问造成其他业务的影响,
尽管拆分集群是很常见的玩法,但是管理起来不是那么方便了,尤其是在查询的时候,可能要分别访问三套集群各自的 API,甚至要切换三套不同的 Kibana 来访问集群的数据,
那么有没有办法将他们无缝的联合在一起呢?


极限网关!


答案自然是有的,通过将 Kibana 访问 Elasticsearch 的地址切换为极限网关的地址,我们可以将请求按照索引来进行智能的路由,
也就是当访问不同的业务索引时会智能的路由到不同的集群,如下图:


WechatIMG27.png




上图,我们分别有 3 个不同的索引:

  • apm-*
  • erp-*
  • mall-*

    分别对应不同的三套 Elasticsearch 集群:
  • ES1-APM
  • ES2-ERP
  • ES3-MALL

    接下来我们来看如何在极限网关里面进行相应的配置来满足这个业务需求。

    配置集群信息


    首先配置 3 个集群的连接信息。
    ```
    elasticsearch:

    • name: es1-apm
      enabled: true
      endpoints:
    • name: es2-erp
      enabled: true
      endpoints:
    • name: es3-mall
      enabled: true
      endpoints:
      • http://192.168.3.188:9208
        ```

        配置服务 Flow

        然后,我们定义 3 个 Flow,分别对应用来访问 3 个不同的 Elasticsearch 集群,如下:
        ```
        flow:

    • name: es1-flow
      filter:
      • elasticsearch:
        elasticsearch: es1-apm
    • name: es2-flow
      filter:
      • elasticsearch:
        elasticsearch: es2-erp
    • name: es3-flow
      filter:
      • elasticsearch:
        elasticsearch: es3-mall
        <br /> <br /> 然后再定义一个 flow 用来进行路径的判断和转发,如下:<br />
    • name: default-flow
      filter:
      • switch:
        remove_prefix: false
        path_rules:
        • prefix: apm-
          flow: es1-flow
        • prefix: erp-
          flow: es2-flow
        • prefix: mall-
          flow: es3-flow
      • flow: #default flow
        flows:
        • es1-flow
          ```

          根据请求路径里面的索引前缀来匹配不同的索引,并转发到不同的 Flow。

          配置路由信息


          接下来,我们定义路由信息,具体配置如下:

          ```
          router:

    • name: my_router
      default_flow: default-flow
      ```

      指向上面定义的默认 flow 来统一请求的处理。

      定义服务及关联路由


      最后,我们定义一个监听为 8000 端口的服务,用来提供给 Kibana 来进行统一的入口访问,如下:
      ```
      entry:

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

      完整配置


      最后的完整配置如下:

      ```
      path.data: data
      path.logs: log

      entry:

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

      flow:
    • name: default-flow
      filter:
      • switch:
        remove_prefix: false
        path_rules:
        • prefix: apm-
          flow: es1-flow
        • prefix: erp-
          flow: es2-flow
        • prefix: mall-
          flow: es3-flow
      • flow: #default flow
        flows:
        • es1-flow
    • name: es1-flow
      filter:
      • elasticsearch:
        elasticsearch: es1-apm
    • name: es2-flow
      filter:
      • elasticsearch:
        elasticsearch: es2-erp
    • name: es3-flow
      filter:
      • elasticsearch:
        elasticsearch: es3-mall

        router:
    • name: my_router
      default_flow: default-flow

      elasticsearch:
    • name: es1-apm
      enabled: true
      endpoints:
    • name: es2-erp
      enabled: true
      endpoints:
    • name: es3-mall
      enabled: true
      endpoints:
      • http://192.168.3.188:9208
        ```

        启动网关


        直接启动网关,如下:

        <br /> ➜ gateway git:(master) ✗ ./bin/gateway -config sample-configs/elasticsearch-route-by-index.yml <br /> <br /> ___ _ _____ __ __ __ _ <br /> / _ \ /_\ /__ \/__\/ / /\ \ \/_\ /\_/\<br /> / /_\///_\\ / /\/_\ \ \/ \/ //_\\\_ _/<br /> / /_\\/ _ \/ / //__ \ /\ / _ \/ \ <br /> \____/\_/ \_/\/ \__/ \/ \/\_/ \_/\_/ <br /> <br /> [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.<br /> [GATEWAY] 1.0.0_SNAPSHOT, 2022-04-20 08:23:56, 2023-12-31 10:10:10, 51650a5c3d6aaa436f3c8a8828ea74894c3524b9<br /> [04-21 13:41:21] [INF] [app.go:174] initializing gateway.<br /> [04-21 13:41:21] [INF] [app.go:175] using config: /Users/medcl/go/src/infini.sh/gateway/sample-configs/elasticsearch-route-by-index.yml.<br /> [04-21 13:41:21] [INF] [instance.go:72] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/c9bpg0ai4h931o4ngs3g<br /> [04-21 13:41:21] [INF] [app.go:283] gateway is up and running now.<br /> [04-21 13:41:21] [INF] [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 /> [04-21 13:41:21] [INF] [reverseproxy.go:255] elasticsearch [es1-apm] hosts: [] => [192.168.3.188:9206]<br /> [04-21 13:41:21] [INF] [reverseproxy.go:255] elasticsearch [es2-erp] hosts: [] => [192.168.3.188:9207]<br /> [04-21 13:41:21] [INF] [reverseproxy.go:255] elasticsearch [es3-mall] hosts: [] => [192.168.3.188:9208]<br /> [04-21 13:41:21] [INF] [actions.go:349] elasticsearch [es2-erp] is available<br /> [04-21 13:41:21] [INF] [actions.go:349] elasticsearch [es1-apm] is available<br /> [04-21 13:41:21] [INF] [entry.go:312] entry [es_entry] listen at: <a href="http://0.0.0.0:8000" rel="nofollow" target="_blank">http://0.0.0.0:8000</a><br /> [04-21 13:41:21] [INF] [module.go:116] all modules are started<br /> [04-21 13:41:21] [INF] [actions.go:349] elasticsearch [es3-mall] is available<br /> [04-21 13:41:55] [INF] [reverseproxy.go:255] elasticsearch [es1-apm] hosts: [] => [192.168.3.188:9206]<br />

        网关启动成功之后,就可以通过网关的 IP+8000 端口来访问目标 Elasticsearch 集群了。

        测试访问


        首先通过 API 来访问测试一下,如下:

        ```
        ➜ ~ curl http://localhost:8000/apm-2022/_search -v

  • Trying 127.0.0.1...
  • TCP_NODELAY set
  • Connected to localhost (127.0.0.1) port 8000 (#0)

    GET /apm-2022/_search HTTP/1.1
    Host: localhost:8000
    User-Agent: curl/7.54.0
    Accept: /

    < HTTP/1.1 200 OK
    < Date: Thu, 21 Apr 2022 05:45:44 GMT
    < content-type: application/json; charset=UTF-8
    < Content-Length: 162
    < X-elastic-product: Elasticsearch
    < X-Backend-Cluster: es1-apm
    < X-Backend-Server: 192.168.3.188:9206

    < X-Filters: filters->elasticsearch
    <
  • Connection #0 to host localhost left intact
    {"took":142,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}%
    <br /> <br /> 可以看到 apm-2022 指向了后端的 `es1-apm` 集群。<br /> <br /> 继续测试,erp 索引的访问,如下:<br />
    ➜ ~ curl http://localhost:8000/erp-2022/_search -v
  • Trying 127.0.0.1...
  • TCP_NODELAY set
  • Connected to localhost (127.0.0.1) port 8000 (#0)

    GET /erp-2022/_search HTTP/1.1
    Host: localhost:8000
    User-Agent: curl/7.54.0
    Accept: /

    < HTTP/1.1 200 OK
    < Date: Thu, 21 Apr 2022 06:24:46 GMT
    < content-type: application/json; charset=UTF-8
    < Content-Length: 161
    < X-Backend-Cluster: es2-erp
    < X-Backend-Server: 192.168.3.188:9207

    < X-Filters: filters->switch->filters->elasticsearch->skipped
    <
  • Connection #0 to host localhost left intact
    {"took":12,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":{"value":0,"relation":"eq"},"max_score":null,"hits":[]}}%
    <br /> 继续测试,mall 索引的访问,如下:<br /> <br />
    ➜ ~ curl http://localhost:8000/mall-2022/_search -v
  • Trying 127.0.0.1...
  • TCP_NODELAY set
  • Connected to localhost (127.0.0.1) port 8000 (#0)

    GET /mall-2022/_search HTTP/1.1
    Host: localhost:8000
    User-Agent: curl/7.54.0
    Accept: /

    < HTTP/1.1 200 OK
    < Date: Thu, 21 Apr 2022 06:25:08 GMT
    < content-type: application/json; charset=UTF-8
    < Content-Length: 134
    < X-Backend-Cluster: es3-mall
    < X-Backend-Server: 192.168.3.188:9208

    < X-Filters: filters->switch->filters->elasticsearch->skipped
    <
  • Connection #0 to host localhost left intact
    {"took":8,"timed_out":false,"_shards":{"total":5,"successful":5,"skipped":0,"failed":0},"hits":{"total":0,"max_score":null,"hits":[]}}%
    ```

    完美转发。

    修改 Kibana 配置


    修改 Kibana 的配置文件: kibana.yml,替换 Elasticsearch 的地址为网关地址(<a href="http://192.168.3.200:8000" rel="nofollow" target="_blank">http://192.168.3.200:8000</a>),如下:
    <br /> elasticsearch.hosts: ["<a href="http://192.168.3.200:8000"" rel="nofollow" target="_blank">http://192.168.3.200:8000"</a>]<br />

    重启 Kibana 让配置生效。

    效果如下



    kibana-clusers-op.jpg




    可以看到,在一个 Kibana 的开发者工具里面,我们已经可以像操作一个集群一样来同时读写实际上来自三个不同集群的索引数据了。

    展望


    通过极限网关,我们还可以非常灵活的进行在线请求的流量编辑,动态组合不同集群的操作。

在极限网关里面使用 JavaScript 脚本来进行复杂的查询改写

medcl 发表了文章 • 1 个评论 • 1912 次浏览 • 2022-04-19 11:55 • 来自相关话题

使用 JavaScript 脚本来进行复杂的查询改写


有这么一个需求:

网关里怎样对跨集群搜索进行支持的呢?我想实现: 输入的搜索请求是 lp:9200/index1/_search
这个索引在3个集群上,需要跨集群检索,也就是网关能否改成 lp:9200/cluster01:index1,cluster02,index1,cluster03:index1/_search 呢?
索引有一百多个,名称不一定是 app, 还可能多个索引一起的。

极限网关自带的过滤器 content_regex_replace 虽然可以实现字符正则替换,但是这个需求是带参数的变量替换,稍微复杂一点,没有办法直接用这个正则替换实现,有什么其他办法实现么?

使用脚本过滤器


当然有的,上面的这个需求,理论上我们只需要将其中的索引 index1 匹配之后,替换为 cluster01:index1,cluster02,index1,cluster03:index1 就行了。

答案就是使用自定义脚本来做,再复杂的业务逻辑都不是问题,都能通过自定义脚本来实现,一行脚本不行,那就两行。

使用极限网关提供的 [JavaScript](https://gateway.infinilabs.com ... cript/) 过滤器可以很灵活的实现这个功能,具体继续看。

定义过滤器


首先创建一个脚本文件,放在网关数据目录的 scripts 子目录下面,如下:

<br /> ➜ gateway ✗ tree data <br /> data<br /> └── gateway<br /> └── nodes<br /> └── c9bpg0ai4h931o4ngs3g<br /> ├── kvdb<br /> ├── queue<br /> ├── scripts<br /> │ └── index_path_rewrite.js<br /> └── stats<br />

这个脚本的内容如下:

<br /> function process(context) {<br /> var originalPath = context.Get("_ctx.request.path");<br /> var matches = originalPath.match(/\/?(.*?)\/_search/)<br /> var indexNames = [];<br /> if(matches && matches.length > 1) {<br /> indexNames = matches[1].split(",")<br /> }<br /> var resultNames = []<br /> var clusterNames = ["cluster01", "cluster02"]<br /> if(indexNames.length > 0) {<br /> for(var i=0; i<indexNames.length; i++){<br /> if(indexNames[i].length > 0) {<br /> for(var j=0; j<clusterNames.length; j++){<br /> resultNames.push(clusterNames[j]+":"+indexNames[i])<br /> }<br /> }<br /> }<br /> }<br /> <br /> if (resultNames.length>0){<br /> var newPath="/"+resultNames.join(",")+"/_search";<br /> context.Put("_ctx.request.path",newPath);<br /> }<br /> }<br />

和普通的 JavaScript 一样,定义一个特定的函数 process 来处理请求里面的上下文信息,_ctx.request.path 是网关内置上下文的一个变量,用来获取请求的路径,通过 context.Get("_ctx.request.path") 在脚本里面进行访问。

中间我们使用了 JavaScript 的正则匹配和字符处理,做了一些字符拼接,得到新的路径 newPath 变量,最后使用 context.Put("_ctx.request.path",newPath) 更新网关请求的路径信息,从而实现查询条件里面的参数替换。

有关网关内置上下文的变量列表,请访问 [Request Context](https://gateway.infinilabs.com ... ntext/)

接下来,创建一个网关配置,并使用 javascript 过滤器调用该脚本,如下:

```
entry:

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

    flow:
  • name: default_flow
    filter:
  • dump:
    context:
  • _ctx.request.path
  • javascript:
    file: index_path_rewrite.js
  • dump:
    context:
  • _ctx.request.path
  • elasticsearch:
    elasticsearch: dev
    router:
  • name: my_router
    default_flow: default_flow

    elasticsearch:
  • name: dev
    enabled: true
    schema: http
    hosts:
  • 192.168.3.188:9206
    <br /> <br /> 上面的例子中,使用了一个 `javascript` 过滤器,并且指定了加载的脚本文件为 `index_path_rewrite.js`,并使用了两个 `dump` 过滤器来输出脚本运行前后的路径信息,最后再使用一个 `elasticsearch` 过滤器来转发请求给 Elasticsearch 进行查询。<br /> <br /> 我们启动网关测试一下,如下:<br /> <br />
    ➜ gateway ✗ ./bin/gateway
    ___
    /
    \ /_\ /
    \/\/ / /\ \ \/\ /_/\
    / /
    \///\ / /\/\ \ \/ \/ //\_ /
    / /\/ \/ / //_ \ /\ / \/ \
    ___/_/ \/\/ \
    / \/ \/_/ _/_/

    [GATEWAY] A light-weight, powerful and high-performance elasticsearch gateway.
    [GATEWAY] 1.0.0_SNAPSHOT, 2022-04-18 07:11:09, 2023-12-31 10:10:10, 8062c4bc6e57a3fefcce71c0628d2d4141e46953
    [04-19 11:41:29] [INF] [app.go:174] initializing gateway.
    [04-19 11:41:29] [INF] [app.go:175] using config: /Users/medcl/go/src/infini.sh/gateway/gateway.yml.
    [04-19 11:41:29] [INF] [instance.go:72] workspace: /Users/medcl/go/src/infini.sh/gateway/data/gateway/nodes/c9bpg0ai4h931o4ngs3g
    [04-19 11:41:29] [INF] [app.go:283] gateway is up and running now.
    [04-19 11:41:30] [INF] [api.go:262] api listen at: http://0.0.0.0:2900
    [04-19 11:41:30] [INF] [entry.go:312] entry [my_es_entry] listen at: http://0.0.0.0:8000
    [04-19 11:41:30] [INF] [module.go:116] all modules are started
    [04-19 11:41:30] [INF] [actions.go:349] elasticsearch [dev] is available
    <br /> <br /> 运行下面的查询来验证查询结果,如下:<br /> <br />
    curl localhost:8000/abc,efg/_search
    <br /> <br /> 可以看到网关通过 `dump` 过滤器输出的调试信息:<br /> <br />
    ---- DUMPING CONTEXT ----
    _ctx.request.path : /abc,efg/_search
    ---- DUMPING CONTEXT ----
    _ctx.request.path : /cluster01:abc,cluster02:abc,cluster01:efg,cluster02:efg/_search
    ```

    查询条件按照我们的需求进行了改写,Nice!

    重写 DSL 查询语句


    好吧,我们刚刚只是修改了查询的索引而已,那么查询请求的 DSL 呢?行不行?

    那自然是可以的嘛,瞧下面的例子:

    <br /> function process(context) {<br /> var originalDSL = context.Get("_ctx.request.body");<br /> if (originalDSL.length >0){<br /> var jsonObj=JSON.parse(originalDSL);<br /> jsonObj.size=123;<br /> jsonObj.aggs= {<br /> "test1": {<br /> "terms": {<br /> "field": "abc",<br /> "size": 10<br /> }<br /> }<br /> }<br /> context.Put("_ctx.request.body",JSON.stringify(jsonObj));<br /> }<br /> }<br />

    先是获取查询请求,然后转换成 JSON 对象,之后任意修改查询对象就行了,保存回去,搞掂。

    测试一下:
    <br /> curl -XPOST localhost:8000/abc,efg/_search -d'{"query":{}}'<br />
    输出:
    <br /> ---- DUMPING CONTEXT ---- <br /> _ctx.request.path : /abc,efg/_search<br /> _ctx.request.body : {"query":{}}<br /> [04-19 18:14:24] [INF] [reverseproxy.go:255] elasticsearch [dev] hosts: [] => [192.168.3.188:9206]<br /> ---- DUMPING CONTEXT ---- <br /> _ctx.request.path : /abc,efg/_search<br /> _ctx.request.body : {"query":{},"size":123,"aggs":{"test1":{"terms":{"field":"abc","size":10}}}}<br />

    是不是感觉解锁了新的世界?

    结论


    通过使用 Javascript 脚本过滤器,我们可以非常灵活的进行复杂逻辑的操作来满足我们的业务需求。

python并发编程之多进程

回复

threeb 发起了问题 • 1 人关注 • 0 个回复 • 2102 次浏览 • 2021-01-20 01:19 • 来自相关话题

Elasticsearch 迁移工具 ESM 更新 0.4.4

medcl 发表了文章 • 10 个评论 • 8541 次浏览 • 2020-05-14 16:07 • 来自相关话题

timg.jpeg

 ESM 0.4.4 修复一堆 bug,支持几个新的特性:
  • 可用于生成测试数据,一般用于压力测试,基于源 ES 或者导入到本地的 JSON 数据,随机修改 ID,可以指定重复次数
  • 修复 Routing 参数在不同 ES 版本下的参数差异,支持 1.x\2.x\3.x\5.x 到 6.x\7.x 的相互导入
  • 修复终端下不能切换到后台执行的 bug,可以以 crontab 定时执行
  • 支持指定 _source 字段导出
  • 支持 _source 字段重命名
  • 支持文档 _type 重命名

 
下载地址:
 
https://github.com/medcl/esm/releases/tag/v0.4.4
 
 
生成测试数据示例:
 
1.直接以来源 es 的 my_index1 的索引数据生成到目标 es 集群的索引 my_index2,产生 10 份一样的数据
./bin/esm -s http://localhost:9201 -d http://localhost:9200 -x my_index1 -y 
my_index2
-n elastic:pass --regenerate_id --repeat_times=10

2.先导出索引文档到本地的文件 dump.json
./bin/esm -s http://localhost:9201 -x my_index1 -o dump.json
再基于这份样本,生成 10 份一样的数据到目标集群
./bin/esm -i dunp.json -d  http://localhost:9201 -y target-index1  --regenerate_id  --repeat_times=10 


更多使用示例参照项目 README

我在写一个项目。随便发一个问题出来。哈哈哈哈

回复

Lxg 发起了问题 • 1 人关注 • 0 个回复 • 2493 次浏览 • 2020-04-08 16:56 • 来自相关话题

对于开发者来说,开发者使用Spring框架主要是

回复

Mingron 发起了问题 • 1 人关注 • 0 个回复 • 2635 次浏览 • 2020-03-23 10:40 • 来自相关话题

有没有用ELK收集数据中心所有网络设备日志的解决方案?

leo_minorui 回复了问题 • 8 人关注 • 9 个回复 • 12447 次浏览 • 2020-11-03 08:19 • 来自相关话题

testtest

回复

匿名用户 发起了问题 • 0 人关注 • 0 个回复 • 2294 次浏览 • 2019-06-20 19:18 • 来自相关话题

【直播回放】ElasticTalk #12 Elasticsearch 数据建模

rockybean 发表了文章 • 0 个评论 • 2745 次浏览 • 2019-05-12 08:17 • 来自相关话题

第12期 ElasticTalk 直播已经结束,我们主要分享了在 Elasticsearch 中进行数据建模设计,内容如下:
  • 数据建模是什么?

  • 数据建模的过程有哪些?
  • Elasticsearch 数据建模要注意哪些?

如果你没来的及参加直播,来看下回放吧!
 

视频回放地址
 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 

招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:
http://www.elastictech.cn/jobs

 
想在 Elasticsearch 领域精进的同学,不妨来看看机会,作为 Elastic 官方战略级合作伙伴,我们的培训都是和 Elastic 官方同步的,机不可失!
而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!

【直播回放】ElasticTalk #10 Kibana Canvas Intro

rockybean 发表了文章 • 0 个评论 • 2731 次浏览 • 2019-04-27 17:03 • 来自相关话题

第10期 ElasticTalk 直播已经结束,我们主要分享了 Kibana Canvas,内容如下:
  • Canvas 是什么?
  • Canvas 与 Dashboard 的区别
  • Canvas 如何上手?

 
如果你没来的及参加直播,来看下回放吧!
 
视频回放
 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 

招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:
http://www.elastictech.cn/jobs
 
想在 Elasticsearch 领域精进的同学,不妨来看看机会,作为 Elastic 官方战略级合作伙伴我们的培训都是和 Elastic 官方同步的,机不可失!
而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!

【直播报名】ElasticTalk #9 Elasticsearch 分词器那些事儿

rockybean 发表了文章 • 0 个评论 • 2492 次浏览 • 2019-04-20 08:03 • 来自相关话题

直播时间:
4月20日(周六) 14:00~15:00

直播内容:
对于刚接触 ES 的新手来说,分词器是个坎儿,如何正确理解分词以及如何正确使用分词器,是很重要的一项基础功,这次我们就来聊聊分词器的那些事儿~

analysis-chain.png

直播方式: 
直播链接会在开始前发送到讨论群中。
点击下方网站链接,选择对应 Webinar 注册即可

Webinar 注册链接

ElasticTalk #5 冷热架构那些事儿 直播回放

rockybean 发表了文章 • 0 个评论 • 3247 次浏览 • 2019-03-23 21:47 • 来自相关话题

第5期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 冷热架构的相关只是,感兴趣的同学可去如下网址观看回放。
 
ElasticTalk #5 Hot-Warm Architecture
 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 
招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:
http://www.elastictech.cn/jobs

ElasticTalk #4 ILM 索引生命周期管理直播回放

rockybean 发表了文章 • 4 个评论 • 6864 次浏览 • 2019-03-17 15:19 • 来自相关话题

第4期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 6.6 新增的 Index Lifecycle Management 功能,感兴趣的同学可去如下网址观看回放。
 
ElasticTalk #4 ILM
 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 
 
第4期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 6.6 新增的 Index Lifecycle Management 功能,感兴趣的同学可去如下网址观看回放。
 
ElasticTalk #4 ILM
 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 
 

【ElasticTalk 直播来袭】Elasticsearch 6.6 之 Index Lifecycle Management Practice

rockybean 发表了文章 • 0 个评论 • 3115 次浏览 • 2019-03-14 17:41 • 来自相关话题

直播时间:

3月16日(本周六) 14:00~15:00

直播内容:

Elastic Stack 已经更新到 6.6 版本,该版本带来很多新功能,比如:
  • Index Lifecycle Management
  • Frozen Index
  • Geoshape based on Bkd Tree
  • SQL adds support for Date histograms
  • ......


在这些众多功能中,Index Lifecycle Management(索引生命周期管理,后文简称 ILM) 是最受社区欢迎的功能,我们此次研讨会将聚焦该功能,为大家讲解关于 ILM 的概念、原理及实践。

ilm_summary.png



直播方式: 待定(B站或者斗鱼)

直播链接会在开始前发送到讨论群中。
点击我报名吧!