如同磁铁吸引四周的铁粉,热情也能吸引周围的人,改变周围的情况。
es

es

Elasticsearch 国产化

Easysearchyangmf2040 发表了文章 • 0 个评论 • 312 次浏览 • 3 天前 • 来自相关话题

背景

Elasticsearch 这些年来在搜索领域一直是领头羊。国内也有非常多的企业在使用 Elasticsearch 来做查询搜索、数据分析、安全分析等等。甚至一些很重要的行业、系统都在使用 Elasticsearch。在使用 Elasticsearch 的道路上狂飙的时候,我们也观察到了一些问题:

  1. Elasticsearch 不再是开源软件了。
  2. Elastic 公司退出了中国直销市场,不提供本土化支持了。
  3. 国家对信创、自主可控的战略化布局。
  4. 国际形势从合作共赢到自闭对垒。
  5. Elasticsearch 软件本身安全问题频发。
  6. Elasticsearch 软件在性能、稳定性和扩展性方面存在很大的提升空间。

基于以上这些问题,推出一个 Elasticsearch 国产化解决方案就很有必要了。我们的解决方案是推出一款名为 Easysearch 的软件,作为 Elasticsearch 国产化替代 。
出发点是在兼容原 Elasticsearch 软件的基础之上,完善更多的企业级功能,同时提高产品的性能、稳定性和扩展性。
下面我将从几个方面简单介绍下 Easysearch 软件。

兼容性

支持原生 Elasticsearch 的 DSL 查询语法,原业务代码无需调整。 支持 SQL ,方便熟悉 SQL 的开发人员上手分析数据。 兼容 Elasticsearch 的 SDK。 兼容现有索引存储格式。 支持冷热架构和索引生命周期,真正做到无缝衔接。

功能增强

提供企业级的安全管理,可对接 LDAP、AD 认证。 重构分布式架构,保持稳定的同时,能支持更大规模的数据。 在不降低性能的同时,实现更高压缩比的数据压缩,直接节省磁盘 40% 以上。 支持 KNN、异步搜索、数据脱敏、可搜索快照、审计等企业级功能。

容灾

支持基于 CDC 的集群复制技术,实现同版本间的容灾。
支持基于请求双写的复制技术,实现跨版本容灾。

信创

全面适配国产 CPU、操作系统,并获得厂家认证。

迁移方案

支持原索引存储格式,可通过快照备份直接恢复到 Easysearch 集群。
提供迁移工具,直接可视化操作迁移数据。

简单的介绍就到这里了,更多信息请访问:https://www.infinilabs.com/products/easysearch

最后

如有需要请联系我,让我们一起位祖国的信创事业添砖加瓦。

如何防止 Elasticsearch 服务 OOM?

Easysearchyangmf2040 发表了文章 • 0 个评论 • 1805 次浏览 • 2024-02-26 10:12 • 来自相关话题

Elasticsearch(简称:ES) 和传统关系型数据库有很多区别, 比如传统数据中普遍都有一个叫“最大连接数”的设置。目的是使数据库系统工作在可控的负载下,避免出现负载过高,资源耗尽,谁也无法登录的局面。

那 ES 在这方面有类似参数吗?答案是没有,这也是为何 ES 会被流量打爆的原因之一。

针对大并发访问 ES 服务,造成 ES 节点 OOM,服务中断的情况,极限科技旗下的 INFINI Gateway 产品(以下简称 “极限网关”)可从两个方面入手,保障 ES 服务的可用性。

  1. 限制最大并发访问连接数。
  2. 限制非重要索引的请求速度,保障重要业务索引的访问速度。

下面我们来详细聊聊。

架构图

所有访问 ES 的请求都发给网关,可部署多个网关。

限制最大连接数

在网关配置文件中,默认有最大并发连接数限制,默认最大 10000。

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: $[[env.GW_BINDING]]
      # See `gateway.disable_reuse_port_by_default` for more information.
      reuse_port: true

使用压测程序测试,看看到达10000个连接后,能否限制新的连接。 超过的连接请求,被丢弃。更多信息参考官方文档

限制索引写入速度

我们先看看不做限制的时候,测试环境的写入速度,在 9w - 15w docs/s 之间波动。虽然峰值很高,但不稳定。 接下来,我们通过网关把写入速度控制在最大 1w docs/s 。 对网关的配置文件 gateway.yml ,做以下修改。

env: # env 下添加
    THROTTLE_BULK_INDEXING_MAX_BYTES: 40485760 #40MB/s
    THROTTLE_BULK_INDEXING_MAX_REQUESTS: 10000 #10k docs/s
    THROTTLE_BULK_INDEXING_ACTION: retry #retry,drop
    THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES: 10 #1000
    THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS: 100 #10

router: # route 部分修改 flow
  - name: my_router
    default_flow: default_flow
    tracing_flow: logging_flow
    rules:
      - method:
          - "*"
        pattern:
          - "/_bulk"
          - "/{any_index}/_bulk"
        flow:
          - write_flow

flow: #flow 部分增加下面两段    
  - name: write_flow
    filter:
      - flow:
          flows:
            - bulking_indexing_limit
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

再次压测,test-index 索引写入速度被限制在了 1w docs/s 。

限制多个索引写入速度

上面的配置是针对 test-index 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引写入达到 2w docs/s,test-index 索引最多不超过 1w docs/s ,可配置如下。

  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "abc":
              max_requests: 20000
              action: drop
              message: "abc doc写入超阈值" #触发限流告警message自定义
              log_warn_message: true
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

限速效果如下

限制读请求速度

我们先看看不做限制的时候,测试环境的读取速度,7w qps 。 接下来我们通过网关把读取速度控制在最大 1w qps 。 继续对网关的配置文件 gateway.yml 做以下修改。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"                                      rules:      
            - pattern: "/(?P<index_name>abc)/_search"                          
              max_qps: 10000
              group: index_name                                    
      - elasticsearch: 
          elasticsearch: prod                            
          max_connection_per_node: 1000

再次进行测试,读取速度被限制在了 1w qps 。

限制多个索引读取速度

上面的配置是针对 abc 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引读取达到 1w qps,test-index 索引最多不超过 2w qps ,可配置如下。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"
          rules:
            - pattern: "/(?P<index_name>abc)/_search"
              max_qps: 10000
              group: index_name
            - pattern: "/(?P<index_name>test-index)/_search"
              max_qps: 20000
              group: index_name
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000

多个网关限速

限速是每个网关自身的控制,如果有多个网关,那么后端 ES 集群收到的请求数等于多个网关限速的总和。 本次介绍就到这里了。相信大家在使用 ES 的过程中也遇到过各种各样的问题。欢迎大家来我们这个平台分享自己的问题、解决方案等。如有任何问题,请随时联系我,期待与您交流!

用 Easysearch 帮助大型车企降本增效

Easysearchyangmf2040 发表了文章 • 0 个评论 • 4153 次浏览 • 2024-02-02 15:15 • 来自相关话题

最近某头部汽车集团需要针对当前 ES 集群进行优化,背景如下: ES 用于支撑包括核心营销系统、管理支持系统、财务类、IT 基础设施类、研发、自动驾驶等多个重要应用,合计超 50 余套集群,累计数据超 1.5PB 。 本文针对其中一个 ES 集群进行分享,该集群原本使用的是 ES 7.3.2 免费版,数据已经 130TB 了,14 个节点。写入数据时经常掉节点,写入性能也不稳定,当天的数据写不完。迫切需要新的解决方案。 分析业务场景后总结需求要点:主要是写,很少查。审计需求,数据需要长期保存。 这个需求比较普遍,处理起来也很简单:

  • 使用 Easysearch 软件,只需少量节点存储近两天的数据。
  • 索引设置开启 ZSTD 压缩功能,节省磁盘空间。
  • 每天索引数据写完后,第二天执行快照备份存放到 S3 存储。
  • 备份成功后,删除索引释放磁盘空间。
  • 需要搜索数据时,直接从快照搜索。

将近期的数据,存放到本地磁盘,保障写入速度。写入完毕的索引,在执行快照备份后,可删除索引,释放本地磁盘空间。

Easysearch 配置要点

path.repo: ["/S3-path"]
node.roles: ["data","search"]
node.search.cache.size: 500mb
  • path.repo : 指定 S3 存储路径,上传快照用。
  • node.roles : 只有 search 角色的节点,才能去搜索快照中的数据。
  • node.search.cache.size : 执行快照搜索时的,缓存大小。

更多信息请参考官方文档

旧数据迁移

通过 Console 将原 ES 集群的数据,迁移到新 Easysearch 集群。迁移时,复制 mapping 和 setting,并在 setting 中添加如下设置。

"codec": "ZSTD",
"source_reuse": true,

原索引数据量大,可拆分成多个小任务。 迁移完,索引存储空间一般节省 50% 左右。 原索引 279GB ,迁移完后 138GB。

搜索快照数据

挂载快照后,搜索快照里的索引和搜索本地的索引,语法完全一样。 如何判断一个索引是在快照还是本地磁盘呢?可以查看索引设置里的 settings.index.store.type 如果是 remote_snapshot ,说明是快照中的数据。如果是空值,则是集群本地的数据。
这次迁移,节省了 6 台主机资源。更重要的是,用上对象存储后,主机磁盘空间压力骤减。
这次介绍就到这里了,有问题联系我。

关于 Easysearch

Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://infinilabs.com/docs/latest/easysearch

【搜索客社区日报】第1769期 (2024-01-05)

社区日报laoyang360 发表了文章 • 0 个评论 • 2712 次浏览 • 2024-01-05 15:41 • 来自相关话题

1、一个Elasticsearch 监控 vue 客户端(昨天还在更新) https://github.com/cars10/elasticvue 2、Elasticsearch 系统设计小抄 https://betterprogramming.pub/ ... 60463 https://towardsdatascience.com ... ebfff 3、CKibana——为了能够在原生kibana上直接使用ElasticSearch语法查询ClickHouse的服务 https://github.com/TongchengOpenSource/ckibana 4、从 Elasticsearch 7.17 迁移到 Elasticsearch 8.x:陷阱和经验教训 https://engineering.zalando.co ... .html 编辑:铭毅天下  更多资讯:http://news.searchkit.cn

开启安全功能 ES 集群就安全了吗?

Easysearchyangmf2040 发表了文章 • 0 个评论 • 2887 次浏览 • 2023-12-27 10:38 • 来自相关话题

背景

经常跟 ES 打交道的朋友都知道,现在主流的 ES 集群安全方案是:RBAC + TLS for Internal + HTTPS 。

作为终端用户一般只需要关心用户名和密码就行了。作为管理和运维 ES 的人员来说,可能希望 ES 能提供密码策略来强制密码强度和密码使用周期。遗憾的是 ES 对密码强度和密码使用周期没有任何强制要求。如果不注意,可能我们天天都在使用“弱密码”或从不修改的密码(直到无法登录)。而且 ES 对连续的认证失败,不会做任何处理,这让 ES 很容易遭受暴力破解的入侵。

那还有没有别的办法,进一步提高安全呢? 其实,网关可以来帮忙。

虽然网关无法强制提高密码复杂度,但可以提高 ES 集群被暴力破解的难度。

大家都知道,暴力破解--本质就是不停的“猜”你的密码。以现在的 CPU 算力,一秒钟“猜”个几千上万次不过是洒洒水,而且 CPU 监控都不带波动的,很难发现异常。从这里入手,一方面,网关可以延长认证失败的过程--延迟返回结果,让破解不再暴力。另一方面,网关可以记录认证失败的情况,做到实时监控,有条件的告警。一旦出现苗头,可以使用网关阻断该 IP 或用户发来的任何请求。

场景模拟

首先,用网关代理 ES 集群,并在 default_flow 中增加一段 response_status_filter 过滤器配置,对返回码是 401 的请求,跳转到 rate_limit_flow 进行降速,延迟 5 秒返回。

  - name: default_flow
    filter:
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
      - response_status_filter:
          exclude:
            - 401
          action: redirect_flow
          flow: rate_limit_flow
  - name: rate_limit_flow
    filter:
      - sleep:
          sleep_in_million_seconds: 5000

其次,对于失败的认证,我们可以通过 Console 来做个看板实时分析,展示。

折线图、饼图图、柱状图等,多种展示方式,大家可充分发挥。

最后,可在 Console 的告警中心,配置对应的告警规则,实时监控该类事件,方便及时跟进处置。

效果测试

先带上正确的用户名密码测试,看看返回速度。

0.011 秒返回。再使用错误的密码测试。

整整 5 秒多后,才回返结果。如果要暴力破解,每 5 秒钟甚至更久才尝试一个密码,这还叫暴力吗?

看板示例

此处仅仅是抛砖引玉,欢迎大家发挥想象。

告警示例

建立告警规则,用户 1 分钟内超过 3 次登录失败,就产生告警。

可在告警中心查看详情,也可将告警推送至微信、钉钉、飞书、邮件等。

查看告警详情,是 es 用户触发了告警。

最后,剩下的工作就是对该账号的处置了。如果有需要可以考虑阻止该用户或 IP 的请求,对应的过滤器文档在这里,老规矩加到 default_flow 里就行了。

如果小伙伴有其他办法提升 ES 集群安全,欢迎和我们一起讨论、交流。我们的宗旨是:让搜索更简单!

给 ES 插上向量检索的翅膀 | DataFunSummit 2023 峰会演讲内容速达

Elasticsearchliaosy 发表了文章 • 0 个评论 • 1293 次浏览 • 2023-07-12 18:37 • 来自相关话题

近日,由 DataFun 主办的 DataFunSummit 2023 数据基础架构峰会 圆满落下帷幕,本次峰会邀请了腾讯、百度、字节、极限科技、Zilliz 等众多企业技术专家为大家带来分布式存储以及向量数据库的架构原理、性能优化与实践解析分享。

向量数据库架构与实践论坛 中,极限科技搜索引擎研发工程师张磊受邀出席做了《给 ES 插上向量检索的翅膀》的主题演讲。据介绍,本次演讲主要介绍了 Elasticsearch(ES)与向量技术的融合,展示其在不同行业中的应用场景和优势,同时也对 ES 与向量的技术细节进行详细讨论,并通过具体案例演示如何利用向量提升搜索能力。

讲师介绍

张磊,极限科技 Easysearch 引擎研发工程师,2013 年开始接触 Elasticsearch,10 余年搜索相关经验,之前主要做一些围绕 Elasticsearch 在日志检索和公安大数据相关业务的开发,对 Elasticsearch 和 Lucene 源码比较熟悉,目前专注于公司内部搜索产品的开发。

《给 ES 插上向量检索的翅膀》PPT 内容

更多 PPT 内容参见 https://elasticsearch.cn/slides/322

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

集群分片数非常多的情况下,是否会造成master节点频繁gc

Elasticsearchxiaohei 回复了问题 • 3 人关注 • 2 个回复 • 1822 次浏览 • 2023-07-07 16:23 • 来自相关话题

ES的正排索引(field data)转为doc values存储后如何做到disk上实时搜索的

Elasticsearchhapjin 回复了问题 • 4 人关注 • 2 个回复 • 5990 次浏览 • 2023-06-20 11:47 • 来自相关话题

es进程异常退出,es日志和系统日志都无相关信息,求助各位大大~

Elasticsearchlemontree666 回复了问题 • 3 人关注 • 2 个回复 • 7133 次浏览 • 2023-06-02 16:20 • 来自相关话题

关于es7中的节点失效探测(fault_detection)参数

回复

Elasticsearchshwtz 发起了问题 • 1 人关注 • 0 个回复 • 5937 次浏览 • 2023-01-17 14:56 • 来自相关话题

elasticsearch 自定义id引发的负载均衡问题

Elasticsearchamc 回复了问题 • 2 人关注 • 1 个回复 • 2042 次浏览 • 2022-12-12 15:04 • 来自相关话题

es的bulk操做,相同的id,可以保证写入数据的顺序性吗?

Elasticsearch陈水鱼 回复了问题 • 3 人关注 • 3 个回复 • 2045 次浏览 • 2022-11-11 11:10 • 来自相关话题

INFINI 产品更新啦 20220923

资讯动态liaosy 发表了文章 • 0 个评论 • 1770 次浏览 • 2022-09-23 22:47 • 来自相关话题

INFINI Labs 产品更新发布

今天 INFINI Labs 为大家又带来了一波产品更新,请查阅。

INFINI Gateway v1.8.0

极限网关本次迭代更新如下:

  • 修复上下文条件 consumer_has_lag参数和 配置、文档不一致的 Bug。
  • 修改备集群故障,主集群不能正常写数据的 Bug。
  • 修复 Bulk 请求处理异常造成数据复制不一致的问题。
  • 修复请求日志里面关于 Bulk 统计数据丢失的问题。
  • 修复大并发情况下,请求体为空的异常。

INFINI Console v0.6.0

口碑爆棚的 Elasticsearch 多集群管控平台 INFINI Console 更新如下:

  • 新增主机概览。

1-640.png

  • 新增主机监控。

2-640.png

  • 节点概览新增日志查看功能(需安装 Agent)。

3-640.png

  • Insight 配置框新增 Search 配置。
  • 优化 Discover 时间范围 Auto Fit,设为15分钟。
  • 优化 Discover 保存搜索,会保存当前的字段过滤和 Insight 图表配置。
  • 优化本地列表搜索查找,支持通配符过滤。
  • 优化告警规则必填字段标记显示。
  • 修复了 Discover 字段过滤白屏问题。
  • 修复了 Discover 表格添加字段后排序失效问题。(感谢@卢宝贤反馈)
  • 修复了 Elasticsearch 8.x 删除文档报错不兼容的问题。(感谢@卢宝贤反馈)
  • 修复了创建新索引不成功时,异常处理的问题。
  • 修复了低版本浏览器js不兼容导致集群注册不成功的问题。
  • 修复了开发工具中使用加载命令失败报错的问题。

INFINI Agent v0.2.0

数据采集工具探针(INFINI Agent)更新如下:

  • 新增按节点读日志文件列表的API
  • 新增读具体日志文件内容的API
  • 新增 Elasticsearch 节点掉线后的基础信息保存
  • 新增主机在线状态的采集
  • 新增基于 Centos 的 Docker 镜像
  • 新增主机配置信息采集: 操作系统信息、磁盘大小、内存大小、CPU配置等
  • 新增主机指标的采集: CPU使用率、磁盘使用率、磁盘IO、内存使用率、swap 使用率、网络IO等
  • 新增 Elasticsearch 进程信息采集
  • 修复发现 Elasticsearch 进程时频繁提示端口访问错误的Bug
  • 修复 Elasticsearch 节点地址为 0.0.0.0 时无法获取节点信息的Bug
  • 修复 CPU 指标数据显示异常的Bug
  • 修复 stats API 在 Windows 平台的兼容性

INFINI Framework 2000923

INFINI Framework 也带来了很多改进:

  • 重构了磁盘队列压缩相关配置,支持段文件的压缩。
  • 当集群不可用的情况下,跳过集群节点元数据的获取。
  • 完善节点可用性检测,避免频繁的不可用状态切换。
  • 修复 Elasticsearch 主机地址为空的异常。
  • 完善本地磁盘队列文件的清理,避免删除正在使用的文件。

期待反馈

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

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

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

也欢迎大家微信扫码添加小助手,加入用户群讨论,或者扫码加入我们的知识星球一起学习交流。 联系我们

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

elasticsearch es如何统计用户文档数量范围内容聚合?

ElasticsearchCharele 回复了问题 • 5 人关注 • 3 个回复 • 2194 次浏览 • 2022-06-01 13:42 • 来自相关话题

logstash推送数据到es执行两次脚本

Logstashmedcl 回复了问题 • 2 人关注 • 1 个回复 • 2056 次浏览 • 2022-04-02 13:28 • 来自相关话题

条新动态, 点击查看
medcl

medcl 回答了问题 • 2014-11-11 17:27 • 6 个回复 不感兴趣

ElasticSearch-Hadoop的目標是什麼呢??

赞同来自:

简单来说,Hadoop还是Hadoop,Elasticsearch还是Elasticsearch,而Elasticsearch-Hadoop在中间用来连接这两个系统,大量的原始数据可以存放在Hadoop里面,通过Elasticsearch—Hadoop可以调用... 显示全部 »
简单来说,Hadoop还是Hadoop,Elasticsearch还是Elasticsearch,而Elasticsearch-Hadoop在中间用来连接这两个系统,大量的原始数据可以存放在Hadoop里面,通过Elasticsearch—Hadoop可以调用Hadoop的Map-Reduce任务来创建elasticsearch的索引,数据进入elasticsearch之后,就可以使用elasticsearch的搜索特性来进行更加高级的分析,比如基于Kibana来作快速分析。

技术上来说elasticsearch-Hadoop实现了Hadoop的读写接口,翻译es的查询到Hadoop的map-reduce,job,这样可以通过es来直接查询Hadoop里面的数据。

HDFS之前可以作为elasticsearch的gateway,1.0之后也能当做snapshot的存储,用来做索引备份,方便恢复数据。
Rubricate

Rubricate 回答了问题 • 2014-11-24 17:22 • 9 个回复 不感兴趣

如何设置分配给elasticsearch的内存大小?

赞同来自:

在 ES_HOME/bin/elasticsearch 里面
在 ES_HOME/bin/elasticsearch 里面
keyword其实可以达到不分词的效果
keyword其实可以达到不分词的效果
Elk的处理能力没有公式可以得到,受很多因素影响,我给出的答案是基于我们的实践经验。我们经历过20G -> 100G -> 200G -> 500G -> 1T这样的过程,集群的data node从最初的4个扩容到现在的20个。目前每天... 显示全部 »
Elk的处理能力没有公式可以得到,受很多因素影响,我给出的答案是基于我们的实践经验。我们经历过20G -> 100G -> 200G -> 500G -> 1T这样的过程,集群的data node从最初的4个扩容到现在的20个。目前每天处理50亿条裸日志,产生的主索引1.5TB,业务繁忙期间,每秒处理8-10万条日志,历史数据保留10天。

如果每天200gb日志估计用redis问题不大,但以后量会大很多,推荐用Kafka,主要原因是redis是单线程,一个实例的处理能力受限于一个cpu内核,而多个实例做lb会很麻烦。kafka是集群方式运作,扩容简单得多。另外Kafka的队列是构造在磁盘上的,相比Reidis可以容忍更长的消费端故障时间。我们目前是2台服务器做kafka集群,上面所说的量撑住毫无压力。
medcl

medcl 回答了问题 • 2015-01-27 18:25 • 4 个回复 不感兴趣

关于elasticsearch的集群问题

赞同来自:

是的,会重新拷贝数据,你真的需要跨机房么?
是的,会重新拷贝数据,你真的需要跨机房么?
首先,你写入的时候要确定内存的使用量如何,不过一般写入内存的使用不会消耗太大。就算是bulk,也只是用一点内存缓冲而已。。。我不知道你的es的磁盘情况如何,es的写入数据是顺序存储,但是在es里面存在大量的索引,这些索引在维护和写入的时候,锁的情况还有随机IO... 显示全部 »
首先,你写入的时候要确定内存的使用量如何,不过一般写入内存的使用不会消耗太大。就算是bulk,也只是用一点内存缓冲而已。。。我不知道你的es的磁盘情况如何,es的写入数据是顺序存储,但是在es里面存在大量的索引,这些索引在维护和写入的时候,锁的情况还有随机IO的消耗都很明显,所以我觉得你的瓶颈更多可能是在磁盘。可以分享下磁盘的情况再讨论~
tonylxc

tonylxc 回答了问题 • 2015-03-15 17:20 • 5 个回复 不感兴趣

es被攻击了,怎么处理?

赞同来自:

1. 永远不要把Elasticsearch端口暴露给外网. Elasticsearch应当运行在private network中.
2. 禁用dynamic scripting.
3. Elasticsearch更新频繁, 务必跟上更新脚步至1.4.4
4. ... 显示全部 »
1. 永远不要把Elasticsearch端口暴露给外网. Elasticsearch应当运行在private network中.
2. 禁用dynamic scripting.
3. Elasticsearch更新频繁, 务必跟上更新脚步至1.4.4
4. Elasticsearch并不依赖于Shield插件. Shield插件只是一个extra sugar, 并且是商业收费.
如果你用的是search api的话 http://elasticsearch-py.readthedocs.io/en/master/api.html#elasticsearch.Elasticsearch.search
我猜你的size参数用的默认值10... 显示全部 »
如果你用的是search api的话 http://elasticsearch-py.readthedocs.io/en/master/api.html#elasticsearch.Elasticsearch.search
我猜你的size参数用的默认值10
size – Number of hits to return (default: 10)
kennywu76

kennywu76 回答了问题 • 2017-02-16 11:03 • 4 个回复 不感兴趣

es自定义分词插件问题

赞同来自:

你用的第三方库com.hankcs.hanlp.dictionary.CoreDictionary  CoreDictionary.java里有一个辞典加载失败时做一个System.exit(-1)的系统调用。  ES使用了 Java Security Man... 显示全部 »
你用的第三方库com.hankcs.hanlp.dictionary.CoreDictionary  CoreDictionary.java里有一个辞典加载失败时做一个System.exit(-1)的系统调用。  ES使用了 Java Security Manager来限制第三方库做不安全的系统调用,所以这个System.exit(-1)就被禁止了。 
 
解决方法一个是更改这个第三方库,在异常的时候不要掉用system.exit,或者为这个库加一个白名单(有安全隐患,不建议这么做)。 
 
参考:
https://www.elastic.co/guide/en/elasticsearch/reference/5.2/modules-scripting-security.html#java-security-manager
http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html
 
 
kennywu76

kennywu76 回答了问题 • 2017-09-11 13:44 • 3 个回复 不感兴趣

现在es能不能用G1来进行内存回收?

赞同来自:

之前版本,官方是有文档明确说明不要用G1。 因为根据Lucene的stress test,发现某些版本JAVA G1存在的Bug,会造成Lucene的段文件损坏。
 
在5.0以后,官方文档没有明确说是否可以使用G1,但是ES启动过程中有一个针对G1 GC的J... 显示全部 »
之前版本,官方是有文档明确说明不要用G1。 因为根据Lucene的stress test,发现某些版本JAVA G1存在的Bug,会造成Lucene的段文件损坏。
 
在5.0以后,官方文档没有明确说是否可以使用G1,但是ES启动过程中有一个针对G1 GC的JVM版本校验
https://www.elastic.co/guide/en/elasticsearch/reference/5.5/_g1gc_check.html
其隐含的意思是说,使用 JDK 8u40以上版本,启用G1应该是安全的。
 
不过,根据经验,在使用ES过程中遇到长时间GC问题时,通常需要调整的不是JVM,而是Query本身。特别是,频繁OLD GC过后, 释放不了Heap空间的情况下,用CMS还是G1不会有什么分别。
我觉得吧,你这个本质是一个语句调优的问题,结果你把大家带跑偏了,es 对于几百万数据的查询肯定是在 ms 级,所以你应该把你的查询语句还有数据模型讲一下,优化你的查询才是正道,不要想这些没用的。
我觉得吧,你这个本质是一个语句调优的问题,结果你把大家带跑偏了,es 对于几百万数据的查询肯定是在 ms 级,所以你应该把你的查询语句还有数据模型讲一下,优化你的查询才是正道,不要想这些没用的。
luohuanfeng

luohuanfeng 回答了问题 • 2018-03-15 11:40 • 6 个回复 不感兴趣

query_string查询多值字段问题请教

赞同来自:

能使用term查询么
能使用term查询么
kennywu76

kennywu76 回答了问题 • 2018-03-23 12:26 • 3 个回复 不感兴趣

使用elasticsearch 做排重存储使用的可行性

赞同来自:

功能上可行,主要还是需要测试一下性能。 因为op=create这种方式写入文档,遇到重复的id会抛异常,从而阻止写入。 所以当有大量重复文档的时候,catch大量的异常产生的性能损耗就不能够忽视。 
 
20w每秒的写入量不算小,自己剋模拟不同量级的id重复情... 显示全部 »
功能上可行,主要还是需要测试一下性能。 因为op=create这种方式写入文档,遇到重复的id会抛异常,从而阻止写入。 所以当有大量重复文档的时候,catch大量的异常产生的性能损耗就不能够忽视。 
 
20w每秒的写入量不算小,自己剋模拟不同量级的id重复情况,测试一下写入吞吐量,据此规划硬件资源。
kennywu76

kennywu76 回答了问题 • 2018-09-18 17:57 • 3 个回复 不感兴趣

es 集群索引 分片分配策略

赞同来自:

可以给不同数据中心的结点,在ES配置文件里配置不同的rack_id这个属性,然后集群设置里将rack_id设置为shard allocation awareness即可。 这样ES会保证,主分片和副本必须分布在rack_id不同的结点上。
 
参考: http... 显示全部 »
可以给不同数据中心的结点,在ES配置文件里配置不同的rack_id这个属性,然后集群设置里将rack_id设置为shard allocation awareness即可。 这样ES会保证,主分片和副本必须分布在rack_id不同的结点上。
 
参考: https://www.elastic.co/guide/en/elasticsearch/reference/6.4/allocation-awareness.html
 
 
 
kennywu76

kennywu76 回答了问题 • 2018-11-01 10:10 • 4 个回复 不感兴趣

Elasticsearch中文分词器问题

赞同来自:

提供一个思路供参考:
 
公司名称可以索引为multi-filed,即一个为keyword类型,一个为text类型。 查询的时候,使用bool Query,对两个字段分别查询后用should连接, 这样完全匹配的公司名称相关度比部分匹配的高,排在前面优先返回。... 显示全部 »
提供一个思路供参考:
 
公司名称可以索引为multi-filed,即一个为keyword类型,一个为text类型。 查询的时候,使用bool Query,对两个字段分别查询后用should连接, 这样完全匹配的公司名称相关度比部分匹配的高,排在前面优先返回。
 
例如:
[code]{
"query": {
"bool": {
"should":
}
}
}
对于常用词的滤除,一个可以考虑在分词器中,将常用词定义为stop word, 从而在分词阶段就滤除掉。 另外也可以通过boosting Query,降低这类词的打分权重。 参考:  not-quite-not.html

集群分片数非常多的情况下,是否会造成master节点频繁gc

回复

Elasticsearchxiaohei 回复了问题 • 3 人关注 • 2 个回复 • 1822 次浏览 • 2023-07-07 16:23 • 来自相关话题

ES的正排索引(field data)转为doc values存储后如何做到disk上实时搜索的

回复

Elasticsearchhapjin 回复了问题 • 4 人关注 • 2 个回复 • 5990 次浏览 • 2023-06-20 11:47 • 来自相关话题

es进程异常退出,es日志和系统日志都无相关信息,求助各位大大~

回复

Elasticsearchlemontree666 回复了问题 • 3 人关注 • 2 个回复 • 7133 次浏览 • 2023-06-02 16:20 • 来自相关话题

关于es7中的节点失效探测(fault_detection)参数

回复

Elasticsearchshwtz 发起了问题 • 1 人关注 • 0 个回复 • 5937 次浏览 • 2023-01-17 14:56 • 来自相关话题

elasticsearch 自定义id引发的负载均衡问题

回复

Elasticsearchamc 回复了问题 • 2 人关注 • 1 个回复 • 2042 次浏览 • 2022-12-12 15:04 • 来自相关话题

es的bulk操做,相同的id,可以保证写入数据的顺序性吗?

回复

Elasticsearch陈水鱼 回复了问题 • 3 人关注 • 3 个回复 • 2045 次浏览 • 2022-11-11 11:10 • 来自相关话题

elasticsearch es如何统计用户文档数量范围内容聚合?

回复

ElasticsearchCharele 回复了问题 • 5 人关注 • 3 个回复 • 2194 次浏览 • 2022-06-01 13:42 • 来自相关话题

logstash推送数据到es执行两次脚本

回复

Logstashmedcl 回复了问题 • 2 人关注 • 1 个回复 • 2056 次浏览 • 2022-04-02 13:28 • 来自相关话题

elasticsearch 分索引后如何快速更新指定数据?

回复

Elasticsearchliujiacheng 回复了问题 • 2 人关注 • 1 个回复 • 1070 次浏览 • 2022-03-24 09:41 • 来自相关话题

segments的version_map_memory指标具体表示什么

回复

ElasticsearchCharele 回复了问题 • 3 人关注 • 2 个回复 • 1513 次浏览 • 2022-02-21 16:43 • 来自相关话题

match_phrase_prefix返回结果如何使越靠前的单词占有的权重越高,排序更靠前

回复

Elasticsearchxiaowuge 回复了问题 • 4 人关注 • 3 个回复 • 2061 次浏览 • 2022-01-25 09:01 • 来自相关话题

es的基础安全从哪个版本开始免费

回复

Elasticsearchenvy666 回复了问题 • 2 人关注 • 1 个回复 • 1215 次浏览 • 2021-11-04 08:49 • 来自相关话题

es7.6副本越少检索速度越快

回复

Elasticsearchtongchuan1992 回复了问题 • 3 人关注 • 3 个回复 • 1324 次浏览 • 2021-09-28 16:48 • 来自相关话题

ElasticSearch 同一个query查询响应时间差异大?

回复

Elasticsearchzmc 回复了问题 • 4 人关注 • 4 个回复 • 2687 次浏览 • 2021-07-21 19:33 • 来自相关话题

search after取出全量数据会比scoll更快吗

回复

Elasticsearchguoyanbiao520 回复了问题 • 7 人关注 • 6 个回复 • 3232 次浏览 • 2021-06-11 18:05 • 来自相关话题

Elasticsearch 国产化

Easysearchyangmf2040 发表了文章 • 0 个评论 • 312 次浏览 • 3 天前 • 来自相关话题

背景

Elasticsearch 这些年来在搜索领域一直是领头羊。国内也有非常多的企业在使用 Elasticsearch 来做查询搜索、数据分析、安全分析等等。甚至一些很重要的行业、系统都在使用 Elasticsearch。在使用 Elasticsearch 的道路上狂飙的时候,我们也观察到了一些问题:

  1. Elasticsearch 不再是开源软件了。
  2. Elastic 公司退出了中国直销市场,不提供本土化支持了。
  3. 国家对信创、自主可控的战略化布局。
  4. 国际形势从合作共赢到自闭对垒。
  5. Elasticsearch 软件本身安全问题频发。
  6. Elasticsearch 软件在性能、稳定性和扩展性方面存在很大的提升空间。

基于以上这些问题,推出一个 Elasticsearch 国产化解决方案就很有必要了。我们的解决方案是推出一款名为 Easysearch 的软件,作为 Elasticsearch 国产化替代 。
出发点是在兼容原 Elasticsearch 软件的基础之上,完善更多的企业级功能,同时提高产品的性能、稳定性和扩展性。
下面我将从几个方面简单介绍下 Easysearch 软件。

兼容性

支持原生 Elasticsearch 的 DSL 查询语法,原业务代码无需调整。 支持 SQL ,方便熟悉 SQL 的开发人员上手分析数据。 兼容 Elasticsearch 的 SDK。 兼容现有索引存储格式。 支持冷热架构和索引生命周期,真正做到无缝衔接。

功能增强

提供企业级的安全管理,可对接 LDAP、AD 认证。 重构分布式架构,保持稳定的同时,能支持更大规模的数据。 在不降低性能的同时,实现更高压缩比的数据压缩,直接节省磁盘 40% 以上。 支持 KNN、异步搜索、数据脱敏、可搜索快照、审计等企业级功能。

容灾

支持基于 CDC 的集群复制技术,实现同版本间的容灾。
支持基于请求双写的复制技术,实现跨版本容灾。

信创

全面适配国产 CPU、操作系统,并获得厂家认证。

迁移方案

支持原索引存储格式,可通过快照备份直接恢复到 Easysearch 集群。
提供迁移工具,直接可视化操作迁移数据。

简单的介绍就到这里了,更多信息请访问:https://www.infinilabs.com/products/easysearch

最后

如有需要请联系我,让我们一起位祖国的信创事业添砖加瓦。

如何防止 Elasticsearch 服务 OOM?

Easysearchyangmf2040 发表了文章 • 0 个评论 • 1805 次浏览 • 2024-02-26 10:12 • 来自相关话题

Elasticsearch(简称:ES) 和传统关系型数据库有很多区别, 比如传统数据中普遍都有一个叫“最大连接数”的设置。目的是使数据库系统工作在可控的负载下,避免出现负载过高,资源耗尽,谁也无法登录的局面。

那 ES 在这方面有类似参数吗?答案是没有,这也是为何 ES 会被流量打爆的原因之一。

针对大并发访问 ES 服务,造成 ES 节点 OOM,服务中断的情况,极限科技旗下的 INFINI Gateway 产品(以下简称 “极限网关”)可从两个方面入手,保障 ES 服务的可用性。

  1. 限制最大并发访问连接数。
  2. 限制非重要索引的请求速度,保障重要业务索引的访问速度。

下面我们来详细聊聊。

架构图

所有访问 ES 的请求都发给网关,可部署多个网关。

限制最大连接数

在网关配置文件中,默认有最大并发连接数限制,默认最大 10000。

entry:
  - name: my_es_entry
    enabled: true
    router: my_router
    max_concurrency: 10000
    network:
      binding: $[[env.GW_BINDING]]
      # See `gateway.disable_reuse_port_by_default` for more information.
      reuse_port: true

使用压测程序测试,看看到达10000个连接后,能否限制新的连接。 超过的连接请求,被丢弃。更多信息参考官方文档

限制索引写入速度

我们先看看不做限制的时候,测试环境的写入速度,在 9w - 15w docs/s 之间波动。虽然峰值很高,但不稳定。 接下来,我们通过网关把写入速度控制在最大 1w docs/s 。 对网关的配置文件 gateway.yml ,做以下修改。

env: # env 下添加
    THROTTLE_BULK_INDEXING_MAX_BYTES: 40485760 #40MB/s
    THROTTLE_BULK_INDEXING_MAX_REQUESTS: 10000 #10k docs/s
    THROTTLE_BULK_INDEXING_ACTION: retry #retry,drop
    THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES: 10 #1000
    THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS: 100 #10

router: # route 部分修改 flow
  - name: my_router
    default_flow: default_flow
    tracing_flow: logging_flow
    rules:
      - method:
          - "*"
        pattern:
          - "/_bulk"
          - "/{any_index}/_bulk"
        flow:
          - write_flow

flow: #flow 部分增加下面两段    
  - name: write_flow
    filter:
      - flow:
          flows:
            - bulking_indexing_limit
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

再次压测,test-index 索引写入速度被限制在了 1w docs/s 。

限制多个索引写入速度

上面的配置是针对 test-index 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引写入达到 2w docs/s,test-index 索引最多不超过 1w docs/s ,可配置如下。

  - name: bulking_indexing_limit
    filter:
      - bulk_request_throttle:
          indices:
            "abc":
              max_requests: 20000
              action: drop
              message: "abc doc写入超阈值" #触发限流告警message自定义
              log_warn_message: true
            "test-index":
              max_bytes: $[[env.THROTTLE_BULK_INDEXING_MAX_BYTES]]
              max_requests: $[[env.THROTTLE_BULK_INDEXING_MAX_REQUESTS]]
              action: $[[env.THROTTLE_BULK_INDEXING_ACTION]]
              retry_delay_in_ms: $[[env.THROTTLE_BULK_INDEXING_RETRY_DELAY_IN_MS]]
              max_retry_times: $[[env.THROTTLE_BULK_INDEXING_MAX_RETRY_TIMES]]
              message: "bulk writing too fast" #触发限流告警message自定义
              log_warn_message: true

限速效果如下

限制读请求速度

我们先看看不做限制的时候,测试环境的读取速度,7w qps 。 接下来我们通过网关把读取速度控制在最大 1w qps 。 继续对网关的配置文件 gateway.yml 做以下修改。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"                                      rules:      
            - pattern: "/(?P<index_name>abc)/_search"                          
              max_qps: 10000
              group: index_name                                    
      - elasticsearch: 
          elasticsearch: prod                            
          max_connection_per_node: 1000

再次进行测试,读取速度被限制在了 1w qps 。

限制多个索引读取速度

上面的配置是针对 abc 索引的写入速度控制。如果想添加其他的索引,新增一段配置即可。 比如,我允许 abc 索引读取达到 1w qps,test-index 索引最多不超过 2w qps ,可配置如下。

  - name: default_flow
    filter:
      - request_path_limiter:
          message: "Hey, You just reached our request limit!"
          rules:
            - pattern: "/(?P<index_name>abc)/_search"
              max_qps: 10000
              group: index_name
            - pattern: "/(?P<index_name>test-index)/_search"
              max_qps: 20000
              group: index_name
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000

多个网关限速

限速是每个网关自身的控制,如果有多个网关,那么后端 ES 集群收到的请求数等于多个网关限速的总和。 本次介绍就到这里了。相信大家在使用 ES 的过程中也遇到过各种各样的问题。欢迎大家来我们这个平台分享自己的问题、解决方案等。如有任何问题,请随时联系我,期待与您交流!

用 Easysearch 帮助大型车企降本增效

Easysearchyangmf2040 发表了文章 • 0 个评论 • 4153 次浏览 • 2024-02-02 15:15 • 来自相关话题

最近某头部汽车集团需要针对当前 ES 集群进行优化,背景如下: ES 用于支撑包括核心营销系统、管理支持系统、财务类、IT 基础设施类、研发、自动驾驶等多个重要应用,合计超 50 余套集群,累计数据超 1.5PB 。 本文针对其中一个 ES 集群进行分享,该集群原本使用的是 ES 7.3.2 免费版,数据已经 130TB 了,14 个节点。写入数据时经常掉节点,写入性能也不稳定,当天的数据写不完。迫切需要新的解决方案。 分析业务场景后总结需求要点:主要是写,很少查。审计需求,数据需要长期保存。 这个需求比较普遍,处理起来也很简单:

  • 使用 Easysearch 软件,只需少量节点存储近两天的数据。
  • 索引设置开启 ZSTD 压缩功能,节省磁盘空间。
  • 每天索引数据写完后,第二天执行快照备份存放到 S3 存储。
  • 备份成功后,删除索引释放磁盘空间。
  • 需要搜索数据时,直接从快照搜索。

将近期的数据,存放到本地磁盘,保障写入速度。写入完毕的索引,在执行快照备份后,可删除索引,释放本地磁盘空间。

Easysearch 配置要点

path.repo: ["/S3-path"]
node.roles: ["data","search"]
node.search.cache.size: 500mb
  • path.repo : 指定 S3 存储路径,上传快照用。
  • node.roles : 只有 search 角色的节点,才能去搜索快照中的数据。
  • node.search.cache.size : 执行快照搜索时的,缓存大小。

更多信息请参考官方文档

旧数据迁移

通过 Console 将原 ES 集群的数据,迁移到新 Easysearch 集群。迁移时,复制 mapping 和 setting,并在 setting 中添加如下设置。

"codec": "ZSTD",
"source_reuse": true,

原索引数据量大,可拆分成多个小任务。 迁移完,索引存储空间一般节省 50% 左右。 原索引 279GB ,迁移完后 138GB。

搜索快照数据

挂载快照后,搜索快照里的索引和搜索本地的索引,语法完全一样。 如何判断一个索引是在快照还是本地磁盘呢?可以查看索引设置里的 settings.index.store.type 如果是 remote_snapshot ,说明是快照中的数据。如果是空值,则是集群本地的数据。
这次迁移,节省了 6 台主机资源。更重要的是,用上对象存储后,主机磁盘空间压力骤减。
这次介绍就到这里了,有问题联系我。

关于 Easysearch

Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://infinilabs.com/docs/latest/easysearch

【搜索客社区日报】第1769期 (2024-01-05)

社区日报laoyang360 发表了文章 • 0 个评论 • 2712 次浏览 • 2024-01-05 15:41 • 来自相关话题

1、一个Elasticsearch 监控 vue 客户端(昨天还在更新) https://github.com/cars10/elasticvue 2、Elasticsearch 系统设计小抄 https://betterprogramming.pub/ ... 60463 https://towardsdatascience.com ... ebfff 3、CKibana——为了能够在原生kibana上直接使用ElasticSearch语法查询ClickHouse的服务 https://github.com/TongchengOpenSource/ckibana 4、从 Elasticsearch 7.17 迁移到 Elasticsearch 8.x:陷阱和经验教训 https://engineering.zalando.co ... .html 编辑:铭毅天下  更多资讯:http://news.searchkit.cn

开启安全功能 ES 集群就安全了吗?

Easysearchyangmf2040 发表了文章 • 0 个评论 • 2887 次浏览 • 2023-12-27 10:38 • 来自相关话题

背景

经常跟 ES 打交道的朋友都知道,现在主流的 ES 集群安全方案是:RBAC + TLS for Internal + HTTPS 。

作为终端用户一般只需要关心用户名和密码就行了。作为管理和运维 ES 的人员来说,可能希望 ES 能提供密码策略来强制密码强度和密码使用周期。遗憾的是 ES 对密码强度和密码使用周期没有任何强制要求。如果不注意,可能我们天天都在使用“弱密码”或从不修改的密码(直到无法登录)。而且 ES 对连续的认证失败,不会做任何处理,这让 ES 很容易遭受暴力破解的入侵。

那还有没有别的办法,进一步提高安全呢? 其实,网关可以来帮忙。

虽然网关无法强制提高密码复杂度,但可以提高 ES 集群被暴力破解的难度。

大家都知道,暴力破解--本质就是不停的“猜”你的密码。以现在的 CPU 算力,一秒钟“猜”个几千上万次不过是洒洒水,而且 CPU 监控都不带波动的,很难发现异常。从这里入手,一方面,网关可以延长认证失败的过程--延迟返回结果,让破解不再暴力。另一方面,网关可以记录认证失败的情况,做到实时监控,有条件的告警。一旦出现苗头,可以使用网关阻断该 IP 或用户发来的任何请求。

场景模拟

首先,用网关代理 ES 集群,并在 default_flow 中增加一段 response_status_filter 过滤器配置,对返回码是 401 的请求,跳转到 rate_limit_flow 进行降速,延迟 5 秒返回。

  - name: default_flow
    filter:
      - elasticsearch:
          elasticsearch: prod
          max_connection_per_node: 1000
      - response_status_filter:
          exclude:
            - 401
          action: redirect_flow
          flow: rate_limit_flow
  - name: rate_limit_flow
    filter:
      - sleep:
          sleep_in_million_seconds: 5000

其次,对于失败的认证,我们可以通过 Console 来做个看板实时分析,展示。

折线图、饼图图、柱状图等,多种展示方式,大家可充分发挥。

最后,可在 Console 的告警中心,配置对应的告警规则,实时监控该类事件,方便及时跟进处置。

效果测试

先带上正确的用户名密码测试,看看返回速度。

0.011 秒返回。再使用错误的密码测试。

整整 5 秒多后,才回返结果。如果要暴力破解,每 5 秒钟甚至更久才尝试一个密码,这还叫暴力吗?

看板示例

此处仅仅是抛砖引玉,欢迎大家发挥想象。

告警示例

建立告警规则,用户 1 分钟内超过 3 次登录失败,就产生告警。

可在告警中心查看详情,也可将告警推送至微信、钉钉、飞书、邮件等。

查看告警详情,是 es 用户触发了告警。

最后,剩下的工作就是对该账号的处置了。如果有需要可以考虑阻止该用户或 IP 的请求,对应的过滤器文档在这里,老规矩加到 default_flow 里就行了。

如果小伙伴有其他办法提升 ES 集群安全,欢迎和我们一起讨论、交流。我们的宗旨是:让搜索更简单!

给 ES 插上向量检索的翅膀 | DataFunSummit 2023 峰会演讲内容速达

Elasticsearchliaosy 发表了文章 • 0 个评论 • 1293 次浏览 • 2023-07-12 18:37 • 来自相关话题

近日,由 DataFun 主办的 DataFunSummit 2023 数据基础架构峰会 圆满落下帷幕,本次峰会邀请了腾讯、百度、字节、极限科技、Zilliz 等众多企业技术专家为大家带来分布式存储以及向量数据库的架构原理、性能优化与实践解析分享。

向量数据库架构与实践论坛 中,极限科技搜索引擎研发工程师张磊受邀出席做了《给 ES 插上向量检索的翅膀》的主题演讲。据介绍,本次演讲主要介绍了 Elasticsearch(ES)与向量技术的融合,展示其在不同行业中的应用场景和优势,同时也对 ES 与向量的技术细节进行详细讨论,并通过具体案例演示如何利用向量提升搜索能力。

讲师介绍

张磊,极限科技 Easysearch 引擎研发工程师,2013 年开始接触 Elasticsearch,10 余年搜索相关经验,之前主要做一些围绕 Elasticsearch 在日志检索和公安大数据相关业务的开发,对 Elasticsearch 和 Lucene 源码比较熟悉,目前专注于公司内部搜索产品的开发。

《给 ES 插上向量检索的翅膀》PPT 内容

更多 PPT 内容参见 https://elasticsearch.cn/slides/322

关于 Easysearch

INFINI Easysearch 是一个分布式的近实时搜索与分析引擎,核心引擎基于开源的 Apache Lucene。Easysearch 衍生自基于开源协议 Apache 2.0 的 Elasticsearch 7.10 版本。Easysearch 的目标是提供一个轻量级的 Elasticsearch 可替代版本,并继续完善和支持更多的企业级功能。与 Elasticsearch 相比,Easysearch 更关注在搜索业务场景的优化和继续保持其产品的简洁与易用性。

官网文档:https://www.infinilabs.com/docs/latest/easysearch

下载地址:https://www.infinilabs.com/download

INFINI 产品更新啦 20220923

资讯动态liaosy 发表了文章 • 0 个评论 • 1770 次浏览 • 2022-09-23 22:47 • 来自相关话题

INFINI Labs 产品更新发布

今天 INFINI Labs 为大家又带来了一波产品更新,请查阅。

INFINI Gateway v1.8.0

极限网关本次迭代更新如下:

  • 修复上下文条件 consumer_has_lag参数和 配置、文档不一致的 Bug。
  • 修改备集群故障,主集群不能正常写数据的 Bug。
  • 修复 Bulk 请求处理异常造成数据复制不一致的问题。
  • 修复请求日志里面关于 Bulk 统计数据丢失的问题。
  • 修复大并发情况下,请求体为空的异常。

INFINI Console v0.6.0

口碑爆棚的 Elasticsearch 多集群管控平台 INFINI Console 更新如下:

  • 新增主机概览。

1-640.png

  • 新增主机监控。

2-640.png

  • 节点概览新增日志查看功能(需安装 Agent)。

3-640.png

  • Insight 配置框新增 Search 配置。
  • 优化 Discover 时间范围 Auto Fit,设为15分钟。
  • 优化 Discover 保存搜索,会保存当前的字段过滤和 Insight 图表配置。
  • 优化本地列表搜索查找,支持通配符过滤。
  • 优化告警规则必填字段标记显示。
  • 修复了 Discover 字段过滤白屏问题。
  • 修复了 Discover 表格添加字段后排序失效问题。(感谢@卢宝贤反馈)
  • 修复了 Elasticsearch 8.x 删除文档报错不兼容的问题。(感谢@卢宝贤反馈)
  • 修复了创建新索引不成功时,异常处理的问题。
  • 修复了低版本浏览器js不兼容导致集群注册不成功的问题。
  • 修复了开发工具中使用加载命令失败报错的问题。

INFINI Agent v0.2.0

数据采集工具探针(INFINI Agent)更新如下:

  • 新增按节点读日志文件列表的API
  • 新增读具体日志文件内容的API
  • 新增 Elasticsearch 节点掉线后的基础信息保存
  • 新增主机在线状态的采集
  • 新增基于 Centos 的 Docker 镜像
  • 新增主机配置信息采集: 操作系统信息、磁盘大小、内存大小、CPU配置等
  • 新增主机指标的采集: CPU使用率、磁盘使用率、磁盘IO、内存使用率、swap 使用率、网络IO等
  • 新增 Elasticsearch 进程信息采集
  • 修复发现 Elasticsearch 进程时频繁提示端口访问错误的Bug
  • 修复 Elasticsearch 节点地址为 0.0.0.0 时无法获取节点信息的Bug
  • 修复 CPU 指标数据显示异常的Bug
  • 修复 stats API 在 Windows 平台的兼容性

INFINI Framework 2000923

INFINI Framework 也带来了很多改进:

  • 重构了磁盘队列压缩相关配置,支持段文件的压缩。
  • 当集群不可用的情况下,跳过集群节点元数据的获取。
  • 完善节点可用性检测,避免频繁的不可用状态切换。
  • 修复 Elasticsearch 主机地址为空的异常。
  • 完善本地磁盘队列文件的清理,避免删除正在使用的文件。

期待反馈

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

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

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

也欢迎大家微信扫码添加小助手,加入用户群讨论,或者扫码加入我们的知识星球一起学习交流。 联系我们

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

有了这两个小脚本,不需要再傻乎乎地手动安装 Elasticsearch了

Elasticsearchspoofer 发表了文章 • 0 个评论 • 1924 次浏览 • 2022-03-11 19:40 • 来自相关话题

在学习 ES 前一般都需要安装 ES,虽然 ES 可以开箱即用,但如果要学习分布式特性的时候,需要安装多个节点,这个时候还是有点工作量的。下面提供两个小脚本,一个是在 Ubuntu 中安装 3 节点的 ES 伪集群,一个是在 docker 中安装3节点 ES 集群。除了安装 ES 外,脚本还提供了对应版本的 Kibana、Cerebro 0.9.4 的安装。

1、在 Ubuntu 中安装 ES 7.13

这里我们采取下载 ES 安装包并且解压安装的方式,并没有走 Ubuntu apt 的方式。ES 的安装非常简单,这里先献上安装脚本

下面介绍比较重要的配置项:

  • discovery.seed_hosts 在开箱即用的情境下(本机环境)无需配置,ES 会自动扫描本机的 9300 到 9305 端口。一旦进行了网络环境配置,这个自动扫描操作就不会执行。discovery.seed_hosts 配置为 master 候选者节点即可。如果需要指定端口的话,其值可以为:["localhost:9300", "localhost:9301"]

  • cluster.initial_master_nodes 指定新集群 master 候选者列表,其值为节点的名字列表。如果配置了 node.name: my_node_1,所以其值为 ["my_node_1"],而不是 ip 列表 !

  • network.host 和 http.port 是 ES 提供服务的监听地址和端口,线上一定不能配置 ip 为 0.0.0.0,这是非常危险的行为!!!

怎么样来理解这个 discovery.seed_hosts 和 cluster.initial_master_nodes 呢?

cluster.initial_master_nodes 是候选者列表,一般我们线上环境候选者的数量比较少,毕竟是用来做备用的。而且这个配置只跟选举 master 有关,也就是跟其他类型的节点没有关系。就算你有100个数据节点,然后经常增加或者剔除都不需要动这个列表。

discovery.seed_hosts 这个可以理解为是做服务或者节点发现的,其他节点必须知道他们才能进入集群~ 一般配置为集群的master 候选者的列表。

但是这些 master 候选者(组织联系人)可能经常变化,那怎么办呢?这个配置项除了支持 ip 外还支持域名 ~所以可以用域名来解决这个问题,其他节点的配置上写的是域名,域名解析到对应的 ip,如果机器挂了,新的节点 ip 换了,就把域名解析到新的ip即可,这样其他节点的配就不用修改了。所以非 master 候选节点要配 discovery.seed_hosts (组织联系人)

除了修改 ES 服务配置外,还需要配置 JVM 的配置,我们主要配置服务占用的堆内存的大小。JVM 配置需要以下几点:

  • 这两个 jvm 的配置必须配置一样的数值。启动时就分配好内存空间,避免运行时申请分配内存造成系统抖动。
  • Xmx不要超过机器内存的 50%,留下些内存供 JVM 堆外内存使用
  • 并且Xmx不要超过 32G。建议最大配置为 30G。接近 32G,JVM 会启用压缩对象指针的功能,导致性能下降。具体可以参考:a-heap-of-trouble

安装成功后,可以访问: ES:localhost:9211

Kibana: localhost:5601

cerebro: localhost:9800

2、在docker 中安装 ES 7.13

在做一切工作之前,我们必须安装 docker。如果你已经安装好了 docker、docker-compose,可以访问我为你准备的 docker-compose.yaml 文件。

如果你没有安装 docker,完整的教程可以参考在 docker 中安装 ES 文档

下载此文件,将文件保存为 docker-compose.yaml 后,进入这个文件的目录,执行以下指令即可:

docker-compose up

如果你没有下载镜像文件,docker-compose 会自动帮你下载镜像,并且启动容器。

如果 docker-compose 启动失败,说是无权限链接 docker 的话,其报错如下:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: 

Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json?all=1&filters=%7B%22label%22%3A%7B%22com.docker.compose.project%3Ddocker_es%22%3Atrue%7D%7D&limit=0": 

dial unix /var/run/docker.sock: connect: permission denied

可以运行以下指令临时修改:

sudo chmod 666 /var/run/docker.sock

其原因是因为你的 docker 用了 root 启动了。

最后可以访问:

cerebro:ip:9000

Kibana:ip:5601

Elasticsearch: ip:9200,ip:9202,ip:9203

其他学习资料

创建自己的 ES Docker Image

在 docker image 中安装 Elasticsearch 插件

一个开源的 ELK docker-compose 配置

docker 中安装 ES 7.13

docker 中安装 Kibana 7.13

最后附上我写的小册,欢迎刚入门的朋友来订阅~

WX20220224-174733.png

熬了几个月的夜,我的ES小册终于发布啦,适合初学者或者有点基础的同学学习~

Elasticsearchspoofer 发表了文章 • 2 个评论 • 2299 次浏览 • 2022-03-01 12:19 • 来自相关话题

课程简介.png

本小册分为 4 个部分,将由浅入深为你介绍 Elasticsearch 7.x 中的核心技术。主要知识点包括基本概念、常用 API 的使用实践、核心特性的底层原理与思想、集群管理与调优、源码阅读等知识。整个小册的思维导图如下:

知识点.png

你会学到什么?

本小册将会从非常浅显的概念开始与你学习 Elasticsearch 7.x 中的常用 API,在熟悉使用 Elasticsearch 后,我们将会对 Elasticsearch 中部分重要的特性、概念的底层实现原理进行介绍。在了解这些原理后,我们将学习如何部署、运维线上小规模集群,并且与你一起搭建一个简单的 ELK 系统。最后我们会搭建源码阅读的环境并且与你一起阅读部分模块的源码。

所以,通过本小册 4 大部分的学习,你可以收获:

  • 熟练使用 Elasticsearch 来解决搜索需求;
  • 强化 Elasticsearch 集群运维、调优的能力;
  • 通晓 Elasticsearch 核心技术的底层实现;
  • 牢固掌握源码阅读与调试的技巧。

也就是说,学完本课程后,你不仅可以掌握 ElasticSearch 相关的技术,还可以帮助你根据业务的特点快速构建出相应的搜索业务、数据分析、日志系统。真正实现学以致用。

适宜人群

  • 对 Elasticsearch 或搜索引擎感兴趣的同学。
  • 有了解和使用过 Elasticsearch,现在想进一步了解 Elasticsearch 的同学。
  • 准备从事数据搜索、分析相关工作的同学。
  • 从事 Elasticsearch 集群运维的同学。

【年度盛会】Elastic 中国开发者大会 2021 八折购票火热进行中

活动liaosy 发表了文章 • 0 个评论 • 1925 次浏览 • 2021-12-29 11:06 • 来自相关话题

【年度盛会】2021 Elastic 中国开发者大会,来自Elastic、阿里、腾讯、谷歌、字节等业界专家带来的干货分享,精彩内容不容错过,八折购票火热进行中(折扣码: 80OFF),扫码即可报名购票。  
开发者大会2021议题海报2_讲师.png
  【更多演讲嘉宾介绍】 https://conf.elasticsearch.cn/2021/speaker.html 【大会官网】 https://conf.elasticsearch.cn
【年度盛会】2021 Elastic 中国开发者大会,来自Elastic、阿里、腾讯、谷歌、字节等业界专家带来的干货分享,精彩内容不容错过,八折购票火热进行中(折扣码: 80OFF),扫码即可报名购票。  
开发者大会2021议题海报2_讲师.png
  【更多演讲嘉宾介绍】 https://conf.elasticsearch.cn/2021/speaker.html 【大会官网】 https://conf.elasticsearch.cn

【1月8日】Elastic 中国开发者大会 2021 日程新鲜出炉!福利票抢先购!

Elasticsearchliaosy 发表了文章 • 0 个评论 • 2624 次浏览 • 2021-12-27 21:46 • 来自相关话题

重要的事情说三遍

  • Elastic 中国开发者大会 2021 的精彩日程现已上线!
  • Elastic 中国开发者大会 2021 的精彩日程现已上线!
  • Elastic 中国开发者大会 2021 的精彩日程现已上线!

关于本次大会

Elastic 中国开发者大会 2021 是由 Elastic 官方、Elastic 中文社区和极限科技联合主办的开发者大会,作为中国国内唯一一个专门讨论 Elasticsearch 开源技术的大会,是中国最权威和最具实力干货的技术大会,其专业性和内容的质量一直以来在业内都是有口皆碑。本次大会邀请的演讲嘉宾有来自 Elastic 官方、Google、腾讯、阿里巴巴、字节跳动、vivo等众多公司的技术专家,为中国广大的 Elasticsearch 开发者提供一个技术交流和学习切磋的地方,汇集业界众多的成功案例,集思广益,发散思维,促进社区和行业的进步。

更多详细介绍请参见大会官网:

https://conf.elasticsearch.cn

关于大会议程

开发者大会2021议程_8折.png

精彩内容不容错过,八折购票火热进行中(折扣码: 80OFF),扫码购买。

ES Aggs根据聚合的结果(数值)进行过滤

Elasticsearchziyou 发表了文章 • 1 个评论 • 21818 次浏览 • 2019-10-10 14:32 • 来自相关话题

前言

我们在使用聚合时总是有各种各样的聚合需求,其中一个比较常用的就是根据聚合的结果过滤聚合的桶,例如:1、每个IP登录次数超过5次的IP;2、每个IP登录人数超过2的IP。 还有我之前的一个案例,访问量超过1000的人数,这些都是很常见的统计需求。

案例需求

我们在使用聚合计算的时候一般都有两类,一种是计算文档的数量,另一种是计算文档内字段的值的数量(去重计算)或者值的数学计算。两种聚合计算在过滤的时候采用不同的方法来计算。

我们使用以下案例来说明两种过滤的不同: 用户每次登录都会记录一个登录记录:

{"userID":"a","IP":"10.70.25.1","time":"2019-10-10 12:12:12.222"}

然后提出以下两个需求: 1、每个IP登录次数超过5次的IP; 2、每个IP登录人数超过2的IP。

实现

每个IP登录次数超过5次的IP

这个是对登录记录个数的桶聚合统计,然后过滤。使用IP做term聚合,就可以得出每个IP的登录次数,然后term聚合中有一个参数min_doc_count这个字段就可以对文档数量进行过滤,具体的语句如下: 查询语句

{
  "aggs": {
    "IP": {
      "terms": {
        "field": "IP",
        "size": 3000,
        "order": {
          "_count": "desc"
        },
        "min_doc_count": 5
      }
    }
  },
  "size": 0
}

结果

{
  "took" : 614,
  "timed_out" : false,
  "num_reduce_phases" : 3,
  "_shards" : {
    "total" : 1105,
    "successful" : 1105,
    "skipped" : 75,
    "failed" : 0
  },
  "hits" : {
    "total" : 2826,
    "max_score" : 0.0,
    "hits" : [ ]
  },
  "aggregations" : {
    "IP" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "10.25.90.139",
          "doc_count" : 61
        },
        {
          "key" : "10.25.78.146",
          "doc_count" : 45
        },
        {
          "key" : "10.25.94.22",
          "doc_count" : 21
        },
        {
          "key" : "10.25.75.52",
          "doc_count" : 18
        },
        {
          "key" : "10.25.89.32",
          "doc_count" : 13
        },
        {
          "key" : "10.25.93.243",
          "doc_count" : 10
        },
        {
          "key" : "10.25.78.189",
          "doc_count" : 9
        },
        {
          "key" : "10.25.90.82",
          "doc_count" : 8
        },
        {
          "key" : "10.25.91.240",
          "doc_count" : 8
        },
        {
          "key" : "10.25.90.57",
          "doc_count" : 7
        },
        {
          "key" : "10.25.91.251",
          "doc_count" : 7
        },
        {
          "key" : "10.25.95.166",
          "doc_count" : 6
        },
        {
          "key" : "10.25.89.33",
          "doc_count" : 5
        },
        {
          "key" : "10.25.90.88",
          "doc_count" : 5
        },
        {
          "key" : "10.25.92.53",
          "doc_count" : 5
        }
      ]
    }
  }
}

每个IP登录人数超过2的IP

这个是对登录记录用户ID的去重数聚合,然后过滤。对用户ID进行去重可以使用Cardinality Aggregation聚合,然后再使用Bucket Selector Aggregation聚合过滤器过滤数据。具体内容如下: 查询语句

{
  "aggs": {
    "IP": {
      "terms": {
        "field": "IP",
        "size": 3000,
        "order": {
          "distinct": "desc"
        },
        "min_doc_count": 5
      },
      "aggs": {
        "distinct": {
          "cardinality": {
            "field": "IP.keyword"
          }
        },
        "dd":{
          "bucket_selector": {
            "buckets_path": {"userCount":"distinct"},
            "script": "params.userCount > 2"
          }
        }
      }
    }
  },
  "size": 0
}

结果

{
  "took" : 317,
  "timed_out" : false,
  "num_reduce_phases" : 3,
  "_shards" : {
    "total" : 1105,
    "successful" : 1105,
    "skipped" : 75,
    "failed" : 0
  },
  "hits" : {
    "total" : 2826,
    "max_score" : 0.0,
    "hits" : [ ]
  },
  "aggregations" : {
    "IP" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "10.25.75.52",
          "doc_count" : 18,
          "distinct" : {
            "value" : 4
          }
        },
        {
          "key" : "10.25.78.146",
          "doc_count" : 45,
          "distinct" : {
            "value" : 3
          }
        },
        {
          "key" : "10.25.90.139",
          "doc_count" : 61,
          "distinct" : {
            "value" : 3
          }
        },
        {
          "key" : "10.25.91.240",
          "doc_count" : 8,
          "distinct" : {
            "value" : 3
          }
        },
        {
          "key" : "10.25.94.22",
          "doc_count" : 21,
          "distinct" : {
            "value" : 3
          }
        }
      ]
    }
  }
}

桶聚合选择器: https://www.elastic.co/guide/en/elasticsearch/reference/6.8/search-aggregations-pipeline-bucket-selector-aggregation.html

ES6.8权限使用配置

Elasticsearchziyou 发表了文章 • 0 个评论 • 9700 次浏览 • 2019-07-31 10:50 • 来自相关话题

概述 ES的权限控制一直ES使用中的一个问题,因为官方之前一直未免费安全性功能。公司要不选择使用其他插件来解决,要不就是只在内网使用。现在在ES6.8及以后版本ES将部分安全性功能免费开放了, 现在我们就6.8版本的【基于角色的访问控制】进行操作、验证。 1、下载安装ELK6.8版本(此处省略) ES在6.8以后发布的版本才有(7.0是发布在6.8之前的) 2、修改ES配置文件 elasticsearch.yml 在配置文件中添加:
xpack.security.enabled: true
基础版本的安全性功能是默认关闭的。 然后启动ES
./elasticsearch -d
3、设置内置用户密码 参考:内置用户
./bin/elasticsearch-setup-passwords interactive
这里设置的密码要记住,后面会使用到。我们设置简单的密码:123456(密码不能少于6位) 如果是Windows请使用CMD命令行执行 按照提示设置内置用户密码 4、设置kibana用户名密码 在kibana的配置文件kibana.yml里面添加
elasticsearch.username: "kibana"
elasticsearch.password: "123456"
5、然后启动kibana 启动kibana就可以使用用户名与密码进行访问。
Image.png
6、设置logstash用户名和密码 打开配置文件conf,在output中的elasticsearch中添加user、password 例:
output {
    elasticsearch {
      hosts => ["10.68.24.136:9200","10.68.24.137:9200"]
      index => "%{[indexName]}-%{+YYYY.MM.dd}"
      user => "logstash_system"
      password => "123456"
    }

平安科技诚招ES运维工程师 待遇福利丰厚

求职招聘Joey 发表了文章 • 1 个评论 • 4381 次浏览 • 2019-03-06 16:18 • 来自相关话题

平安科技诚招ES运维工程师,待遇福利丰厚,工作地点上海张江,有意者可以将简历发送至 CAIZHEN616@pingan.com.cn   岗位要求 1. 大学本科以上学历,计算机相关专业,2年以上的工作经验; 2. 熟悉linux操作系统、网络、sql等方面的知识,具有大型应用平台运维经验,有过运维自动化项目经验者优先; 3. 熟悉Python、shell语言,并且能够熟练使用Python、Shell进行脚本编写; 4..熟悉ansible、saltstack或其他运维自动化工具,了解elasticsearch、logstash、filebeat等开源软件优先 5. 熟悉docker、kubernetes、swarm等容器及编排技术,熟悉相关网络、存储解决方案,有相关经验优先 平安科技是平安集团的全资子公司,致力于运用人工智能、智能认知、云计算、区块链等前沿科技,为人们打造全新云生活。对内,平安科技是平安集团的高科技内核和科技企业孵化器,负责开发并运营集团的关键平台和服务。对外,平安科技以智慧科技为手段、以智造未来为蓝图,聚焦于医疗、金融、智慧城市三大领域,将国际权威认证的技术能力应用到实际业务场景中,打造生态闭环,积极践行科技改变生活的企业理念。 超过10000名专业IT技术人员和管理专家组成的高级研发团队,为平台的运营稳定和可靠,提供了专家级的技术保障。目前所建立的云生态圈已经承载过5亿的互联网用户,并拓展至海外市场,包括美国、新加坡、香港等国家和地区

Day 12 - Elasticsearch日志场景最佳实践

Adventginger 发表了文章 • 0 个评论 • 6496 次浏览 • 2018-12-12 16:35 • 来自相关话题

1. 背景

Elasticsearch可广泛应用于日志分析、全文检索、结构化数据分析等多种场景,大幅度降低维护多套专用系统的成本,在开源社区非常受欢迎。然而Elasticsearch为满足多种不同的使用场景,底层组合使用了多种数据结构,部分数据结构对具体的用户使用场景可能是冗余的,从而导致默认情况下无法达到性能和成本最优化。 幸运的是,Elasticsearch提供非常灵活的模板配置能力,用户可以按需进行优化。多数情况下,用户结合使用场景进行优化后,Elasticsearch的性能都会有数倍的提升,成本也对应有倍数级别的下降。本文主要介绍不同日志使用场景下的调优经验。

2. 日志处理基本流程

日志处理的基本流程包含:日志采集 -> 数据清洗 -> 存储 -> 可视化分析。Elastic Stack提供完整的日志解决方案,帮助用户完成对日志处理全链路的管理,推荐大家使用。每个流程的处理如下:

  • 日志采集:从业务所在的机器上,较实时的采集日志传递给下游。常用开源组件如Beats、Logstash、Fluentd等。
  • 数据清洗:利用正则解析等机制,完成日志从文本数据到结构化数据的转换。用户可使用Logstash 或 Elasticsearch Ingest模块等完成数据清洗。
  • 存储:使用Elasticsearch对数据进行持久存储,并提供全文搜索和分析能力。
  • 可视化分析:通过图形界面,完成对日志的搜索分析,常用的开源组件如Kibana、Grafana。

使用Elastic Stack处理日志的详细过程,用户可参考官方文章Getting started with the Elastic Stack,这里不展开介绍。

3. 日志场景调优

       对于Elasticsearch的通用调优,之前分享的文章Elasticsearch调优实践,详细介绍了Elasticsearch在性能、稳定性方面的调优经验。而对于日志场景,不同的场景使用方式差别较大,这里主要介绍常见使用方式下,性能和成本的优化思路。

3.1 基础场景

对于多数简单日志使用场景,用户一般只要求存储原始日志,并提供按关键字搜索日志记录的能力。对于此类场景,用户可跳过数据清洗阶段,并参考如下方式进行优化:

  • 建议打开最优压缩,一般可降低40%存储。
  • 设置原始日志字段(message)为text,去除keyword类型子字段,提供全文搜索能力,降低存储。
  • 关闭_all索引,前面已通过message提供全文搜索能力。
  • 对于其他字符串字段,统一设置为keyword类型,避免默认情况下字符串字段同时存储text、keyword两种类型的数据。
  • 使用开源组件(如Beats)上报数据时会包含较多辅助信息,用户可通过修改组件配置文件进行裁剪。

这样去除message的keyword子字段、_all等冗余信息后,再加上最优压缩,可以保证数据相对精简。下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,分词建立索引
                        "match": "message",
                        "mapping": {
                            "type": "text"
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

3.2 精准搜索场景

对于部分用户,普通的全文检索并不能满足需求,希望精准搜索日志中的某部分,例如每条日志中包含程序运行时多个阶段的耗时数据,对具体一个阶段的耗时进行搜索就比较麻烦。对于此类场景,用户可基于基础场景,进行如下调整:

  • 清洗过程中,可仅解析出需要精准搜索的部分作为独立字段,用于精准搜索。
  • 对于精准搜索字段,如果无排序/聚合需求,可以关闭doc_values;对于字符串,一般使用keyword,可按需考虑使用text。

下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,分词建立索引
                        "match": "message",
                        "mapping": {
                            "type": "text"
                        }
                    }
                },
                {
                    "precise_fieldx": {       # 精准搜索字段
                        "match": "fieldx",
                        "mapping": {
                            "type": "keyword",
                            "doc_values": false
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

3.3 统计分析场景

对于某些场景,日志包含的主要是程序运行时输出的统计信息,用户通常会完全解析日志进行精确查询、统计分析,而是否保存原始日志关系不大。对于此类场景,用户可进行如下调整:

  • 清洗过程中,解析出所有需要的数据作为独立字段;原始日志非必要时,建议去除。
  • 如果有强需求保留原始日志,可以设置该字段enabled属性为false,只存储不索引。
  • 多数字段保持默认即可,会自动建立索引、打开doc_values,可用于查询、排序、聚合。
  • 对部分无排序/聚合需求、开销高的字段,可以关闭doc_values。

下面给出这类场景的常用模板,供用户参考:

{
    "order": 5,
    "template": "my_log_*",
    "settings": {
        "translog.durability": "async",
        "translog.sync_interval": "5s",
        "index.refresh_interval": "30s",
        "index.codec": "best_compression"    # 最优压缩
    },
    "mappings": {
        "_default_": {
            "_all": {                        # 关闭_all索引
                "enabled": false
            },
            "dynamic_templates": [
                {
                    "log": {                 # 原始日志字段,关闭索引
                        "match": "message",
                        "mapping": {
                            "enabled": false
                        }
                    }
                },
                {
                    "index_only_fieldx": {   # 仅索引的字段,无排序/聚合需求
                        "match": "fieldx",
                        "mapping": {
                            "type": "keyword",
                            "doc_values": false
                        }
                    }
                },
                {
                    "strings": {             # 其他字符串字段,统一设置为keyword类型
                        "match_mapping_type": "string",
                        "mapping": {
                            "type": "keyword"
                        }
                    }
                }
            ]
        }
    }
}

ES 5.1及之后的版本,支持关键字查询时自动选择目标字段,用户没有必要再使用原始日志字段提供不指定字段进行查询的能力。

4. 小结

日志的使用方式比较灵活,本文结合常见的客户使用方式,从整体上对性能、成本进行优化。用户也可结合自身业务场景,参考文章Elasticsearch调优实践进行更细致的优化。