1.怎么为每个索引选择合适的分片？

[https://opster.com/elasticsear ... Dtrue](https://opster.com/elasticsear ... 3Dtrue)

2.在kibana使用德国高速公路数据示例

[https://spinscale.de/posts/202 ... .html](https://spinscale.de/posts/202 ... s.html)

3.在es查询中查找实体名的方法

[https://stackoverflow.com/ques ... earch](https://stackoverflow.com/ques ... search)

1、Elasticsearch 8.X新特性概览
https://www.elastic.co/guide/e ... .html
2、Elasticsearch 垃圾回收算法解读
https://blog.bigdataboutique.c ... toq2j
3、零停机reindex实践
https://tuleism.github.io/blog ... ndex/
 
 
编辑：铭毅天下
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup

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中。
 



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



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


 
 

1.通过Metricbeat实现外部对Elastic Stack的监控
https://www.cnblogs.com/sanduz ... .html

2.Elasticsearch 慢查询设置
https://blog.csdn.net/wang7075 ... 93713

3.es分析过程
https://www.cnblogs.com/Neeo/a ... .html

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

随着时间点 API（Point in time API）的推出，根据 Elastic 的官方博客 “使用 Elasticsearch 时间点读取器获得随时间推移而保持一致的数据视图”，Scroll 接口将不被推荐作为对搜索结果的分页。

默认情况下，搜索会返回前 10 个匹配的匹配项。 要翻阅更大的结果集，你可以使用搜索 API 的 from 和 size 参数。 from 参数定义要跳过的命中数，默认为 0。 size 参数是要返回的最大命中数。 这两个参数共同定义了一页结果。比如：

GET /twitter/_search
{
  "from": 5,
  "size": 20,
  "query": {
    "match": {
      "city": "北京"
    }
  }
}

避免使用 from 和 size 来分页太深或一次请求太多结果。 搜索请求通常跨越多个分片。 每个分片必须将其请求的命中和任何先前页面的命中加载到内存中。 对于深页面或大型结果集，这些操作会显着增加内存和 CPU 使用率，从而导致性能下降或节点故障。这里的原因是 index.max_result_window 的默认值是 10K，也就是说 from+size 的最大值是1万。搜索请求占用堆内存和时间与 from+size 成比例，这限制了内存。假如你想 hit 从 990 到 1000，那么每个 shard 至少需要 1000 个文档：

原文链接：https://elasticstack.blog.csdn ... 32811