Q:有两个人掉到陷阱里了,死的人叫死人,活人叫什么?

Elasticsearch生态&技术峰会


    开源最大的特征就是开放性,云生态则让开源技术更具开放性与创造性,Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际,我们邀请业界资深人士相聚云端,共话云上Elasticsearch生态与技术的未来。
 
    本次峰会邀请了阿里巴巴副总裁/阿里云智能高级研究员贾扬清、Elastic创始人&CEO Shay Banon共话开源与云生态未来发展之路,也汇聚了13位Elasticsearch技术领域资深的专家带来最前沿的技术分享。
 
    活动时间:2021年2月2日
    直播地址:https://developer.aliyun.com/t ... c9fkf 
 

es20210202.png

 
 

es_dingdinggroup.png

 
继续阅读 »

    开源最大的特征就是开放性,云生态则让开源技术更具开放性与创造性,Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际,我们邀请业界资深人士相聚云端,共话云上Elasticsearch生态与技术的未来。
 
    本次峰会邀请了阿里巴巴副总裁/阿里云智能高级研究员贾扬清、Elastic创始人&CEO Shay Banon共话开源与云生态未来发展之路,也汇聚了13位Elasticsearch技术领域资深的专家带来最前沿的技术分享。
 
    活动时间:2021年2月2日
    直播地址:https://developer.aliyun.com/t ... c9fkf 
 

es20210202.png

 
 

es_dingdinggroup.png

  收起阅读 »

如何使用 Ansible自动化部署 Elastic Stack

Ansible 是新出现的自动化运维工具,基于Python开发,集合了众多运维工具(puppet、chef、func、fabric)的优点,实现了批量系统配置、批量程序部署、批量运行命令等功能。Ansible 是基于 paramiko 开发的,并且基于模块化工作,本身没有批量部署的能力。真正具有批量部署的是 ansible 所运行的模块,ansible 只是提供一种框架。ansible 不需要在远程主机上安装 client/agents,因为它们是基于 ssh 来和远程主机通讯的。ansible 目前已经已经被红帽官方收购,是自动化运维工具中大家认可度最高的,并且上手容易,学习简单。是每位运维工程师必须掌握的技能之一。
 
如果你想了解 ansible 是如何部署 Elastic Stack 的,请阅读系列文章:
 
如何使用 Ansible自动化部署 Elastic Stack - Overview(一)

如何使用 Ansible自动化部署 Elastic Stack - Elasticsearch (二)

如何使用 Ansible自动化部署 Elastic Stack - Kibana(三)

Elastic:如何使用 Ansible自动化部署 Elastic Stack -Security(四)

如何使用 Ansible自动化部署 Elastic Stack -Metricbeat(五)
继续阅读 »
Ansible 是新出现的自动化运维工具,基于Python开发,集合了众多运维工具(puppet、chef、func、fabric)的优点,实现了批量系统配置、批量程序部署、批量运行命令等功能。Ansible 是基于 paramiko 开发的,并且基于模块化工作,本身没有批量部署的能力。真正具有批量部署的是 ansible 所运行的模块,ansible 只是提供一种框架。ansible 不需要在远程主机上安装 client/agents,因为它们是基于 ssh 来和远程主机通讯的。ansible 目前已经已经被红帽官方收购,是自动化运维工具中大家认可度最高的,并且上手容易,学习简单。是每位运维工程师必须掌握的技能之一。
 
如果你想了解 ansible 是如何部署 Elastic Stack 的,请阅读系列文章:
 
如何使用 Ansible自动化部署 Elastic Stack - Overview(一)

如何使用 Ansible自动化部署 Elastic Stack - Elasticsearch (二)

如何使用 Ansible自动化部署 Elastic Stack - Kibana(三)

Elastic:如何使用 Ansible自动化部署 Elastic Stack -Security(四)

如何使用 Ansible自动化部署 Elastic Stack -Metricbeat(五) 收起阅读 »

四倍索引速度提升, 有点东西

最近看到 INFINI Gateway 新增了一个 bulk_reshuffle filter, 于是便简单地测试一下这个功能。(Gateway 下载地址 以及 参考文档)

测试机器配置

系统 处理器 内存
Macos 2 GHz 四核Intel Core i5 16 GB

测试所需软件及版本

  1. Elasticsearch 7.10
  2. Kibana 7.10
  3. INFINI Gateway 最新版本
  4. Logstash 7.10
  5. Metricbeat 7.10

本文就省略以上软件的下载和安装步骤了。 另外本文中测试 Elasticsearch 集群含两个节点,每个节点配置内存都为 1GB ,其他参数均为默认。

测试步骤

准备测试数据文件

本文测试数据文件 nginx_mock_log ,文件中每行结构如下:

{"timestamp":1611540661651,"method":"POST","msg":"mock log"}

大概一千多万条

Logstatsh 使用 Input file 模式直接输出数据到 Elasticsearch

编辑 Logstash 配置 test.conf 如下:

input{
     file {
        path => ["/test/nginx_mock_log"]
        type => "file_monitor"
        start_position => "beginning"
    }
}

output{
    elasticsearch {
        hosts => ["localhost:9200"]
        index => "nginx_mock_log"
        http_compression => false
    }
}

在 kibana 中创建索引 nginx_mock_log ,将主分片设置为2(为了体现出 Gateway的性能优势, 主分片数应设置大于1), 配置如下:


PUT nginx_mock_log
{
"mappings" : {
      "properties" : {
        "@timestamp" : {
          "type" : "date"
        },
        "@version" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "host" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "message" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "path" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "type" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    },
    "settings" : {
        "number_of_shards" : "2"
    }
}

运行 Logstash

/usr/local/logstash/bin/logstash -f test.conf

打开 Kibana Stack Monitorning 查看 Indexing Rate 监控指标如下图:

1.png

从图中可以看到索引速率基本保持在4300/s 上下

Logstatsh 使用 Input file 模式输出数据到 Gateway

进入 Kibana 删除索引 nginx_mock_log 并重建

DELETE nginx_mock_log

PUT nginx_mock_log
{
"mappings" : {
      "properties" : {
        "@timestamp" : {
          "type" : "date"
        },
        "@version" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "host" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "message" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "path" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "type" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    },
    "settings" : {
        "number_of_shards" : "2"
    }
}

修改 Logstash 配置 test.conf 如下:

input{
     file {
        path => ["/test/nginx_mock_log"]
        type => "file_monitor"
        start_position => "beginning"
    }
}

output{
    elasticsearch {
        hosts => ["localhost:8000"]
        index => "nginx_mock_log"
        http_compression => false
    }
}

修改 Gateway 配置文件 gateway.yaml 如下:

path.data: data
path.logs: log

entry:
  - name: es_gateway #your gateway endpoint
    enabled: true
    router: default
    network:
      binding: localhost:8000
      reuse_port: true #you can start multi gateway instance, they share same port, to full utilize system's resources

flow:
  - name: bulk_es_test
    filter: #comment out any filter sections, like you don't need cache or rate-limiter
      - name: bulk_reshuffle
        parameters:
          elasticsearch: dev
          level: node
          mode: async
      - name: elasticsearch
        parameters:
          elasticsearch: dev
          refresh:
            enabled: true
            interval: 30s
  - name: request_logging
    filter:
      - name: request_logging
        parameters:
          queue_name: request_logging
router:
  - name: default
    default_flow: bulk_es_test
    tracing_flow: request_logging

elasticsearch:
- name: dev
  enabled: true
  endpoint: http://localhost:9200 # if your elasticsearch is using https, your gateway should be listen on as https as well
  basic_auth: #used to discovery full cluster nodes, or check elasticsearch's health and versions
    username: elastic
    password: yV6syH3KLt4DxqMlCyag
  discovery: # auto discovery elasticsearch cluster nodes
    enabled: true
    refresh:
      enabled: true

modules:
- name: elastic
  enabled: true
  elasticsearch: dev
  store:
    enabled: true
  orm:
    enabled: true
    init_template: true
    template_name: ".infini-default1"
    index_prefix: "gateway_"

- name: pipeline
  enabled: true
  runners:
    - name: nodes_index
      enabled: true
      max_go_routine: 2
      threshold_in_ms: 0
      timeout_in_ms: 5000
      pipeline_id: bulk_request_ingest
    - name: request_logging_test_name
      enabled: true
      max_go_routine: 2
      threshold_in_ms: 0
      timeout_in_ms: 5000
      pipeline_id: request_logging_index

pipelines:
- name: bulk_request_ingest
  start:
    joint: bulk_indexing
    enabled: true
    parameters:
      elasticsearch: "dev"
      timeout: "5s"
      worker_size: 10
      bulk_size_in_mb: 1 #in MB
- name: request_logging_index
  start:
    joint: json_indexing
    enabled: true
    parameters:
      index_name: "gateway_requests"
      elasticsearch: "dev"
      input_queue: "request_logging"
      timeout: "5s"
      worker_size: 10
      bulk_size_in_mb: 1 #in MB

queue:
  min_msg_size: 1
  max_msg_size: 5000000000
  max_bytes_per_file: 53687091200
  sync_every_records: 100000 # sync by records count
  sync_timeout_in_ms: 10000 # sync by time in million seconds
  write_chan_buffer: 1000
  read_chan_buffer: 1000

以上各配置节点含义,请参考 Gateway 文档

启动 Gateway ./gateway

删除 Logstash data 目录

rm -rf /usr/local/logstash/data

启动 Logstash

/usr/local/logstash/bin/logstash -f test.conf

打开 Kibana Stack Monitorning 查看 Indexing Rate 监控指标如下图:

2.png

从上图后半部分可以看到索引速率可以保持在 25000/s 上下(一会儿的功夫,一千多万条数据导入ES完事了)

前面看到 Gateway 配置开启了 request_logging,因此可以在 Kibana Dashboard 里面的 INFINI Gateway Dashboard 查看请求信息,如下图:

3.png

4.png

注意,上面图中的请求速率是 _bulk 请求的速率,不是索引速率

总结

从测试结果来看,相同环境下,用 Logstash elasticsearch output 输出数据到 Gateway 的方式比 Logstash elasticsearch output 直接到 ES 的方式速率快了4倍,不得不说这速率是真的杠杠的。至于能不能通过参数调优再提升速率呢?大家有兴趣的自己下载测试吧!最后感谢 medcl 大神出品。

继续阅读 »

最近看到 INFINI Gateway 新增了一个 bulk_reshuffle filter, 于是便简单地测试一下这个功能。(Gateway 下载地址 以及 参考文档)

测试机器配置

系统 处理器 内存
Macos 2 GHz 四核Intel Core i5 16 GB

测试所需软件及版本

  1. Elasticsearch 7.10
  2. Kibana 7.10
  3. INFINI Gateway 最新版本
  4. Logstash 7.10
  5. Metricbeat 7.10

本文就省略以上软件的下载和安装步骤了。 另外本文中测试 Elasticsearch 集群含两个节点,每个节点配置内存都为 1GB ,其他参数均为默认。

测试步骤

准备测试数据文件

本文测试数据文件 nginx_mock_log ,文件中每行结构如下:

{"timestamp":1611540661651,"method":"POST","msg":"mock log"}

大概一千多万条

Logstatsh 使用 Input file 模式直接输出数据到 Elasticsearch

编辑 Logstash 配置 test.conf 如下:

input{
     file {
        path => ["/test/nginx_mock_log"]
        type => "file_monitor"
        start_position => "beginning"
    }
}

output{
    elasticsearch {
        hosts => ["localhost:9200"]
        index => "nginx_mock_log"
        http_compression => false
    }
}

在 kibana 中创建索引 nginx_mock_log ,将主分片设置为2(为了体现出 Gateway的性能优势, 主分片数应设置大于1), 配置如下:


PUT nginx_mock_log
{
"mappings" : {
      "properties" : {
        "@timestamp" : {
          "type" : "date"
        },
        "@version" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "host" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "message" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "path" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "type" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    },
    "settings" : {
        "number_of_shards" : "2"
    }
}

运行 Logstash

/usr/local/logstash/bin/logstash -f test.conf

打开 Kibana Stack Monitorning 查看 Indexing Rate 监控指标如下图:

1.png

从图中可以看到索引速率基本保持在4300/s 上下

Logstatsh 使用 Input file 模式输出数据到 Gateway

进入 Kibana 删除索引 nginx_mock_log 并重建

DELETE nginx_mock_log

PUT nginx_mock_log
{
"mappings" : {
      "properties" : {
        "@timestamp" : {
          "type" : "date"
        },
        "@version" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "host" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "message" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "path" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "type" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    },
    "settings" : {
        "number_of_shards" : "2"
    }
}

修改 Logstash 配置 test.conf 如下:

input{
     file {
        path => ["/test/nginx_mock_log"]
        type => "file_monitor"
        start_position => "beginning"
    }
}

output{
    elasticsearch {
        hosts => ["localhost:8000"]
        index => "nginx_mock_log"
        http_compression => false
    }
}

修改 Gateway 配置文件 gateway.yaml 如下:

path.data: data
path.logs: log

entry:
  - name: es_gateway #your gateway endpoint
    enabled: true
    router: default
    network:
      binding: localhost:8000
      reuse_port: true #you can start multi gateway instance, they share same port, to full utilize system's resources

flow:
  - name: bulk_es_test
    filter: #comment out any filter sections, like you don't need cache or rate-limiter
      - name: bulk_reshuffle
        parameters:
          elasticsearch: dev
          level: node
          mode: async
      - name: elasticsearch
        parameters:
          elasticsearch: dev
          refresh:
            enabled: true
            interval: 30s
  - name: request_logging
    filter:
      - name: request_logging
        parameters:
          queue_name: request_logging
router:
  - name: default
    default_flow: bulk_es_test
    tracing_flow: request_logging

elasticsearch:
- name: dev
  enabled: true
  endpoint: http://localhost:9200 # if your elasticsearch is using https, your gateway should be listen on as https as well
  basic_auth: #used to discovery full cluster nodes, or check elasticsearch's health and versions
    username: elastic
    password: yV6syH3KLt4DxqMlCyag
  discovery: # auto discovery elasticsearch cluster nodes
    enabled: true
    refresh:
      enabled: true

modules:
- name: elastic
  enabled: true
  elasticsearch: dev
  store:
    enabled: true
  orm:
    enabled: true
    init_template: true
    template_name: ".infini-default1"
    index_prefix: "gateway_"

- name: pipeline
  enabled: true
  runners:
    - name: nodes_index
      enabled: true
      max_go_routine: 2
      threshold_in_ms: 0
      timeout_in_ms: 5000
      pipeline_id: bulk_request_ingest
    - name: request_logging_test_name
      enabled: true
      max_go_routine: 2
      threshold_in_ms: 0
      timeout_in_ms: 5000
      pipeline_id: request_logging_index

pipelines:
- name: bulk_request_ingest
  start:
    joint: bulk_indexing
    enabled: true
    parameters:
      elasticsearch: "dev"
      timeout: "5s"
      worker_size: 10
      bulk_size_in_mb: 1 #in MB
- name: request_logging_index
  start:
    joint: json_indexing
    enabled: true
    parameters:
      index_name: "gateway_requests"
      elasticsearch: "dev"
      input_queue: "request_logging"
      timeout: "5s"
      worker_size: 10
      bulk_size_in_mb: 1 #in MB

queue:
  min_msg_size: 1
  max_msg_size: 5000000000
  max_bytes_per_file: 53687091200
  sync_every_records: 100000 # sync by records count
  sync_timeout_in_ms: 10000 # sync by time in million seconds
  write_chan_buffer: 1000
  read_chan_buffer: 1000

以上各配置节点含义,请参考 Gateway 文档

启动 Gateway ./gateway

删除 Logstash data 目录

rm -rf /usr/local/logstash/data

启动 Logstash

/usr/local/logstash/bin/logstash -f test.conf

打开 Kibana Stack Monitorning 查看 Indexing Rate 监控指标如下图:

2.png

从上图后半部分可以看到索引速率可以保持在 25000/s 上下(一会儿的功夫,一千多万条数据导入ES完事了)

前面看到 Gateway 配置开启了 request_logging,因此可以在 Kibana Dashboard 里面的 INFINI Gateway Dashboard 查看请求信息,如下图:

3.png

4.png

注意,上面图中的请求速率是 _bulk 请求的速率,不是索引速率

总结

从测试结果来看,相同环境下,用 Logstash elasticsearch output 输出数据到 Gateway 的方式比 Logstash elasticsearch output 直接到 ES 的方式速率快了4倍,不得不说这速率是真的杠杠的。至于能不能通过参数调优再提升速率呢?大家有兴趣的自己下载测试吧!最后感谢 medcl 大神出品。

收起阅读 »

Elastic:开放公开,火力全开(第二部分)

Elasticsearch 和 Kibana 的许可协议即将变更

我们即将把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 的源代码变更为双重许可模式(即 SSPL 1.0 和 Elastic 许可),以便用户选择适合自己的许可。通过这一许可协议的变更,这样既能确保我们的社区和客户继续以免费开放的方式使用、修改和重新分发代码,又能开展基于代码的协作,而且还可以限制云服务提供商在不向社区提供任何回馈的情况下,将 Elasticsearch 和 Kibana 作为一项对外提供的服务,从而保护我们在开发免费及开放产品方面的持续投资。此次变更将适用于 Elasticsearch 和 Kibana 的所有维护分支,并从我们即将发布的 7.11 版本开始生效。我们的发行版将继续使用与三年前相同的 Elastic 许可。

此次源代码许可协议变更对绝大部分免费使用默认分发版的社区用户没有影响,也不会影响我们的云服务客户或自管型软件客户。

近年来,市场已发生了很大的变化,社区开始逐渐的认识到,开源公司只有更好地保护了自己的软件,才能够实现持续创新和进行必要的投资。随着很多公司不断的转型到 SaaS 产品,有些云服务提供商已经采用了开源产品,并在不向社区提供任何回馈的情况下,将其作为一项对外提供的服务。在大约三年前,我们开放了商业代码,并将他们全面的开放,所有这些都是在 Elastic 许可下进行的,从而让我们现在可以采用 SSPL 和 Elastic 许可的双重授权许可策略,这对我们来说是水到渠成的一步。这与近年来许多其他开源公司(包括开发 SSPL 的 MongoDB)的做法类似。SSPL 虽然允许自由随意地使用及修改产品源代码,但有一个基本要求,也就是,在 SSPL 协议下,如果您将产品作为服务对外提供,则必须同时公开发布所做出的任何修改,以及您自己构建的管理层源代码。

我们的开源之旅

我个人的开源之旅可以追溯到很久以前。2005 年,我开源了我的第一个项目 — Compass,在 Apache Lucene 的基础上提供了一个 Java 框架,那时我在为我妻子开发一个关于菜谱的应用。在接下来的五年间里,我投入了无数个周末和夜晚来完善这个项目,从编写代码到帮助用户解决故障、功能等方面的各种问题。

我并没有细想自己做这件事的目的是什么,尤其是我还有一份已经沦为“副业”的工作,但我醉心于此,因为这是能产生如此积极影响的机会 — 尝试通过开源的力量,打造出一款优质产品,而且更重要的是,围绕这款产品构建起一个良好的社区。

2009 年,我决定重新再来一次,于是开始编写一个全新的项目,它就是 Elasticsearch。我花了很多个夜晚和周末来构建这个项目,并在 2010 年开放了源代码。我甚至辞掉了工作,决定全力以赴。通过编写代码、在 GitHub 上写博客、发邮件及通过 IRC 聊天工具,为用户提供帮助。

而当我们在 2012 年成立 Elastic 公司时,也将这种精神带到了我们的公司。我们在免费开放的产品上投入了大量资金,并支持用户社区的快速发展。我们从单纯的 Elasticsearch 扩展到 Kibana、Logstash、Beats,现在,Elastic Stack 中内置了一系列的解决方案:Elastic 企业搜索、可观测性和安全。

我们有成熟的产品,围绕这些产品培育了充满活力的社区,并专注于为用户提供最大价值。今天,我们有数百名工程师,他们每天的工作内容就是努力让我们的产品变得更好。而且我们还有成千上万的社区成员参与其中,帮助我们取得共同成功。

我为我们建立的公司感到骄傲,更为我们赢得用户的信任而深感责任重大。我们从成立之初就是一家开放、透明的公司,并且我们在各项决策中也一直坚持全心全意为社区和广大用户服务。
 
详细阅读,请参阅文章 https://elasticstack.blog.csdn ... 38956
继续阅读 »
Elasticsearch 和 Kibana 的许可协议即将变更

我们即将把根据 Apache 2.0 许可授权的 Elasticsearch 和 Kibana 的源代码变更为双重许可模式(即 SSPL 1.0 和 Elastic 许可),以便用户选择适合自己的许可。通过这一许可协议的变更,这样既能确保我们的社区和客户继续以免费开放的方式使用、修改和重新分发代码,又能开展基于代码的协作,而且还可以限制云服务提供商在不向社区提供任何回馈的情况下,将 Elasticsearch 和 Kibana 作为一项对外提供的服务,从而保护我们在开发免费及开放产品方面的持续投资。此次变更将适用于 Elasticsearch 和 Kibana 的所有维护分支,并从我们即将发布的 7.11 版本开始生效。我们的发行版将继续使用与三年前相同的 Elastic 许可。

此次源代码许可协议变更对绝大部分免费使用默认分发版的社区用户没有影响,也不会影响我们的云服务客户或自管型软件客户。

近年来,市场已发生了很大的变化,社区开始逐渐的认识到,开源公司只有更好地保护了自己的软件,才能够实现持续创新和进行必要的投资。随着很多公司不断的转型到 SaaS 产品,有些云服务提供商已经采用了开源产品,并在不向社区提供任何回馈的情况下,将其作为一项对外提供的服务。在大约三年前,我们开放了商业代码,并将他们全面的开放,所有这些都是在 Elastic 许可下进行的,从而让我们现在可以采用 SSPL 和 Elastic 许可的双重授权许可策略,这对我们来说是水到渠成的一步。这与近年来许多其他开源公司(包括开发 SSPL 的 MongoDB)的做法类似。SSPL 虽然允许自由随意地使用及修改产品源代码,但有一个基本要求,也就是,在 SSPL 协议下,如果您将产品作为服务对外提供,则必须同时公开发布所做出的任何修改,以及您自己构建的管理层源代码。

我们的开源之旅

我个人的开源之旅可以追溯到很久以前。2005 年,我开源了我的第一个项目 — Compass,在 Apache Lucene 的基础上提供了一个 Java 框架,那时我在为我妻子开发一个关于菜谱的应用。在接下来的五年间里,我投入了无数个周末和夜晚来完善这个项目,从编写代码到帮助用户解决故障、功能等方面的各种问题。

我并没有细想自己做这件事的目的是什么,尤其是我还有一份已经沦为“副业”的工作,但我醉心于此,因为这是能产生如此积极影响的机会 — 尝试通过开源的力量,打造出一款优质产品,而且更重要的是,围绕这款产品构建起一个良好的社区。

2009 年,我决定重新再来一次,于是开始编写一个全新的项目,它就是 Elasticsearch。我花了很多个夜晚和周末来构建这个项目,并在 2010 年开放了源代码。我甚至辞掉了工作,决定全力以赴。通过编写代码、在 GitHub 上写博客、发邮件及通过 IRC 聊天工具,为用户提供帮助。

而当我们在 2012 年成立 Elastic 公司时,也将这种精神带到了我们的公司。我们在免费开放的产品上投入了大量资金,并支持用户社区的快速发展。我们从单纯的 Elasticsearch 扩展到 Kibana、Logstash、Beats,现在,Elastic Stack 中内置了一系列的解决方案:Elastic 企业搜索、可观测性和安全。

我们有成熟的产品,围绕这些产品培育了充满活力的社区,并专注于为用户提供最大价值。今天,我们有数百名工程师,他们每天的工作内容就是努力让我们的产品变得更好。而且我们还有成千上万的社区成员参与其中,帮助我们取得共同成功。

我为我们建立的公司感到骄傲,更为我们赢得用户的信任而深感责任重大。我们从成立之初就是一家开放、透明的公司,并且我们在各项决策中也一直坚持全心全意为社区和广大用户服务。
 
详细阅读,请参阅文章 https://elasticstack.blog.csdn ... 38956 收起阅读 »

社区日报 第1176期 (2020-01-21)

1.Elasticsearch评分
https://blog.mimacom.com/elast ... nges/
2.使用Elasticsearch-rails对索引进行非规范化(梯子)
https://medium.com/wolox/why-a ... 03c7c
3.Elastic stack 中的 kibana Map
https://spoon-elastic.com/all- ... -7-6/

编辑:寂寞的烟
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.Elasticsearch评分
https://blog.mimacom.com/elast ... nges/
2.使用Elasticsearch-rails对索引进行非规范化(梯子)
https://medium.com/wolox/why-a ... 03c7c
3.Elastic stack 中的 kibana Map
https://spoon-elastic.com/all- ... -7-6/

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

社区日报 第1180期 (2021-01-25)

1. Netflix媒体数据库实现(自备梯子)
https://netflixtechblog.com/im ... 0b42a 
2. 基于搜索历史的个性化搜索服务
https://www.elastic.co/blog/pe ... story
3. 可能遇见的问题及详解
https://mp.weixin.qq.com/s/EcCmujV9HhQRvorppXLepQ

编辑:wt
归档:https://ela.st/cn-daily-all 
订阅:https://ela.st/cn-daily-sub 
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. Netflix媒体数据库实现(自备梯子)
https://netflixtechblog.com/im ... 0b42a 
2. 基于搜索历史的个性化搜索服务
https://www.elastic.co/blog/pe ... story
3. 可能遇见的问题及详解
https://mp.weixin.qq.com/s/EcCmujV9HhQRvorppXLepQ

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

社区日报 第1179期 (2021-01-24)

1.ELK架构图。 
https://terrastruct.com/blog/e ... gram/ 
2.如何在Docker Swarm上轻松设置ELK。 
https://blog.creekorful.com/20 ... warm/ 
3.Google已关闭对Chromium同步功能的访问权限。 
https://bodhi.fedoraproject.or ... 282e5

编辑:至尊宝
归档:https://ela.st/cn-daily-all 
订阅:https://ela.st/cn-daily-sub 
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.ELK架构图。 
https://terrastruct.com/blog/e ... gram/ 
2.如何在Docker Swarm上轻松设置ELK。 
https://blog.creekorful.com/20 ... warm/ 
3.Google已关闭对Chromium同步功能的访问权限。 
https://bodhi.fedoraproject.or ... 282e5

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

社区日报 第1177期 (2020-01-22)

1、Elasticsearch 百人大作战,只能你来
https://developer.aliyun.com/t ... 31778
 
2、好不好奇?各种Elasticsearch专利都被抢注申请
http://www.soopat.com/Home/Res ... Q%3DY
 
3、深入解读:Elasticsearch Filter VS Query
https://towardsdatascience.com ... bd4c0
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1、Elasticsearch 百人大作战,只能你来
https://developer.aliyun.com/t ... 31778
 
2、好不好奇?各种Elasticsearch专利都被抢注申请
http://www.soopat.com/Home/Res ... Q%3DY
 
3、深入解读:Elasticsearch Filter VS Query
https://towardsdatascience.com ... bd4c0
 
编辑:铭毅天下
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup 收起阅读 »

Terms lookup query - 关联两个不同索引的搜索

我们知道 Elasticsearch 的搜索和传统的 RDMS 搜索是不同的。它不可以使用 joins 来把两个不同索引关联起来,并进行搜索。我们针对多个索引的搜索只限于:GET index1,index2,other_index*/_search这样的操作。上面的操作不能使得我们的搜索结果进行任何的关联,因为搜索的结果都是分开的。在实际的使用中,比如我们想从一个索引中搜索到一个关键字,而这个关键字可以作为另外一个搜索中的一个参数来使用。也就是说第二个搜索中关键字是动态的,而不是固定的。比如在如下的搜索中,我希望 blue 这个关键字是从另外一个索引中被搜索出来的而不是硬编码写进去的。

GET my-index-000001/_search
{
"query": {
"term": {
"color": {
"value": "blue"
}
}
}
}

我们想通过一个搜索的命令来实现,那么我们该如何完成这样的操作呢?

在今天的文章中,我将使用 Terms lookup query 来展示如何实现这样的功能。
 
详细阅读,请参阅文章 https://elasticstack.blog.csdn ... 57984
继续阅读 »
我们知道 Elasticsearch 的搜索和传统的 RDMS 搜索是不同的。它不可以使用 joins 来把两个不同索引关联起来,并进行搜索。我们针对多个索引的搜索只限于:GET index1,index2,other_index*/_search这样的操作。上面的操作不能使得我们的搜索结果进行任何的关联,因为搜索的结果都是分开的。在实际的使用中,比如我们想从一个索引中搜索到一个关键字,而这个关键字可以作为另外一个搜索中的一个参数来使用。也就是说第二个搜索中关键字是动态的,而不是固定的。比如在如下的搜索中,我希望 blue 这个关键字是从另外一个索引中被搜索出来的而不是硬编码写进去的。

GET my-index-000001/_search
{
"query": {
"term": {
"color": {
"value": "blue"
}
}
}
}

我们想通过一个搜索的命令来实现,那么我们该如何完成这样的操作呢?

在今天的文章中,我将使用 Terms lookup query 来展示如何实现这样的功能。
 
详细阅读,请参阅文章 https://elasticstack.blog.csdn ... 57984 收起阅读 »

ES 7.4.2的Sort Script查询性能比较差

我们的es从5.3.2升级到7.4.1,遇到一个脚本的性能问题。同样的一段Sort Script脚本, 在ES 7.4.1的执行要比ES 5.3.2要慢至少一倍。一个主要的特点就是departure_city_ids可能会很多,通过doc获取一个deparature_city_ids的数据, 数据的大小最大的时候达到两千多个左右。Type为keyword类型。

  • 具体的sort script脚本实例已经贴在下面了。

脚本实例:

"sort": [
    {
      "_script": {
        "script": {
          "inline": "return doc['departure_city_ids'].size()",
          "lang": "painless"
        },
        "type": "number",
        "order": "desc"
      }
    }
  ]

https://discuss.elastic.co/t/the-performance-of-script-based-sorting-in-es-7-4-2-verison-is-very-poor/261241

继续阅读 »

我们的es从5.3.2升级到7.4.1,遇到一个脚本的性能问题。同样的一段Sort Script脚本, 在ES 7.4.1的执行要比ES 5.3.2要慢至少一倍。一个主要的特点就是departure_city_ids可能会很多,通过doc获取一个deparature_city_ids的数据, 数据的大小最大的时候达到两千多个左右。Type为keyword类型。

  • 具体的sort script脚本实例已经贴在下面了。

脚本实例:

"sort": [
    {
      "_script": {
        "script": {
          "inline": "return doc['departure_city_ids'].size()",
          "lang": "painless"
        },
        "type": "number",
        "order": "desc"
      }
    }
  ]

https://discuss.elastic.co/t/the-performance-of-script-based-sorting-in-es-7-4-2-verison-is-very-poor/261241

收起阅读 »

Elastic Security 入门

Elastic 安全是在 Elastic Stack 上构建对所有人的统一保护。Elastic Security 使分析人员能够预防,检测和响应威胁。 这个免费开放的解决方案可提供SIEM,端点安全,威胁搜寻,云监视等功能。Elastic Security 由 SIEM 及 Endpoint 两个部分组成。通过这两个部件的组合,它可以帮安全专家解决 SIEM, 端点安全, 威胁搜寻、云监测及其它的安全使用案例等功能。Elastic Security 的真正作用就是保护我们的数据免受不被允许的用户所访问。详细阅读,请参阅 “Elastic Security 入门” https://elasticstack.blog.csdn ... 47180
继续阅读 »
Elastic 安全是在 Elastic Stack 上构建对所有人的统一保护。Elastic Security 使分析人员能够预防,检测和响应威胁。 这个免费开放的解决方案可提供SIEM,端点安全,威胁搜寻,云监视等功能。Elastic Security 由 SIEM 及 Endpoint 两个部分组成。通过这两个部件的组合,它可以帮安全专家解决 SIEM, 端点安全, 威胁搜寻、云监测及其它的安全使用案例等功能。Elastic Security 的真正作用就是保护我们的数据免受不被允许的用户所访问。详细阅读,请参阅 “Elastic Security 入门” https://elasticstack.blog.csdn ... 47180 收起阅读 »

社区日报 第1173期 (2020-01-18)

1. Elasticsearch 更改开源协议
https://www.infoq.cn/article/XcwStbdflSYMpAt3QzIR

2.基于深度语义匹配,上下文相关的问答系统
https://bit.ly/35Q5INT

3.Elastic 产品生命周期结束期,请及时升级你的Elastic Stack噢
https://www.elastic.co/cn/support/eol

编辑:cyberdak
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1. Elasticsearch 更改开源协议
https://www.infoq.cn/article/XcwStbdflSYMpAt3QzIR

2.基于深度语义匹配,上下文相关的问答系统
https://bit.ly/35Q5INT

3.Elastic 产品生命周期结束期,请及时升级你的Elastic Stack噢
https://www.elastic.co/cn/support/eol

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

社区日报 第1172期 (2021-01-17)

1.在Skroutz进行搜索:从Kafka到Elasticsearch。
https://engineering.skroutz.gr ... arch/
2.通过好莱坞电影学习Elasticsearch。
https://realptsdengineer.com/l ... -way/
3.Twitter将允许员工永远在家工作
https://www.buzzfeednews.com/a ... rever

编辑:至尊宝
归档:https://ela.st/cn-daily-all
订阅:https://ela.st/cn-daily-sub
沙龙:https://ela.st/cn-meetup
继续阅读 »
1.在Skroutz进行搜索:从Kafka到Elasticsearch。
https://engineering.skroutz.gr ... arch/
2.通过好莱坞电影学习Elasticsearch。
https://realptsdengineer.com/l ... -way/
3.Twitter将允许员工永远在家工作
https://www.buzzfeednews.com/a ... rever

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