好的想法是十分钱一打,真正无价的是能够实现这些想法的人。

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

活动liaosy 发表了文章 • 0 个评论 • 4210 次浏览 • 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容灾技术探讨和测试

Elasticsearchyangmf2040 发表了文章 • 3 个评论 • 5332 次浏览 • 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 个评论 • 2568 次浏览 • 2021-10-18 13:18 • 来自相关话题

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

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

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

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

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

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

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

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

Elasticsearchmedcl 发表了文章 • 7 个评论 • 4472 次浏览 • 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 /> 上面定义了两个集群,分别命名为v2v7`,待会会用到这些资源。

      定义一个服务入口


      ```
      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-flowv7-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 个评论 • 1933 次浏览 • 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

 
 

【杭州站】Elastic & 阿里云 Meetup 6月5号

活动liaosy 发表了文章 • 0 个评论 • 3050 次浏览 • 2021-05-22 17:38 • 来自相关话题

![banner](https://elasticsearch.cn/uploa ... c.png )

活动介绍

本次Meetup杭州站由阿里云和Elastic联合举办,邀请来自滴滴、安恒信息、阿里云的资深技术专家探讨在搜索、安全、内核优化等方向的实践与创新,以及发布由数十位优秀技术开发者共创而成的实战指南,共同分享 Elasticsearch技术大咖的一线经验与深度思考。

报名方式

链接:https://www.bagevent.com/event/7449056
扫码:
![sign up](https://elasticsearch.cn/uploa ... b4.png)

活动时间

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同城会钉群

![DingTalk](https://ucc.alicdn.com/pic/dev ... 8e.png)

活动海报

![poster](https://ucc.alicdn.com/pic/dev ... 1a.png)

2021 Elastic 中文社区深圳线下 Meetup 重磅重启,讲师招募进行中!

活动howardhuang 发表了文章 • 0 个评论 • 3077 次浏览 • 2021-05-21 15:49 • 来自相关话题

各位社区的小伙伴们大家好!过去一年多以来,疫情阻挡了我们聚会的脚步,但阻挡不了我们 ES 技术演进的脚步,ES 中文社区前期持续举办了多期线上 meetup 活动,输出了多个高质量的技术主题分享。如今在深圳,线下 meetup 活动重磅重启!6月26日我们将在深圳腾讯滨海大厦多功能厅,和大家欢聚一堂,畅谈 ES 各个领域最新的黑科技。目前讲师招募持续进行中,欢迎各路大佬扫码报名!


Elastic_中文社区深圳_Meetup.jpg



活动链接:https://www.bagevent.com/event/7440283

《腾讯Elasticsearch海量规模背后的内核优化剖析》答疑

Elasticsearchhowardhuang 发表了文章 • 37 个评论 • 8644 次浏览 • 2020-05-09 17:05 • 来自相关话题

今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈,由于时间关系,大家的问题没能及时答复,这里集中解答,大家如果还有其它疑问也可以持续提问。感谢大家的关注!
另外腾讯云上有内核增强版的ES服务,包含了我们所有的内核优化项,欢迎大家体验!
团队也在持续招聘,欢迎简历来砸:danielhuang@tencent.com; johngqjiang@tencent.com

今天下午的《腾讯Elasticsearch海量规模背后的内核优化剖析》分享 大家反映强烈,由于时间关系,大家的问题没能及时答复,这里集中解答,大家如果还有其它疑问也可以持续提问。感谢大家的关注!
另外腾讯云上有内核增强版的ES服务,包含了我们所有的内核优化项,欢迎大家体验!
团队也在持续招聘,欢迎简历来砸:danielhuang@tencent.com; johngqjiang@tencent.com

Elastic 官方培训开放注册中!

资讯动态medcl 发表了文章 • 3 个评论 • 5617 次浏览 • 2020-04-10 18:42 • 来自相关话题

Elastic 官方线上公开培训课现已开放注册。


Jietu20200410-182232.png



本次课程为官方收费课程,为针对中国及亚洲华语学员单独开设的课程,本次课程为在线虚拟课程,共计 两门课程,包含一次 Elastic 认证工程师考试机会。


课程大纲!


本次课程的内容为 Elasticsearch 核心课程,分为两个部分:

  • Elasticsearch Engineer I - Virtual
  • Elasticsearch Engineer II - Virtual


    各个课程的大纲分别为:

    Elasticsearch Engineer I - Virtual

  • Elasticsearch 基础理论
  • Elasticsearch 查询
  • Elasticsearch 聚合
  • Elasticsearch 文本分析与映射
  • Elasticsearch 节点与分片
  • Elasticsearch 监控与诊断

    更多详情请访问:https://training.elastic.co/in ... rtual


    Elasticsearch Engineer II - Virtual

  • Elasticsearch 数据建模
  • Elasticsearch 数据加工
  • Elasticsearch 从开发到生产环境
  • Elasticsearch 集群部署
  • Elasticsearch 节点和索引管理
  • Elasticsearch 高级使用技巧

    更多详情请访问:https://training.elastic.co/in ... 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。

    https://training.elastic.co/lo ... China


    人工报名!


    报名方法二:您可以联系下面的 Elastic 官方合作伙伴,由他们来帮你购买课程和处理发票事宜。

    扫下发二维码立即联系客服

    Jietu20200410-173221.png





    常见问题!


    Q:能否支持选择单项课程,如 ENG I 或者 ENG II?
    A:不支持,本次课程为捆绑优惠套餐

    Q:能否支持信用卡付款?
    A:支持,信用卡需支持双币卡

    Q:能否支持微信支付宝付款?
    A:支持,需要联系人工报名

    Q:能否提供发票用于报销?
    A:支持,需要联系人工报名,有额外税点


    本次课程名额有限,距离开课的时间也不多了,有兴趣的同学们赶快报名吧。


    免责声明


    有关此次在线培训活动的最终解释权给 Elastic 所有。

[活动推荐] ECUG For Future - 技术人的年度盛会

活动medcl 发表了文章 • 1 个评论 • 2814 次浏览 • 2019-12-21 22:37 • 来自相关话题

作为 Elastic 中文社区的福利,我这里有 10 张免费的门票,有兴趣参会的小伙伴私信我一下;

【限量门票】ECUG技术人的年度盛会,听谷歌、阿里、七牛云、CODING等大佬分享干货。http://hdxu.cn/JH9N4
【亮点满满】微服务拆分的技术实践、基于区块链的可信计算、阿里巴巴Kubernetes应用管理实践中的经验与教训、ServiceMesh在网易的落地关键点总结、构建快速应用开发的套路……2020年1月4日-5日,杭州见~

活动链接:http://hdxu.cn/JH9N4

600x300.png

 
更多活动介绍:

活动介绍1221.jpg.png

重磅《Elasticsearch 中国开发者调查报告》探索开发者的现状和未来

活动medcl 发表了文章 • 28 个评论 • 14023 次浏览 • 2019-12-06 21:10 • 来自相关话题

点击免费下载 [《 Elasticsearch 开发者调查报告》](https://elasticsearch.cn/slides/249)



2010 年,Elasticsearch 首个版本发布,经过近 10 年的发展,Elastic Stack 系列开源项目的热度持续升温,Elastic 技术社区的用户量和开发者群体逐步壮大,也在不断进化。那么,这个群体是谁?他们在怎样使用 Elastic Stack ?他们又将如何进阶成长?

为了洞察这个独特开发者群体的发展、技术应用现状,以及整个行业的发展趋势,Elastic 技术社区、阿里巴巴 Elasticsearch 技术团队和阿里云开发者社区联合首发《 Elasticsearch 中国开发者调查报告》。

ba58d7e4a18b407f91c29509d5e2c91a.png


本次报告从开发者的职业路径、Elasticsearch 的技术演进、技术社区的发展等三个维度,描绘了开发者群体的轮廓和成长路径。

开发者们的典型画像

90后是 Elasticsearch 技术兴起的中坚力量,6 成以上开源贡献者管理着 TB 或 PB 级的海量数据。

be6fcddd60eb47b9a05046f5efc18ba2.png



技术入门进阶之路

从入门到进阶,资深专家的第一手技术指南。

131efb591e774fc692ed22305f3397ed.png



Elasticsearch 的实践应用 TOP 5

信息检索和日志分析占实际应用场景的大壁江山,业务数据分析、数据库加速、运维指标监控三者平分秋色。

1ed371b5fefe48418fd3cf509044d854.png



大厂的最佳实践

18位资深专家分享在 Elasticsearch 技术领域的案例干货。

8f41b6c899514dc0a0bcf37dc472f551.png



Elastic 技术社区的建设经验

30多场线下活动,触达5000多人次,技术社区如何培育发展?

e92b5fe700e64750a01f39ceabb87f8b.png



Elasticsearch 因轻量级、稳定、可靠、快速等特性成为越来越多开发者的选择,本报告将为从业者们提供更多关于职业、行业以及技术应用的参照依据,一览开发者的现状和未来。

关于本次调查的详细数据分析、案例经验和行业前瞻,请下载 [《 Elasticsearch 中国开发者调查报告》](https://elasticsearch.cn/slides/249) 并详细阅读报告全文。

qr-code.jpg



【深圳ES Meetup】李猛:DB与ES结合,是业务系统实践值得探讨的事

活动nodexy 发表了文章 • 2 个评论 • 6099 次浏览 • 2019-11-09 17:41 • 来自相关话题

1月16日 Elastic 中文社区深圳 Meetup 上,李猛将带来关于ES 实践方面的主题分享。借此机会,我们邀请到他聊聊作为ES深度用户在探索ES过程中的心得以及对ES社区、活动、未来生态发展等方面的看法。
 
李猛 架构师/Elastic认证工程师

Elastic Stack产品深度用户,2012/2013年接触Elasticsearch,对Elastic Stack开发、架构、运维等方面有深入体验,实践过多种ES项目,最暴力的大数据分析应用,最复杂的业务系统应用等。
 

Q1、作为深度用户,当初是基于什么样的动机和考量选择使用 ES 产品并持续深入探索的?
A:易用性与功能强大,个人平常比较爱好算法研究,选择任何数据产品本质上都是选择算法,算法的本质决定了产品的强大。
架构是个宏观问题,ES的设计是标准的分布式,架构的优秀设计带来的是易用性;
算法是个微观问题,ES集成了很多优秀的算法,这样在很多业务场景下都可满足,而不用更换不同的数据产品,这样也会带来产品运维方面的便利性,保障应用的技术栈不至于过多复杂。


Q2、在探索 DB 与 ES 的互通方面,有遇到什么难题吗?最后是如何解决的呢?

A:数据一致性与实时性问题。应用架构思维变化,业务调整变化与技术方案变化。


Q3、结合您的实践经历,对 ES 目前的生态发展、应用以及未来有什么样的看法?

A:ES目前主要应用是在单索引条件下查询,附带有简单的聚合分析能力。复杂的分析能力不具备,ES未来会增强复杂的分析能力,比如有条件的支持2个索引的关联分析。


Q4、您对本次技术沙龙活动的主题分享有什么期待?

A:期望更多人参加探讨更多的业务应用场景,比如传统应用方面、大数据方面、机器学习方面;帮助大家以后项目实战有更多的案例参考。


Q5、您对 Elastic 中文社区发展有什么意见或建议呢?

A:ES目前在国内的热度几乎超过任何数据库,几乎大大小小的公司,都在使用;从开始入门到成熟运用多多少少都会遇到很多问题,  希望社区活动更加多一点,业余的交流更多一点。比如可以办一些,走进某些企业的活动。


11月16日 Elastic 中文社区深圳 Meetup 火热报名中


分享主题:《DB到ES数据实时同步之路》 李猛 

主题摘要:关系型数据库天然具备最严格的事务特性,有效的保证数据库一致性,但在高效查询方面显得很无力;Elasticsearch天然具备高效的查询算法,但在数据一致性方面却是先天缺陷;如何将DB与ES的优点结合,是任何一个企业公司业务系统实践都值得探讨的事。


b89578fa-29bc-49c3-a515-837cf1dcf7c3.png

 

邀请参加 Elasticsearch 中文分词器需求调查问卷

Elasticsearchmedcl 发表了文章 • 4 个评论 • 5066 次浏览 • 2019-06-24 20:23 • 来自相关话题

Jietu20190624-202208.gif

 亲爱的 Elasticsearch 中文用户:
 
为了能够充分了解您对 Elasticsearch 中文分词需求的基本情况,以便我们更有针对性地改进中文分词下的使用体验,并优化相关分词器,请您抽出几分钟的时间填写以下问卷。问卷题目中的选项没有对错之分,请您根据实际情况或想法进行填写。您的信息将被严格保密,请放心填写!

调研结束后,我们将随机抽出 5 名同学,每人送 Elastic 纪念 T 恤一件。谢谢您对本次调查的参与和支持~
 
问卷填写地址:http://elasticsearch.mikecrm.com/nz0FxmK
 
谢谢!
 
以下是 5 位幸运的参与者:
 
  • 韦先生 *4270
  • 汪科  *9396
  • 乔驰  *3096
  • 彭先生 *4350
  • 张丽斌 *5329

 
再次感谢大家的参与。

Shay Banon: 关于“Open” Distro、开源和公司建设的几点思考

资讯动态medcl 发表了文章 • 1 个评论 • 4430 次浏览 • 2019-03-13 10:19 • 来自相关话题

Shay 的一篇文章,分享一下,关于 Elastic、开源及社区。
https://www.elastic.co/blog/on ... mpany
Elastic 关注的焦点始终是:开发强大的产品,围绕这些产品构建社区,并帮助用户实现成功。

我在 2009 年坐下来编写了 Elasticsearch 最初的几行代码,并以开源方式提供给用户。因此我放弃了原来的工作,花了两年时间开发产品并围绕这些产品打造杰出的社区。在 2012 年,我们围绕所开发的产品创建了公司:Elastic。我们投入巨大精力维持用户社区,并且采用围绕这一社区而开发的开源产品生态系统。我们向 Apache Lucene 中新添了多得数不清的功能,将其打造成无比坚固的基石,以方便所有人在其基础上进行开发。我们增加了 Kibana(由 Rashid 开发)、Logstash(由 Jordan 开发)和 PacketBeat(由 Monica 和 Tudor 开发)等等,不胜枚举。我们开发产品,围绕这些产品打造社区,并专注于为用户提供最大价值。现在,我们有数百名 Elastic 的开发人员每天都在努力工作,致力于实现这一承诺。每天都有数十万名社区用户帮助我们取得共同成功。对于我们为打造强大社区而创建的这家公司,我感到无比自豪。

我们与用户群体之间已经建立了很大程度的信任,我对此既感到骄傲,也感到自己身负重任。我们从成立之初就是一家开源公司,并且我们在所有事务中也一直坚持全心全意为社区和广大用户服务。我们同时还专注于确保任何事情都不能让我们偏离初衷。

公司成立多年以来,我们一直面临着来自外界的担忧、不确定性和质疑。如果开发的产品大获成功,这种事情肯定会发生。这种担忧、不确定性和质疑主要来自大型(超大型)公司,因为他们担心这一发展势头会对他们不利。这是很自然的事情。“千万别使用这款产品,它就是个玩具罢了。” “这款产品只有这么几个开发人员,如果他们遭遇车祸,接下来怎么办呢?” “他们根本不知道‘企业’的需求。” “他们关于 X、Y 或 Z(插入适用于您的时下热门词汇)的说法根本不对。” 我们绝不会被这些言论左右,也不会介意这些说法。这些言论的目的就是为了分散我们和我们社区的精力,让我们偏离初衷,让我们不能继续开发用户喜欢的优秀产品,让我们不能专注于打造用户热爱的卓越社区。如果我们纠结于这些言论,那就愧对了用户对我们的期望,而我们绝对不会让用户失望。

我们的产品被不断地复刻、重新分发和重新打包,次数多到我都数不清了。这代表我们的产品十分成功,使用范围越来越广泛。这些复刻、重新分发和重新打包的公司各式各样,既有各家供应商,也有大型中国企业,而这次就是 Amazon。凡事皆有“原因”,但有时这些原因会被蒙上“大公无私”或“造福公众”的虚伪面具。这些复刻、重新分发和重新打包的产品却没有一个能维持长久。这些公司开发此类产品是为了达到自己的目的,混淆视听,并分裂社区。我们致力于开发用户喜欢的优秀产品并打造用户热爱的卓越社区,正是这一承诺和专注支持我们发展到今天,广大用户对这一点也十分认同。我们已经和您建立了极大的信任,创新速度能够满足您的期望,并且彼此之间的配合也都十分融洽,这一点毫无疑问,大家都看到了。

我们坚信开源理念,也坚信这一理念所赋予的力量。同时,我们从一开始就与大家沟通过,某些功能将是商用功能,并且说明了原因。我相信,我们公司之所以能够取得共同成功,这与我们坚守诚信密不可分。我们编写开源代码时坚持这样的方式:可以向其中添加插件,并允许用户干净地加以实施。我们的这一方式从最初一直不曾改变,多年以来,我们之所以能与广大用户建立信任,正是因为我们一直坚守承诺并努力服务于用户。

我们的商用代码一直都是其他公司的“灵感来源”,有很多公司直接复制我们的代码,甚至将这些代码用于特定的分发包或者复刻版本中,最新推出的 Amazon 产品就是一个例子,很不幸,其中包括多个关键故障,会给用户造成巨大麻烦。我们一直专注于开发用户喜欢的优秀产品,并打造用户热爱的卓越社区。我们并未因为其他公司的这些行为而偏离初衷,这一专注给我们带来了十倍的回报。

我们的品牌已经很多次遭滥用、盗用和不实呈现。很多公司都故意错误地声称他们与我们公司之间有合作,其中就包括 Amazon。然而这些行为并未让我们偏离初衷,我们一直专注于开发用户喜欢的优秀产品,并打造用户热爱的卓越社区。不能专心行事是公司发展的大忌,所以我们绝不会让这些公司的举动左右我们。最重要的是您,我们的用户,而不是围绕产品周围的熙攘噪音。

如果收购其他公司的话,我们会开放源码。当开始看到用户将 Elastic 产品用于 APM 用例时,我们所有人都感到无比兴奋。我们曾收购 OpBeat(APM 领域一家专门从事 SaaS 业务的公司),这是我们公司的一项重大商业投资,然后我们将大部分内容都开源提供给用户,并让用户能够自由使用全部这些内容。决策过程就这么简单,因为我们专注于开发用户喜欢的产品,并打造用户热爱的社区,所以作为我们的用户,您理应使用这些产品。

在其他公司封闭源码的同时,我们却在开放源码。我们的开源代码一直都是一样的,而且都基于同样的许可证,同时我们还加大力度争取在公司层面越来越开放。我们针对现有商用代码使用了另外一套更加宽容的许可证,并且开放了源码。我们希望在从事的所有事情中,都能打造与我们的开源代码相同程度的协作和透明度。与用户进行过多场讨论后,我们决定通过这种方式来直接满足用户的需求,看到大家对此种做法如此认同,我感到十分高兴。自此之后,我们在开源方面的投入一直在增加,同时也致力于提供更多免费功能和体验(已明确地进行标志和分发)。

其他公司看到我们取得成功,便与我们联系要求建立特殊的合作关系以就代码进行协作,要求获得优待以便凌驾于我们的用户之上,这时我们的答案很简单:不行。这些年来,这样的事情发生了很多次,最近又发生了一次,那就是 Amazon。有些公司遵守我们的宗旨,并成为了我们和社区的优秀合作伙伴。很遗憾,其他公司则未能做到。我们承诺:我们会同等对待每一位帮助我们开发产品的开发人员。任何人都没有优先权,如果有人要求优先权,我们会断然拒绝所有此类要求。我们的答案从始至终只有一个:发送提取请求,和所有其他人一样。质量将会说明一切。

我之所以写下上面这些内容,主要有下列几项原因。首先,我们所有人有时都需要自我反省,取得成功靠的是什么,背后的原因又是什么,从而确保我们坚持正确的发展路线。这一点适用于作为我们广大用户的您,适用于我们的社区,也适用于我们公司。第二,我想告诉其他公司,虽然有很多理由会让你们偏离初衷,但还请保持专注,并真正服务于用户,这才是唯一重要的事。最后一点,我想重申我们的承诺:继续开发用户喜爱的产品并打造用户热爱的社区。这是我们的真正目标。

在 Elastic,每一天都是第 0 天(与我们所服务的开发人员一样,我们也使用从零开始的计数方法)。从我写下第一行代码,到我们和所有用户经过的 10 年历程,再到未来,我们一直坚守初心。谨此代表 Elastic 向大家表示真诚的感谢。

Elasticsearch 北京站活动: Elastic{ON} - 2019 年 4 月 10 日

活动medcl 发表了文章 • 5 个评论 • 5762 次浏览 • 2019-03-06 10:26 • 来自相关话题

Elastic 官方将于 4 月 10 日在北京举行为期一天的 Elasticsearch 官方活动 - Elastic{ON} Tour,这是 Elastic{ON} Tour 在中国的第一站,欢迎参加。

活动内容精彩纷呈,您在会上可以深入了解产品路线图,获取专家建议,而且我们还会为您深入剖析从 Machine Learning 到规模扩展等方方面面的内容。

早鸟优惠票,仅限 75 张。

[报名及注册地址](https://www.elastic.co/elasticon/tour/2019/beijing)

[直接报名的地址](http://elastic.360event.cn/elastic_regi1a.aspx)

有小部分优惠码请微信联系:elasticchina


深入了解日志、搜索和安全等内容,精彩无限


了解 Elasticsearch、Kibana、Beats 和 Logstash 的路线图。与专家见面。从其他 Elastic Stack 用户那里学习经验。Elastic{ON} 参会门票价格实惠,您只需从工作中抽出最短的时间,便可获得所需的实用内容、专家建议和实操培训,还能拓宽 自己的人脉。

  • 深入了解 Elastic Stack 的发展路线图。

  • 在 “Ask Me Anything”(有问必答)展台进行咨询,由专家面对面为您答疑解惑。

  • 结识 Elastic 的工程师、专家和用户。

  • 通过演讲和现场演示,了解诸如 APM 和 Elasticsearch SQL 等全新功能。

  • 了解如何确定部署规模并对架构进行优化。

  • 免费参加一场按需提供的日志、指标或 APM 基础知识培训课程,课程原价 200 美元。


    日程安排


    上午 8:00 - 结束

    Ask Me Anything(有问必答) + 演示
    全天均可以访问 “Ask Me Anything”(有问必答)展台,面对面获取 Elastic 工程师和架构师提供的专业建议。亲自现场演示诸如 Canvas、APM 等崭新功能,加深自己的了解。

    上午 8:00 - 上午 9:00

    登记入场,赞助商展示,以及多元化讨论
    戴上胸牌,了解我们的赞助商有哪些活动,然后在群组讨论中分享您对多元化以及包容性的看法。

    上午 9:00 - 上午 9:30

    开场主题演讲
    Elastic Stack 的开发人员直接为您奉上关于新产品、功能、解决方案和部署选项的愿景。

    上午 9:30 - 上午 10:15

    Elastic Stack 最新动态
    了解 Elasticsearch、Kibana、Beats 和 Logstash 的产品路线图,而且会有精彩演示和重磅发布,涵盖从 rollup(汇总)到 Elastic SQL 在内的方方面面。

    上午 10:15 - 上午 10:45

    日志、指标和 APM:运维分析的三连击
    集中存储日志和指标,现在还可将 APM 数据也包括在内,助力您在运维可见度方面达到更高水平。了解 Elasticsearch 如何将所有这些类型的数据高效地存储在单一存储库内,查看如何通过 Kibana 来搜索日志、分析指标和利用 APM 功能,以便更好地监测性能并更快速地完成故障排查。

    上午 10:45 - 上午 11:00

    上午中场休息
    上午 11:00 - 上午 11:30
    使用 Elastic Stack 进行端对端安全分析
    希望在日新月异的安全领域领先竞争对手吗?了解如何按照您需要的速度和规模创建集中式安全分析平台,以便在威胁检测和跟踪活动中进行不定期分析。

    上午 11:30 - 中午 12:00

    技术讲座
    Elastic 专家将会就与您所在社区内用户相关的主题进行分享。

    中午 12:00 - 下午 1:00

    午餐
    和与会的其他人员以及 Elastic 专家共进午餐。

    下午 1:00 - 下午 1:30

    用户案例
    了解本地用户如何在业务分析、网络安全和日志等领域应用 Elastic Stack。

    下午 1:30 - 下午 2:00

    用户案例
    了解本地用户如何在业务分析、网络安全和日志等领域应用 Elastic Stack。

    下午 2:00 - 下午 2:20

    合作伙伴讲座
    了解 Elastic 合作伙伴最新推出的最优产品和服务。

    下午 2:20 - 下午 2:40

    中场休息
    拜访赞助商,亲自完成 Elastic 演示内容,前往 “Ask Me Anything”(有问必答)展台尽情提问并一扫心中疑惑。

    下午 2:40 - 下午 3:10

    技术讲座
    Elastic 专家将会就与您所在社区内用户相关的主题进行分享。

    下午 3:10 - 下午 3:40

    用户案例
    了解本地用户如何在业务分析、网络安全和日志等领域应用 Elastic Stack。

    下午 3:40 - 下午 4:10

    用户案例
    了解本地用户如何在业务分析、网络安全和日志等领域应用 Elastic Stack。

    下午 4:10 - 下午 4:15

    结束和幸运抽奖
    一天活动结束,参加幸运抽奖。

    下午 4:15 - 下午 5:15

    欢乐时光


    [报名及注册地址](https://www.elastic.co/elasticon/tour/2019/beijing)


    北京站.png



    750x280.png