Elastic Stack 6.7 版本隆重推出，这一版本到底有多棒呢？我们不确定圣诞节是来得太早了，还是太晚了，反正我们所有人的圣诞大礼一下子全来啦！
 在此篇发布博文中，我们将会为大家介绍这一版本中的部分亮点。务必查看单独的发布博文，深入了解完整详情。如果您能试用最新版本，那就再好不过啦。6.7 版本已在我们的 <a href="/cn/cloud/elasticsearch-service">Elasticsearch 服务</a>上推出；Elasticsearch 服务是唯一提供这些功能的托管型 Elasticsearch 产品。或者，您也可以<a href="/cn/downloads">下载 Elastic Stack</a>，并在您的首选部署环境中自行管理。
 <h3>Elastic 地图：扩大 Kibana 中地理数据的映射能力</h3>
 地理数据是搜索中十分重要的一部分，这些基于位置的数据为很多用例提供支持，从对附近的餐厅进行排名，到理解最新市场活动在何处产生的反响最为强烈，再到在全球范围内追踪网络威胁，都离不开地理数据搜索。多年以来，我们投入巨大精力在整个堆栈范围内改善地理数据功能，从在 Elasticsearch 中实现更高的存储效率和大幅改善查询性能，到在 Kibana 中提供更多的地理空间可视化选项，再到使用 Elastic 地图服务自由地托管基础地图 (Basemap) 和国家/地区边界，我们做了很多工作。
 为了紧跟这一发展步伐，我们十分兴奋地推出 Elastic 地图，这是专门针对在 Kibana 中映射、查询和可视化地理空间数据而推出的一项崭新解决方案。Elastic 地图引入了下面这些功能，可以极大扩展 Kibana 中现有的地理空间可视化选项：
 <ul>
 <li>在同一地图上对多个图层和数据源进行可视化</li>
 <li>在地图上的矢量图层中实现数据驱动的动态样式</li>
 <li>同时对聚合数据和文档级数据进行映射</li>
 <li>可对单独图层的可视性进行控制（基于缩放级别），以降低可视内容的杂乱程度</li>
 </ul>
 而且，与 Kibana 中的所有其他内容一样，Elastic 地图也内嵌具有 autocomplete（自动完成）功能的搜索栏，为您在进行各类搜索和查询时提供您希望 Elastic Stack 实现的实时体验。
 <img asset_uid="bltcfa8e336725e2ec4" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltcfa8e336725e2ec4/5c99ef3898d5092a05466c63/gif-maps-stack-pr-med-fidelity.gif" alt="gif-maps-stack-pr-med-fidelity.gif" height="auto" />
 有关完整详情，请查看这篇<a href="/cn/blog/elastic-maps-beta-released">详尽的 Elastic 地图发布博文</a>。
 <h3>Elastic 运行状态监测：主动监测服务和应用程序的运行状态</h3>
 在之前的几个发布版本中，我们推出了多项功能，包括针对 Kubernetes 的自动发现 (autodiscovery)，以及基础设施和日志解决方案，这些功能均旨在帮助拥有基础设施监测和可观察性用例的 Elastic 用户简化操作。在这些近期工作的基础上，我们在此十分激动地推出一项全新解决方案：Elastic 运行状态监测；通过此解决方案，用户能够轻松检测到应用服务的质量何时开始下滑或者响应时间何时开始变长，此方案还能够主动向用户发送问题通知，甚至在应用程序发现这些服务中存在的问题之前便能发送通知。
 Elastic 运行状态监测解决方案基于 Heartbeat，可以在公司/组织的网络之内和之外进行部署；Heartbeat 是一款适用于运行状态监测的轻量型数据采集器。此解决方案只需获得正在监测的理想 HTTP、TCP 或 ICMP 端点的网络访问权限即可。运行状态监测解决方案的用例包括：主机可用性、服务监测、网站监测，以及 API 监测。
 将运行状态数据以及日志、指标和跟踪数据全部添加到 Elasticsearch 即意味着：用户能够在单一操作存储内更加高效地跟踪和管理他们的全部数据。
 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3c129cd22cc557ac/672d627f069a861207817875/animated-gif-kibana-dashboard-canvas.gif" alt="animated-gif-kibana-dashboard-canvas.gif" height="auto" />
 有关新发布运行状态监测解决方案的完整详情，请查看这篇<a href="/cn/blog/elastic-uptime-monitoring-solution-released">详细博文</a>。
 <h2>Elasticsearch</h2>
 6.7 是 Elasticsearch 的一个重大发布版本。本版本不仅包含数项新功能，我们还十分激动地将多项关键的 Elasticsearch 功能升级至正式版本 (GA) 状态，此举标志着这些功能可以应用于生产环境。
 如 Elasticsearch 博文所讲，如果 Elasticsearch 中的功能可用由三个字母组成的首字母缩写来表示 ，则这些功能很可能已在 6.7 中升级为 GA。
 <h3>跨集群复制 (CCA) 升级为 GA</h3>
 我们最早在 6.5 版本中推出了公测版跨集群复制 (CCR) 功能，此功能是人们呼声最高的 Elasticsearch 功能之一。CCR 的用例十分多样，包括跨数据中心和跨地区复制，复制数据以便数据距离应用程序服务器和用户更近一些，以及维护从大量小型集群复制而来的集中式报告集群。
 除了将此功能升级为 GA 状态之外，6.7 版本还在易用性和 UI 方面对 CCR 进行了多项改进。有关详情，请查看 <a href="/cn/blog/elasticsearch-6-7-0-released">Elasticsearch 发布博文</a>。
 <h3>索引生命周期 (ILM) 升级为 GA</h3>
 我们在 Elasticsearch 6.6 中推出了公测版索引生命周期 (ILM) 功能，现在此功能已升级为正式版本，可以应用于生产环境。
 随着时间的增加，应该如何对 Elasticsearch 索引进行存储和配置，这是一项至关重要的管理性工作，可以优化集群性能并降低成本。ILM 可以帮助 Elasticsearch 管理员制定并自动化这些生命周期管理政策，即随着数据的时间越来越长，如何管理数据并在热、温、冷和删这四个阶段之间转移数据。
 除了将索引生命周期管理升级至 GA 状态以外，6.7 版本还为此功能增加了多项新特性。最重要的一点，用户现在可以在冷阶段添加“冻结索引”操作，从而大大减少存储索引所需的堆内存。有关此操作以及其他 ILM 改进的相关信息，请访问 <a href="/cn/blog/elasticsearch-6-7-0-released">Elasticsearch 6.7 详细博文</a>。
 <h3>Elasticsearch SQL（包括 JDBC 和 ODBC 客户端）已升级为 GA</h3>
 <a href="/cn/products/stack/elasticsearch-sql">Elasticsearch SQL</a> 是我们在 6.3 版本中推出的一项功能，可以让用户使用业已非常熟悉的语法与他们的 Elasticsearch 数据进行交互和查询，这一语法就是：SQL。借助这一新增功能，更多用户可以体验 Elasticsearch 的全文本搜索性能。除了 SQL 查询语法，Elasticsearch SQL 功能还包括 JDBC 和 ODBC 客户端，这两个客户端可以允许支持这些驱动程序的第三方工具作为后端数据存储连接至 Elasticsearch。
 能够将所有这些功能均升级至 GA 状态，我们倍感兴奋。有关完整详情，请查看 <a href="/cn/blog/elasticsearch-6-7-0-released">Elasticsearch 博文</a>。
 我们在这里只是简单介绍了 Elasticsearch 6.7 的冰山一角。Elasticsearch 6.7 还有很多其他改进。有关完整详情，请查看 <a href="/cn/blog/elasticsearch-6-7-0-released">Elasticsearch 发布博文</a>。
 <h2>Kibana</h2>
 <h3>Canvas 升级为 GA</h3>
 <a href="/cn/products/stack/canvas">Canvas</a> 是我们在 6.5 版本中推出的一项公测版功能，可以让用户以满足完美像素要求的精准度呈现并展示 Elasticsearch 中的实时数据。我们十分兴奋地在 6.7 版本中将 Canvas 升级为 GA。借助 Canvas，用户可将在 Kibana 内通过可视化展示信息的能力提高至新高度，以让更广泛的受众了解自己的数据分析和洞见。Canvas 全面支持 Elasticsearch SQL，而且和 JDBC 及 ODBC 客户端一样，能够让用户将自己数据的影响范围和影响力扩大至更广泛的商业受众。
 <h3>推出 Kibana 本地化版本；首个即是简体中文版</h3>
 在 6.7 版本中，Kibana 推出了首个本地化版本，现在可以提供简体中文版。这标志着我们开始投入更大精力完成 Kibana 的本地化工作。除了推出简体中文版界面以外，Kibana 6.7 还推出了新的本地化框架，以在未来为更多语言提供支持。有了这一本地化框架，Elastic 社区的用户便可使用必要的工具来添加他们自己的定制翻译。
 如欲了解有关 Canvas GA、Kibana 本地化版本以及 Kibana 6.7 的其他功能，请查看 <a href="/cn/blog/kibana-6-7-0-released">Kibana 6.7 完整发布博文</a>。
 <h2>Beats</h2>
 <h3>Functionbeat 升级为 GA</h3>
 Functionbeat 是一种全新类型的 Beat，可作为一项功能部署在无服务器计算框架中，并允许用户将云端基础设施的日志和指标串流至 Elasticsearch。这一功能在 6.5 版本中作为公测版推出，现在此功能在 6.7 版本中已升级至 GA 状态。Functionbeat 目前支持 AWS Lambda 框架，而且可以从 CloudWatch Logs、SQS 和 Kinesis 串流数据。
 有关 Functionbeat 和其他 Beats 6.7 更新的相关信息，请阅读 <a href="/cn/blog/beats-6-7-0-released">Beats 发布博文</a>。
 <h3>日志和基础设施解决方案现已升级为 GA</h3>
 <a href="/cn/blog/elastic-infrastructure-app-released">基础设施</a>和<a href="/cn/blog/elastic-logs-app-released">日志</a>解决方案都是在 6.5 版本中作为公测版推出的功能。我们在此十分激动地将这两项解决方案升级至 GA 状态。
 <a href="/cn/solutions/logging">日志解决方案</a>可以在小巧的定制显示器中为用户提供实时的日志 tail 操作信息。这与文件的 tail 操作类似，但是能够在单一串流视图中看到来自您的全部基础设施的日志。而且，通过使用由 Elasticsearch 提供支持的嵌入式搜索栏，用户可以轻松将串流视图缩小至仅包括他们查找的日志。
 <a href="/cn/solutions/metrics">基础设施解决方案</a>能够让用户整体了解他们基础设施内所有组件（服务器、Kubernetes pod、Docker 容器）的运行状况，这样用户便可更加轻松地使用日志和指标数据诊断问题。量身定制的用户界面是在 Metricbeat 自动检测 (autodetect) 功能的基础上构建而成的，能够让用户只需单击一次即可交互式查看并钻取日志、指标和 APM 痕迹。
 <h2>使用升级助手为升级至 7.0 版本做好准备</h2>
 7.0.0 版本即将推出（您可<a href="/cn/blog/elastic-stack-7-0-0-beta1-released">在此处查看公测版</a>）。我们在 6.7 中推出了升级助手，帮助用户在现有的 Elastic Stack 环境中为升级至 7.0 做好准备。升级助手同时包括 API 和 UI，是一项重要的集群检查工具，可以帮助您规划升级事宜，并发现诸如弃用警告、需要升级或重新索引的索引等信息，助您拥有更加顺利的升级体验。
 <h2>立即试用</h2>
 您既可在我们的 <a href="/cn/cloud/elasticsearch-service/signup">Elasticsearch 服务</a>上部署集群，也可<a href="/cn/downloads">下载堆栈</a>以轻松试用这些最新功能。

elastic-stack-blog-banner.png

elastic-stack-blog-thumb.png

Elastic Stack 6.7.0 released

Golang 因为其语法简单，上手快且方便部署被开发者所青睐。今天在这里就给大家介绍一下如果使用 Elastic Stack 来分析 Golang 程序的内存使用情况，方便对 Golang 程序做长期监控进而调优和诊断，甚至发现一些潜在的内存泄露等问题。
Elastic Stack 包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat。今天主要用到 Elasticsearch、Metricbeat 和 Kibana。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包才10M 左右，内存资源占用和 CPU 开销也较小，对目标服务器的部署环境也没有依赖。目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务：
<ul>
 <li>Apache Module</li>
 <li>Couchbase Module</li>
 <li>Docker Module</li>
 <li>HAProxy Module</li>
 <li>kafka Module</li>
 <li>MongoDB Module</li>
 <li>MySQL Module</li>
 <li>Nginx Module</li>
 <li>PostgreSQL Module</li>
 <li>Prometheus Module</li>
 <li>Redis Module</li>
 <li>System Module</li>
 <li>ZooKeeper Module</li>
</ul>
如果你的应用不在上述列表，其实Metricbeat 是可以扩展的。本文接下来所用的 Golang Module 就是为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布。想了解是如何扩展这个模块的可以查看 <a href="https://github.com/elastic/beats/tree/master/metricbeat/module/golang">代码路径</a> 和 <a href="https://github.com/elastic/beats/pull/3536">PR地址</a>。
现在我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析：
<img asset_uid="blt4e97dc508fe57d70" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4e97dc508fe57d70/5bbf10620e6edaf014d240f0/kibana-dashboard-golang.jpg" alt="kibana-dashboard-golang.jpg" height="auto" />
如上图所见，最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况。System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存而不是进程对应的虚拟内存；Bytes Allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存；GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个 limit 值会随着每次 GC 而变化；GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况。Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 就是活跃的对象大小；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计。CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费在 GC 上面的时间越多。上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以。如果GC 比率占到个位数甚至更多比例，那便需要进一步优化程序。
有了这些信息我们就能够知道该 Golang 的内存使用、分配和 GC 的执行情况。假如要分析是否有内存泄露，便要看内存使用和堆内存分配的趋势是否平稳。另外 GC limit 和 Byte Allocation 一直上升，那就是有内存泄露的问题，结合历史信息还能对不同版本／提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就是如何具体使用，首先需要启用 Golang 的 expvar 服务，expvar（<a href="https://golang.org/pkg/expvar/">https://golang.org/pkg/expvar/</a>） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。 使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上：<pre class="prettyprint">import _ "expvar"</pre>
如果 Golang 没有启动 http 服务，使用下面的方式启动一个即可，这里端口是 6060：<pre class="prettyprint">func metricsHandler(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Type", "application/json; charset=utf-8") first := true report := func(key string, value interface{}) { if !first { fmt.Fprintf(w, ",\n") } first = false if str, ok := value.(string); ok { fmt.Fprintf(w, "%q: %q", key, str) } else { fmt.Fprintf(w, "%q: %v", key, value) } } fmt.Fprintf(w, "{\n") expvar.Do(func(kv expvar.KeyValue) { report(kv.Key, kv.Value) }) fmt.Fprintf(w, "\n}\n") } func main() { mux := http.NewServeMux() mux.HandleFunc("/debug/vars", metricsHandler) endpoint := http.ListenAndServe("localhost:6060", mux) } </pre>
默认注册的访问路径是/debug/vars， 编译启动之后，就可以通过 <a href="http://localhost:6060/debug/vars">http://localhost:6060/debug/vars</a> 来访问 expvar。以 JSON 格式暴露出来的这些内部变量，默认提供了 Golang 的 runtime.Memstats 信息，也就是上面分析的数据源。
现在&nbsp;Golang 程序已经启动，并且通过 expvar 暴露出了运行时的内存使用情况，我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：<a href="https://www.elastic.co/downloads/beats/metricbeat">https://www.elastic.co/downloads/beats/metricbeat</a> ）。启动 Metricbeat 前，记住修改配置文件：metricbeat.yml<pre class="prettyprint">metricbeat.modules: - module: golang metricsets: ["heap"] enabled: true period: 10s hosts: ["localhost:6060"] heap.path: "/debug/vars" </pre>
上面的参数启用了 Golang 监控模块，并且会10秒获取一次配置路径的返回内存数据，我们同样配置该配置文件，设置数据输出到本机的 Elasticsearch：<pre class="prettyprint">output.elasticsearch: hosts: ["localhost:9200"] </pre>
现在启动 Metricbeat：<pre class="prettyprint">./metricbeat -e -v </pre>
在 Elasticsearch 里应该就有数据了，当然记得确保 Elasticsearch 和 Kibana 是可用状态。你可以在 Kibana 根据数据灵活自定义可视化，推荐使用 Timelion 来进行分析。当然也可以直接导入提供的样例仪表板，得出结果就是上面第一个图的效果。 关于如何导入样例仪表板请参照这个文档：<a href="https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-sample-dashboards.html">https://www.elastic.co/guide/e ... .html</a>
除了监控已经有的内存信息之外，如果你想要暴露一些内部的业务指标，通过 expvar 便可以。一个简单的例子：<pre class="prettyprint">var inerInt int64 = 1024 pubInt := expvar.NewInt("your_metric_key") pubInt.Set(inerInt) pubInt.Add(2) </pre>
在 Metricbeat 内部也可以暴露很多内部运行的信息，所以 Metricbeat 是自我监控。 首先，启动的时候带上参数设置&nbsp;pprof 监控的地址：<pre class="prettyprint">./metricbeat -httpprof="127.0.0.1:6060" -e -v </pre>
这样我们就能够通过 <a href="http://127.0.0.1:6060/debug/vars]http://127.0.0.1:6060/debug/vars">http://127.0.0.1:6060/debug/vars]http://127.0.0.1:6060/debug/vars</a> 访问到内部运行情况：<pre class="prettyprint">{ "output.events.acked": 1088, "output.write.bytes": 1027455, "output.write.errors": 0, "output.messages.dropped": 0, "output.elasticsearch.publishEvents.call.count": 24, "output.elasticsearch.read.bytes": 12215, "output.elasticsearch.read.errors": 0, "output.elasticsearch.write.bytes": 1027455, "output.elasticsearch.write.errors": 0, "output.elasticsearch.events.acked": 1088, "output.elasticsearch.events.not_acked": 0, "output.kafka.events.acked": 0, "output.kafka.events.not_acked": 0, "output.kafka.publishEvents.call.count": 0, "output.logstash.write.errors": 0, "output.logstash.write.bytes": 0, "output.logstash.events.acked": 0, "output.logstash.events.not_acked": 0, "output.logstash.publishEvents.call.count": 0, "output.logstash.read.bytes": 0, "output.logstash.read.errors": 0, "output.redis.events.acked": 0, "output.redis.events.not_acked": 0, "output.redis.read.bytes": 0, "output.redis.read.errors": 0, "output.redis.write.bytes": 0, "output.redis.write.errors": 0, "beat.memstats.memory_total": 155721720, "beat.memstats.memory_alloc": 3632728, "beat.memstats.gc_next": 6052800, "cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"], "fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}}, "libbeat.config.module.running": 0, "libbeat.config.module.starts": 0, "libbeat.config.module.stops": 0, "libbeat.config.reloads": 0, "memstats": {"Alloc":3637704,"TotalAlloc":155 ... ... </pre>
比如，上面就能看到 output&nbsp;模块&nbsp;Elasticsearch 的处理情况，如 output.elasticsearch.events.acked 参数表示发送到 Elasticsearch Ack&nbsp;返回之后的消息。
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型。我们需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改：<pre class="prettyprint">- module: golang metricsets: ["heap","expvar"] enabled: true period: 1s hosts: ["localhost:6060"] heap.path: "/debug/vars" expvar: namespace: "metricbeat" path: "/debug/vars" </pre>
上面的一个参数 namespace 表示自定义指标的一个命令空间，主要是为了方便管理。这里是 Metricbeat 自身的信息，所以 namespace 就是 metricbeat。
重启 Metricbeat 就能收到新的数据，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked 和&nbsp;output.elasticsearch.events.not_acked&nbsp;这两个指标，我们在&nbsp;Kibana 里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。 Timelion 表达式：<pre class="prettyprint">.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed") </pre>
效果：
<img asset_uid="blt4e97dc508fe57d70" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4e97dc508fe57d70/5bbf10620e6edaf014d240f0/kibana-dashboard-golang.jpg" alt="kibana-dashboard-golang.jpg" height="auto" />
从上图可以看到，发往 Elasticsearch 的消息很稳定。同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看：
<img asset_uid="bltbd45fb9460b34183" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltbd45fb9460b34183/5bbf106a0e6edaf014d240f6/graph-golang2.jpg" alt="graph-golang2.jpg" height="auto" />
上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。

banner-five-years-animals-pig-brain-machine.jpg

thumb-five-years-animals-pig-brain-machine.jpg

Tuning Go Apps with Metricbeat

使用 Elastic Stack 来监控和调优 Golang 应用程序

按需预测是 6.1 中最新推出的 X-Pack Machine Learning 功能。之前，Elastic Machine Learning 的设计目标是使用历史数据来预测“现在”的正常数值范围，并将其与我们实际看到的数据进行对比，进而实时识别异常情况。目前在 6.1 中，Machine Learning 可以完成数据建模，并预估未来多个时段的情况。
我们之所以将其称为“按需预测”，是因为借助 Machine Learning 中内置的预测模型，用户可以使用既有的 Machine Learning 作业来预测此模型在预测日期范围内的增长情况。预测结果会写到 Elasticsearch 索引中，从而允许用户将实际结果与预测模型进行对比。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6c5085b9c3625afc/5fa9a2efbfc5dd718865a9e8/blog-ml-on-demand-1.png" width="624" height="249" style="width: 624px; height: 249px;" />
<h3>借助 Machine Learning 和预测功能进行容量规划</h3>
我们之前也提到，既往表现并不能代表未来结果。但是，要想预测结果来进行容量规划，最佳方式就是使用既往表现指标。
您如何确定某一资源何时会达到容量限值呢？举例说明，如果您正在监测服务器磁盘空间，则您可能需要预测磁盘空间何时会用完。您可以使用 Elastic 的 Machine Learning 预测模型来预测未来情况，并确定何时需要向系统中添加存储。
您还可以通过容量规划来预测未来特定时刻某个度量指标的值。举例说明此种情况，您想预测贵公司周一下午会接到多少通客户来电。通过分析历史数据并使用复杂的 Machine Learning 模型，您便能获得所需信息来做出人员调配和资源配置决策。
<h3>开始使用预测功能</h3>
您可以从既有 Machine Learning 作业的单一指标查看器 (Single Metric Viewer) 中运行预测功能。系统升级到 6.1 之后，屏幕右上角将会新增一个选项按钮来让您运行预测作业。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc3fee563af5d45e4/5fa9a2f5faf76f509e12ea05/blog-ml-on-demand-2.gif" width="600" height="309" style="width: 600px; height: 309px;" />
Machine Learning 作业的预测结果会以深黄色的趋势线表示，置信度模型会以颜色较浅的黄条表示。如果浅黄区带较窄，则表示预测模型的置信度较高。如果预测模型的置信度降低，浅黄区带将会变宽。
<h3>创建预测模型时的注意事项</h3>
为了更好地理解结果，创建预测模型时，有几个细节需要考虑。预测结果可能与您的预期不相符，而且并非每个数据集都能得出预测结果。&nbsp;&nbsp;
我们建议您首先收集足量的历史数据，然后再尝试运行 Machine Learning 预测作业。历史数据量通常以大约 3 周或者 3 个完整的定期数据周期为宜。如果您在学习阶段过早地运行预测，由于这时模型尚未建立，显示的结果很可能根本不能用。
如果预测置信度水平超出合理范围，预测模型将会提前停止。&nbsp;预测作业将终止并显示一条消息（如下所示），告诉您置信度水平超出可接受范围。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb340ab200ea89b37/5fa9a2f54e40cf53001f510d/blog-ml-on-demand-3.png" width="624" height="60" style="width: 624px; height: 60px;" />
如果模型绘图为“打开”状态，预测结果将会容易理解得多。这是一个可选项，对单指标作业而言，此项默认为打开。对多指标作业而言，可以通过下列方法打开模型绘图选项：<a href="/guide/en/elasticsearch/reference/current/ml-job-resource.html#ml-apimodelplotconfig">在 Machine Learning 作业配置中对 “model-plot-config” 选项</a>进行配置。
为了帮助在单一指标查看器之外跟踪任何具体预测结果，每个预测结果都有一个唯一 ID（称为 forecast_ID），这样的话，用户便可单独查询每个搜索结果。虽然可以针对同一指标进行多次预测，但对任何单一指标而言，UI 仅会显示最近运行的五个预测结果。尽管这样，所有预测结果仍可使用，也会占用相应的索引空间。如果您从 UI 运行的话，预测结果会在 14 天后自动删除，而如果您直接使用 API，则可以指定数据过期日期。有关详情，请查看<a href="/guide/en/elasticsearch/reference/current/ml-forecast.html#_request_parameters_3">预测文档</a>。
Machine Learning 是 Elastic 白金级订阅服务中的功能，但是您可以下载免费试用版 <a href="/cn/downloads/x-pack">X-Pack 并亲自尝试一下</a>。

machine-learning-forecasting-v2.jpg

What's New in 6.1.0 Machine Learning (4).png

On-demand forecasting with machine learning in Elasticsearch

在 Elasticsearch 中使用 Machine Learning 实现按需预测

这篇文章总结了在 <a href="/cn/elasticon/conf/2018/sf">Elastic {ON} 2018</a> 上的用户发言。想了解到更多这样的讲座吗？查看会议档案或了解 <a href="/cn/elasticon">Elastic {ON} Tour</a> 何时会到您附近的城市举办。
<a href="https://ottomotors.com/">OTTO Motors</a> 是 <a href="https://www.clearpathrobotics.com/">Clearpath Robotics</a> 旗下的一家公司，主要设计、制造和操作自动驾驶工业车辆。他们的目标是使用机器人技术来淘汰人为操作。他们的移动机器人队在 40 多个国家/地区运行，可帮助公司实现作业自动化，包括一些对人类有危险的作业。
操作如此多的机器人需要一个能够快速识别问题、提高开发速度、以成本价实现解决方案工业化以及能轻松连接物联网技术的管理系统。OTTO Motors 还高度依赖智能路径规划，这需要对大量的数据点进行实时处理，才能让单个机器人和机器人队知道如何从 A 点前往 B 点。
OTTO Motors 需要一个完整的堆栈解决方案，该解决方案可以在不花费巨大费用或不需要构建新技术的情况下进行测试，并且可以很容易地接入公司内部已经在使用的现有软件。在寻找符合所有这些标准的解决方案时，OTTO Motors 团队对形形色色的物联网解决方案进行了调查。OTTO Motors 的前基础架构经理 Greg Jacobs 说：“我们想要一种能快速投入使用的解决方案。调查发现，Elastic 是我们最好的切入点。 ”
最终，OTTO Motors 的团队选择了 <a href="/cn/products">Elastic Stack</a>，原因有三个：
<ol>
 <li>Elastic 公司的产品有随时可用的 HTTP/JSON API。有了 Elastic Stack，我们可以很轻松地将数据输入服务，因为它与其他已经在使用的现有内部产品和服务配合得很好。此外，Elastic 提供了易于使用的客户端库和丰富的数据收集选项。</li>
 <li>只需要一台计算机用来安装和运行 Elastic Stack，开箱即用，并且是一个独立的系统，不需要建造其他任何东西就可以运行。从安装起，就很容易开始、探索、使用 Elastic Stack 接入东西、并随着 OTTO Motors 需求的增长而扩展。</li>
 <li>KIbana 是基于网络的，非常易于使用，并且集成良好，供各种最终用户/用例使用，这使得它在整个公司都很有用。</li>
</ol>
Greg Jacobs 再次强调：“[Elastic Stack] 是我们种下的种子。但是它不会变成一个有围墙的花园。它将与所有其他东西一起运作。”
为此，OTTO Motors 在将 Elastic Stack 用于物联网应用之外还部署它来帮助软件开发质量保证、信息技术安全以及为探索性报告构建仪表板。例如，OTTO Motors 测试机器人的自动化系统制作虚拟码头集装箱来创建激光雷达数据，然后机器人将这些数据读取为真实障碍物。Elastic 还允许 OTTO Motors 执行机器人可以瞬间完成的高速模拟。这使得 OTTO Motors 能够以比正常速度快数百倍甚至数千倍的速度运行机器人队管理软件，同时使用 Elastic 公司提供的 <a href="/cn/products/beats/metricbeat">Metricbeat</a> 和其他工具来测试系统内的问题。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltee4a974b8d3accea/5f9b2254432f517518d40b71/blog-otto-motors.png" data-sys-asset-uid="bltee4a974b8d3accea" alt="blog-otto-motors.png" />
运行一大群机器人会产生大量的数据，这些数据被输入到 Elastic 数据库。OTTO Motors 机器人收集的数据量是惊人的：机器人队中每个机器人每 10 秒钟有 5000 多个数据点。这包括中央处理器时间、无线信号、电机温度、导航细节等。他们使用 Elastic 将所有数据汇总到 30 分钟的报告窗口中。 
OTTO Motors 还使用 Elastic 的监测功能来创建定制仪表板，以发现隐藏的趋势，查看哪些指数受到最大冲击，并了解哪些受到用户的欢迎。
OTTO Motors 案例的核心是针对整个堆栈的需求和对应的解决方案。想了解 OTTO Motors 如何使用 Elastic Stack 使他们的机器人在全球范围内工作得更好吗？观看来自 <a href="/cn/elasticon/conf/2018/sf">Elastic {ON} 2018</a> 的<a href="/cn/elasticon/conf/2018/sf/the-quick-starter-stack-for-robotics-iot-and-big-data">机器人、物联网和大数据快速入门系列</a>。在该座谈会中，您将详细了解到 Elastic Stack 是如何实现维护和发展智能自动驾驶机器人队伍成。
<a href="/cn/elasticon/conf/2018/sf/the-quick-starter-stack-for-robotics-iot-and-big-data"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt649d393fa3c4fcfe/5c57df9352256ff20b4afaf7/Screen_Shot_2018-08-22_at_1.28.13_PM.png" data-sys-asset-uid="blt649d393fa3c4fcfe" alt="OttoMotors" style="display: block;margin: auto;" /></a>

Otto Motors Robot.jpg

Otto Lifting Boxes.jpg

OTTO Motors: Using the Elastic Stack to Expand the IoT Landscape

OTTO Motors：利用 Elastic Stack 拓展物联网使用场景

Elastic 通过协作来完成各项工作。
我们的工程师 24 小时不停地工作（确实如此，因为我们是一家 <a href="/cn/about/our-source-code">分布式公司</a>）来开发新产品和功能。这是一项巨大的工作，需要仔细关注细节。但是不管我们有多小心，我们都无法做到完美，对于任何像我们这样复杂的开源项目，我们仍然需要社区的帮助来使它变得更好。
在<a href="/cn/blog/solving-the-small-but-important-issues-with-fix-it-fridays">使用 Fix-It Friday 解决小但重要的问题</a>中，我们讨论了社区的贡献如何推动我们不断成功开发产品。作为一个开源项目的一大好处是，我们有一个庞大的开发者社区，他们会寻找漏洞，并急切地等找到堵住漏洞的机会。
如果您是社区的新成员，并且是第一次提交您的 Pull Request (PR)，或者对这个过程的工作方式有疑问，那么您来对了地方！在这篇文章中，我们将概述 pull request 是如何帮助 Elastic 运作的，我们收到 pull request 时如何进行处理，以及如何避免可能妨碍您的建议得到采纳的常见错误。
<h2>那么，我如何提交 Pull Request？</h2>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt20df7811154eb06b/5fa98bde42256d5ffdf418b1/blog-how-we-pull-1.png" style="border: none;transform: rotate(0.00rad);webkit-transform: rotate(0.00rad);" width="624" height="275"/>
提交 PR 之前，您需要在 GITHUB 存储库中创建一个分叉，并对代码进行更改。这通常是在您自己的 GitHub 帐户下完成的，它会为您创建一个源存储库的副本。我们所有的项目都存在它们自己的 GitHub 存储库中。GitHub上的 <a href="https://github.com/elastic">Elastic 组织页面</a>上提供了我们存储库的完整列表。&nbsp;
一旦创建了存储库的分支并更改了代码，系统会询问您是否要创建 PR，并将建议的更改推送到产品存储库的主分支。例如，<a href="https://github.com/elastic/elasticsearch">Elasticsearch 存储库</a>，如下所示。为了简单起见，我们将在这篇文章中展示 Elasticsearch 存储库中的例子。 
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt236f36ccc109c964/5fa98bd64a4abb73ff79c618/blog-how-we-pull-2.png" style="border: none;transform: rotate(0.00rad);webkit-transform: rotate(0.00rad);" width="624" height="336"/>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc7e6969602ebde49/5fa98bde6f82405d9a4aa965/blog-how-we-pull-3.png" style="border: none;transform: rotate(0.00rad);webkit-transform: rotate(0.00rad);" width="624" height="84"/>
当您点击“New pull request”（新建 pull request）时，您会首先看到我们的 <a href="https://github.com/elastic/elasticsearch/blob/master/.github/PULL_REQUEST_TEMPLATE.md">pull request 模板</a>。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7f6935bae5ef3748/5fa98bd646f622769b5ec879/blog-how-we-pull-4.png" style="border: none;transform: rotate(0.00rad);webkit-transform: rotate(0.00rad);" width="624" height="247"/>
这个模板将为您提供指导，帮助您的 PR 通过第一次审查，所以一定要通读，因为每个产品都有自己的标准和文档。模板会给您指导，帮助您的 PR 通过第一次审查。
提交时确保避免这些常见错误：
<ul>
 <li>提交重复项 - 首先，根据您的代码要修复的错误，搜索有没有打开的 PR 已经在解决这个问题。副本通常被拒绝。</li>
 <li>不包括测试 - 包含代码更改的 PR 应包括说明新代码行为的测试。理想情况下，这个测试应该重现 PR 正在修复的问题，这样测试在没有代码的情况下会失败，而在应用代码时通过。</li>
 <li>仅主分支 - 确保任何更改代码的 PR 均针对相关目录中的主分支提出。</li>
</ul>
完成模板中列出的所有要求后，单击“创建 Pull Request”。现在一切准备就绪了。
<h2>分门别类和添加标签</h2>
我们的第一步是确保 PR 符合一个好请求的标准（如上所述），如果符合，就给 PR 贴上标签，这样会有合适的审核者来查看，以便进一步评估。标签可能包括 &gt;bug、&gt;功能等等。一旦 Pull Request 有了标签，它就会被分配给适当的子团队来处理。在这之后，处理请求是负责该领域的团队进行。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3cb04a52dd873501/5fa98bde65bdd35303e00a60/blog-how-we-pull-5.png" style="border: none;transform: rotate(0.00rad);webkit-transform: rotate(0.00rad);" width="624" height="409"/>
<h2>开始进程</h2>
一旦 PR 被贴上标签，它就会被我们的一个开发者领取。我们会尽快回复请求者，不过我们请您在提交 PR 时有耐心，因为由于请求的级别和深度各不相同，正确处理请求可能需要一些时间。&nbsp;
<h2>提交文件变更</h2>
注意：我们还收到许多修改或请求修改我们文档的 PR。这个过程比代码更改简单得多 — 只需要在 Elastic 文档页面上点击“编辑”，进行更改，然后提交请求。不需要分叉项目，也不需要测试。我们用“&gt;doc”标记这些 PR，并尽快处理。
<h2>通常，我们有更多的工作要做</h2>
PR 通常需要在准备合并之前进行调整。此时，PR 变成了一个协作空间，社区成员在这里进行讨论，提出改变，并做出更多改进。
在审查过程中，我们对会 PR 进行测试，测试结果可以在 GitHub 上看到。有时，即使提交的测试有效，当应用 PR 中的更改时，测试也可能会失败。不过，这并不是最后的结果。我们将帮助贡献者修复贡献的代码，以便所有测试都通过。
代码风格以及代码和命名约定，也是我们在这个阶段关注的问题。提交 Pull Request 的用户应该注意：他们的代码会至少经过一轮审查。代码从来都不是完美的（甚至我们的代码都不完美！）并在提交时准备用于合并 — 因此，在此过程中可能需要您的合作。
<h2>我的 PR 需要多长时间才能被纳入？</h2>
每个 PR 的处理时间有所不同。一行简单的代码可能会被快速处理，但是复杂的代码更改会经过多轮审查。如果您觉得您的 PR 已经提交了很长时间但是没有任何动静，可以开一张支持请求来提醒我们此 PR 仍处于活跃状态。
<h2>纳入代码</h2>
当一切准备就绪时，评审者会在批准操作中添加一条评论 — 可能是 LGTM（“我觉得不错”）评论，或者类似的内容。PR 被接受后，Elastic 开发人员会将 pull request 合并到主分支中，然后根据需要将更改返回到开发分支。
简而言之，这就是它的工作原理。当然，Pull Request 各不相同。这个过程可能非常简单，也可能很困难。您深入了解这一过程的唯一方法是卷起袖子亲自操作。
准备好提交您的第一份 PR 报告了吗？浏览 <a href="https://github.com/elastic">GitHub上提供的 Elastic 存储库</a>，熟悉这些指南，并尝试一下。如果您对这个过程有任何进一步的疑问，那么就去我们的<a href="https://discuss.elastic.co/">讨论论坛</a>，并创建一个主题，我们会很乐意提供帮助。

Debug.jpg

Code request.jpg

How We Handle Pull Requests at Elastic

我们如何处理 Elastic Pull Request

Elastic Cloud

Data ingestion

Enterprise search

Elasticsearch from the Bottom Up, Part 1

自下而上认识 Elasticsearch：第 1 部分

从问世伊始，Elastic (ELK) Stack（包括 Elasticsearch、Logstash、Beats 和 Kibana）就一直以免费和开放为理念。

从问世伊始，Elastic Stack（包括 Elasticsearch、Logstash、Beats 和 Kibana）就一直秉持免费和开放的理念。我们不仅免费提供自己的技术堆栈，还面向公众开放，这包括将它存储在公共仓库中，让社区直接参与，以透明的方式进行开发。免费和开放这两条简单的原则打破了壁垒，创造了无限可能。<h3>充满活力的社区</h3>将独具魅力的技术与免费散布和开放开发结合，就能造就一个充满活力的社区。免费降低了采用门槛，开放式开发则促成了协作、贡献和创新。任何人都可以下载 Elastic Stack 并轻松入门使用。它可以在笔记本上运行，协助开发搜索支持的新应用程序，或安装在数据中心，监测基础设施并应对安全威胁。用户可以查看（并贡献）代码，直接向我们的工程团队提供反馈、提出问题或发送请求，与社区内的同行互相交流。Elastic Stack 是提升实力的利器。<h3>更优质的产品，更新的方向。</h3>坚持免费和开放原则，再结合富于创造、热情洋溢和积极参与的社区，不仅可以让产品越来越完善，还能借着社区为产品发展开创有趣的新方向。 社区是我们灵感的不竭源泉，提供了诸多推动我们前进的杰出创意。在 Elasticsearch 创立初期，正是富于创造的社区推动了 Logstash、Kibana 和 Beats 的诞生。 后来，Elasticsearch、Logstash 和 Kibana 整合成为 ELK Stack（现在的 Elastic Stack），并埋下新用例（日志）的种子。 现在，我们又拥有了专属的可观测性解决方案。 随后，安全从业人员注意到 ELK Stack，并开始用它进行安全分析，成就了现在免费和开放的 SIEM。 这些年来，这种趋势一直在社区创建和启发的功能、扩展、插件和用例中延续。<h3>免费和开放流淌在我们的基因中</h3>免费和开放原则深深印刻在我们的自我定义和发展模式中。我们希望产品可以不断提升，应用于学习，并规模化运行于生产环境中。 所以诸多核心功能、产品和解决方案都免费提供。 例如：技术堆栈中原生开发的<a href="/cn/what-is/elastic-stack-security">免费安全功能</a>。对于确保每个集群得到保护，这已是至关重要的工具。但我们更进一步的，将 Kibana 基于角色的访问控制和真正的多租户功能也全部免费开放。我们相信在开放环境中开发的产品更加安全。<a href="/cn/what-is/kibana-lens">Kibana Lens</a>：它是我们在 Elastic Stack 7.5 版本中加入的测试版功能，可以让 Elasticsearch 中存储的数据更加容易实现可视化。它汇集了多年来社区中关于 Kibana 存储库的反馈，是这些智慧的结晶。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0ea7bdf603fb6318/5f8a0bb4f6c586323f8b3d9b/blog-elastic-free-open-1.gif" width="617" height="350" style="width: 617px; height: 350px;"/><a href="/cn/maps">Elastic Maps</a>：它正式发布于 Elastic Stack 版本 7.3，为可视化浏览存储在 Elasticsearch 中的位置数据开辟了新的方式。它的问世与 Elasticsearch 中进行的大量地理相关工作密不可分。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdf19428aa0eeba13/5f8a0c10dcf0e74b7cbf6f1d/blog-elastic-free-open-2.gif" width="625.1259259259259" height="352" style="width: 625.1259259259259px; height: 352px;"/><a href="/cn/what-is/kibana-canvas">Canvas</a>：它正式发布于版本 6.5，让您可以将 Elasticsearch 数据转化为具有动态展示风格的仪表板，打造您专属的数据呈现模式。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd3bcb6c0c16af459/5c3047b6e71ce40c6e4ad94b/airport4-upd.gif"/> 我们甚至还将这种开放的理念应用于研发一站式解决方案，帮助客户解决关键难题。 这些解决方案中都有在开放环境中开发的组件，所有人都可以免费使用。<ul><li><a href="/cn/enterprise-search">Elastic 企业搜索</a>与免费和开放的开发者工具相辅相成，提供强大和现代化的搜索体验。</li><li><a href="/cn/observability">Elastic 可观测性</a>将我们免费和开放的日志监测、指标、APM 以及运行状态监测产品整合成一个强大的解决方案。</li><li><a href="/cn/security">Elastic 安全</a>将免费的 SIEM 与开放的社区、开放路线图和开放的数据模型相结合。</li></ul>这只是一小部分示例。还有更多等待您探索。<h3>即刻体验</h3>所有人都可以快速、无障碍实现 Elastic Stack 入门。 有多种方式可以帮您迈出使用 Elastic Stack 的第一步。<ul><li>用三分钟在<a href="https://www.elastic.co/cn/cloud/elasticsearch-service/signup"> Elastic Cloud 中注册申请免费试用</a>，也就是说，要拥有属于自己的 Elastic Stack，煮一杯咖啡的时间绰绰有余。</li><li>想要在本地进行测试？没事儿！您随时都可以<a href="https://www.elastic.co/cn/start">下载最新的版本，并自行运行</a>。</li><li>希望了解 Elastic Stack 的使用效果，以及全球各地的企业如何使用 Elastic 产品和解决方案应对极具挑战的业务和技术问题？请访问<a href="https://www.elastic.co/cn/videos/">包含使用指导网络研讨会和客户案例研究视频的视频库</a>。</li></ul>我们相信，最好的产品产生于开放的环境，也离不开与充满热情、激励创新的研发人员和用户紧密协作。所以，我们需要您的加入！<a href="http://discuss.elastic.co">立即加入我们的论坛</a>，直接与我们的工程师交流，或者查看我们<a href="https://github.com/elastic/elasticsearch">公共</a> <a href="https://github.com/elastic/kibana">GitHub</a> <a href="https://github.com/elastic/beats">仓库</a>中的新成果和新资讯。对于我们来说，贡献这件事不仅包括写代码，还包括提供新的想法，向他人展示可能性，创造一个所有人都可以学习和成长的社区。

Elastic Stack：免费。开放，成就无限可能。开源，再次启航。

Elastic Stack：免费。开放，成就无限可能。开源，再次启航。

elastic-apm-distributed-tracing-large.jpg

Real user monitoring

Observability

elastic-apm-distributed-tracing-small.png

A Sip of Elastic RUM (Real User Monitoring)

Elastic RUM（真实用户监测）浅谈

宣布推出 Elastic App Search 网络爬虫公测版发布，这是一款简单而又功能强大的程序，可采集公开发布的网络内容，这样您就能够迅速从您的网站上搜索这些内容。

我们非常高兴地宣布在 Elastic Enterprise Search 7.11 中发布 Elastic App Search 网络爬虫公测版，这是一款简单而又功能强大的程序，可采集公开发布的网络内容，让您能够迅速从您的网站上搜索这些内容。
让网站上的内容可搜索有多种方法。<a href="/cn/app-search/">Elastic App Search</a> 已经允许用户通过上传或粘贴 JSON 以及通过 API 终端来采集内容。此版本引入的公测版网络爬虫为用户提供了另一种采集内容的快捷方法。
<div class="video embed-container shadow m-b-40" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/fAt7DBU5BEVoycw7Zd5Uew.jpg" data-uuid="fAt7DBU5BEVoycw7Zd5Uew" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" style="width: 100%;margin: auto;display: block;" width="100%" /></div>
此网络爬虫在自管型部署和 Elastic Cloud 部署可用，能从公共网站中检索信息，让您可从 App Search 引擎中搜索这些内容。App Search 会在后台为您完成大量的复杂工作，为可搜索的内容建立相关性，让您通过滑块就能轻松进行调整，而无需使用代码。&nbsp;
现在，我们来深入了解将此网络爬虫引入 App Search 的原因。
<h2>此款网络爬虫有何不同？&nbsp;</h2>
简而言之：焦点在于 Elastic Cloud。&nbsp;
如果这些年您关注着 Elastic Enterprise Search（我们爱我们的粉丝团），您会记得 <a href="/cn/site-search/">Elastic Site Search</a> 推出过（现在仍提供）此网络爬虫。不过，广受欢迎的 <a href="/cn/cloud/">Elastic Cloud</a> 只支持 Elastic App Search 和 Workplace Search 。&nbsp;
您可能会问，“对，然后呢？”&nbsp;
我们对网络爬虫进行了完全的重新设计和构造，将它迁移到 Elastic Cloud 上的 App Search 具有多个引人注目的好处：
<ul>
 <li>省心省力，优势众多：作为 Elasticsearch 和 Kibana 的托管服务，Elastic Cloud 在运行速度、扩展性和相关性方面表现出色，这些是 Elastic 的独特优势。可一键升级、轻松扩展以及支持索引生命周期管理 (ILM)，而这些只是客户青睐 Elastic Cloud 的部分原因。如果您已在使用 Elastic 可观测性或 Elastic 安全，则可以通过一个功能强大的控制台管理整个部署。</li>
</ul>
<ul>
 <li>按需选择数据：Elastic Cloud 在<a href="/guide/en/cloud/current/ec-regions-templates-instances.html">全球 40 多个区域</a>得到全球主要云服务提供商的支持：Google Cloud (GCP)、Microsoft Azure 和 Amazon Web Services (AWS)。以个性化方式选择数据和云。</li>
</ul>
<ul>
 <li>定价：Elastic 采用按资源使用量定价的新型模式，您无需担心难以理解用户数、查询数、文档大小或部署的代理等晦涩指标。您只需考虑用于存储、搜索和分析数据的硬件资源成本即可，而不必考虑用例。</li>
</ul>
尽管本博文重点介绍云部署，但您也须了解，现在可通过自管型部署方式获取 App Search 网络爬虫，但此方法不适用于 <a href="/cn/site-search/">Elastic Site Search</a>（或 <a href="https://swiftype.com/">Swiftype</a>）。
<h2>这款网络爬虫具体爬取哪些内容？</h2>
在深入介绍如何设置此网络爬虫前，我们先了解该网络爬虫在指定公共网站上会爬取哪些内容。
当您提供 URL（如 https://www.elastic.co）时，此网络爬虫会访问相应网页。在相应的网页中，此网络爬虫会跟踪从中发现的每个新链接，并提取内容以将内容采集到 App Search 引擎。此过程称为内容发现。它会采用相似方式爬取发现的每个链接。下方的树形图从概括说明了此工作原理。
<img class="shadow" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd079d0afd366c587/6014796627b1080f84371f97/app-search-web-crawler-visual.png" data-sys-asset-uid="bltd079d0afd366c587" alt="App Search 网络爬虫 - 爬取由有链接关系的网页组成的“树”" style="display: block;margin: auto;" />
在上图中，此网络爬虫爬取了所有蓝色网页并为其编制了索引。不过，这些网页都未链接到粉色网页，因此此网络爬虫不会爬取后者，也不会为其编制索引。必须直接将非互连的网页作为入口点提供，或将其包含在站点地图中，这样此网络爬虫才能访问该网页。我们将在本博文的后续部分中介绍如何设置入口点。
<h3>提取的内容类型</h3>
此网络爬虫的公测版可以从 HTML 页面中提取以下内容：
<ul>
 <li aria-level="1">页面标题</li>
 <li aria-level="1">描述（元数据）</li>
 <li aria-level="1">关键字 (元数据)</li>
 <li aria-level="1">正文（进行标准化，并去除 html 标记）</li>
 <li aria-level="1">标准 URL</li>
 <li aria-level="1">其他 URL（针对同一个文档）</li>
 <li aria-level="1">链接</li>
</ul>
<h2>实际演练：开始使用此网络爬虫</h2>
<div class="video embed-container shadow m-b-40" style="height: 319.725px;"><img class="vidyard-player-embed shadow m-b-40" src="https://play.vidyard.com/QrcimKbjdV1hW4ogWqZNso.jpg" data-uuid="QrcimKbjdV1hW4ogWqZNso" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-hidden_controls="1" data-muted="0" muted="0" style="width: 100%;margin: auto;display: block;" width="100%" /></div>
我们将从头开始，在 Elastic Cloud 上创建一个新的 Elastic Enterprise Search 部署。如果是 Elastic <a href="/cn/site-search/">Site Search</a> 现有客户、<a href="https://swiftype.com/">Swiftype 客户</a>或 Elastic Cloud 新客户，请务必报名参加 <a href="https://cloud.elastic.co/registration">14 天的免费试用活动</a>，以便体验此款网络爬虫的奥妙。
<ul>
 <li>在 <a>www.elastic.co</a> 网页的右上角，选择“登录”。</li>
 <li>系统会提供几种单点登录方式。您也可以创建一个新帐户。</li>
 <li>登录后，选择“创建部署”。</li>
 <li>选择 Elastic Enterprise Search 部署模板。此模板在 CPU 输出、存储和可用性区域方面进行了优化。创建部署后，可根据特定需求调整每个部署模板。</li>
 <li>从列表中选择云提供商。现提供三种方案供您选择：Google Cloud (GCP)、Microsoft Azure 或 Amazon Web Services (AWS)</li>
 <li>为部署命名，然后单击“创建部署”。</li>
 <li>您将看到一个通知屏幕，其中显示您已创建部署。&nbsp;</li>
</ul>
<div class="video embed-container shadow m-b-40" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/icLyWEvS9Exoj3L6979Bs5.jpg" data-uuid="icLyWEvS9Exoj3L6979Bs5" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-hidden_controls="1" data-muted="0" muted="0" style="width: 100%;margin: auto;display: block;" width="100%" /></div>
恭喜！您已在创建您的第一个 App Search 引擎。
Elastic Enterprise Search 解决方案包括两种应用程序：App Search 和 <a href="/cn/workplace-search">Workplace Search</a>。在本教程中，要选择“启动 App Search”按钮。
<img class="shadow" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt56aa9339ce722187/6014773d0069f70f777217d1/enterprise-search-overview.jpg" data-sys-asset-uid="blt56aa9339ce722187" alt="Elastic Enterprise Search 新部署的欢迎屏幕" style="display: block;margin: auto;" />
非常棒！现在您已打开 App Search，可继续创建网络爬虫。
您可通过入门流程创建您的首个搜索引擎。只需为您的引擎命名（可使用“我的搜索引擎”之类的名称），然后您将看到一个屏幕，其中提供了四种采集数据的方法：粘贴 JSON、上传 JSON 文件、通过 API 编制索引或使用此网络爬虫。现在您知道要选择哪种方法了。
此时，您可以选择添加自己的网站作为要爬取的域名 URL，也可选择 Elastic.co 来增加乐趣。记住，您在其中提供了要提取的内容的 URL 时，此网络爬虫才会访问指定的网页。它会从该网页中跟踪所发现的网页中的每个新链接，直到此网络爬虫无法继续访问。
<div class="video embed-container shadow m-b-40" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/PG5SqAVwVCrnXp8EYnGbdR.jpg" data-uuid="PG5SqAVwVCrnXp8EYnGbdR" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-hidden_controls="1" data-muted="0" muted="0" style="width: 100%;margin: auto;display: block;" width="100%" /></div>
这时 Entry Points 功能会派上用场。如果有一个独立的页面未与其他页面链接，只需将其完整 URL 添加为入口点。此网络爬虫将从入口点开始为相应内容编制索引，并继续查找新链接以提取其中的内容，直至它无法继续访问为止。
您可以从同一个控制台页面创建爬取规则。借助这些规则，管理员可将其 URL 匹配规则的网页包括在内或排除在外。例如，您的营销部门可能使用带有路径模式 /lp 标识的营销活动登陆页。这些登陆页非常适合通过目标内容发展新业务，但可能不是您希望搜索引擎包含的内容类型。&nbsp;
可在爬网规则部分添加新策略，从而不允许为包含 /lp 的任何 URL 中的内容编制索引。&nbsp;&nbsp;
激动人心的时刻到了！现在可爬取内容了。添加所有入口点并创建所有爬取规则后，选择开始爬取按钮。&nbsp;
<div class="video embed-container shadow m-b-40" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/SfGPHLPLVed2aUpBiurqiy.jpg" data-uuid="SfGPHLPLVed2aUpBiurqiy" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-hidden_controls="1" data-muted="0" muted="0" style="width: 100%;margin: auto;display: block;" width="100%" /></div>
单击“文档”选项卡，观察将内容采集到 App Search 引擎的过程。也可以单击屏幕右上方的“查询测试器”图标，这样就可从 App Search UI 中的任意位置开始搜索引擎。
如果想要立刻在搜索框中检测结果，可选择“Reference&nbsp;UI”选项卡。其中提供了基于 React 的搜索框，即点即用。不过，最好还是使用 Elastic <a href="/cn/enterprise-search/search-ui">Search UI</a> JavaScript 库生成自己的搜索体验，并进行个性化设置。
<h2>现在轮到您动手了</h2>
我们相信，您会喜欢这款简单而又功能强大的网络爬虫设计。因此接下来轮到您亲自体验了！
目前 Elastic App Cloud 网络爬虫提供公测版，您可通过所有<a href="/cn/pricing/">订阅级别</a>获取它，并且自管型部署和 Elastic Cloud 部署均提供此版本。现有 Elastic Cloud 客户能够直接从 <a href="https://cloud.elastic.co/">Elastic Cloud 控制台</a>访问 Enterprise Search。&nbsp;
刚接触 Elastic Cloud？请查看<a href="/cn/training/free#quick-starts">快速入门指南</a> — 您可以通过这些培训短视频快速入门，然后开始<a href="https://cloud.elastic.co/registration">免费试用 Elastic Enterprise Search 14 天</a>。也可以免费<a href="/cn/downloads/enterprise-search">下载</a> App Search 和 Workplace Search 的自管型版本。
<h2>资源：</h2>
博文：<a href="/cn/blog/whats-new-elastic-enterprise-search-7-11-0-web-crawler-box-content-source">Elastic Enterprise Search 新功能：网络爬虫以及将 Box 作为内容源</a>
文档：<a href="/guide/en/app-search/7.11/web-crawler.html">App Search 网络爬虫</a>
开始使用：<a href="/cn/enterprise-search">Elastic Cloud：开始免费试用 14 天</a>

blog-banner-app-search-web-crawler.png

Elasticsearch

Search applications

Search UI

Search analytics

Visualization

Semantic search

Cloud search

Real-time analysis

blog-thumbnail-app-search-web-crawler.jpg

Introducing the Elastic App Search web crawler

Elastic App Search 网络爬虫简介

我们之前曾宣布对 Elasticsearch 和 Kibana 的许可协议进行变更，将把根据 Apache 2.0 许可授权的源代码变更为采用 Elastic 许可 + SSPL 的双重授权许可模式。当时，我们还<a href="/cn/blog/license-change-clarification">提到</a>将与社区密切合作，开发出一个让授权更加简单且宽松的 Elastic 许可版本。我很高兴与大家分享我们取得的成果。 Elastic 许可已经被广泛使用。目前，超过 90% 的软件下载使用的都是 Elastic 许可，这些用户享受到了免费开源的基础级服务<a href="/cn/subscriptions">提供的巨大附加价值</a>。正是因为这种价值，我们绝大多数的用户和社区成员都已经在基于 Elastic 许可使用软件了，所以他们认为最近的这次许可变更对自己并没什么影响。我们很高兴看到这一点，因为我们的初衷就是尽量减少对社区的任何影响。 我们借此机会与社区合作，找到进一步简化 Elastic 许可的方法。在与一些主动要求进行澄清的用户交谈后，我们相信这个新版本的许可将有助于极大消除您的大部分顾虑，同时避免我们的产品<a href="https://twitter.com/kimchy/status/1351534442993446917">遭到滥用并减少用户的误传和混淆</a>。<h2>Elastic 许可 v2</h2><a href="/cn/licensing/elastic-license">Elastic 许可 v2 (ELv2)</a> 是一个非常简单的非 Copyleft 许可，它授权被许可人“使用、复制、分发和提供软件，以及制作软件的衍生作品”，并且只有三个总体性限制。您不得：<ol><li>将产品作为托管服务提供给其他人&nbsp;</li><li>规避许可密钥功能或移除/隐藏受许可密钥保护的功能&nbsp;</li><li>移除或隐藏任何许可协议、版权或其他声明</li></ol>ELv2 适用于所有版本的 Elasticsearch 和 Kibana，包括分发版以及所有免费和付费功能的源代码。 我们本着开放的精神共享免费和付费功能的源代码。但遗憾的是，我们的<a href="/cn/blog/dear-search-guard-users-including-amazon-elasticsearch-service-open-distro-and-others">版权</a>和<a href="https://twitter.com/kimchy/status/1351534442993446917">商标</a>却一再遭到滥用。对于此次更新的许可，我们的目标是在尽可能宽松的情况下提供最基本的保护。我希望这些保护措施可以得到理解。请<a href="/cn/licensing/elastic-license/faq">查看我们的常见问答</a>，以进一步了解有关 ELv2 的信息。我们创建 ELv2 就是希望它能够为人所用。这是我们在 2015 年就期望推出的许可，当时我们还是一家面临<a href="https://twitter.com/kimchy/status/1351534442993446917">误传</a>问题的小公司。它吸收了我们的经验以及从其他做出类似变更的公司（<a href="https://www.mongodb.com/blog/post/mongodb-now-released-under-the-server-side-public-license">MongoDB</a>、<a href="https://www.cockroachlabs.com/docs/v24.2/licensing-faqs.html" target="_self">CockroachDB</a>、<a href="https://redislabs.com/blog/redis-labs-modules-license-changes/">RedisLabs</a>、<a href="https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/">TimescaleDB</a>、<a href="https://www.graylog.org/post/graylog-v4-0-licensing-sspl">Graylog</a> 等）身上学到的所有经验教训。希望我们这样做能够给大家一点帮助。很多公司都面临着类似的决定。我希望随着时间的推移，我们这些有着相似目标的公司能够凝聚起来，共同削减许可数量，并希望 ELv2 成为这方面的催化剂。 本着这种精神，我们与 <a href="https://heathermeeker.com/about-me/">Heather Meeker</a> 合作开发了 ELv2。Heather Meeker 是一位律师，曾因帮助起草包括 Mozilla Public License 2.0 在内的许多 OSS 许可而闻名，她还帮助许多组织构建了有着类似精神的许可，如 <a href="https://www.confluent.io/confluent-community-license/">Confluent Community License</a>、<a href="https://www.mongodb.com/licensing/server-side-public-license/faq">SSPL</a> 等等。我们也在积极参与 <a href="https://polyformproject.org/">Polyform Project</a> 和 <a href="https://faircode.io">Fair-code</a> 等计划，以进一步提高公众对该许可的认识，并寻找促进其更广泛使用的方法。&nbsp;<h2>用户仍然可以使用 SSPL 获取源代码</h2>我们添加了 <a href="https://www.mongodb.com/licensing/server-side-public-license">SSPL</a>（一个由 <a href="https://www.mongodb.com/blog/post/mongodb-now-released-under-the-server-side-public-license">MongoDB</a> 创建的 Copyleft 许可）作为一个选项，以尽量减少此次许可变更对用户的影响。MongoDB 是目前最受欢迎的项目之一，有数百万喜欢使用 SSPL 的开发人员在使用它。 自从我们宣布这一消息以来，有许多用户向我们表示，他们很感激我们提供了这一选项。他们的组织已经在使用 MongoDB 了，这使得我们的许可变更对他们来说没什么影响。 SSPL 是一种可获得源代码的许可选项，如下图所示：<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd65944c1b54a1e0b/6018987f29a02c49ba1f3e4a/chart-license-update-2021.jpg" class="img-fluid"/>需要明确的是，我们<a href="https://writing.kemitchell.com/2021/01/20/Righteous-Expedient-Wrong.html">仍然</a>没有声明 SSPL 或 Elastic 许可是受到了 OSI 批准的许可。<h2>对我们的云客户和本地部署客户仍然没有影响&nbsp;</h2>需要重申的是：此次变更对任何 Elastic Cloud 或自管型客户都没有影响。我们的客户已经在使用基于 Elastic 许可的默认分发版，他们的使用需要遵守其订阅协议条款，该协议继续授予他们访问附加功能、获得支持和兑现其他 Elastic 承诺（例如，知识产权侵权赔偿）的权限。<h2>未来发展之路</h2>这些变更，包括使 Elastic 许可更加宽松，都是为了帮助我们专注于打造出色的产品和投资于我们的社区。这意味着我们将开发出更多卓越的功能，其中的许多功能我们将免费提供，并将在开放的环境中开发。但我们的承诺不局限于代码。通过这些许可变更，让我们能够专注于重要的事情：让我们的产品助力您取得成功。

blog-banner-generic-elastic.png

Kibana

blog-thumb-generic-elastic-lockup.png

Introducing Elastic License v2, simplified and more permissive; SSPL remains an option

隆重推出授权更加简单且宽松的 Elastic 许可 v2；SSPL 仍可选择使用

<h2>背景介绍</h2>
当我们希望充分利用硬件时，经常会采用<a href="/cn/blog/hot-warm-architecture-in-elasticsearch-5-x">热温</a>架构。当我们有基于时间的数据时，如<a href="/cn/blog/observability-with-the-elastic-stack">日志、指标和 APM 数据</a>时，它特别有用。这类设置大多依赖于这样一个事实，即相应数据是只读的（采集后），索引可以基于时间（或大小）。因此可以根据我们期望的保留期轻松删除它们。在这个架构中，我们将 Elasticsearch 节点分为两种类型：“热”和“温”。
热节点保存最新数据，因而需要处理所有索引负载。由于最近的数据通常是最常被查询的，因此热节点是我们集群中最强大的节点：存储速度快、内存容量大、CPU 性能出色。但是，这种超高配置也意味着成本高昂，所以在热节点上存储不常查询的旧数据并不划算。
另一方面，温节点将以更具成本效益的方式专用于长期存储。温节点上的数据不像热节点上那样经常可能被查询，集群内的数据将根据我们的计划保留期从热节点移到温节点（通过<a href="/guide/en/elasticsearch/reference/6.6/shard-allocation-filtering.html">分片分配过滤</a>实现），同时仍然可供在线查询。
从 Elastic Stack 6.3 开始，我们一直在构建新功能，以增强热温架构并简化对基于时间的数据进行处理的过程。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte8ad3502d7fba4c1/5c98d0a5c9ab24634dcd6d86/hot-warm-features-frozen-indices-transp.png" data-sys-asset-uid="blte8ad3502d7fba4c1" alt="hot-warm-features-frozen-indices-transp.png" width="550" style="margin: auto;display: block;" />
<a href="/cn/blog/data-rollups-in-elasticsearch-you-know-for-saving-space">数据汇总</a>最先在 6.3 版中推出，用于节省存储空间。在时序数据中，我们需要获取最新数据的细粒度细节。但是我们不太可能对历史数据有同样的需求，因为我们通常将数据集视为一个整体。这样，汇总功能就应运而生了；从版本 6.5 开始，我们可以<a href="/cn/blog/how-to-create-manage-and-visualize-elasticsearch-rollup-data-in-kibana">在 Kibana 中创建、管理和可视化汇总数据</a>。
不久之后，我们添加了<a href="/guide/en/elasticsearch/reference/6.6/modules-snapshots.html#_source_only_repository">仅源快照</a>。这最大限度减少了快照数量，进而显著减少了所需的存储空间；其缺点在于，如果我们想要恢复数据和进行查询，就必须重新索引数据。这从 6.5 版开始就可以使用了。
在 6.6 版中，我们发布了两个强大的功能：索引生命周期管理 (ILM) 和冻结索引
<a href="/guide/en/elasticsearch/reference/6.6/index-lifecycle-management.html">ILM</a> 提供了随时间推移自动管理索引的方法。它简化了索引从热到热的移动，当索引太旧时允许删除，或者自动强制将索引合并到一个段。
在这篇博客的剩余部分，我们将讨论冻结指数。
<h2>为什么冻结指数？</h2>
“旧”数据最大的难点之一是，不管年龄多大，指数仍然有很大的内存足迹。即使我们把它们放在冷节点上，它们仍然使用堆。
一个可能的解决方案是关闭索引。如果我们关闭一个索引，它不需要内存，但是我们需要重新打开它来运行搜索。重新打开索引将导致操作成本，并且还需要在关闭之前使用的堆。
在每个节点上，内存（堆）与存储的比率将限制每个节点的可用存储量。对于内存密集型场景，它可能低至 1:8（内存:数据），对于要求较低的内存用例，它可能接近 1:100。
这就是冻结指数的来源。如果我们可以有仍然打开的索引——让它们保持可搜索性——但不占据堆会怎么样？我们可以向保存冻结索引的数据节点添加更多存储，打破 1:100 的比率，理解搜索可能会变慢的折衷。
当我们冻结一个索引时，它变成只读的，它的临时数据结构从内存中删除。反过来，当我们对冻结的索引运行查询时，我们必须将数据结构加载到内存中。搜索冻结的索引不一定要很慢。Lucene 很大程度上依赖于文件系统缓存，它可能有足够的容量将索引的大部分保留在内存中。在这种情况下，每个碎片的搜索速度相当。然而，冻结的索引仍然受到限制，使得每个节点同时只执行一个冻结的碎片。与未冻结的索引相比，这一方面可能会降低搜索速度。
<h2>冻结是如何工作的</h2>
冻结的索引通过专用的<a href="/guide/en/elasticsearch/reference/6.6/modules-threadpool.html#search-throttled">搜索节流</a>线程池进行搜索。默认情况下，这使用单个线程，以确保冻结的索引一次一个地加载到内存中。如果正在进行并发搜索，它们将进入队列以添加额外的保护措施，防止节点耗尽内存。
因此，在热-温架构中，我们现在能够将索引从热转换为温，然后能够在归档或删除之前冻结它们，从而降低硬件需求。
在冻结索引之前，为了降低基础架构成本，我们必须对数据进行快照和归档，这增加了巨大的运营成本。如果我们需要再次搜索，就必须恢复数据。现在，我们可以保持历史数据可供搜索，而不需要很大的内存占用。如果我们需要在已经冻结的索引上再次写入，我们可以<a href="/guide/en/elasticsearch/reference/6.6/unfreeze-index-api.html">解冻它</a>。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta19e364f7d3f763a/5c98d09ec9ab24634dcd6d80/index-states-transp.png" data-sys-asset-uid="blta19e364f7d3f763a" alt="index-states-transp.png" width="400" style="margin: auto;display: block;" />
<h2>如何冻结 Elasticsearch 索引</h2>
冻结索引易于在集群中实现，因此让我们开始学习如何使用<a href="/guide/en/elasticsearch/reference/6.6/freeze-index-api.html">冻结索引 API</a> 以及如何<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/sql-index-frozen.html">搜索冻结索引</a>。
首先，我们将从在测试索引上创建一些样本数据开始。<pre class="prettyprint">POST /sampledata/_doc { "name":"Jane", "lastname":"Doe" } POST /sampledata/_doc { "name":"John", "lastname":"Doe" } </pre>
然后检查我们的数据是否被摄入。这将返回两次点击：<pre class="prettyprint">GET /sampledata/_search </pre>
作为最佳实践，在冻结索引之前，建议首先运行 <a href="/guide/en/elasticsearch/reference/current/indices-forcemerge.html">force_merge</a>。这将确保每个碎片在磁盘上只有一个片段。它还将提供更好的压缩，并简化我们在对冻结索引运行聚合或排序搜索请求时所需的数据结构。在具有多个段的冻结索引上运行搜索可能会产生高达多个数量级的显著性能开销。<pre class="prettyprint">POST /sampledata/_forcemerge?max_num_segments=1 </pre>
下一步是通过取消冻结索引 API 端点来调用对我们的索引的冻结。<pre class="prettyprint">POST /sampledata/_freeze </pre>
<h2>搜索冻结索引</h2>
现在它被冻结了，你会发现常规搜索不起作用。其原因是，为了限制每个节点的内存消耗，冻结的索引被<a href="/guide/en/elasticsearch/reference/6.6/_searching_a_frozen_index.html">限制</a>。&nbsp;由于我们可能会错误地锁定冻结的索引，我们将通过向请求中添加 ignore_throttled=false 来防止意外减速。<pre class="prettyprint">GET /sampledata/_search?ignore_throttled=false { "query": { "match": { "name": "jane" } } } </pre>
现在，我们可以通过运行以下请求来检查新索引的状态：<pre class="prettyprint">GET _cat/indices/sampledata?v&amp;h=health,status,index,pri,rep,docs.count,store.size </pre>
这将返回与以下类似的结果，索引状态为“open”：<pre class="prettyprint">health status index pri rep docs.count store.size green open sampledata 5 1 2 17.8kb </pre>
如上所述，我们必须保护集群不会耗尽内存，因此我们可以在节点上同时加载用于搜索的冻结索引的数量是有限的。搜索受限线程池中的线程数默认为 1，默认队列为 100。这意味着如果我们运行一个以上的请求，它们将排队多达一百个。我们可以通过以下请求监控<a href="/guide/en/elasticsearch/reference/6.6/cat-thread-pool.html#cat-thread-pool">线程池状态</a>，以检查队列和拒绝：<pre class="prettyprint">GET _cat/thread_pool/search_throttled?v&amp;h=node_name,name,active,rejected,queue,completed&amp;s=node_name </pre>
它应该返回类似以下内容的响应：<pre class="prettyprint">node_name name active rejected queue completed instance-0000000000 search_throttled 0 0 0 25 instance-0000000001 search_throttled 0 0 0 22 instance-0000000002 search_throttled 0 0 0 0 </pre>
冻结的指数可能会慢一些，但可以用非常有效的方式进行预过滤。还建议将请求参数 pre_filter_shard_size 设置为1。<pre class="prettyprint">GET /sampledata/_search?ignore_throttled=false&amp;pre_filter_shard_size=1 { "query": { "match": { "name": "jane" } } } </pre>
这不会给查询增加很大的消耗，并且允许我们利用通常的场景。例如，当在时间序列索引上搜索日期范围时，并非所有碎片都匹配。
<h2>如何写入冻结的 Elasticsearch 索引</h2>
如果我们试图写一个已经冻结的索引会发生什么？让我们去寻找答案。<pre class="prettyprint">POST /sampledata/_doc { "name":"Janie", "lastname":"Doe" } </pre>
发生什么事了？冻结的索引是只读的，因此写入被阻止。我们可以在索引设置中检查这些：<pre class="prettyprint">GET /sampledata/_settings?flat_settings=true </pre>
将返回：<pre class="prettyprint">{ "sampledata" : { "settings" : { "index.blocks.write" : "true", "index.frozen" : "true", .... } } } </pre>
我们必须使用<a href="/guide/en/elasticsearch/reference/6.6/unfreeze-index-api.html">解冻索引 API</a>，调用索引上的解冻端点。<pre class="prettyprint">POST /sampledata/_unfreeze </pre>
现在我们将能够创建第三个文档并搜索它。<pre class="prettyprint">POST /sampledata/_doc { "name":"Janie", "lastname":"Doe" } GET /sampledata/_search { "query": { "match": { "name": "janie" } } } </pre>
解冻只能在特殊情况下进行。请记住，在再次冻结索引之前，一定要运行“force_merge”，以确保最佳性能。
<h2>在 Kibana 使用冻结指数</h2>
首先，我们需要加载一些样本数据，比如<a href="/guide/en/kibana/6.6/tutorial-sample-data.html">样本飞行数据</a>。
点击“Add”按钮获取样本飞行数据。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt142abc81bf2e4ac0/5c98d104632578d5055bb49f/kibana-load-data.png" alt="kibana-load-data.png" width="700" style="margin: auto;display: block;" data-sys-asset-uid="blt142abc81bf2e4ac0" />
现在，我们应该能够通过单击“View data”按钮来查看加载的数据。仪表板将与这个相似。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt70ea061b7b398da9/5c98d0ff026179ca592ee205/flight-dashboard.png" width="100%" data-sys-asset-uid="blt70ea061b7b398da9" alt="flight-dashboard.png" style="margin: auto;display: block;" />
现在我们可以测试冻结指数：<pre class="prettyprint">POST /kibana_sample_data_flights/_forcemerge?max_num_segments=1 POST /kibana_sample_data_flights/_freeze </pre>
如果我们回到仪表板，我们会注意到数据显然已经“disappeared”。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0a68db6e72e372e7/5c98d0f9acf2956c56cb1953/empty-flight-dashboard.png" data-sys-asset-uid="blt0a68db6e72e372e7" alt="empty-flight-dashboard.png" width="100%" style="margin: auto;display: block;" />
我们需要告诉 Kibana 允许搜索冻结的索引，默认情况下是禁用的。
转到 Kibana 管理，选择高级设置。在搜索部分，您会发现“Search in frozen indices”被禁用。切换以启用和保存更改。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf5f1d58c21e9ba65/5c98d0f249a201165fca1028/frozen-indices-kibana-settings.png" data-sys-asset-uid="bltf5f1d58c21e9ba65" alt="frozen-indices-kibana-settings.png" width="100%" style="margin: auto;display: block;" />
航班的仪表板会再次显示数据。
<h2>总结</h2>
冻结指数是热-温架构中非常强大的工具。它们提供了一个更具成本效益的解决方案，可以在保留在线搜索的同时提高保留率。我建议您用硬件和数据测试搜索延迟，以便为冻结的索引提供合适的大小和搜索延迟。
查看 <a href="/guide/en/elasticsearch/reference/6.6/frozen-indices.html">Elasticsearch 文档</a>，了解有关<a href="/guide/en/elasticsearch/reference/6.6/freeze-index-api.html">冻结索引 API</a> 的更多信息。一如既往，如果您有任何问题，请联系我们的<a href="https://discuss.elastic.co/">讨论</a>论坛。冻结快乐！

frozen-indices-freeze-index-api.jpg

frozen-indices-freeze-index-api-small.jpg

Creating frozen indices with the Elasticsearch Freeze index API

使用 Elasticsearch Freeze index API 创建冻结索引

<html><head></head><body>Elastic Cloud &#x4F01;&#x4E1A;&#x7248; (ECE) 1.0 &#x6B63;&#x5F0F;&#x53D1;&#x5E03;&#x901A;&#x7528;&#x7248;&#x672C;&#xFF0C;&#x6211;&#x4EEC;&#x4E3A;&#x6B64;&#x6FC0;&#x52A8;&#x4E0D;&#x5DF2;&#x3002;&#x8FD9;&#x6B3E;&#x65B0;&#x4EA7;&#x54C1;&#x80FD;&#x591F;&#x8BA9;&#x60A8;&#x5728;&#x60A8;&#x9009;&#x62E9;&#x7684;&#x73AF;&#x5883;&#x4E2D;&#xFF0C;&#x6309;&#x7167;&#x60A8;&#x60F3;&#x8981;&#x7684;&#x65B9;&#x5F0F;&#xFF0C;&#x901A;&#x8FC7;&#x5355;&#x4E2A;&#x63A7;&#x5236;&#x53F0;&#x914D;&#x7F6E;&#x3001;&#x76D1;&#x63A7;&#x3001;&#x7F16;&#x6392;&#x4E00;&#x7CFB;&#x5217; Elasticsearch &#x96C6;&#x7FA4;&#x548C; Kibana &#x5B9E;&#x4F8B;&#x3002;
&#xFF08;&#x5982;&#x679C;&#x60A8;&#x60F3;&#x8981;&#x6DF1;&#x5165;&#x4E86;&#x89E3;&#xFF0C;&#xA0;<a href="/downloads/enterprise">&#x6B22;&#x8FCE;&#x8BD5;&#x7528;</a>&#x5E76;&#x4EAB;&#x53D7;&#x5B83;&#x5E26;&#x7ED9;&#x60A8;&#x7684;&#x4F53;&#x9A8C;&#x3002;&#x6B64;&#x5916;&#xFF0C;&#x60A8;&#x6216;&#x8BB8;&#x6B63;&#x5728;&#x671F;&#x5F85;&#x6211;&#x4EEC;&#x5373;&#x5C06;&#x63A8;&#x51FA;&#x7684;<a href="/webinars/elastic-cloud-enterprise-launch-demo">&#x7F51;&#x7EDC;&#x7814;&#x8BA8;&#x4F1A;&#x548C;&#x4EA7;&#x54C1;&#x6F14;&#x793A;</a>&#x3002;)
&#x4ECA;&#x5929;&#x53D1;&#x5E03;&#x901A;&#x7528;&#x7248;&#x672C;&#x4E4B;&#x524D;&#xFF0C;&#x6211;&#x4EEC;&#x5DF2;&#x7ECF;&#x63A2;&#x8BA8;&#x4E86;<a href="/blog/cloud-enterprise-the-architecture">&#x4EA7;&#x54C1;&#x67B6;&#x6784;</a>, <a href="/blog/elastic-cloud-enterprise-beta">&#x4E1A;&#x52A1;&#x4EF7;&#x503C;</a>&#x548C;<a href="/blog/introducing-elastic-cloud-enterprise-public-alpha">&#x76EE;&#x6807;&#x7528;&#x6237;</a>&#x3002;&#x73B0;&#x5728;&#xFF0C;&#x6211;&#x4EEC;&#x60F3;&#x66F4;&#x52A0;&#x8BE6;&#x7EC6;&#x5730;&#x4ECB;&#x7ECD;&#x7528;&#x6237;&#x5E94;&#x7528; ECE &#x8FD9;&#x6B3E;&#x4EA7;&#x54C1;&#x7684;&#x5177;&#x4F53;&#x65B9;&#x6CD5;&#x3002;

&#x6211;&#x4EEC;&#x7684;&#x5F88;&#x591A;&#x7528;&#x6237;&#x5728;&#x4EA7;&#x54C1;&#x5E94;&#x7528;&#x65B9;&#x9762;&#x90FD;&#x6709;&#x7C7B;&#x4F3C;&#x7684;&#x7ECF;&#x5386;&#x3002;&#x4EE5; X &#x516C;&#x53F8;&#x4E3A;&#x4F8B;&#xFF0C;&#x4ED6;&#x4EEC;&#x7684;&#x5F00;&#x53D1;&#x4EBA;&#x5458;&#x5904;&#x7406;&#x4E0E;&#x6570;&#x636E;&#x76F8;&#x5173;&#x7684;&#x95EE;&#x9898;&#x65F6;&#xFF0C;&#x5076;&#x7136;&#x53D1;&#x73B0;&#x4E86; Elasticsearch&#xFF0C;&#x5C31;&#x5C06;&#x5B83;&#x4E0B;&#x8F7D;&#x4E0B;&#x6765;&#x5E76;&#x542F;&#x7528;&#x4E86;&#x6D4B;&#x8BD5;&#x96C6;&#x7FA4;&#xFF0C;&#x8F93;&#x5165;&#x4E86;&#x4E00;&#x4E9B;&#x6570;&#x636E;&#x540E;&#x53D1;&#x73B0;&#x64CD;&#x4F5C;&#x6210;&#x529F;&#x3002;&#x540C;&#x4E8B;&#x542C;&#x8BF4;&#x540E;&#x5C31;&#x589E;&#x52A0;&#x4E86;&#x81EA;&#x5DF1;&#x7684;&#x6570;&#x636E;&#xFF0C;&#x800C;&#x96C6;&#x7FA4;&#x4E3A;&#x4E86;&#x652F;&#x6301;&#x8FD9;&#x4E9B;&#x65B0;&#x589E;&#x7684;&#x6570;&#x636E;&#xFF0C;&#x4E0D;&#x5F97;&#x4E0D;&#x6269;&#x5927;&#x89C4;&#x6A21;&#x3002;&#x4E0D;&#x4E45;&#x4E4B;&#x540E;&#xFF0C;X &#x516C;&#x53F8;&#x5728;&#x53D1;&#x6325;&#x751F;&#x4EA7;&#x652F;&#x6301;&#x4F5C;&#x7528;&#x7684;&#x4EFB;&#x52A1;&#x5173;&#x952E;&#x578B;&#x529F;&#x80FD;&#x4E2D;&#x8FD0;&#x884C;&#x7684; Elasticsearch &#x8282;&#x70B9;&#x5C31;&#x589E;&#x52A0;&#x5230;&#x4E86;&#x51E0;&#x5341;&#x4E2A;&#x3002;
<h2>&#x800C;&#x8FD9;&#x4EC5;&#x4EC5;&#x662F;&#x5F00;&#x59CB;&#x3002;</h2>&#x5047;&#x8BBE; X &#x516C;&#x53F8;&#x662F;&#x4E00;&#x5BB6;&#x94F6;&#x884C;&#x3002;&#x4ED6;&#x4EEC;&#x7684;&#x591A;&#x8282;&#x70B9;&#x751F;&#x4EA7;&#x96C6;&#x7FA4;&#x76EE;&#x524D;&#x652F;&#x6301;&#x5C06;&#x65E5;&#x5FD7;&#x7528;&#x4F8B;&#x5E94;&#x7528;&#x5230;&#x591A;&#x4E2A;&#x5E94;&#x7528;&#x8303;&#x56F4;&#xFF0C;&#x4F46;&#x662F;&#x4ED6;&#x4EEC;&#x73B0;&#x5728;&#x5E0C;&#x671B;&#x5C06;&#x5B89;&#x5168;&#x5206;&#x6790;&#x548C;&#x4EA4;&#x6613;&#x5206;&#x6790;&#x5E94;&#x7528;&#x5230;&#x65B0;&#x7684;&#x5E94;&#x7528;&#x8303;&#x56F4;&#x3002;&#x6B64;&#x5916;&#xFF0C;&#x8425;&#x9500;&#x56E2;&#x961F;&#x3001;&#x4EBA;&#x529B;&#x8D44;&#x6E90;&#x56E2;&#x961F;&#x548C; SRE &#x56E2;&#x961F;&#x90FD;&#x542C;&#x8BF4;&#x4E86; Elastic&#xFF0C;&#x5E76;&#x4E14;&#x8981;&#x6C42;&#x8BD5;&#x7528;&#x6216;&#x8005;&#x5E94;&#x7528;&#x5B83;&#x6765;&#x89E3;&#x51B3;&#x5404;&#x81EA;&#x7684;&#x4E1A;&#x52A1;&#x95EE;&#x9898;&#x3002;

&#x73B0;&#x5728;&#x7684;&#x5C40;&#x9762;&#x53D8;&#x5F97;&#x8D8A;&#x6765;&#x8D8A;&#x6709;&#x610F;&#x601D;&#x4E86;&#x3002;&#x5404;&#x79CD;&#x5404;&#x6837;&#x7684;&#x95EE;&#x9898;&#x805A;&#x5728;&#x4E86;&#x4E00;&#x8D77;&#xFF0C;&#x8FD9;&#x4E9B;&#x95EE;&#x9898;&#x5E26;&#x6765;&#x7684;&#x9EBB;&#x70E6;&#x662F;&#x7531;&#x96C6;&#x7FA4;&#x89C4;&#x6A21;&#x7684;&#x7BA1;&#x7406;&#x96BE;&#x9898;&#x81EA;&#x7136;&#x884D;&#x751F;&#x51FA;&#x6765;&#x7684;&#xFF0C;&#x4F8B;&#x5982;&#x591A;&#x7528;&#x4F8B;&#x3001;&#x591A;&#x79DF;&#x6237;&#x3001;&#x8D8A;&#x6765;&#x8D8A;&#x591A;&#x7684;&#x6570;&#x636E;&#x3002;

<img src="https://api.contentstack.io/v2/uploads/59265e494c6ffd0c60497281/download?uid=bltfbe986c1caa92091" data-sys-asset-uid="bltfbe986c1caa92091" alt="elasticsearch-multitenant-multi-use-case-management-monitoring-orchestration.png">
&#x8FD9;&#x6837;&#x7684;&#x95EE;&#x9898;&#x662F;&#x6211;&#x4EEC;&#x4E50;&#x4E8E;&#x9762;&#x5BF9;&#x7684;&#xFF0C;&#x4E0D;&#x8FC7;&#x89E3;&#x51B3;&#x8D77;&#x6765;&#x9887;&#x5177;&#x6311;&#x6218;&#x3002;&#x4E3A;&#x4E86;&#x89E3;&#x91CA;&#x6E05;&#x695A;&#xFF0C;&#x6211;&#x4EEC;&#x5148;&#x8FDB;&#x884C;&#x5206;&#x89E3;&#xFF0C;&#x805A;&#x7126;&#x4E24;&#x4E2A;&#xFF08;&#x81EA;&#x7136;&#x800C;&#x7136;&#x5B58;&#x5728;&#x7684;&#xFF09;&#x95EE;&#x9898;&#xFF1A;1) &#x4F60;&#x4EEC;&#x662F;&#x8C01;&#xFF1B;2) &#x4F60;&#x4EEC;&#x60F3;&#x8981;&#x505A;&#x4EC0;&#x4E48;&#xFF1F;

&#x7B2C;&#x4E00;&#x4E2A;&#x95EE;&#x9898;&#xFF1A;&#x4F60;&#x4EEC;&#x662F;&#x8C01;&#xFF1F;
&#x5982;&#x679C;&#x4F60;&#x4EEC;&#x662F;&#x96C6;&#x7FA4;&#x7684;&#x79DF;&#x6237;&#x3002;&#x4F60;&#x4EEC;&#x4F1A;&#x5173;&#x5FC3;&#x83B7;&#x53D6;&#x6D1E;&#x5BDF;&#x6240;&#x9700;&#x7684;&#x65F6;&#x95F4;&#x3001;&#x5FEB;&#x901F;&#x54CD;&#x5E94;&#x3001;&#x81EA;&#x5B9A;&#x4E49;&#x4F53;&#x9A8C;&#x4EE5;&#x53CA;&#x80FD;&#x5426;&#x6EE1;&#x8DB3;&#x671F;&#x671B;&#x3002;&#x4F46;&#x662F;&#xFF0C;&#x5982;&#x679C;&#x5BF9;&#x6240;&#x6709;&#x79DF;&#x6237;&#x90FD;&#x7B49;&#x800C;&#x89C6;&#x4E4B;&#xFF0C;&#x8FD9;&#x662F;&#x4E0D;&#x660E;&#x667A;&#x7684;&#x505A;&#x6CD5;&#x3002;&#x4ED6;&#x4EEC;&#x6709;&#x4E0D;&#x540C;&#x7684;&#x9700;&#x6C42;&#x3001;&#x4E60;&#x60EF;&#x548C;&#x8981;&#x6C42; &#x2014; &#x6BCF;&#x4E2A;&#x8981;&#x7D20;&#x90FD;&#x53EF;&#x80FD;&#x5BFC;&#x81F4;&#x6469;&#x64E6;&#x548C;&#x632B;&#x8D25;&#x3002;
<ul>
	<li> &#x4E0D;&#x540C;&#x7684;&#x8BBF;&#x95EE;&#x63A7;&#x5236;&#x914D;&#x7F6E;&#x3002; &#x79DF;&#x6237;&#x4F1A;&#x6709;&#x4E0D;&#x540C;&#x7684;&#x7528;&#x4F8B;&#x3002;&#x6709;&#x4E9B;&#x53EF;&#x80FD;&#x8981;&#x8FDB;&#x884C;&#x5168;&#x6587;&#x641C;&#x7D22;&#x6216;&#x9700;&#x8981;&#x667A;&#x80FD;&#x63D0;&#x793A;&#x548C;&#x63A8;&#x8350;&#x3002;&#x5176;&#x4ED6;&#x53EF;&#x80FD;&#x8981;&#x5BF9;&#x5B89;&#x5168;&#x6570;&#x636E;&#x8FDB;&#x884C;&#x7E41;&#x91CD;&#x7684;&#x805A;&#x5408;&#x3001;&#x65E5;&#x5FD7;&#x5206;&#x6790;&#x6216;&#x626B;&#x63CF;&#x548C;&#x904D;&#x5386;&#x3002;</li>
</ul>
<ul>
	<li>&#x4E0D;&#x540C;&#x7684;&#x670D;&#x52A1;&#x6C34;&#x5E73;&#x534F;&#x8BAE; (SLA)&#x3002;&#x6267;&#x884C;&#x5A01;&#x80C1;&#x8FFD;&#x8E2A;&#x7684;&#x5B89;&#x5168;&#x56E2;&#x961F;&#x53EF;&#x80FD;&#x5E76;&#x4E0D;&#x5E0C;&#x671B;&#x4ED6;&#x4EEC;&#x7684;&#x5206;&#x6790;&#x6240;&#x83B7;&#x5F97;&#x7684;&#x54CD;&#x5E94;&#x6709;&#x5EF6;&#x8FDF;&#xFF0C;&#x4F46;&#x662F;&#x4ED6;&#x4EEC;&#x5BF9;&#x96C6;&#x7FA4;&#x8FDB;&#x884C;&#x7684;&#x4EFB;&#x52A1;&#x91CF;&#x7E41;&#x91CD;&#x7684;&#x67E5;&#x8BE2;&#x53EF;&#x80FD;&#x4F1A;&#x5BF9;&#x5176;&#x4ED6;&#x79DF;&#x6237;&#x7684; SLA &#x9884;&#x671F;&#x4EA7;&#x751F;&#x8D1F;&#x9762;&#x5F71;&#x54CD;&#x3002;</li>
</ul><ul>
	<li> &#x4E0D;&#x540C;&#x7684;&#x7248;&#x672C; &#x5E76;&#x975E;&#x6240;&#x6709;&#x79DF;&#x6237;&#x90FD;&#x8FD0;&#x884C;&#x76F8;&#x540C;&#x7248;&#x672C;&#x7684; Elastic &#x4EA7;&#x54C1;&#x3002;&#x4ED6;&#x4EEC;&#x53EF;&#x80FD;&#x51FA;&#x4E8E;&#x7279;&#x5B9A;&#x7684;&#x539F;&#x56E0;&#x800C;&#x5FC5;&#x987B;&#x4F7F;&#x7528;&#x67D0;&#x4E2A;&#x7279;&#x5B9A;&#x7684;&#x7248;&#x672C;&#xFF0C;&#x56E0;&#x6B64;&#x5982;&#x679C;&#x786C;&#x8981;&#x4ED6;&#x4EEC;&#x5728;&#x6CA1;&#x6709;&#x51C6;&#x5907;&#x597D;&#x7684;&#x60C5;&#x51B5;&#x4E0B;&#x5347;&#x7EA7;&#xFF0C;&#x4F1A;&#x9002;&#x5F97;&#x5176;&#x53CD;&#x3002;
</li>
</ul>&#x8FD8;&#x6709;&#x5176;&#x4ED6;&#x8981;&#x8003;&#x8651;&#x7684;&#x56E0;&#x7D20;&#x3002;&#x4F8B;&#x5982;&#xFF0C;&#x4E0D;&#x540C;&#x7684;&#x5907;&#x4EFD;&#x7B56;&#x7565;&#x4F1A;&#x4EA7;&#x751F;&#x989D;&#x5916;&#x7684;&#x5DE5;&#x4F5C;&#x91CF;&#xFF0C;&#x6216;&#x7ED9;&#x57FA;&#x7840;&#x8BBE;&#x65BD;&#x5E26;&#x6765;&#x8D1F;&#x62C5;&#x3002;&#x8FD8;&#x6709;&#x4E9B;&#x79DF;&#x6237;&#x53EF;&#x80FD;&#x4F1A;&#x6784;&#x5EFA;&#x4EFB;&#x52A1;&#x91CF;&#x7E41;&#x91CD;&#x7684;&#x544A;&#x8B66;&#xFF0C;&#x9700;&#x8981;&#x67E5;&#x8BE2;&#x7684;&#x6570;&#x636E;&#x91CF;&#x76F8;&#x5F53;&#x4E8E;&#x4E00;&#x5E74;&#x7684;&#x6570;&#x636E;&#x91CF;&#xFF0C;&#x8FD9;&#x4F1A;&#x59A8;&#x788D;&#x5176;&#x4ED6;&#x79DF;&#x6237;&#x7684;&#x96C6;&#x7FA4;&#x3002;
&#x5982;&#x679C;&#x4F60;&#x4EEC;&#x662F;&#x751F;&#x4EA7;&#x56E2;&#x961F;&#x3002;Elastic &#x7684;&#x6240;&#x6709;&#x9B54;&#x529B;&#x90FD;&#x4F1A;&#x901A;&#x8FC7;&#x4F60;&#x4EEC;&#x53D1;&#x6325;&#x51FA;&#x6765;&#x3002;&#x4F60;&#x4EEC;&#x4F1A;&#x5173;&#x6CE8;&#x5982;&#x4F55;&#x63D0;&#x4F9B;&#x826F;&#x597D;&#x7684;&#x7528;&#x6237;&#x4F53;&#x9A8C;&#xFF0C;&#x4E3A;&#x9879;&#x76EE;&#x6216;&#x90E8;&#x95E8;&#x5E26;&#x6765;&#x66F4;&#x9AD8;&#x7684;&#x6295;&#x8D44;&#x56DE;&#x62A5;&#x7387;&#xFF08;ROI&#xFF09;&#xFF0C;&#x5E76;&#x4E14;&#x8981;&#x786E;&#x4FDD;&#x4E0D;&#x4F1A;&#x56E0;&#x4E3A;&#x5904;&#x7406;&#x5E94;&#x6025;&#x95EE;&#x9898;&#x800C;&#x5BFC;&#x81F4;&#x65F6;&#x95F4;&#x8FC7;&#x4E8E;&#x7D27;&#x5F20;&#x3002;&#x4ECE;&#x8FD9;&#x4E2A;&#x89D2;&#x5EA6;&#x6765;&#x770B;&#xFF0C;&#x6211;&#x4EEC;&#x9700;&#x8981;&#x8003;&#x8651;&#x53E6;&#x5916;&#x4E00;&#x7EC4;&#x8981;&#x7D20;&#x3002;<ul>
	<li>&#x4F55;&#x65F6;&#x7EF4;&#x62A4;&#x3002; &#x8FD9;&#x662F;&#x4E2A;&#x8001;&#x751F;&#x5E38;&#x8C08;&#x7684;&#x95EE;&#x9898;&#xFF1A;&#x4E3A;&#x4E86;&#x5C06;&#x7CFB;&#x7EDF;&#x548C;&#x7528;&#x6237;&#x5F71;&#x54CD;&#x964D;&#x81F3;&#x6700;&#x4F4E;&#xFF0C;&#x5E94;&#x8BE5;&#x4F55;&#x65F6;&#x7EF4;&#x62A4;&#xFF1F;&#x5982;&#x4F55;&#x534F;&#x8C03;&#x4E0D;&#x540C;&#x7684;&#x65F6;&#x533A;&#x548C;&#x4E0D;&#x540C;&#x7684;&#x4F7F;&#x7528;&#x6A21;&#x5F0F;&#xFF1F;
</li>
</ul><ul>
	<li>&#x4E00;&#x4E2A;&#x79DF;&#x6237;&#x8BA9;&#x5168;&#x76D8;&#x5D29;&#x6E83;&#x3002;&#x5982;&#x679C;&#x67D0;&#x4E2A;&#x79DF;&#x6237;&#x6267;&#x884C;&#x5927;&#x578B;&#x67E5;&#x8BE2;&#xFF0C;&#x963B;&#x585E;&#x6574;&#x4E2A;&#x96C6;&#x7FA4;&#xFF0C;&#x5185;&#x90E8;&#x5BA2;&#x6237;&#x53EF;&#x80FD;&#x4F1A;&#x56E0;&#x6B64;&#x63D0;&#x51FA;&#x8BBF;&#x95EE;&#x53D7;&#x963B;&#x7684;&#x95EE;&#x9898;&#x3002;
</li>
</ul><ul>
	<li>&#x5B89;&#x5168;&#x5408;&#x89C4;&#x6027;&#x3002;&#x6709;&#x4E9B;&#x79DF;&#x6237;&#x51FA;&#x4E8E;&#x5B89;&#x5168;&#x539F;&#x56E0;&#xFF0C;&#x4E0D;&#x80FD;&#x5C06;&#x81EA;&#x5DF1;&#x7684;&#x6570;&#x636E;&#x4E0E;&#x5176;&#x4ED6;&#x79DF;&#x6237;&#x7684;&#x6570;&#x636E;&#x653E;&#x5728;&#x540C;&#x4E00;&#x4E2A;&#x96C6;&#x7FA4;&#x4E2D;&#x3002;</li>
</ul><ul>
	<li>&#x5927;&#x5BB6;&#x90FD;&#x7231;&#x7528; Kibana&#x3002;&#x76EE;&#x524D;&#xFF0C;Kibana &#x6CA1;&#x6709;&#x591A;&#x79DF;&#x6237;&#x67B6;&#x6784;&#xFF0C;&#x56E0;&#x6B64;&#x7528;&#x6237;&#x4E0D;&#x5F97;&#x4E0D;&#x542F;&#x7528;&#x591A;&#x4E2A; Kibana &#x5B9E;&#x4F8B;&#xFF0C;&#x8FD9;&#x5C31;&#x610F;&#x5473;&#x7740;&#x4F1A;&#x5E26;&#x6765;&#x989D;&#x5916;&#x7684;&#x7BA1;&#x7406;&#x5DE5;&#x4F5C;&#x3002;</li>
</ul><h2>&#x90A3;&#x8BE5;&#x600E;&#x4E48;&#x505A;&#x5462;&#xFF1F;&#xA0;</h2>&#x8F6F;&#x4EF6;&#x8FD0;&#x4F5C;&#x5982;&#x6B64;&#x987A;&#x5229;&#xFF0C;&#x5E76;&#x4E14;&#x7ED9;&#x7EC4;&#x7EC7;&#x8BB8;&#x4E0B;&#x4E86;&#x5982;&#x6B64;&#x591A;&#x7684;&#x627F;&#x8BFA;&#xFF0C;&#x90A3;&#x4E48;&#x751F;&#x4EA7;&#x56E2;&#x961F;&#x5E94;&#x8BE5;&#x600E;&#x4E48;&#x505A;&#x6765;&#x9632;&#x96C6;&#x7FA4;&#xFF08;&#x6216;&#x8005;&#x53EF;&#x80FD;&#x662F;&#x4ED6;&#x4EEC;&#x7684;&#x7CBE;&#x795E;&#xFF09;&#x5D29;&#x6E83;&#x5462;&#xFF1F; 
<img src="https://api.contentstack.io/v2/uploads/59274e879f9948b9770cd236/download?uid=blt03ec1aecac47f465" data-sys-asset-uid="blt03ec1aecac47f465" alt="elasticsearch-kibana-clusters-instances-at-scale-manage-monitor-elastic-cloud-enterprise.png">
&#x56E0;&#x4E3A;&#xFF0C;&#x8FD9;&#x5C31;&#x662F;&#x4F60;&#x4EEC;&#x7684;&#x73B0;&#x72B6;&#x2026;&#x2026; 
&#x4F60;&#x4EEC;&#x6709;&#x4E00;&#x4E2A;&#x9009;&#x62E9;&#xFF08;&#x4E8B;&#x5B9E;&#x4E0A;&#xFF0C;&#x7EC8;&#x7A76;&#x4F1A;&#x53D1;&#x5C55;&#x5230;&#x8FD9;&#x4E00;&#x6B65;&#xFF09;&#xFF1A;&#x62C6;&#x5206;&#x96C6;&#x7FA4;&#x3002;&#x5C06;&#x96C6;&#x7FA4;&#x62C6;&#x5206;&#x6210;&#x5C0F;&#x5757;&#x80FD;&#x591F;&#x89E3;&#x51B3;&#x6211;&#x4EEC;&#x8BA8;&#x8BBA;&#x8FC7;&#x7684;&#x90E8;&#x5206;&#x75DB;&#x70B9;&#xFF0C;&#x4F46;&#x7684;&#x786E;&#x8981;&#x4ED8;&#x51FA;&#x4E00;&#x4E9B;&#x4EE3;&#x4EF7;&#x3002;
&#x90E8;&#x7F72;&#x548C;&#x914D;&#x7F6E;&#x9700;&#x8981;&#x8003;&#x8651;&#x4F7F;&#x7528;&#x914D;&#x7F6E;&#x7BA1;&#x7406;&#x5DE5;&#x5177;&#x6216;&#x7F16;&#x6392;&#x5DE5;&#x5177;&#x3001;&#x8DE8;&#x5404;&#x4E2A;&#x96C6;&#x7FA4;&#x7BA1;&#x7406;&#x4E0D;&#x540C;&#x7684; Elastic &#x7248;&#x672C;&#xFF08;&#x8FD9;&#x5BF9;&#x4E8E; 5.x &#x4E4B;&#x524D;&#x7684;&#x7248;&#x672C;&#x4F1A;&#x6709;&#x4E9B;&#x56F0;&#x96BE;&#xFF09;&#x3001;&#x652F;&#x6301;&#x4E0D;&#x540C;&#x7684; SLA &#x751A;&#x81F3;&#x4E0D;&#x540C;&#x7C7B;&#x578B;&#x7684;&#x57FA;&#x7840;&#x8BBE;&#x65BD;&#xFF0C;&#x7B49;&#x7B49;&#x3002;
<p这会产生滑坡效应：如果一个租户获得了自己的集群，其他租户也想要自己的集群。简单的事情汇集起来，管理就会变得更加复杂。不久之后，生产团队就会面临这样的风险：为集群提供支持所花费的时间，比他们完成原定目标所花费的时间还要多。 <="" p=""></p这会产生滑坡效应：如果一个租户获得了自己的集群，其他租户也想要自己的集群。简单的事情汇集起来，管理就会变得更加复杂。不久之后，生产团队就会面临这样的风险：为集群提供支持所花费的时间，比他们完成原定目标所花费的时间还要多。><h2>&#x73B0;&#x5728;&#xFF0C;&#x6211;&#x4EEC;&#x6765;&#x5566;&#x3002;</h2>ECE &#x80FD;&#x591F;&#x8F7B;&#x677E;&#x3001;&#x5F7B;&#x5E95;&#x5730;&#x89E3;&#x51B3;&#x8FD9;&#x4E00;&#x7C7B;&#x96BE;&#x9898;&#x3002;&#x5B83;&#x80FD;&#x591F;&#x901A;&#x8FC7;&#x5355;&#x4E2A;&#x63A7;&#x5236;&#x53F0;&#x6EE1;&#x8DB3;&#x6240;&#x6709;&#x8FD9;&#x4E9B;&#x9700;&#x6C42;&#xFF0C;&#x5E76;&#x5C06;&#x6240;&#x6709;&#x64CD;&#x4F5C;&#x7B80;&#x5316;&#x3002;
&#x65E0;&#x8BBA;&#x662F;&#x65B0;&#x5EFA;&#x96C6;&#x7FA4;&#x3001;&#x6839;&#x636E;&#x9700;&#x8981;&#x8C03;&#x6574;&#x89C4;&#x6A21;&#x3001;&#x6258;&#x7BA1;&#x548C;&#x5347;&#x7EA7;&#x591A;&#x4E2A;&#x7248;&#x672C;&#xFF0C;&#x8FD8;&#x662F;&#x542F;&#x7528; Kibana &#x548C; X-Pack &#x2014; &#x60A8;&#x53EA;&#x9700;&#x5355;&#x51FB;&#x6216;&#x63D0;&#x4EA4; API &#x8C03;&#x7528;&#x5373;&#x53EF;&#x3002;&#x60A8;&#x53EF;&#x4EE5;&#x901A;&#x8FC7;&#x5355;&#x4E00;&#x7BA1;&#x7406;&#x5E73;&#x53F0;&#x76D1;&#x63A7;&#x6574;&#x4E2A;&#x90E8;&#x7F72;&#xFF0C;&#x5E76;&#x786E;&#x4FDD;&#x6240;&#x6709;&#x4EBA;&#x6EE1;&#x610F;&#x3002;&#x7136;&#x540E;&#xFF0C;&#x60A8;&#x5C31;&#x53EF;&#x4EE5;&#x4E13;&#x6CE8;&#x4E8E;&#x5904;&#x7406;&#x9879;&#x76EE;&#xFF0C;&#x63A8;&#x8FDB;&#x4E1A;&#x52A1;&#x53D1;&#x5C55;&#x3002;
&#x73B0;&#x5728;&#xFF0C;&#x65E0;&#x8BBA;&#x4EFB;&#x4F55;&#x65F6;&#x5019;&#xFF0C;&#x53EA;&#x8981;&#x6709;&#x4EBA;&#x60F3;&#x8981;&#x8BD5;&#x7528; Elastic &#x6216;&#x5168;&#x9762;&#x6295;&#x5165;&#x751F;&#x4EA7;&#xFF0C;&#x90FD;&#x80FD;&#x591F;&#x8F7B;&#x677E;&#x5B9E;&#x73B0;&#x3002;&#x60F3;&#x8981;&#x4E00;&#x70B9; POC &#x6D4B;&#x8BD5;&#x65F6;&#x95F4;&#xFF1F;&#x53EF;&#x4EE5;&#x542F;&#x7528;&#x65B0;&#x7684;&#x96C6;&#x7FA4;&#x3002;&#x9700;&#x8981;&#x4E00;&#x4E2A;&#x77ED;&#x671F;&#x5B58;&#x5728;&#x7684;&#x73AF;&#x5883;&#xFF1F;&#x6CA1;&#x95EE;&#x9898;&#x3002;&#x60F3;&#x8981;&#x6C42;&#x63D0;&#x4F9B;&#x7B26;&#x5408;&#x5B89;&#x5168;&#x8BA1;&#x5212;&#x7684;&#x786C;&#x4EF6;&#x5374;&#x6709;&#x987E;&#x8651;&#xFF1F;&#x522B;&#x62C5;&#x5FC3;&#x3002;&#xFF08;&#x4EBA;&#x4EEC;&#x4E0D;&#x4F1A;&#x4EC5;&#x4EC5;&#x51FA;&#x4E8E;&#x6D4B;&#x8BD5;&#x7684;&#x539F;&#x56E0;&#xFF0C;&#x5C31;&#x8981;&#x6C42;&#x63D0;&#x4F9B;&#x65B0;&#x7684;&#x865A;&#x62DF;&#x673A;&#x6216;&#x4E13;&#x7528;&#x673A;&#x5668;&#x2026;&#x2026;&#xFF09;ECE &#x5DF2;&#x7ECF;&#x5904;&#x7406;&#x597D;&#x4E86;&#x3002;&#x9879;&#x76EE;&#x9700;&#x8981;&#x591A;&#x4E2A;&#x73AF;&#x5883;&#x8FDB;&#x884C; QA &#x548C;&#x9884;&#x751F;&#x4EA7;&#xFF1F;&#x542C;&#x4E0A;&#x53BB;&#x4E5F;&#x6CA1;&#x6709;&#x95EE;&#x9898;&#x3002;
ECE &#x7684;&#x8BBE;&#x8BA1;&#x521D;&#x8877;&#xFF0C;&#x5C31;&#x662F;&#x4E3A;&#x4E86;&#x89E3;&#x51B3;&#x8FD9;&#x4E9B;&#x95EE;&#x9898;&#xFF0C;&#x5E76;&#x4E14;&#x5706;&#x6EE1;&#x5730;&#x89E3;&#x51B3;&#x8FD9;&#x4E9B;&#x95EE;&#x9898;&#x3002;ECE &#x6240;&#x7528;&#x7684;&#x4EE3;&#x7801;&#x5E93;&#x4E0E;&#x6211;&#x4EEC; Elastic Cloud &#x670D;&#x52A1;&#x6240;&#x7528;&#x7684;&#x4EE3;&#x7801;&#x5E93;&#x662F;&#x4E00;&#x6837;&#x7684;&#x3002;&#x622A;&#x81F3;&#x76EE;&#x524D;&#xFF0C;Elastic Cloud &#x670D;&#x52A1;&#x5DF2;&#x7ECF;&#x5728;&#x8FC7;&#x53BB;&#x51E0;&#x5E74;&#x91CC;&#x6258;&#x7BA1;&#x4E86;&#x6210;&#x5343;&#x4E0A;&#x4E07;&#x4E2A;&#x96C6;&#x7FA4;&#x3002;&#x603B;&#x800C;&#x8A00;&#x4E4B;&#xFF0C;&#x53EA;&#x8981;&#x60A8;&#x5E0C;&#x671B;&#x4E0E; Elastic &#x5171;&#x540C;&#x6210;&#x957F;&#xFF0C;ECE &#x8FD9;&#x6B3E;&#x4EA7;&#x54C1;&#x5C31;&#x662F;&#x60A8;&#x7684;&#x7406;&#x60F3;&#x9009;&#x62E9;&#x3002;&#x4E8B;&#x5B9E;&#x4E0A;&#xFF0C;&#x5728;&#x6211;&#x4EEC;&#x7684;&#x7B2C;&#x4E00;&#x6279;&#x5BA2;&#x6237;&#x4E2D;&#xFF0C;&#x6709;&#x4E00;&#x4E2A;&#x5BA2;&#x6237;&#x53EA;&#x6709; 5 &#x4E2A;&#x751F;&#x4EA7;&#x96C6;&#x7FA4;&#xFF0C;&#x4F46;&#x662F;&#x4ED6;&#x4EEC;&#x53D1;&#x73B0;&#xFF0C;&#x8FD9;&#x6B3E;&#x4EA7;&#x54C1;&#x7684;&#x96C6;&#x4E2D;&#x5F0F;&#x7BA1;&#x7406;&#x7279;&#x6027;&#x80FD;&#x591F;&#x4E3A;&#x4ED6;&#x4EEC;&#x5B9E;&#x73B0;&#x672A;&#x6765;&#x53D1;&#x5C55;&#x671F;&#x671B;&#x5E26;&#x6765;&#x4EF7;&#x503C;&#x3002;
&#x5FEB;&#x5FEB;&#x884C;&#x52A8;&#x8D77;&#x6765;<a href="/downloads/enterprise">&#x8BD5;&#x7528;&#x8FD9;&#x6B3E;&#x4EA7;&#x54C1;</a>&#x5427;&#xFF01;&#x8BA9;<a href="/guide/en/cloud-enterprise/current/index.html">&#x5206;&#x6B65;&#x4ECB;&#x7ECD;&#x6587;&#x6863;</a>&#x5E26;&#x60A8;&#x8BE6;&#x7EC6;&#x4E86;&#x89E3;&#x5176;&#x4E2D;&#x7684;&#x7EC6;&#x8282;&#x3002;
</body></html>

space-shuttle-enterprise-elastic-cloud-elasticsearch-fullbleed.jpg

A New Elasticsearch Frontier: Elastic Cloud Enterprise 1.0 GA

Elasticsearch 新边界：Elastic Cloud 企业版 1.0 通用版本

我们非常高兴在 2021 年度《Gartner 应用程序性能监测魔力象限》中被评为有远见者。立即下载免费报告，了解我们荣评有远见者的原因所在。

<table style="background: #FFFFD2;">
 <tbody>
 <tr>
 <td>Elastic 在今年的 <a href="/cn/explore/devops-observability/gartner-magic-quadrant-apm">2022 年度《Gartner APM 和可观测性魔力象限》</a>中再次被定位为有远见者，看一看 Elastic 为什么连续两年获评此称号。</td>
 </tr>
 </tbody>
</table>
我们非常高兴地宣布，Elastic 在 2021 年度《Gartner 应用程序性能监测魔力象限》中被评为有远见者。我们对进入“有远见者”这一象限感到十分兴奋，并相信这一殊荣也证实了我们基于 Elastic Stack 提供现代应用程序性能监测解决方案这一模式的独到之处。&nbsp; 
<a href="/cn/explore/devops-observability/gartner-magic-quadrant-apm?elektra=blog&storm=cta1&rogue=APM-GIC">下载免费报告</a>&nbsp;，了解 Gartner 如何进行市场评估，以及为什么将首次参选的 Elastic 评为有远见者。&nbsp; 
<figcaption style="text-align: center;">
 <figcaption style="box-sizing: border-box; margin-bottom: 20px; font-style: italic; line-height: 24px; color: rgb(52, 55, 65); font-family: Inter, arial, sans-serif; text-align: center;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd8b23ae829f98657/6077079e1f74bb759da6b46a/2021_Gartner_Magic_Quadrant_Application_Performance_Monitoring.png" data-sys-asset-uid="bltd8b23ae829f98657" alt="2021_Gartner_Magic_Quadrant_Application_Performance_Monitoring.png" /> 2021 年度《Gartner 应用程序性能监测魔力象限》&nbsp;1</figcaption>
</figcaption>

Gartner 报告称：“APM 工具已经成为强大的分析平台，可从追踪、指标和日志中采集、分析和构建上下文信息。选择 APM 软件的基础架构和运维领导者，必须权衡这些功能与核心 APM 功能，以及新供应商和既有供应商提供的自动化。” 2
<h2>构建在强大基础之上的差异化产品&nbsp;</h2>
Elastic Stack（旧称 ELK Stack）多年来一直是一个广为使用的日志分析和管理解决方案。<a href="/cn/elasticon/tour/2016/chicago/elastic-on-aisle-5-building-kroger-digital-data-pipeline">Kroger</a>、<a href="/cn/elasticon/archive/2020/global/observability-with-elastic-at-audi-business-innovation">Audi</a>、<a href="/cn/elasticon/archive/2020/observability/americas/migrating-a-legacy-logging-system-etsy-journey-to-elastic-cloud">Etsy</a>、<a href="/cn/elasticon/conf/2018/sf/application-infrastructure-monitoring-at-citigroup">Citigroup</a> 和其他数千个组织 — 从小型初创公司到财富 50 强企业 — 都在使用 Elastic 作为他们的集中式日志监测平台。极快的查询速度、在不损失性能的情况下以特别的方式流畅地搜索和查询 PB 级数据的能力，以及不按采集率收费的以价值为中心的定价模型，这些只是使 Elastic 成为企业日志分析标准的部分原因。&nbsp;&nbsp;
在过去几年中，我们斥巨资构建了一个统一的可观测性平台，将这些核心设计原则应用于其他数据类型和用例，如基础架构监测、应用程序性能监测、用户体验监测，等等。我们已经看到，许多开始以 Elastic 作为日志解决方案的客户将他们的整个监测工具整合到了 Elastic 上。我们相信，Gartner 的认可是对我们战略和投资的又一次外部验证。&nbsp;
<h3>灵活的解决方案能够满足您独特的监测需求</h3>
应用程序的构建方式和交付方式都在不断变化。因此，客户亟需一个灵活的监测解决方案，既能满足自身不断变化的独特需求，又不会受到供应商路线图的阻碍。&nbsp;
我们很早就意识到了这一点，并着手在构建开放、灵活和可扩展的平台方面进行了优化。无论是采集尚未受支持的新数据源、以一种不同的方式可视化监测数据、编写自定义异常检测作业，还是将所有监测数据导出到外部工具以供数据科学家查看，Elastic 可观测性都可以轻松为您实现。&nbsp;
即使我们一直致力于为 Elastic 可观测性中的特定监测、调查和修复工作流构建更丰富、更有利于表达意见的用户体验，我们也会继续将基础 Elastic Stack 平台的灵活性注入到我们的可观测性体验中，因为我们深知，每个组织都有自己与众不同的需求，而这些需求不可能通过一个开箱即用型的产品完全解决。&nbsp;
<h3>无可比拟的部署选择&nbsp;</h3>
随着混合云和多云环境的兴起，我们知道，监测混合工作负载已是势在必行。Elastic 可观测性可以在 40 多个地区（数量还在不断增长）通过 Google Cloud、Microsoft Azure 和 Amazon Web Services (AWS) 上的 <a href="http://cloud.elastic.co">Elastic Cloud</a> 使用，也可以部署在本地。通过对联合搜索和分析的支持，您仍可以在混合云或多云环境中实现统一的可见性，同时让您的可观测性工具更靠近被监测的工作负载（从而避免大量的数据传输成本）。&nbsp;
<h3>简单、统一的定价，实现更好的成本控制和可预测性&nbsp;&nbsp;</h3>
传统的以及较新的 APM 解决方案的定价模型既复杂又苛刻，常常迫使用户优化他们的架构来解决成本问题，而不是最大程度地提高可见性。我们认为，不应因为成本而迫使用户在采集数据时丢弃数据或仅监测第 1 层应用，也不应因为成本问题而只选择足够重要的指标来跟踪。&nbsp;
Elastic 可观测性采用了一种全新的、基于资源的统一定价模型，简单明了。您只需为所有数据类型和用例使用的硬件资源支付费用。当您采集第 201 个自定义指标或超过某个任意容器计数阈值时，系统不会自动激活任何隐藏的附加服务。这种定价方法简单透明，既能帮您管理成本，又不会限制监测范围。
而且，我们会不断创新，帮助您从 Elastic 投资中获得更多收益。例如，通过最近推出的冷层和<a href="/cn/blog/introducing-elasticsearch-frozen-tier-searchbox-on-s3">冻结层</a>（由<a href="/cn/blog/introducing-elasticsearch-searchable-snapshots">可搜索快照</a>提供支持），您只需花费很少的成本，就能够直接搜索存储在低成本存储（如 Amazon S3）上数年的数据。&nbsp;
<h3>功能强大的免费开放层</h3>
我们有许多客户都是通过我们的免费开放层开始自己 Elastic 之旅的 — 在这里，他们可以快速上手并在验证价值后再成为付费客户。&nbsp; 免费层包含了各种强大的功能，并且对使用（例如，用户、主机、指标等）没有设置任何限制，这意味着您可以大规模地评估和验证价值。&nbsp;
如果您希望获得托管体验，<a href="/cn/cloud?elektra=blog-gartner-mq-2021">Elastic Cloud 上的托管服务免费试用版</a>始终向您敞开大门。
<h2>下载免费报告</h2>
立即阅读 <a href="/cn/explore/devops-observability/gartner-magic-quadrant-apm?elektra=blog&storm=cta1&rogue=APM-GIC">2021 年度《Gartner 应用程序性能监测魔力象限》</a>报告，了解有关 Elastic 进入有远见者象限的更多信息。
<h4></h4>
<h5>免责声明：</h5>
[1] 这张图片由 Gartner Inc. 发布，截取自一篇较长的研究文档，应在整个文档的背景下进行评估。该 Gartner 文档可向 <a href="/cn/explore/devops-observability/gartner-magic-quadrant-apm?elektra=blog&storm=cta1&rogue=APM-GIC">Elastic</a> 索取。
[2]&nbsp;Gartner，《应用程序性能监测魔力象限》；Federico De Silva、Padraig Byrne 和 Josh Chessman 于 2021 年 4 月
Gartner 不为其研究出版物中描述的任何供应商、产品或服务提供担保，也不建议技术用户只选择评级最高或具有其他名号的供应商。Gartner 研究出版物包含 Gartner 研究组织的观点，这些观点不应被解释为事实陈述。Gartner 不对此研究做任何明示或暗示保证，包括对适销性或针对特定用途适用性的任何保证。

blog-thumb-generic-elastic.png

Elastic named a Visionary in the 2021 Gartner Magic Quadrant for Application Performance Monitoring

Elastic 在 2021 年度《Gartner 应用程序性能监测魔力象限》中被评为有远见者

Elasticsearch 是一个分布式系统，可以优化客户端与 Elasticsearch 集群之间的连接，这对于最终用户的体验是极为重要的。看看监听是不是合适的解决方案。

Elasticsearch 为许多常用工具和应用提供了强大的搜索体验，从用于运营分析的仪表板，到在地图上显示距离您家最近的露台餐厅，实施场景多种多样。在所有这些实施中，应用程序和集群之间的连接都通过 <a href="https://www.elastic.co/guide/en/elasticsearch/client/index.html">Elasticsearch 客户端</a>实现。优化客户端与 Elasticsearch 集群之间的连接，对于最终用户的体验是极为重要的。配置一个必须连接到的节点的 URL 是 Elasticsearch 客户端中比较典型的做法。但您可以进一步优化，监听就是用于优化客户端与 Elasticsearch 集群之间连接的一种方法。下面来介绍监听的工作原理，让大家了解什么业务场景适合使用监听，以及什么业务场景应避免使用监听。<h2>什么是监听？</h2>作为分布式系统，Elasticsearch 的索引存在于相互连接的多个节点中，形成一个集群。除了容错性之外，分布式系统还有一大优势，那就是数据被分片存储到多个节点中，这样一来，搜索的运行速度比通过庞大体量的单个节点进行搜索要快得多。配置一个指向 Elasticsearch 集群中一个节点的 URL 是客户端中的典型做法。虽然这是最简单的配置，但这种设置的主要缺点是，您发出的所有请求都会发送到一个特定的协调节点。这样单个节点就要承受巨大压力，整体性能也可能会受到影响。解决这个问题的办法是向客户端传递节点的静态列表，这样请求就会平均分配到各个节点上。或者，您也可以启用“监听”功能。使用静态节点列表时，不能保证节点始终正常运行。例如，如果您关闭一个节点进行升级或添加若干新节点，会发生什么情况？如果启用监听功能，客户端将开始调用 _nodes/_all/http 终端，而响应将是集群中存在的所有节点及其 IP 地址的列表。然后，客户端将更新其连接池，以使用所有新节点，并保持集群的状态与客户端的连接池同步。请注意，即使客户端下载了完整的节点列表，常规 API 调用也不会使用只作主节点的节点。监听功能可以解决这个发现问题。那为什么不是默认启用监听呢？问得好！<h2>什么场景适合使用监听功能？</h2>监听功能可能是一把双刃剑。如果尝试调用 _nodes/_all/http 终端，您会看到一个列表，其中包含了节点及其各自的终端。但有几个问题需要考虑：<ul><li>如果您的 Elasticsearch 集群位于自己的网络中，会发生什么情况？</li><li>如果您的 Elasticsearch 集群位于负载均衡器后面会怎样？</li></ul>这两个问题的答案很简单：您将得到毫无用处的 IP 地址，因为您处在不同的网络中。您可以用 Docker 自己试试。启动一个 Elasticsearch 实例（一个就够了），然后从本地计算机调用 call _nodes/_all/http。您会发现节点的 IP 地址与您刚才使用的 IP 地址不同。使用下面的命令启动一个 Elasticsearch 实例：<pre class="prettyprint">docker run \ -p 9200:9200 \ -e "discovery.type=single-node" \ docker.elastic.co/elasticsearch/elasticsearch:7.8.0 </pre>现在，您可以使用下面的命令读取节点 IP（在下面的代码片段中，为了更轻松地读取响应，我们将使用 <a href="https://github.com/stedolan/jq">jq</a>。）：<pre class="prettyprint">curl -s localhost:9200/_nodes/_all/http | jq .nodes[].http.publish_address </pre>最后，您可以复制在终端中打印的 IP 地址，然后尝试向其发送一个请求：<pre class="prettyprint">curl {ip_address}:9200 | jq . </pre>可以看见，您不会得到成功响应。这意味着，如果在集群位于另一个网络中时，在客户端中启用监听，客户端就会将所有新节点添加到其连接池中。这是因为它无法理解这些 IP 地址是错误的，对其中一个节点的每一次查询都会失败。由于具有正确 IP 地址的初始节点已不在集群状态中，因此会被丢弃，很快就会出现“无活动连接”错误。<h3>但我们可以解决这个问题。</h3>要解决这个问题，您可以将 Elasticsearch 配置为绑定到其主机，但公布另一个主机。<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.8/modules-http.html#_http_settings">http.publish_host</a> 配置选项可以帮您做到这一点。现在，在进行新配置后，尝试运行上面的 Docker 命令：<pre class="prettyprint">docker run \ -p 9200:9200 \ -e "discovery.type=single-node" \ -e "http.publish_host=localhost" \ docker.elastic.co/elasticsearch/elasticsearch:7.8.0 </pre>接着，再次运行下面的命令：<pre class="prettyprint">curl -s localhost:9200/_nodes/_all/http | jq .nodes[].http.publish_address </pre>终端将显示以下内容：<pre class="prettyprint">"localhost/{ip_address}:9200" </pre>如果您配置了发布主机，那么官方客户端（v7 及更高版本）就会智能地使用主机地址而不是 IP。由此可见，在启用监听功能之前，应该了解自己的基础架构。解决 IP 地址问题的方法有很多，但没有皆大欢喜的解决方案，因为这完全取决于您的系统配置。典型的开发设置是将 Elasticsearch 集群与客户端放在同一网络中，但在真实场景中无法复制这个方案，因为这样做会导致安全问题，而且您的基础架构可能更加复杂。您可以配置负载均衡器来处理这些 IP 地址。或者，就像 Elastic 在 <a href="/cn/cloud">Elastic Cloud</a> 中所采取的方式，您可以让代理来处理故障节点，这样客户端就会始终将查询发送给代理，然后代理再将查询发送到相应的节点。<h2>什么场景不适合使用监听功能？</h2>在许多情况下，监听可能会导致一些问题，其中包括：<ul><li>您的客户端正在进行身份验证的 Elasticsearch 用户没有访问节点 API 的适当权限（monitoring_user 角色）。</li><li>您正在与云服务提供商协作。</li></ul>通常情况下，云服务提供商会将 Elasticsearch 隐藏在代理后面，这样监听操作会变得毫无用处，因为返回的地址和主机名在您的网络中可能没有任何意义。通常，这些云服务提供商会为您处理监听和池化等复杂操作，因此您不需要启用这些功能。如果您使用的是 <a href="/cn/cloud">Elastic Cloud</a>，官方客户端会在内部简化大多数操作（例如连接池处理），以避免在已经完成的操作上花费时间。如前所述，在使用 Docker 或 Kubernetes 时，还会出现其他问题。除非您配置了发布主机选项，否则监听结果将无法使用。经验之谈：如果 Elasticsearch 与客户端位于不同的网络中（或者有负载均衡器），应禁用监听功能，除非基础架构中的某些配置支持您准确地使用监听。<h2>通过什么方式监听？</h2>客户端提供了多种监听策略。我们来逐个分析：<h3>在启动时监听</h3>顾名思义，启用这个选项后，客户端将仅在初始化或首次使用时尝试执行一次监听请求。<h3>在连接失败时监听</h3>如果启用了这个选项，客户端就会在每次节点出现故障（即连接中断或节点无效）时尝试执行监听请求。<h3>监听间隔</h3>除了在启动时监听和发生故障时监听之外，定期监听也很有用，比如集群通常在高峰时段水平扩展这样的场景。应用程序或许可以查看正常运行节点的子集。但是，如果不定期进行监听，它就永远找不到在水平扩展期间添加的节点。<h3>定制配置</h3>在某些情况下，您可能希望对监听过程进行更精细的控制。客户端非常灵活，可让您配置定制监听终端，您也可以完全覆盖监听逻辑，提供自己的监听逻辑。<h2>结论</h2>启用监听功能后，您的应用程序将更具弹性，更能适应不断发生的变化。但在启用此功能之前，您应该了解自己的基础架构，以便决定采用什么样的解决方案最合适。最佳方案甚至可能是不采用监听。如果您不想考虑监听和连接池配置，而是想使用一个简单的连接字符串，不妨试试 Elastic Cloud 上 <a href="/cn/elasticsearch/service">Elasticsearch Service 的 14 天免费试用版</a>。

blog-banner-training-checklist-clipboard.png

Optimizing

blog-thumb-training-checklist-clipboard.png

Elasticsearch sniffing best practices: What, when, why, how

Elasticsearch 监听最佳实践：实施内容、实施场景、原因和方法

在 Elastic Stack 6.5 版本中，我们发布了两种与数据交互的新途径：“Infrastructure”（基础架构）UI 和“Logs”（日志）UI。在 6.5 版本中，这两个工具尚处于公测版阶段，但稍后我会询问您更多的反馈信息。对于这两个新工具，我想略微谈一下设计初衷、用户体验和 UI 配置。下面我们先从“Logs”（日志）UI 开始。<h2>“Logs”（日志）UI</h2><h3>设计初衷</h3>下面这些话我已经耳熟能详：“就把日志给我，我不需要什么花哨的东西，我需要知道的都写在日志里了，我只要看日志”。我们听从您的心声，竭力改进，现提供三种方案供您选择：一是使用功能更为强大的 tail -f 命令，在页面底部查看最近的记录；二是使用表格、图表、标签云等，获得良好的视觉体验；三是使用表格视图。您应该能够选用最适合自己的方式展开工作，Elastic Stack 的开放式设计也支持这一点。<table border="0" style="width: 100%;"><tbody><tr><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf9bdf54b4eeab8bc/5c57d6fb85820dce0bcc2bf5/Logs-small.jpg" data-sys-asset-uid="bltf9bdf54b4eeab8bc" alt="Logs-small.jpg" style="background-color: initial;"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1af8714b20964974/5c57d6ef16a7de000c2b32a0/visuals-small.jpg" data-sys-asset-uid="blt1af8714b20964974" alt="visuals-small.jpg"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7193fa48ab952fe4/5c57d6e94c9f4feb0b4c5843/discover-small.jpg" data-sys-asset-uid="blt7193fa48ab952fe4" alt="discover-small.jpg"/> </td></tr></tbody></table><h3>用户体验</h3>使用“Logs”（日志）UI 与对日志文件执行 tail 命令类似，但可在一个控制台中查看来自所有系统的所有日志。日志源源不断地进入，视图底部是最近的记录，就像 tail -f 命令结果一样。默认情况下，“Logs”（日志）UI 会显示满足配置条件的所有日志的所有记录（下一节将做详细介绍）。当您在处理一个问题时，如果决定不需要将所有服务的所有日志都收集在一起（日志流入速度超过任何人的阅读速度），则只需在顶部搜索栏键入内容即可更改交互方式。例如，如果我只想看到 Apache httpd pod 中 Kubernetes 标签层为“frontend”的 404 错误，我只需在搜索栏中开始键入内容，并让自动完成功能帮我找到合适的日志即可：<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6f7988e6a847040c/5ca7ef626583cf3c4114a271/animated-gif-logs-ui-optimized.gif"/>而在以前，要想实现上述目的，我们需要打开终端，向您的 k8s 提供商提供身份验证，再找出您需要的 Pod，然后运行 kubectl logs -f … | grep 404（若在非容器架构中，我们则需要查找主机名、使用 SSH 登录，再对日志执行 tail 命令等），操作起来十分繁琐。我们希望您的生活更轻松，并以您想要的查看方式提供数据。<h3>配置</h3><a href="/guide/en/kibana/6.x/xpack-logs.html">“Logs”（日志 UI）文档</a>还在原来的位置，这里我将重点介绍一些配置选项。以下是您可以粘贴到 config/kibana.yml 中的默认配置，然后根据这些默认配置进行修改：<pre class="prettyprint">xpack.infra.sources.default.logAlias: "filebeat-*" xpack.infra.sources.default.fields.timestamp: "@timestamp" xpack.infra.sources.default.fields.message: ['message', '@message'] </pre>配置非常简单，在“Logs”（日志）UI 中显示的这些现成行都是与 filebeat-* 别名匹配的每个索引的 message 字段。那么，如果您想添加所有的 Logstash 索引该怎么办呢？只需像这样修改 config/kibana.yml 条目中的 xpack.infra.sources.default.logAlias，然后重启 Kibana 即可：<pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*" xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*" </pre>不要忘了重启 Kibana。重新打开“Logs”（日志）UI 并单击“Stream Live”（实时流式传输），您应会看到所有的 Logstash 和 Filebeat 日志都流入到“Logs”（日志）UI。注意：如果您更习惯使用 <a href="/guide/en/elasticsearch/reference/6.5/indices-aliases.html">Elasticsearch 别名</a>，则只需将 xpack.infra.sources.default.logAlias 设置为别名的名称，然后根据需要更新别名即可。以下是使用 logs 别名的等效方法创建别名：<pre class="prettyprint">curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d' { "actions" : [ { "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } } ] } ' </pre>更新 config/kibana.yml：<pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*" xpack.infra.sources.default.logAlias: "logs" </pre><h2>“Infrastructure”（基础架构）UI</h2><h3>设计初衷</h3>我看到了管理基础架构的三个基本成熟度级别：<ol><li>发现故障，然后打开监测系统进行探查。</li><li>将所有系统的关键指标绘制在一个大仪表板上并仔细观察这些指标，然后深入研究问题所在。</li><li>借助机器学习实现操作自动化，进而发现正常行为，检测新出现的问题，并向操作人员发出警告。</li></ol>“Infrastructure”（基础架构）UI 旨在让操作人员进入“在大型仪表板上绘制关键指标”的阶段。可以肯定地说，我们都需要进入“机器学习自动化阶段”；更多相关内容，请参阅 <a href="/cn/products/stack/machine-learning">Elastic Machine Learning</a>。如果您观看本博文末尾的视频，将会看到一个工作流：从一个机器学习作业的警告开始，然后依次是 APM、分布式跟踪、“Infrastructure”（基础架构）和“Logs”（日志）UI。在 Elasticsearch 中，将所有日志、指标、APM 和分布式跟踪结合在一起，让您能够使用各种分析和可视化工具呈现数据。接下来，让我们来看看“Infrastructure”（基础架构）UI，然后再做深入学习。在这个视图中，我们看到的是 Kubernetes Pod，我已经将它们按命名空间进行了分组。我当前正在查看入站网络流量。通过右键单击其中一个 Pod，即可跳转到这个 Pod 的日志，或者跳转到为其精心组织的指标仪表板。<h3>用户体验</h3>目前支持三种类型的设备：主机、Kubernetes (k8s) Pod 和 Docker 容器。“Infrastructure”（基础架构）UI 的强大之处在于，您可以看到大量设备中关键指标的状态。指标数量较多时，在您使用搜索栏或单击某个组深入到一个感兴趣的子集前，看到的都将是没有文本的彩色方块。此外，您还可以启动一个设备的日志，或者显示一个指标仪表板。我提到过“关键指标”；目前就是这个列表，它们都来自 Metricbeat：主机：CPU、内存、负载、入站流量、出站流量及日志速率 Kubernetes：CPU、内存、入站流量、出站流量 Docker： CPU、内存、入站流量、出站流量通过分组可使您放大设备列表。如果您支持使用 Kubernetes 部署的特定应用程序，则适合用命名空间组。如果您认为某个问题与某个特定节点过载有关，则需要通过按命名空间和节点进行分组来进一步细分。以下是目前的分组列表（每种设备类型最多可以使用两个分组）：主机：可用区域、机器类型、项目 ID、云服务提供商 Kubernetes：命名空间、节点 Docker：主机、可用区域、机器类型、项目 ID、提供商如果上面的分组都不支持您希望的数据交互方式，则可以使用搜索栏。只需开始键入内容，<a href="/guide/en/kibana/6.5/kuery-query.html">Kibana 查询语言</a> (KQL) 自动完成功能就会提供引导。我在前述“Logs”（日志）UI 的 GIF 图中提供了一个示例，当我开始键入 kubernetes 时，Kibana 便会依次提供 labels 和 tier，并随后根据 Elasticsearch 中索引的内容提供可能的选择。在您对资源进行分组后，即可通过单击它进行深入查看，让您看到该组的更多细节。 如果您对某个特定的主机、Pod 或容器感兴趣，则可以深入研究它的日志或指标。 以下是主机指标视图的一部分：<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0db77ee61091f61f/5d2848c18e6f797b0da2f02e/screenshot-metrics-infrastructure-monitoring-feature-page.jpg"/><h3>配置</h3>对于“Infrastructure”（基础架构）UI 几乎不需要进行任何配置。只需部署 Metricbeat 并启用<a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-system.html">系统模块</a>即可。如果您运行的是容器，则还需要启用 <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-kubernetes.html">Kubernetes</a> 和 <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-docker.html">Docker 模块</a>。除非您修改了默认索引模式 (metricbeat-*)，否则配置既告完成。如果您需要定制某些选项，请参考<a href="/guide/en/kibana/6.x/xpack-infra.html">“Infrastructure”（基础架构）UI 文档</a>，其中有详细介绍。我在这里只列出一些关键选项：<pre class="prettyprint">xpack.infra.sources.default.metricAlias: "metricbeat-*" xpack.infra.sources.default.fields.host: "beat.hostname" xpack.infra.sources.default.fields.container: "docker.container.name" xpack.infra.sources.default.fields.pod: "kubernetes.pod.name" </pre><h2>说说您的看法</h2>这两个 UI 均处于公测版阶段，我们非常期待您的反馈，即使在正式发布后也欢迎您持续提出宝贵意见。请告诉我们您更喜欢的数据交互方式。在此公测版的“Infrastructure”（基础架构）UI 中，分组是否足以支持贵团队的组织方式？怎样会更好？我们有合适的指标来驱动颜色吗？您是否需要其他途径来筛选“Logs”（日志）UI 中的日志？当您从“Infrastructure”（基础架构）UI 中启动指标视图时，是否看到了您所关心的指标？前往 <a href="https://discuss.elastic.co/c/kibana">Kibana 论坛</a>，告诉我们您喜欢什么、不喜欢什么，以及需求等等。开发人员会阅读并回应这些讨论，并希望收到您的反馈。此外，您还可以在 <a href="https://github.com/elastic/kibana">GitHub</a> 上开立问题，提交 PR，或密切跟踪它们的状态。<h2>快来试试吧</h2>我们的实时<a href="https://demo.elastic.co/">演示系统</a>提供了您可以进行搜索、可视化和交互的日志和指标。 转到“Infrastructure”（基础架构）磁贴并单击，启动“Infrastructure”（基础架构）UI：<a href="https://demo.elastic.co"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc85a8861b14f7f05/5c57d682a669c2e50b763c45/JumpIn.jpg" data-sys-asset-uid="bltc85a8861b14f7f05" alt="JumpIn.jpg" width="200" height="187" style="width: 200;height: 187;"/></a>您可以切换到 Kubernetes 或 Docker 视图，使用 UI 分组对象，或者 使用搜索栏缩小视图。 左键单击主机、Pod 或容器并启动该对象的“Logs”（日志）UI。当您位于 demo.elastic.co 时，不妨看看部分 仪表板和可视化效果。 您可以从 <a href="https://demo.elastic.co/">登录页</a>导航到不同区域。<h2>观看演示</h2>下面是一段视频，展示了这些 UI 的工作流，以及机器学习和具有分布式跟踪的 APM！再次感谢您的阅读和反馈！<div class="video embed-container" style="height: 478px;"><img style="width: 677;margin: auto;display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/78EpMXQeU57jR7HrKsMXqK.jpg" data-uuid="78EpMXQeU57jR7HrKsMXqK" data-v="4" data-type="inline" width="677"/></div>

infrastructure-and-logs-background.jpg

infrastructure-and-logs-thumbnail.jpg

Infrastructure and Logs UI: New ways for Ops to interact with Elasticsearch

“Infrastructure”（基础架构）和“Logs”（日志）UI：操作人员与 Elasticsearch 交互的新途径

通过使用 Elastic Stack 监测 Nginx 服务器，可帮助您识别基础架构问题，计划例行维护，甚至阻止 DDOS 攻击。

在本文中，我们将介绍如何使用 Elastic Stack 的各种组件来监测 Nginx。我们会使用 Metricbeat 和 Filebeat 来收集数据。这些数据将发送到 Elasticsearch 并存储在其中。最后，我们会使用 Kibana 查看数据。
Metricbeat 将收集与连接相关的数据（活动、已处理、已接受等），以及客户端请求的总数。Filebeat 将收集与访问日志和错误日志相关的数据。收集的信息会因不同的设置而有所变化，但在大多数情况下，我们可以使用这些信息来推断某些事情，例如：
<ul>
	<li>如果针对某个资源的错误日志数出现陡增，则可能意味着我们删除了一个仍在需要的资源。</li>
	<li>访问日志就可以了解一项服务出现峰值的时间（从而可以确定执行维护之类操作的最佳时间）。</li>
	<li>如果客户端请求数突然出现陡增，则表明可能有恶意攻击（如 DDOS 攻击）。</li>
</ul>本文的重点是介绍监测功能，因此，像 ElasticSearch 设置这样的内容将简单带过。我使用的是 Mac 系统，所以将会使用 Elasticsearch、Metricbeat、Filebeat 和 Kibana 的 Mac 发行版。有关其他平台的发行版，<a href="/downloads/">可以从下载页面获取</a>。
<h2>安装 Elasticsearch</h2><a href="/products/beats/metricbeat">Metricbeat</a> 和 <a href="/products/beats/filebeat">Filebeat</a>（实际上是所有 <a href="/products/beats/">Beats</a>）都需要 Elasticsearch 集群来存储数据。我们将在本地设置一个简单的 Elasticsearch 集群。由于我们未对外公开 Elasticsearch，所以我们无需花费时间<a href="/blog/getting-started-with-elasticsearch-security">配置安全性</a>。
<h4>第 1 步：下载 Elasticsearch</h4><pre class="prettyprint">curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.0-darwin-x86_64.tar.gz
</pre><h4>第 2 步：解压缩存档文件</h4><pre class="prettyprint">tar -xvf elasticsearch-7.1.0-darwin-x86_64.tar.gz
</pre><h4>第 3 步：更改为 bin 目录</h4><pre class="prettyprint">cd elasticsearch-7.1.0/bin
</pre><h4>第 4 步：启动我们的单一节点集群</h4><pre class="prettyprint">./elasticsearch
</pre>默认情况下，您的集群将在 <code>localhost:9200</code> 运行。
<h2>运行 Nginx</h2>有许多途径可以运行 Nginx — 在主机上独立运行、通过 Docker 容器运行，或者在 Kubernetes 设置中运行等等。Beats 具有自动发现功能，可在服务器容器加速和被删除时侦听容器 API 事件，以跟踪服务器容器。
鉴于 Nginx 可以通过多种方式进行设置和配置，本文将不做过多假设，并会展示主机配置和自动发现（在本用例中是 Docker）示例。
<h2>配置 Metricbeat 和 Filebeat</h2>现在，我们将配置 Beats 来开始收集和发送数据。
<h3>Metricbeat</h3>我们将使用 Metricbeat 收集指标。
<h4>第 1 步：下载 Metricbeat：</h4><pre class="prettyprint">curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-7.1.0-darwin-x86_64.tar.gz
</pre><h4>第 2 步：解压缩存档文件</h4><pre class="prettyprint">tar -xvf metricbeat-7.1.0-darwin-x86_64.tar.gz
</pre><h4>第 3 步：更改目录</h4><pre class="prettyprint">cd metricbeat-7.1.0-darwin-x86_64
</pre>配置时间！
默认情况下，配置文件 (metricbeat.yml) 将查找在 localhost:9200 运行的 Elasticsearch 集群，这是我们早前配置好的。
<h4>第 4 步：启用相关的 Metricbeat 模块</h4>默认情况下，仅收集系统级别的指标：
<pre class="prettyprint">./metricbeat modules enable nginx
</pre><h4>第 5 步：更改文件所有权</h4>我们需要更改几个文件的所有权，因为我们将以根用户身份运行 Metricbeat（或者，您可以选择在命令行中使用 --strict.perms=false 选项来禁用严格的权限检查）：
<pre class="prettyprint">sudo chown root metricbeat.yml 
sudo chown root modules.d/system.yml 
sudo chown root modules.d/nginx.yml
</pre><h4>第 6 步：启用指标集</h4>如果打开 <code>modules.d/nginx.yml</code> 文件，即可启用 <code>stubstatus</code> 指标集，包括取消注释以下内容：
<pre class="prettyprint">#metricsets:
# - stubstatus
</pre>这个指标集从 Nginx <a href="https://nginx.org/en/docs/http/ngx_http_stub_status_module.html">ngx_http_stub_status</a> 模块收集数据，因此，请务必配置此 Nginx 模块以便指标集正常工作。
此外，您还可以更改此处监测的主机，默认情况下监测的是 <code>&lt;a href="http://127.0.0.1">http://127.0.0.1&lt;/a></code>。对于基于主机的设置，这就是我们需要的所有信息。
<h4>第 7 步：自动发现设置（备选）</h4>使用<a href="/guide/en/beats/metricbeat/7.1/configuration-autodiscover.html">自动发现</a>设置时，在三个提供程序（Docker、Kubernetes 和 Jolokia）之间的等效配置将会有所不同。Docker 示例将如下所示，其中我们在 <code>metricbeat.yml</code> 配置文件底部添加了 <code>metricbeat.autodiscover</code>。
<pre class="prettyprint">metricbeat.autodiscover:
 providers:
 - type: docker
 templates:
 - condition:
 contains:
 docker.container.image: nginx
 config:
 - module: nginx
 metricsets: ["stubstatus"]
 hosts: "${data.host}:${data.port}"
</pre>使用此配置后，将会匹配使用名称中含 Nginx 的图像的所有 Docker 容器（<a href="/guide/en/beats/metricbeat/7.1/defining-processors.html#conditions">contains 将执行子字符串匹配，而不是精确匹配</a>），并将使用一个 config 来启用带有子状态指标集的 Nginx 模块。
<h4>第 8 步：运行 Metricbeat</h4>很好，现在我们已经配置好了，我们接着可以运行带有标志的 Metricbeat，将日志发送到 stderr 并禁用 syslog/文件输出：
<pre class="prettyprint">sudo ./metricbeat -e
</pre>如果一切正常，您应该看到一些初始输出，然后在 Metricbeat 每次将数据发回集群时看到更多的输出。
<h3>Filebeat</h3>我们将使用 Filebeat 收集日志。
<h4>第 1 步：下载 Filebeat</h4><pre class="prettyprint">curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.1.0-darwin-x86_64.tar.gz
</pre><h4>第 2 步：解压缩存档文件</h4><pre class="prettyprint">tar -xvf filebeat-7.1.0-darwin-x86_64.tar.gz
</pre><h4>第 3 步：更改目录</h4><pre class="prettyprint">cd filebeat-7.1.0-darwin-x86_64
</pre><h4>第 4 步：启用 Nginx 模块</h4><pre class="prettyprint">./filebeat modules enable nginx
</pre>默认情况下，将收集访问日志和错误日志。至于日志文件路径，Filebeat 将尝试根据您的操作系统来确定这些路径，如果您需要显式设置不同的路径，则可以在 modules.d/nginx.yml 配置文件中设置路径。
<h4>第 5 步：更改文件所有权</h4><pre class="prettyprint">sudo chown root filebeat.yml
sudo chown root modules.d/nginx.yml
sudo chown root module/nginx/access/manifest.yml
sudo chown root module/nginx/error/manifest.yml
</pre>对于基于主机的设置，这些就是我们需要的所有信息。
<h4>第 6 步：自动发现设置（备选）</h4>如上所述，需要额外配置才能使用自动发现。与前面部分类似，Docker 示例需要将自动发现部分添加到 config 中，filebeat.yml 将类似如下所示：
<pre class="prettyprint">filebeat.autodiscover:
 providers:
 - type: docker
 templates:
 - condition:
 contains:
 docker.container.image: nginx
 config:
 - module: nginx
 access:
 input:
 type: docker
 containers.ids:
 - "${data.docker.container.id}"
 error:
 input:
 type: docker
 containers.ids:
 - "${data.docker.container.id}"
</pre>其中我们会配置访问选项和错误选项，以使用 <a href="/guide/en/beats/filebeat/7.1/filebeat-input-docker.html">Docker 输入</a>。Docker 输入将在其路径（Docker 日志所在的基本路径，默认情况下为 <code>/var/lib/docker/containers）</code>下搜索容器日志。我们使用<a href="/guide/en/beats/filebeat/7.1/configuration-autodiscover.html#_docker_2">与模板条件匹配的容器 ID</a> 指定 <code>containers.ids</code>。总而言之，日志（默认情况下）将来自 <code>/var/lib/docker/containers/ac29b98ad83ca43bb4c15ae8f0d03aff8c7d57bf5dee9024124374b92b14b0f2/</code>（ID 会有所不同）。
<h4>第 7 步：运行 Filebeat</h4><pre class="prettyprint">sudo ./filebeat -e
</pre><h2>安装 Kibana</h2>至此，我们有了 Metricbeat 和 Filebeat 来发送关于 Nginx 服务器的数据，接下来我们需要一种途径来查看这些数据，这就要使用 Kibana 了。
<h4>第 1 步：下载 Kibana</h4><pre class="prettyprint">curl -O https://artifacts.elastic.co/downloads/kibana/kibana-7.1.0-darwin-x86_64.tar.gz
</pre><h4>第 2 步：解压缩存档文件并更改目录</h4><pre class="prettyprint">tar -xzf kibana-7.1.0-darwin-x86_64.tar.gz
</pre><pre class="prettyprint">cd kibana-7.1.0-darwin-x86_64
</pre><h4>第 3 步：运行 Kibana</h4><pre class="prettyprint">./bin/kibana
</pre>默认情况下，Kibana 将使用 Elasticsearch 主机 <code>http://localhost:9200</code>，并可从 <code>http://localhost:5601</code> 访问 Kibana。
如果您导航到 <a href="http://localhost:5601"><code>http://localhost:5601</code></a>，应会看到以下欢迎内容：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltad0c6331722acdc1/5d2dba9c9f0a7673f0580236/nginx-monitoring-image1.png" data-sys-asset-uid="bltad0c6331722acdc1" alt="“Welcome to Kibana”（欢迎使用 Kibana）屏幕" style="display: block; margin: auto;" width="420" height="530">
您可以选择尝试操作样本数据，但在这里我们将单击 Explore on my own（浏览我自己的数据）。
<h2>在 Kibana 中可视化 Nginx 数据</h2>接下来，我们将介绍如何使用 Kibana 查看和分析数据。
<h3>基础架构</h3>如果我们导航到 Kibana 侧栏上的“Infrastructure”（基础架构）应用，将能够看到基础架构（最后一刻）的快照视图。根据所使用的配置，可以在“Hosts”（主机）下访问基于非自动发现的设置的数据，对于自动发现的设置，Docker 和 Kubernetes 按钮（基于所使用的提供程序）将引导您访问正确的数据集：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1873b9142f8f4dc9/5d2d374e9f0a7673f057fe6c/nginx-monitoring-image2.png" data-sys-asset-uid="blt1873b9142f8f4dc9" alt="Hosts（主机）、Kubernetes 和 Docker 按钮" style="display: block; margin: auto;" width="420" height="100">
因为我使用的是基于主机的设置，所以我可以单击“Hosts”（主机）按钮，查看正在从 Metricbeat 发送的下列数据：
<h2><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2594e5bbb16134f9/5d2d37839f0a7673f057fe72/nginx-monitoring-image3.png" style="background-color: initial; font-family: proximaNovaRegular, Arial, Helvetica, sans-serif; font-size: 14px; color: rgb(116, 133, 144); display: block; margin: auto;" data-sys-asset-uid="blt2594e5bbb16134f9" alt="单击“Hosts”（主机）按钮可查看正在发送的数据"></h2>如果我们选择其中一个节点，并选择查看指标，则可以看到一个针对该单一 Nginx 服务器的详细指标页面。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt134bbe8e86663c4b/5d2d37bdae880b03aa40661e/nginx-monitoring-image4.png" data-sys-asset-uid="blt134bbe8e86663c4b" alt="显示服务器指标的 Kibana 图表" style="display: block; margin: auto;">
<h3>日志</h3>如果导航到“Logs”（日志）应用，我们将能够看到从 Filebeat 发送来的访问日志和错误日志。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt79961499be8a9f3b/5d2d3803ae880b03aa406624/nginx-monitoring-image5.jpg" data-sys-asset-uid="blt79961499be8a9f3b" alt="显示错误日志和访问日志的 Kibana Logs 应用" style="display: block; margin: auto;">
<h3>预配置的 Nginx 仪表板</h3>至此，我们已经有了 Kibana 的正在运行和可访问的实例，我们接下来可以加载一些预制的仪表板。
要加载 Metricbeat 仪表板，请在 Metricbeat 目录中运行以下命令：
<pre class="prettyprint">sudo ./metricbeat setup --dashboards
</pre>对 Filebeat 执行相同命令：
<pre class="prettyprint">sudo ./filebeat setup --dashboards
</pre>现在，如果我们导航到 Kibana 中的“Dashboards”（仪表板）选项卡，应看到以下内容：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf6e6bf414a9c13c8/5d2d383eb3c3b6032396a3d7/nginx-monitoring-image6.jpg" data-sys-asset-uid="bltf6e6bf414a9c13c8" alt="显示可用仪表板的 Kibana 页面" style="display: block; margin: auto;">
如果将范围缩小到“nginx”搜索，我们将看到以下可用的仪表板：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltcf3ccffbb71a48aa/5d2d38bb2eb7167479193ecf/nginx-monitoring-image7.png" data-sys-asset-uid="bltcf3ccffbb71a48aa" alt="显示可用 Nginx 仪表板的 Kibana 页面" style="display: block; margin: auto;" width="720" height="390">
例如，[Filebeat Nginx] 访问日志和错误日志 ECS 仪表板将类似如下所示：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt51e7d57d2a6b575d/5d2d38f88e6f797b0da30462/nginx-monitoring-image8.jpg" data-sys-asset-uid="blt51e7d57d2a6b575d" alt="Filebeat Nginx 访问日志和错误日志 ECS" style="display: block; margin: auto;">
至此，我们已经学习了如何使用 Elastic Stack 来监测 Nginx 服务器。其中可以使用各种选项（例如，不同的分组和筛选选项）来深入了解对您真正重要的信息。
<h2>亲自试用</h2>Elastic Stack 入门非常简单 — 您可以通过提供的 curl 命令下载各种产品，也可以浏览我们的<a href="/downloads/">下载</a>页面，从中获取产品。甚至更为简单的是，可以先注册获得 <a href="/cloud/elasticsearch-service/signup">Elasticsearch 服务</a>的 14 天免费试用，然后再获取产品。如果遇到任何问题，可以访问<a href="https://discuss.elastic.co/">讨论</a>论坛来了解更多信息。

monitor-nginx-blog-banner.jpg

monitor-nginx-blog-thumb.jpg

How to monitor NGINX web servers with the Elastic Stack

如何使用 Elastic Stack 监测 Nginx Web 服务器

响应速度和相关度是非常重要的。但搜索体验同样重要！Elastic App Search 和 React 可以协助您打造引人入胜的搜索体验。

当用户搜索某个内容时，他们希望获得相关的结果。但相关的结果只是赢得访客好感的一部分因素；为用户提供良好的搜索体验也很重要。搜索不仅要快速，积极响应用户输入，还要让用户感觉到智能和高效。本教程将通过演示如何使用 React 和 <a href="https://github.com/swiftype/swiftype-app-search-javascript" target="_self">Elastic App Search JavaScript 客户端</a>打造流畅、强大的搜索体验，向您讲授应用程序搜索方面的知识。最后，您会得到一个外观好看、相关度高、基于 React 构建的应用程序；使用该应用程序，您可以按分面和作为 URI 一部分维护的状态进行排序，实时搜索各种 npm 包。完整的代码可以在 <a href="https://github.com/swiftype/app-search-demo-react" target="_self">GitHub</a> 上找到。<hr/>刚好！我们新发布了一篇文章，其中介绍了如何使用 Search UI（Elastic 的一个开源库）更快地打造出色的搜索体验。<a href="/cn/blog/how-to-build-great-react-search-experiences-quickly" target="_self">读一读吧</a>！<hr/><h2>要求</h2>要开始操作，您需要具备以下内容：<ol><li>最新版本的 <a href="https://nodejs.org/en/" target="_self">Node.js</a>。</li><li>最新版本的 <a href="https://www.npmjs.com/" target="_self">npm</a>。</li><li>Elastic App Search Service 账号或有效的 <a href="https://info.elastic.co/app-search-trial.html?elektra=blog" target="_self">14 天免费试用版</a>。</li><li>大约 30 分钟的时间。</li></ol><h2>App Search 简介</h2>应用程序是围绕数据构建的。Facebook 以一种有趣的方式呈现“朋友”数据，迅速占据了我们的社交圈。eBay 最初是寻找和购买二手商品的最便捷方式。维基百科让读者可以更轻松地了解万事万物！应用程序的存在是为了解决数据问题。在这方面，搜索是必不可少的伙伴。如果是主流的应用程序，搜索将是它所提供服务中的关键部分：查找朋友、产品、对话或文章。数据集越大、越有趣，应用程序就会越受欢迎，尤其是在搜索相关性高且可获得回报的情况下。<a href="/cn/cloud/app-search-service" target="_self">Elastic App Search</a> 是在 <a href="https://github.com/elastic/elasticsearch" target="_self">Elasticsearch</a> 的基础上构建的，Elasticsearch 是一个开源的分布式 RESTful 风格搜索引擎。使用 Elastic App Search，开发人员可以访问一组性能稳健的 API 终端，这些终端经过优化，可以处理高级应用程序搜索用例。<h2>开始构建引擎</h2>首先，在 App Search 中创建一个引擎。引擎会采集用于编制索引的对象。您的数据就是对象；它可以是朋友的资料、产品或维基页面。将数据采集到 App Search 中之后，就会根据灵活的模式为数据建立索引，并针对搜索进行优化。这样，我们可以利用不同的客户端库来打造愉快的搜索体验。在本示例中，我们将调用 node-modules 引擎。引擎创建完成后，我们需要<a href="https://app.swiftype.com/as/credentials" target="_self">凭据</a>页面中的三个信息:<ol><li>主机标识符，前缀为 host-</li><li>专用 API 密钥，前缀为 private-</li><li>公共搜索密钥，前缀为 search-</li></ol>有了这些信息，我们就可以克隆项目，进入目录，签出 starter 分支，然后运行 npm install：<pre class="prettyprint" style="font-size: 12.6px;">$ git clone https://github.com/swiftype/app-search-demo-react.git $ cd react-tutorial && git checkout starter && npm install </pre>太好了，我们已经准备好应用程序。但搜索需要数据...<h2>采集 ~</h2>在大多数情况下，您的对象将存放在数据库或后端 API 中。在本示例中，我们将使用静态 .json 文件。存储库包含两个脚本：init-data.js 和 index-data.js。init-data.js 是一个抓取器，用于从 npm 获取格式良好的 node-module 数据。数据存在于 node-modules.json 文件中。index-data.js 是一个索引器，它会将数据采集到 App Search 引擎中，为其建立索引。为了运行索引器脚本，我们需要同时传递主机标识符和专用 API 密钥。<pre class="prettyprint" style="font-size: 12.6px;">$ REACT_APP_HOST_IDENTIFIER={Your Host Identifier} \ REACT_APP_API_KEY={Your Private API Key} \ npm run index-data </pre>对象以 100 个为一批快速发送到我们的 App Search 引擎，然后构建索引。现在，我们应该为新创建的<a href="https://app.swiftype.com/as/engines/node-modules" target="_self">引擎</a>创建一个仪表板，其中有大约 9,500 个 npm 包被索引为文档。浏览一下这些数据，熟悉其中的内容，可能会有所帮助。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb780390565978c73/5c304feb5a7621286e3e90af/app_search_engine_overview.png" data-sys-asset-uid="bltb780390565978c73" alt="app_search_engine_overview.png" style="margin-top: auto;margin-right: auto;margin-bottom: auto;margin-left: auto;display: block;"/><h2>响应能力</h2>引擎填充了数据并准备好之后，我们就可以开始构建核心应用程序了。<pre class="prettyprint" style="font-size: 12.6px;">$ npm start </pre>从项目目录中启动 npm 将打开 React 样板文件。它从 App.cs 中提取样式，让我们可以更好地根据自身需求进行定制。之后，我们将需要一个搜索框，在其中输入搜索查询。用户会寻找这些有用的矩形，因为搜索引擎和浏览器已经让用户形成习惯：在这里输入，找到想要的内容！<pre class="prettyprint" style="font-size: 12.6px;">//App.css ... .App-search-box { height:40px; width:500px; font-size:1em; margin-top:10px; } </pre>我们还需要将 App Search 的访问凭据放在一个安全的地方，比如 .env 文件中。在项目根目录下创建一个 .env 文件并进行填充，如下所示：<pre class="prettyprint" style="font-size: 12.6px;">//.env REACT_APP_HOST_IDENTIFIER={your host identifier, prefixed with <code>host-</code>} REACT_APP_SEARCH_KEY={your public search key, prefixed with <code>search-</code>} </pre>将变量安全地隐藏起来后，我们就可以开始编写搜索逻辑了。<h2>开始搜索</h2>App.js 文件中存放了核心逻辑。这个文件和其他大多数启动文件都是由 <a href="https://github.com/facebook/create-react-app" target="_self">create-react-app</a> 创建的；create-react-app 是一个无需任何配置即可引导 React 应用程序启动的工具。在编写一些逻辑来测试搜索之前，我们需要安装 Swiftype App Search JavaScript 客户端库：<pre class="prettyprint" style="font-size: 12.6px;">$ npm install --save swiftype-app-search-javascript </pre>将以下代码放入 App.js 中。它将执行基本搜索。我们将把 foo 硬编码为我们的示例搜索词：<pre class="prettyprint" style="font-size: 12.6px;">import * as SwiftypeAppSearch from "swiftype-app-search-javascript"; const client = SwiftypeAppSearch.createClient({ hostIdentifier: process.env.REACT_APP_HOST_IDENTIFIER, apiKey: process.env.REACT_APP_SEARCH_KEY, engineName: "node-modules" }); //我们可以查询任何内容，以 <code>foo</code> 为例。 const query = "foo"; const options = {}; client.search(query, options) .then(resultList => console.log(resultList)) .catch(error => console.log(error)) </pre>浏览器将刷新，并通过 console.log 创建一个 resultList 数组。要查看这个数组，我们可以打开浏览器的开发人员控制台。我们可以用另一个字符串替换 foo 查询，这样可以尝试更多的查询。更改了查询并刷新页面后，可以看到调整后的结果集。太棒了！这样我们就已经在 node-module 中进行搜索了。<h2>结果良好</h2>我们用一个简单的模式进行搜索，但是隐藏在 console.log 中的结果没有什么用处。我们将删除基本的 React 样式和之前的代码，然后进行扩展。我们将创建以下内容：<ol><li>一个状态变量，它将包含一个响应属性。</li><li>一个 performQuery 方法，它将使用 client.search 来查询 App Search。它将查询结果存储在响应属性中。</li><li>一个 componentDidMount 生命周期挂钩，它将在应用程序加载时运行一次。我们将再次查询 foo，但可以使用任何想要的查询。</li><li>结构化 HTML，用于保存结果数据输出和结果总数。</li></ol><pre class="prettyprint" style="font-size: 12.6px;">//App.js // ...已截断！ class App extends Component { state = { 	// 一个新的状态属性，用于保存最近的查询响应 	response: null }; componentDidMount() { 	/*在 componentDidMount 中调用此方法可以确保结果 	在应用首次加载时显示在屏幕上*/ 	this.performQuery("foo"); } // 用于执行查询并存储响应的方法 performQuery = queryString => { 	client.search(queryString, {}).then( 	response => { 	// 现在添加此行可以检查完整的响应 	console.log(response); 	this.setState({ response }); 	}, 	error => { 	console.log(`error: ${error}`); 	} 	); }; render() { 	const {response} = this.state; 	if (!response) return null; 	return ( 	<div className="App"> 	<header className="App-header"> 	<h1 className="App-title">Node Module Search</h1> 	</header> 	{/*显示此查询的结果总数*/} 	<h2>{response.info.meta.page.total_results} Results</h2> 	{/*遍历结果，并显示它们的 Name 和 Description*/} 	{response.results.map(result => ( 	<div key={result.getRaw("id")}> 	Name: {result.getRaw("name")} 	Description: {result.getRaw("description")} 	</div> 	))} 	</div> 	); } } // ...已截断！ </pre>我们点击保存的那一刻，结果将出现在 http://localhost:3000 中，共有 27 条结果，还有一些看起来很美观的模块。如果出现问题，我们可以检查控制台，因为我们在代码中嵌套了两个 console.logs。<h2>出色的搜索框填充</h2>我们一直将 foo 硬编码到查询中。搜索的最大价值在于它始于自由的表达。当您开发出了出色的搜索体验后，就能针对更常用的表达进行优化，从而创建出相关度最高的结果集。这一切都始于一个空白的画板：搜索框。为了打造一个强大的搜索框，我们将向 state 添加一个名为 queryString 的属性。为了用新字符串更新 queryString，我们将创建一个 updateQuery 方法；利用 onChange 句柄来更新 queryString，并在每次用户更改搜索框中的文本时触发新的搜索。我们完整的 App 类现在如下所示：<pre class="prettyprint" style="font-size: 12.6px;">//src/App.js // ...已截断！ class App extends Component { state = { 	// 一个新的状态属性，用于跟踪搜索框中的值 	queryString: "", 	response: null }; componentDidMount() { 	// 删除“node”的硬编码搜索 	this.performQuery(this.state.queryString); } // 每次用户在搜索框中输入时，处理 <code>onChange</code> 事件。 updateQuery = e => { 	const queryString = e.target.value; 	this.setState( 	{ 	queryString // 保存用户输入的查询字符串 	}, 	() => { 	this.performQuery(queryString); // 触发新的搜索 	} 	); }; performQuery = queryString => { 	client.search(queryString, {}).then( 	response => { 	this.setState({ 	response 	}); 	}, 	error => { 	console.log(`error: ${error}`); 	} 	); }; render() { 	const {response, queryString} = this.state; 	if (!response) return null; 	return ( 	<div className="App"> 	<header className="App-header"> 	<h1 className="App-title">Node Module Search</h1> 	</header> 	{/*一个搜索框，连接到我们的查询字符串 value 和 onChange 	句柄*/} 	<input 	className="App-search-box" 	type="text" 	placeholder="Enter a search term here" 	value={queryString} 	onChange={this.updateQuery} 	/> 	<h2>{response.info.meta.page.total_results} Results</h2> 	{response.results.map(result => ( 	<div key={result.getRaw("id")}> 	Name: {result.getRaw("name")} 	Description: {result.getRaw("description")} 	</div> 	))} 	</div> 	); } } // ...已截断！ </pre><h2>Debounce 方法！</h2>在这个迭代中，每次在搜索框中检测到更改时都会进行搜索，这种操作对我们的系统来说可能过于密集。为了解决这个问题，我们将应用一个由 <a href="https://lodash.com/" target="_self">Lodash</a> 提供的 _debounce_ 函数。<pre class="prettyprint" style="font-size: 12.6px;">$ npm install --save lodash </pre>Debounce 是一种基于定义的毫秒数对入站请求数量进行速率限制的方法。可能遇到这样的情况：用户正在考虑如何表达他们的查询，输入了错别字，或者打字非常快，等等，因此，我们不需要对每个检测到的更改都进行查询。通过将 performQuery 方法封装在 Lodash 的 debounce 函数中，我们可以指定 200 毫秒的速率限制，即在下一次搜索查询开始之前，必须有 200 毫秒没有任何输入：<pre class="prettyprint" style="font-size: 12.6px;">//App.js // ...已截断！ import { debounce } from "lodash"; // Import debounce // ...已截断！ performQuery = debounce(queryString => { client.search(queryString, {}).then( 	response => { 	this.setState({ 	response 	}); 	}, 	error => { 	console.log(`error: ${error}`); 	} ); }, 200); // 200 毫秒。 // ...已截断！ </pre>限制速率除了让我们的服务器可以休息一下，还能帮助用户顺利地进行查询。这将大有帮助！毕竟用户感受十分重要。<h2>后续操作</h2>这是基于 React 构建高质量搜索体验的开始。往后，我们还可以添加很多出色的功能。我们可以添加样式或实现动态 App Search 功能，比如<a href="https://swiftype.com/documentation/app-search/guides/facets" target="_self">分面搜索</a>、<a href="https://swiftype.com/documentation/app-search/guides/curations" target="_self">结果管理</a>或<a href="https://swiftype.com/documentation/app-search/guides/search-customizations#relevance-tuning" target="_self">相关度调整</a>。或者，我们还可以探索<a href="/cn/blog/introducing-the-analytics-api-suite-in-elastic-app-search" target="_self">分析 API 套件</a>，发掘有关用户搜索活动的有价值的见解。如果我们想真正地深入了解，可以参阅主分支中的 <a href="https://github.com/swiftype/app-search-demo-react/blob/master/README.md" target="_self">README</a>，它对教程内容进行了扩展，创建了基于 URI 的状态管理，添加了巧妙的样式、分页、筛选和分面搜索。通过一些样式方面的定制，可以将它作为高质量搜索体验的基础。<h2>总结</h2>过去，构建相关度高且有价值的应用程序搜索是非常复杂的。通过 Elastic App Search 这种方便又可控的方法，您可以在 Web 应用程序中编写有价值、可微调的搜索引擎。最值得一提的是，不论是工程师还是不太懂技术的利益相关者，都可以在一个精巧而直观的仪表板中管理关键功能。您可以直接进入 App Search，<a href="https://info.elastic.co/app-search-trial-v9.html?ultron=how-to-build-application-search-with-react-and-elastic-app-search&blade=blog&hulk=cpc" target="_self">免费试用 14 天</a>，无需提供信用卡信息。

dazzling_full_bleed.jpg

dazzling_thumbnail.jpg

How to Build Application Search with React and Elastic App Search

如何使用 React 和 Elastic App Search 打造应用程序搜索体验

Kibana 6.1 引入了一个全新的实验性可视化类型：控件。控件提供了向 Kibana 仪表板添加交互式输入的功能。控件可用于创建两种类型的输入：下拉菜单和范围滑块。
在这篇文章中，我们将通过一个示例来说明如何使用这两种新输入。但让我们先看一段简短的视频（时长 2:23），了解我们将要执行的步骤。
<div class="video embed-container" style="height: 478px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/LS4ij6jVJvcwBDdvXpwQHv.jpg" data-uuid="LS4ij6jVJvcwBDdvXpwQHv" data-v="4" data-type="inline">

</div>在开始使用控件可视化之前，我们需要使用数据集来设置 Elastic Stack。Nick Peihl 最近发表了一篇博文“<a href="https://www.elastic.co/cn/blog/visualizing-france-salary-data-with-region-maps-in-kibana">在 Kibana 中使用区域地图，从而将法国工资数据可视化</a>”。我想接着 Nick 的话茬，演示如何使用控件来提供交互式仪表板。关注 Nick 的博客，了解如何将 <a href="https://www.kaggle.com/etiennelq/french-employment-by-town">INSEE 的就业、工资和法国城镇人口</a>数据集导入 Elasticsearch。别忘了在 Kibana 中创建一个新的索引模式来匹配 <code>france-example-*</code>。
<h2>创建下拉菜单和范围滑块</h2>我们首先创建一个下拉菜单输入，允许按区域进行筛选。下拉菜单选项列表是使用字词聚合的结果动态填充的。
首先切换到可视化应用程序，单击“<code>+</code>”按钮以创建新的可视化。向下滚动到“<code>Others</code>”部分并选择“<code>Controls</code>”。“<code>Options list</code>”已默认选中，因此只需单击“<code>Add</code>”。接下来，选择索引模式 <code>france-example-*</code>，选择字段 <code>Region_Name.keyword</code>，将大小设置为 25（数据集中有 25 个独一无二的区域）。最后，单击“<code>play</code>”。可视化将显示一个下拉菜单，其中包含 <code>france-example-*</code> 索引中字段 <code>Region_Name.keyword</code> 的字词聚合结果。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt38d4b5e89034bc45/5c3056a1b7017c456eff09d3/First_Shot.png" data-sys-asset-uid="blt38d4b5e89034bc45" alt="First Shot.png"> 
接下来，我们创建一个范围滑块，允许按净工资进行筛选。范围滑块的最小值和最大值是用最小值和最大值聚合的结果动态填充的。
选择“<code>Range slider</code>”并单击“<code>Add</code>”，即可添加范围滑块输入。选择索引模式 <code>france-example-*</code>，选择字段 <code>mean_net_salary</code>，然后单击“<code>play</code>”。可视化将显示一个范围滑块，它的范围由 <code>france-example-*</code> 索引中字段 <code>mean_net_salary</code> 上的最小值和最大值聚合的结果定义。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt276bca9250125b31/5c30569d760e7f7a666d6921/withSlider.png" data-sys-asset-uid="blt276bca9250125b31" alt="withSlider.png">
<h2>链接下拉菜单输入</h2>Kibana 6.3 中新增了链接下拉菜单输入的功能，这样第一个输入的选择将筛选第二个输入的字词。我们通过添加另一个下拉菜单控件来允许按城镇进行筛选，看看这个功能是怎样起作用的。
选择“<code>Options list</code>”并单击“<code>Add</code>”，即可添加另一个下拉菜单控件。选择索引模式 <code>france-example-*</code>，选择字段 <code>Town_Name.keyword</code>，然后将大小设置为 100。要将控件链接到区域控件，请选择父控件“region”。最后，单击“<code>play</code>”。可视化将显示另一个下拉菜单。在区域下拉菜单有值之前，下拉菜单将被禁用。然后，城镇下拉菜单将包含索引 <code>france-example-*</code> 中字段 <code>Town_Name.keyword</code> 上按所选区域筛选的字词聚合结果。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt121acde9b5ebb40c/5c305699e7a0881470c3a4af/allthree.png" data-sys-asset-uid="blt121acde9b5ebb40c" alt="allthree.png">
<h2>将所有内容整合到一起</h2>切换到仪表板应用程序，并创建一个新的仪表板。添加控件可视化，以及 <a href="https://www.elastic.co/cn/blog/visualizing-france-salary-data-with-region-maps-in-kibana">Nick 的博文</a>中创建的“按部门划分的平均性别工资比率 — 区域地图”可视化。将控件设置为感兴趣的值。单击“Apply changes”（应用更改），通过下拉菜单和范围滑块输入筛选数据集。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt64c02637fb32b01a/5c305697760e7f7a666d691b/withmap.png" data-sys-asset-uid="blt64c02637fb32b01a" alt="withmap.png">
<h2>后续操作</h2>控件可视化仍处于实验阶段。现在正是试用它的好时机，欢迎在我们的 <a href="https://discuss.elastic.co/c/kibana">Kibana 论坛</a>上提供反馈。您的反馈可以帮助改进未来的功能。

Kibana Intput Controls FullBleed.jpg

Kibana Input Controls thumbnail.jpg

Interactive Inputs on Kibana Dashboards

Kibana 仪表板上的交互式输入

如果您已经在组织中使用开源监测工具，那么可以将这些工具与 Elastic Stack 一起使用，来监测 Kubernetes。但是，如果您刚刚接触 Kubernetes 监测，不妨采用一种更简单的方法：使用 Filebeat 和 Metricbeat。

banner-blog-illustration-kubernetes.png

Beats

Logstash

thumb-blog-illustration-kubernetes.png

Monitoring Kubernetes the Elastic way using Filebeat and Metricbeat

用 Elastic 的方式使用 Filebeat 和 Metricbeat 监测 Kubernetes

Elasticsearch 背后的一个关键原则是，让您可以充分利用您的数据。最初，搜索是一种只读业务，搜索引擎从单一源加载数据。随着使用量的增加，Elasticsearch 在应用程序中的重要性与日俱增，数据需要由多个组件更新。多个组件会导致并发，而并发又导致了冲突。Elasticsearch 的版本控制系统就是帮助解决这些冲突的。<h2>举例说明版本控制的必要性</h2>为了说明情况，我们假设有一个网站，人们用它来评价 T 恤的设计。这个网站很简单。它列出了所有设计，用户可以对设计竖起大拇指，也可以使用拇指向下图标对设计投反对票。对于每件 T 恤，网站都会显示当前的赞成票与反对票的对比情况。每个搜索引擎的记录如下：<pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1' -d' { "name": "elasticsearch", "votes": 999 }' </pre>可以看到，每件 T 恤的设计都有一个名称和一个票数计数器，用于跟踪当前的对比情况。为了保持简单化和可扩展性，网站是完全无状态的。当有人浏览页面并点击赞成票按钮时，系统会向服务器发送一个 AJAX 请求，指示 Elasticsearch 更新计数器。为此，一个简单的实现方法是，获取当前的票数值，将其递增 1，然后发送给 Elasticsearch：<pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1' -d' { "name": "elasticsearch", "votes": 1000 }' </pre>这种做法有一个严重的缺陷，那就是可能会丢失票数。假设 Adam 和 Eve 同时在查看同一个页面。此时该页面显示票数为 999。由于这两个人都是支持者，他们都点击了赞成票按钮。现在，Elasticsearch 收到了上述请求的两个相同副本来更新文档，它很乐意这样做。这意味着总票数不再是 1001 票，而是现在的 1000 票。糟糕！当然， 使用更新 API 可以变得更加智能，并传达这样一个事实：投票数可以递增，而不是设置为特定值：<pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1/_update' -d' { "script" : "ctx._source.votes += 1" }' </pre>这样做的逻辑是，Elasticsearch 首先在内部检索文档，执行更新，然后再次执行索引。虽然这样做更有可能成功，但仍然存在与先前相同的潜在问题。在检索文档和再次执行索引之间的一个短暂的时间段内，可能会出现错误。为了处理上述情况，帮助解决更复杂的问题，Elasticsearch 提供了内置的版本控制系统。<h2>Elasticsearch 的版本控制系统</h2>您存储在 Elasticsearch 中的每一个文档都有一个相关的版本号。这个版本号是介于 1 和 2 63-1（包含本数）之间的一个正数。当您第一次对文档进行索引时，它会得到版本号 1，您可以在 Elasticsearch 返回的响应中看到这一点。例如，以下是本博文中第一个 cURL 命令的结果：<pre class="programlisting prettyprint lang-js">{ "ok": true, "_index": "designs", "_type": "shirt", "_id": "1", "_version": 1 } </pre>每次对这个文档执行写入操作（无论是 索引、更新还是删除），Elasticsearch 都会将版本号递增 1。这种递增是原子性的，并且保证会在操作成功返回时进行递增。Elasticsearch 还会在 get 操作的响应中返回文档的当前版本（请注意，这些都是实时的），此外，还会 收到指示，在每次搜索结果中都返回当前版本。<h2>乐观锁定</h2>回到我们的示例中，我们需要解决两个用户同时尝试更新同一文档的问题。传统的解决方法是锁定：在更新文档之前，一个人将获取文档锁，完成更新后再释放锁。对文档执行锁定后，就可以保证没有人能更改该文档。在许多应用程序中，这也意味着如果有人正在修改文档，则在修改完成之前，其他人都无法读取该文档。这种锁定方式虽然有效，但也需要付出代价。在高吞吐量的系统环境下，它有两个主要缺点：<ul><li>在许多情况下，根本不需要这样做。如果操作得当，极少会发生冲突。当然，冲突也会发生，但只占系统操作的一小部分。</li><li>锁定的前提是您真的需要这样做。如果您只是想要呈现一个网页，可以获取一些略微过时但一致的值，即使系统知道这些值即刻会发生变化也没关系。读取操作并不总是需要等到正在进行的写入操作完成。</li></ul>借助 Elasticsearch 的版本控制系统，可以轻松地使用另一种模式，即乐观锁定。不需要每次都获取锁，而是让 Elasticsearch 知道您希望找到哪个版本的文档。如果文档在此期间没有发生变化，则操作成功，不会锁定。如果文档中的某些内容发生了变化，有了更新的版本，Elasticsearch 会向您发出信号，让您适当地进行处理。回到上面的搜索引擎投票示例，来看看它的工作原理。当我们呈现一个关于衬衫设计的页面时，会记下文档的当前版本。这会随我们对页面发起的 get 请求的响应一起返回：<pre class="programlisting prettyprint lang-js">curl -XGET 'http://localhost:9200/designs/shirt/1' { "_index": "designs", "_type": "shirt", "_id": "1", "_version": 4, "exists": true, "_source": { "name": "elasticsearch", "votes": 1002 } } </pre>在用户投票后，如果在此期间没有发生任何更改，我们可以指示 Elasticsearch 仅索引新值 (1003)：（注意额外的 version 查询字符串参数）<pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1?version=4' -d' { "name": "elasticsearch", "votes": 1003 }' </pre>在内部，Elasticsearch 要做的是比较两个版本号。这比获取锁和释放锁要简单很多。如果没有人更改文档，操作将成功，状态代码为 200 OK。不过，如果有人更改了文档（导致内部版本号增大），操作将失败，状态代码为 409 Conflict。现在，我们的网站可以做出正确的响应。它会检索新文档，增加投票数，然后使用新版本值重试。这很有可能会成功。如果不成功，我们只需要重复执行上述过程。这种模式非常常见，Elasticsearch 的 更新终端都可以为您执行此操作。您可以设置 retry_on_conflict 参数，让它在版本发生冲突的情况下重试操作。在与脚本更新结合使用时，尤其方便。例如，下面这个 cURL 将告诉 Elasticsearch 在失败之前尝试更新文档最多 5 次：<pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1/_update?retry_on_conflict=5' -d' { "script" : "ctx._source.votes += 1" }' </pre>请注意，版本控制检查是一个完全可选的功能。您可以选择在更新某些字段（比如 votes）时强制执行版本控制，而在更新其他字段（通常是文本字段，比如 name）时忽略版本控制。这完全取决于应用程序的需求和您的权衡。<h2>已经有版本控制系统了吗？</h2>除了内部支持外，Elasticsearch 还可以很好地与其他系统维护的文档版本配合使用。例如，您可能将数据存储在另一个数据库中，它会为您维护版本控制，或者可能有一些应用程序特定的逻辑来决定版本控制的行为方式。在这种情况下，您仍然可以使用 Elasticsearch 的版本控制支持，指示它使用 external 版本类型。Elasticsearch 可以与任何数值的版本控制系统（1:263-1 范围内）配合使用，前提是保证每次对文档进行更改时，版本号的数值都会增大。若要让 Elasticssearch 使用外部版本控制，请在 每个更改数据的请求中添加 version_type 参数和 version 参数。例如：<pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1?version=526&amp;version_type=external' -d' { "name": "elasticsearch", "votes": 1003 }' </pre>在其他平台维护版本控制意味着 Elasticsearch 不一定知道其中的每一次更改。这对版本控制的实现有细微的影响。我们来看看上面的索引命令。使用 internal 版本控制，意味着“仅在文档的当前版本等于 526 时，才会对该文档更新进行索引”。如果版本匹配，Elasticsearch 会将版本号增加 1，并存储该文档。但是，如果使用外部版本控制系统，就无法强制执行此要求。版本控制系统可能并不是每次都递增 1。它或许会使用任意数字跳级增加（想想基于时间的版本控制）。或者，可能很难将每一次版本变更都传达给 Elasticsearch。鉴于所有这些原因，external 版本控制支持的行为会略有不同。将 version_type 设置为 external 后，Elasticsearch 将按照指定的版本号存储，不会递增版本号。此外，Elasticsearch 不会检查是否完全匹配，只会在当前存储的版本大于或等于索引命令中的版本时返回版本冲突错误。这实际上意味着“只有在没有其他人同时提供相同或更新版本的情况下，才会存储此信息”。具体来说，如果存储的版本号小于 526，上述请求就会成功。如果大于或等于 526，将导致请求失败。重要提示：使用 external 版本控制时，请确保始终将当前 version（和 version_type）添加到任何索引、更新或删除调用中。如果您忘记这样做，Elasticsearch 将使用它的内部系统来处理该请求，这会导致错误地递增版本号。<h2>最后关于删除的一些内容。</h2>删除数据可能会导致版本控制系统出现问题。一旦删除了数据，系统就无法正确地知道新请求是否已经过期，或者是否实际上包含了新信息。例如，假设我们运行以下代码来删除一条记录：<pre class="programlisting prettyprint lang-js">curl -XDELETE 'http://localhost:9200/designs/shirt/1?version=1000&amp;version_type=external' </pre>这个删除操作是文档的第 1000 个版本。如果我们将知道的所有信息都删除，未同步的后续请求就会出错：<pre class="programlisting prettyprint lang-js">curl -XPOST 'http://localhost:9200/designs/shirt/1/?version=999&amp;version_type=external' -d' { "name": "elasticsearch", "votes": 3001 }' </pre>如果我们忘记了该文档曾经存在过，就会接受这个调用，并创建一个新文档。但是，实际上，该操作的版本 (999) 指示这是旧版本，应继续删除该文档。您可能会说，这很简单，并不是真的删除所有内容，而是要记住删除操作、它们所引用的文档 ID 及其版本。虽然这确实解决了这个问题，但也有代价。如果有人重复执行索引文档再删除文档的操作，资源很快就会耗尽。Elasticsearch 搜索在两者之间实现了平衡。它会保留删除记录，但一分钟后就会忘记这些记录。这就是删除垃圾收集。对于大多数实际用例来说，60 秒足以让系统跟上进度，并让延迟的请求到达。如果您认为不够，可以进行更改，将索引的 index.gc_deletes 设置为其他时间范围。

Elasticsearch Versioning Support

Elasticsearch 版本控制支持

更新：本文提及我们的托管式 Elasticsearch 产品时使用的是旧称 Found。请注意，Found 现在称为 Elastic Cloud。
Elasticsearch 可用于许多不同的用例：“经典”全文本搜索、分析存储、自动完成工具、拼写检查工具、告警引擎以及通用文档存储。本文简要概述了各种常见用途和需要考虑的重要事项，同时说明了读者可参考哪些资源来了解详细信息。
<section id="introduction" class="level2">
 <h2><a href="#introduction">简介</a></h2>
 在 Found 中，我们看到 Elasticsearch 有许多不同的用例。我们经常被问到“你们的典型客户是谁？”，但除了“他们宁愿花时间构建，也不愿意处理一堆集群！”之外，并没有明确的答案。我们了解到，Elasticsearch 有许多超赞的用途，有些用途甚至令人不可思议！
 鉴于 Elasticsearch 仍然相当不成熟，我们的客户倾向于先在特定项目中使用 Elasticsearch，然后再加入更多的集群进行日志记录和分析。
 一般来说，开发过程最初是为网站或文档集合构建简单的搜索。然后，可能会添加分面导航，以及拼写检查或“您是不是要找？”的回答。也许有必要添加模糊搜索和自动完成功能，甚至可能还要添加“输入即搜索”。由于相关度很重要，最终可能会根据用户的身份角色、用户所在的位置或用户认识的人添加更高级的排名方案。当然，要知道用户实际做了什么，就必须记录使用情况并存储指标，这样我们就能知道一切都在正常运行。
 您可以使用 Elasticsearch 实现所有这些功能甚至更多功能，但是不同用途会产生截然不同的复杂性和资源需求。
</section>
<section id="you-know-for-search-and-counting" class="level2">
 <h2><a href="#you-know-for-search-and-counting">众所周知的用途是搜索！（而且还在不断增加！）</a></h2>
 不出意外的话，Elasticsearch 经常用于执行“搜索”，这通常意味着有一个带有放大镜图标的输入框。我们在这里所说的“搜索”可能会有歧义，因此我们将采用更具体的叫法。例如，我会将不同类型的搜索称为“简单搜索”、“模糊搜索”、“聚合”，简单指的是通过一个简单的 match 查询就能实现的搜索。
 让很多人没有想到的是，简单搜索是 Elasticsearch 可以执行的资源消耗量最小的任务之一。如果您需要的只是常规、非模糊 match 查询的前十个结果，可通过每秒数百次的速度在价格低廉的硬件上持续搜索数千万个文档集合。但是，如果在需求列表中添加模糊搜索或分面导航，CPU 和内存需求就会大大增加。
 现代搜索界面通常会有某种分面导航，以便用户快速了解搜索结果的分布情况。由特定作者撰写、处于特定价格范围且具有特定评分的书籍有多少？这些都是使用 Elasticsearch 中的聚合实现的，聚合的形式多种多样。您可以对词条、数值范围、日期范围、地理距离等进行聚合。
 令很多人想不到的是，从数百万份文档中筛选出匹配文档要比以各种方式统计和聚合匹配文档更加轻松。尽管如此，与信息检索问题“哪十个文档与这些条件相匹配（且相关度最高）？”相比，聚合成本高昂。在通过评分找出最佳文档时，Lucene 会使用一些技巧，比如“这组文档不匹配其他文档匹配的所有内容，所以不可能是最佳文档，直接跳过”。 在筛选时，<a href="/cn/blog/found-optimizing-elasticsearch-searches#find-a-friend-in-filters">Elasticsearch 会大量使用筛选缓存</a>。Elasticsearch 和 Lucene 的优势是尽可能减轻工作量，但使用聚合时，二者<a href="/cn/blog/found-optimizing-elasticsearch-searches#aggregation-abundance">始终需要计算所有匹配内容</a>。
 在<a href="/cn/blog/found-elasticsearch-from-the-bottom-up">自下而上认识 Elasticsearch</a> 中，我们介绍了倒排索引的工作原理，以及如何使用字典和发布列表执行简单的搜索。本文以及我们关于文本分析的文章应该清楚说明了为什么在使用搜索时务必正确处理文本。<a href="/cn/blog/found-sizing-elasticsearch#searching">Elasticsearch 规模调整</a>和<a href="/cn/blog/found-elasticsearch-in-production#a-typical-search-request">生产环境中的 Elasticsearch</a> 均详细说明了您可以如何使用内存。
</section>
<section id="analytics" class="level2">
 <h2><a href="#analytics">分析</a></h2>
 分析工作负载倾向于计数并汇总大量数据，甚至可能是大数据，不管这意味着什么！这些操作依赖于 <a href="/cn/blog/found-elasticsearch-aggregations">Elasticsearch 的聚合</a>，而聚合通常由 <a href="/cn/kibana">Kibana</a> 等工具生成。
 我们已经提到过，这些聚合在 CPU 和内存方面的成本十分高昂。对内存的需求很大，因为 Elasticsearch 需要快速查找给定文档的值，这就涉及到将所有文档的所有数据加载到“字段缓存”的内存中。使用<a href="/cn/blog/disk-based-field-data-a-k-a-doc-values">“文档值”</a>可以缓解这种情况，但在索引文档之前，需要在映射中启用“文档值”。
 此外，分析搜索的执行对象通常是<a href="/cn/blog/found-sizing-elasticsearch#timestamped-data">带有时间戳的数据，因此按时间划分索引（比如每日或每月索引）可能会比较合适</a>。每个时间单位有一个索引，这样易于减少搜索空间，并<a href="/cn/blog/curator-tending-your-time-series-indices">清理和存档旧数据</a>。
</section>
<section id="fuzzy-searching" class="level2">
 <h2><a href="#fuzzy-searching">模糊搜索</a></h2>
 模糊搜索是一种对拼写错误宽容的搜索。例如，在搜索 Levenstein 时，可以找到 Levenshtein。我们关于<a href="/cn/blog/found-fuzzy-search/">模糊搜索</a>的文章更加详细地介绍了模糊搜索的使用方法和工作原理。
 模糊搜索可轻松启用，并且可以大大提高“查全率”，但执行成本同样十分高昂。默认情况下，输入的一个词条会被改写为每个字段 50 个词条的 OR，再加上 multi_field，会导致<a href="/cn/blog/found-elasticsearch-top-down#query-rewriting">改写后的查询</a>中词条呈现组合爆炸式增长。
 在将搜索的更改和改进交付生产之前，请务必始终使用实际数据量对其进行测试。在添加 fuzziness 参数时尤其要这样做。这一选项可轻松启用，但会使您的搜索成本提高几个数量级。
 <blockquote>模糊搜索会消耗大量 CPU。请谨慎添加，而且可能不是每个字段都要添加。</blockquote>
</section>
<section id="autocompletion-and-instant-search" class="level2">
 <h2><a href="#autocompletion-and-instant-search">自动完成和即时搜索</a></h2>
 用户的输入即搜索有多种形式。可以是简单的建议（例如，现有标记），尝试根据搜索历史来预测搜索，或者只是为每个（受限制的）击键执行一次新搜索。
 Elasticsearch 中有很多不同的功能有助于构建这些功能，例如 prefix 查询、match_phrase_prefix、索引 ngram 以及一系列<a href="/cn/blog/you-complete-me/">不同的提示器</a>。
 这类搜索对延迟非常敏感。人类界定“即时”反应的阈值通常是 100 毫秒。搜索几乎每一个击键也会产生相当高的搜索吞吐量。因此，重要的是搜索成本低，这些索引与内存匹配。
 自动完成搜索，同时显示最有可能完成的搜索结果（与 Google 的操作相似），应该视为两个独立的搜索问题。当自动完成先前的搜索时，要搜索的数据量可能比搜索的内容少得多，这会将其全部保存在内存中，使模糊搜索更加容易实现。由于自动完成搜索的搜索负载要比全面搜索高得多，因此，将两者分开，则有可能在完全独立的 Elasticsearch 集群中单独进行扩展。
 Soundcloud 在改进搜索体验时，对搜索建议进行了提升。如果能够很好地实现，不仅会提高搜索精确度，还会明显减少支持全面搜索的基础架构的负载。人们搜索的内容通常呈 Zipf 分布：通常情况下，10% 的唯一搜索，会占有 90% 的搜索量 。因此，最佳搜索建议的全部结果很可能已缓存（在您的应用层），可以“即时”显示。
 Elasticsearch 的提示器功能的实现，离不开 Soundcloud 的搜索提示器背后的诸多工程。Muir 和 Willauer 曾就 <a href="https://www.youtube.com/watch?v=XrssyUPQcG4">Lucene 查询建议</a>做出精彩演讲，如需了解详情，强烈建议您观看。
</section>
<section id="multi-tenancy" class="level2">
 <h2><a href="#multi-tenancy">多租户</a></h2>
 通常情况下，您有多个客户或用户拥有单独的文档集合，用户永远无法搜索不属于自己的文档。在这种情况下，通常会导致采用各个用户拥有独立索引的设计。
 但这往往会导致索引数过多。几乎在每种情况下，我们都能看到按用户建立索引的功能已经实现，但实际上最好使用更大的 Elasticsearch 索引。使用大量小型索引有几个主要缺点：
 <ul>
 <li>内存开销无法忽视。数千个小型索引将消耗大量堆空间。文件描述符的数量也会激增。</li>
 <li>可能会出现大量重复内容。请考虑一下<a href="/cn/blog/found-elasticsearch-from-the-bottom-up">倒排索引的工作原理</a>，以及 Lucene 如何分段写入和压缩内容。</li>
 <li>快照/还原目前是连续的过程，每个索引都会产生开销。对数千个微型索引拍取快照所需的时间，比对几个大型索引拍取快照所需的时间要多一个数量级。</li>
 </ul>
 <a href="/cn/blog/found-sizing-elasticsearch#data-flows-and-their-partitioning-strategies">Elasticsearch 规模调整</a>提供了关于分片和分区策略的更多信息以及大量参考资料。修复索引设计欠佳的应用程序需要付出巨大的努力，因此，花时间去了解不同的方法是值得的。
 <blockquote>您可能不应为多租户应用程序的每个用户创建索引。</blockquote>
</section>
<section id="schema-free-user-defined-schemas" class="level2">
 <h2><a href="#schema-free-user-defined-schemas">模式自由/用户定义的模式</a></h2>
 对于拥有多个个人客户的情况，我们还发现，在很多用例中，不同的用户可能拥有完全不同的文档。例如，如果您要提供用户调查/问卷服务，不同的调查很可能包含完全不同的字段。
 通常的结果是使用 Elasticsearch 的“动态映射”，有时会宣传 Elasticsearch 不区分模式。但是，Elasticsearch 会在后台为您创建映射，如果映射变得过大，就会导致“<a href="/cn/blog/found-crash-elasticsearch#mapping-explosion">映射爆炸式增长</a>”，从而带来问题。因此，请务必确保文档中的值最终呈现为值，而非单独的字段。“<a href="/cn/blog/found-beginner-troubleshooting#keyvalue-woes">键/值问题</a>”和“。
 Elasticsearch 有各种映射功能，包括<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-templates.html">索引模板</a>、<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-root-object-type.html#_dynamic_templates">动态模板</a>、<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-core-types.html#_multi_fields_3">多字段</a>等。用起来！
 <blockquote>即使不使用映射，也要知道 Elasticsearch 为您创建了什么映射。</blockquote>
</section>
<section id="user-defined-searches" class="level2">
 <h2><a href="#user-defined-searches">用户定义的搜索</a></h2>
 与用户定义的模式有关通常表示需要让最终用户通过自定义筛选器、评分和聚合来定义其搜索。其中一种常见的方法是，将搜索请求限制在某些索引范围内，并且/或者使用筛选器包装用户的查询。
 即使这样做，当用户可以定义自定义搜索请求时，也有几种情况会造成严重破坏，例如搜索的表达占用大量 CPU、导致内存独占，或者导致 Elasticsearch 崩溃。这些主题在<a href="/cn/blog/found-crash-elasticsearch">导致 Elasticsearch 崩溃的六种情况</a>和<a href="/cn/blog/found-elasticsearch-security">保护您的 Elasticsearch 集群</a>中有所介绍。
 <blockquote>请务必谨慎处理用户定义的搜索请求。</blockquote>
</section>
<section id="crawling-and-document-processing" class="level2">
 <h2><a href="#crawling-and-document-processing">爬取和文档处理</a></h2>
 有许多方法可以将数据导入 Elasticsearch。
 河流是 Elasticsearch 的一个概念，表示 Elasticsearch 从源（比如 JDBC 连接的数据库、消息队列、Twitter 数据流或通过爬取网站）拉取数据。这些操作非常容易上手，但我们很快就可以发现，无论是在扩展方面还是在生产环境中运行，河流这一方法均具有挑战性。因此，“河流”已被弃用，我们应该寻求在 Elasticsearch 之外解决这些问题。<a href="/cn/logstash">Logstash</a> 一直在竭力支持更多系统，因此可以取代大量河流。对于自定义应用程序而言，在<a href="/cn/blog/found-keeping-elasticsearch-in-sync">将数据同步到 Elasticsearch</a> 和<a href="/cn/blog/found-document-processing">准备 Elasticsearch 文档</a>时，会遇到诸多挑战，河流这类简单通用的方法不足以应对此类挑战。在爬取时，人们将 <a href="http://blog.florian-hopf.de/2014/07/scrapy-and-elasticsearch.html">Scrapy</a> 和 <a href="http://nutch.apache.org/">Nutch</a> 与 Elasticsearch 结合使用。
 这涉及到将 Word 文档或 PDF 等文档处理和转换为 Elasticsearch 可以索引的纯文本。“mapper-attachments”插件可用于在 Elasticsearch 中完成此类转换。不过，虽然附件插件使用方便，但我们建议在将文档发送到 Elasticsearch 之前首先完成文档转换。这样，您就可以最大程度地<a href="/cn/blog/found-document-processing#external-systems-and-pipelines">控制文档的转换和优化</a>。诸如此类的文档转换通常是“内容优化”的“文档/文本处理管道”中的第一步。您发送到 Elasticsearch 的文档应该是“内容优化/准备”的结果，让 Elasticsearch 完成最终的文本处理和索引。文档转换虽然会大量占用 CPU，但却容易并行化。最好让 Elasticsearch 将时间花在索引和搜索上，让“上游”客户端完成文档转换。
 <blockquote>将处理后的数据推送到 Elasticsearch，而不是从 Elasticsearch 拉取数据并在其中进行处理。</blockquote>
</section>
<section id="summary" class="level2">
 <h2><a href="#summary">总结</a></h2>
 Elasticsearch 有很多内容需要学习，有时候很难知道自己需要学习哪些内容。
 本文介绍了一些常见用例，以及所有这些用例中需要注意的一些重要事项。希望您已经找到与自己的需求相关的新内容，并更快地将 Elasticsearch 应用程序投入生产。
</section>

Uses of Elasticsearch, and Things to Learn

Elasticsearch 的用途和注意事项

准备好试用 Elasticsearch 并查看结果了吗？复制并粘贴这些请求即可开始。

classroom_2000.jpg

classroom_720.jpg

A Practical Introduction to Elasticsearch

Elasticsearch 实用介绍

blog-banner-release-apm.png

how-to-apm-ruby-banner.png

How to instrument your Ruby app with the Elastic APM Ruby agent

如何使用 Elastic APM Ruby 代理装载 Ruby 应用

学习使用 Vega（一种基于 JSON 的开源声明性语言）在 Kibana 中构建丰富的可视化。

blog-vega-fb.jpg

blog-vega-thumb.jpg

Getting Started with Vega Visualizations in Kibana

Kibana 中 Vega 可视化入门

了解如何开始使用最新的 Elastic 和 Microsoft Azure 集成，从而简化各项操作并最大限度地掌控您的 Azure 环境。

我们最近宣布，<a href="https://www.elastic.co/cn/blog/experience-elasticsearch-microsoft-azure-portal">用户可以在 Azure 门户中查找、部署和管理 Elasticsearch</a>。这项新集成的入门体验非常简单，所有操作都可使用 Azure 门户和您熟悉的工具完成，您无需注册外部服务或配置账单信息，便可轻松部署 Elastic。 
在这篇博文中，您将了解如何在 Azure 上创建和管理 Elasticsearch 资源，以及如何自动将 Azure 日志和指标采集到 Elastic 中。请参阅我们的<a href="https://www.elastic.co/guide/en/cloud/current/ec-azure-marketplace-native.html">文档</a>，了解更多详细信息。
 <h3>从 Azure 控制台开始</h3>首先，登录 <a href="https://portal.azure.com">Azure</a> 门户。我们将系统介绍在 Azure 上创建 Elasticsearch 资源所需的步骤。在幕后，这个过程将使用 Elastic Cloud 配置一个平台订阅。
<ol>
	<li aria-level="1">确保您的 Azure 帐户在要部署 Elasticsearch 的订阅上配置了所有者访问权限。您可以阅读 <a href="https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/add-change-subscription-administrator#assign-a-subscription-administrator">Microsoft Azure 文档</a>，以了解有关 Azure 订阅的更多信息。</li>
</ol><ol start="2">
	<li aria-level="1">从 Azure 搜索栏中搜索 <code>Elasticsearch</code>。或者，您也可以从这个<a href="https://portal.azure.com/#blade/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/elastic.ec-azure-pp">市场列表</a>中访问该集成。</li>
	<li aria-level="1"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6482bdb25c932ce5/60a6b2b54adeb65c03d75564/search_bar.png" data-sys-asset-uid="blt6482bdb25c932ce5" alt="Screenshot of Azure portal search bar" style="display: block; margin: auto;"></li>
</ol><ol start="3">
	<li aria-level="1">单击 Add（添加），开始创建 Elasticsearch 资源。</li>
</ol><ol start="4">
	<li aria-level="1">输入所需的资源详细信息：</li>
</ol><ul>
	<li aria-level="1">Subscription（订阅）— 这个平台购买的订阅将位于 Azure 订阅项下。</li>
	<li aria-level="1">Resource group（资源组）— 资源组与 Elasticsearch 资源相关联</li>
	<li aria-level="1">Resource name（资源名称）— Elasticsearch 资源的名称</li>
	<li aria-level="1">Region（区域）— Elasticsearch 将部署到的区域。之后，还会陆续增加其他 Azure 区域。更多详情，请查看我们的<a href="https://www.elastic.co/guide/en/cloud/current/ec-azure-marketplace-native.html">文档</a>。</li>
	<li aria-level="1">Size（大小）— Elasticsearch 资源的大小。默认集群大小为 480GB 的存储空间和 16GB 的 RAM。创建资源后，您可以修改集群的大小。</li>
	<li aria-level="1">Pricing plan（定价套餐）— Elasticsearch 采用按需付费的定价模式。</li>
	<li aria-level="1">Price（价格）— 基于区域和部署大小的大致价格（创建资源后可编辑）。有关完整的价格列表，请参阅 <a href="https://cloud.elastic.co/pricing">Elastic Cloud 定价计算器</a>。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt452b884e92b42499/60a6d70feab8ca74ace852ab/Create_Elastic_R_(1).png" data-sys-asset-uid="blt452b884e92b42499" alt="Screenshot of how to create an Elastic resource" style="display: block; margin: auto;"></li>
</ul><ol start="5">
	<li aria-level="1">配置日志和指标。使用这些标志，可将 Azure 订阅活动日志和资源日志自动采集到您的 Elasticsearch 集群中。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0d68d246a02de40f/60a6d728a450c25ac83cf247/Create_Elastic_R.png" data-sys-asset-uid="blt0d68d246a02de40f" alt="Screenshot of how to create an Elastic resource" style="display: block; margin: auto;"></li>
</ol><ol start="6">
	<li aria-level="1">指定资源标签 — 与任何其他 Azure 资源都类似。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt00291734fc78835f/60a6d7af6a7d7e6562204c21/Create_Elastic_R_(2).png" data-sys-asset-uid="blt00291734fc78835f" alt="Screenshot of how to create an Elastic resource" style="display: block; margin: auto;"></li>
</ol><ol start="7">
	<li aria-level="1">复查您的信息并选择 Review + create（复查 + 创建）。这将部署 Elasticsearch。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltbb4938a1a15e6ecc/60a6cdd5b29743655f6324fe/Screenshots_-_En.png" data-sys-asset-uid="bltbb4938a1a15e6ecc" alt="Screenshot for creating an Elastic resource" style="display: block; margin: auto;"></li>
</ol>祝贺，您已成功在 Azure 门户中部署了 Elasticsearch！稍等几分钟，您就会在门户中看到 Elasticsearch 资源概述页面。您可能还会注意到您的 Azure 帐户中有一个 Elastic 订阅。Elasticsearch 资源也将显示在您的整合式 Azure 账单上。&nbsp;
 <h3>在 Azure 中管理 Elasticsearch</h3>至此，您的 Elasticsearch 资源已经配置完毕，接下来让我们仔细看看 Elasticsearch 资源概述页面。您已经熟悉了我们上面提到的各个字段，但这个页面还显示了其他一些值得注意的细节：
<ul>
	<li aria-level="1">Status（状态）— Elasticsearch 资源的状态。如果您的集群运行顺利，您将看到 <code>Healthy</code>。</li>
	<li aria-level="1">Version（版本）— 部署的 Elasticsearch 版本。默认情况下，Azure 会部署可用的最新版本。如果您要部署较旧的版本，请参阅下面的 Advanced settings（高级设置）。</li>
	<li aria-level="1">Advanced settings（高级设置）— 这是转至 Elastic Cloud 控制台的链接，方便您根据需要对资源进行其他更改。您可以在 Elastic Cloud 控制台中执行的操作包括：
	<ul>
		<li aria-level="2">重新调整集群大小</li>
		<li aria-level="2">启用自动扩展</li>
		<li aria-level="2">升级到较新版本的 Elasticsearch</li>
		<li aria-level="2">设置流量筛选器以确保连接安全</li>
	</ul></li>
</ul><ul>
	<li aria-level="1">Elasticsearch endpoint（Elasticsearch 终端）— 这是 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/rest-apis.html">Elasticsearch API</a> 的终端。</li>
	<li aria-level="1">Deployment URL（部署 URL）— 帮助您开始使用 Elastic 的 Kibana 链接。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc29869b698f3dc28/60a6cf9d0a03095ac9585af1/Screenshots_-_En_(1).png" data-sys-asset-uid="bltc29869b698f3dc28" alt="Screenshot of overview page" style="display: block; margin: auto;"></li>
</ul><h3>探索 Elastic 解决方案</h3>您现在可以探索 Elastic 针对搜索、可观测性、安全和分析用例提供的所有解决方案。要开始使用，请在 Azure 中的 Elasticsearch 概述页面单击 Kibana。选择您的 Azure 帐户，通过单点登录直接进入 Elastic。
在 Elastic 中，您可以按照产品内的指南来配置集成、采集数据并开始探索数据，以获得有意义的见解。此外，您还可以利用公测版中提供的 Fleet 来优化数据采集过程。只需在左侧菜单中导览到 Fleet，然后选择 Integrations（集成），即可查看可以采集的各种类型的数据。
<h3><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2fffbe16304696c1/60a6d0756a7d7e6562204bd0/Home_-_Elastic_(1).png" data-sys-asset-uid="blt2fffbe16304696c1" alt="Screenshot of Kibana"> </h3><h3>Azure 日志和指标</h3>通过最新的 Elastic 集成，您可以自动将 Azure 日志和指标采集到 Elastic 中。集成点有以下两个：
Azure 订阅日志和资源日志
<a href="https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/activity-log-schema">Azure 订阅日志</a>提供有关任何订阅级别事件的详细信息。<a href="https://docs.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs-categories">Azure 资源日志</a>描述这些服务或资源的操作。这两种日志结合在一起，即可获得 Azure 平台的运行概况，帮助分析师和管理员更好地审计 Azure 中的活动。通过这项 Elastic 集成增强功能，只需单击几下，即可轻松将这些日志从 Azure 导出到 Elastic 中，无需手动部署代理或配置采集工作负载。
要开始采集订阅和资源日志：
<ol>
	<li aria-level="1">前往 Logs & metrics（日志和指标）选项卡。您可以通过 Create Elastic Resource（创建 Elastic 资源）流程访问该选项卡，也可以从概述页面中的现有 Elasticsearch 资源进入。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2f9dd4647a4a58a6/60a6f23fa450c25ac83cf2f2/Create_Elastic_R.png" data-sys-asset-uid="blt2f9dd4647a4a58a6" alt="Screenshot of how to create an Elastic resource" style="display: block; margin: auto;"></li>
</ol><ol start="2">
	<li aria-level="1">单击订阅活动日志和/或资源日志旁边的复选框。</li>
</ol><ol start="3">
	<li aria-level="1">或者，您可以指定标记规则，以在日志收集中包含或排除特定资源。默认情况下，如果未指定标记规则，则会采集所有支持资源的日志。</li>
</ol><ol start="4">
	<li aria-level="1">选择 Save（保存）（或完成资源创建）。日志数据很快就会开始出现在 Elastic 中。</li>
</ol><ol start="5">
	<li aria-level="1">要查看您的日志数据，请登录 Kibana，您可以从 Azure 中的 Elasticsearch 概述页面访问相应数据。进入 Kibana 后，您可以查看 Discover（发现）选项卡，以查看原始日志数据。Dashboard（仪表板）选项卡会显示一些为 Azure 数据预配置的现成仪表板。</li>
</ol><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0f9cae41ae35d52a/60abe125b29743655f633371/kibana-screenshot-1.png" data-sys-asset-uid="blt0f9cae41ae35d52a" alt="Screenshot of logs data in Kibana" style="display: block; margin: auto;">
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt546802b8e5da1134/60abe144a5998d6af956724a/kibana-screenshot-2.png" data-sys-asset-uid="blt546802b8e5da1134" alt="Screenshot of logs data in Kibana" style="display: block; margin: auto;">
请注意，这项集成中的日志收集取决于是否支持 Azure 服务，以及部署 Azure 服务的区域。更多详情，请参阅我们的<a href="https://www.elastic.co/guide/en/cloud/current/ec-azure-marketplace-native.html">文档</a>。
虚拟机日志和指标
来自<a href="https://azure.microsoft.com/en-ca/services/virtual-machines/">虚拟机</a>的系统日志可以轻松发送到 Elastic 进行更深入的分析。通过 Elastic，您可以对虚拟机数据执行搜索、可视化、获得告警和进行故障排除。
要开始体验，请按照以下步骤操作：
<ol>
	<li aria-level="1">前往 Elastic 资源中的 Virtual machines（虚拟机）选项卡。<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6c327b387a8ade7d/60a6d28a0a03095ac9585af9/os-hotmail3_-_Mi_(1).png" data-sys-asset-uid="blt6c327b387a8ade7d" alt="Screenshot of virtual machines overview" style="display: block; margin: auto;"></li>
</ol><ol start="2">
	<li aria-level="1">选择要监测的虚拟机，然后单击 Install Extension（安装扩展）。这一操作将会在您的虚拟机上安装 Elastic VM 扩展，用于部署 <a href="https://www.elastic.co/guide/en/fleet/current/fleet-overview.html#elastic-agent">Elastic Agent</a> 以收集系统日志和指标。</li>
</ol><ol start="3">
	<li aria-level="1">安装扩展后，日志和指标将开始流入 Elastic。在 View data（查看数据）列下，您可以找到两个便捷链接，单击即可前往 Elastic，以便您查看数据：</li>
</ol><ul>
	<li aria-level="1">Logs（日志）：这个链接会将您转到 Elastic 中的日志流，以便您查看和搜索日志数据。</li>
	<li aria-level="1">Metrics（指标）：这个链接会将您转到预先筛选的仪表板，可总体查看虚拟机的运行状况。</li>
</ul><ol start="4">
	<li aria-level="1">您可以使用 <a href="https://www.elastic.co/guide/en/fleet/current/agent-policy.html">Fleet</a> 直接在 Elastic 中进一步管理 Elastic Agent 及其收集的数据。</li>
</ol>至此，您的平台日志和虚拟机数据已在 Elastic 中，不妨再探索一下 Elastic 都提供了哪些功能：
<ul>
	<li aria-level="1">采集环境中的<a href="https://www.elastic.co/cn/integrations">其他数据</a></li>
	<li aria-level="1">通过<a href="https://www.elastic.co/guide/en/machine-learning/current/xpack-ml.html">异常检测</a>发现数据中的异常模式</li>
	<li aria-level="1">将日志和指标数据与系统痕迹整合在一起，以进行<a href="https://www.elastic.co/guide/en/apm/index.html">应用程序性能监测</a></li>
	<li aria-level="1">使用 <a href="https://www.elastic.co/guide/en/security/current/es-overview.html">Elastic 安全</a>通过威胁检测和终端防御来保护您的环境</li>
	<li aria-level="1">使用<a href="https://www.elastic.co/guide/en/enterprise-search/current/index.html">企业搜索</a>构建高度定制的个性化搜索体验</li>
</ul> <h3>整合式账单</h3>在整合式 Microsoft 发票上，您的所有 Elastic 使用量将在一个行项目中显示，并会累积到您的 Azure 支出承诺中。您可以从 <a href="https://cloud.elastic.co/account/usage">Elastic 成本分析页面</a>按区域和部署探究您的 Elastic 使用费。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt8969ece53004060a/60a6d1fd77e996669f49ddec/8480671-2144fa7b9e4534ade59a42a87d9c1581.png" data-sys-asset-uid="blt8969ece53004060a" alt="Screenshot of billing and usage overview" style="display: block; margin: auto;">
<h3>如何获得支持</h3>Elastic 为这项集成提供支持。我们随时为您提供帮助，您可以通过 Azure 门户，单击 Elasticsearch 资源概述中的新支持请求（New support request），与我们取得联系。单击后您会转到 Elastic Cloud 控制台，您可以在其中为 Elastic 支持团队创建支持案例。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9d2e33082a77971f/60a6d187c8faf774ab45f8b9/os-hotmail3_-_Mi.png" data-sys-asset-uid="blt9d2e33082a77971f" alt="Screenshot of how to contact support" style="display: block; margin: auto;">
<h3>立即试用</h3>我们介绍了如何<a href="https://portal.azure.com/#blade/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/elastic.ec-azure-pp">在 Azure 上开始使用 Elasticsearch (Elastic Cloud)</a>，并探索了原生日志和指标监测功能，让您对这项令人兴奋的集成有一个大致的了解。您可以通过 Azure 门户进行部署，进一步了解各项功能。
要了解更多信息，请查看我们的<a href="https://www.elastic.co/guide/en/cloud/current/ec-azure-marketplace-native.html">文档</a>。有问题或反馈？请发送电子邮件至 <a href="mailto:azure-co-sell@elastic.co">azure-co-sell@elastic.co</a> 联系我们。

cloud-azure-blog-banner.png

blog-thumb-cloud-azure.png

How to deploy and manage Elastic on Microsoft Azure

如何部署和管理 Microsoft Azure 上的 Elastic

更新：本文提及我们的托管式 Elasticsearch 产品时使用的是旧称 Found。请注意，Found 现在称为 Elastic Cloud。<a href="https://www.elastic.co/cn/cloud/as-a-service/signup">托管式 Elasticsearch 可在 Elastic Cloud 上免费试用 14 天</a>。Elasticsearch 可以用作“NoSQL”数据库吗？NoSQL 在不同的上下文中有不同的含义，有趣的是，它实际上与 SQL 无关。我们将从一种“不确定的情况”入手，了解 Elasticsearch 的各种属性，以及它为了成为迄今为止最灵活、最具可扩展性、性能最佳的搜索和分析引擎之一而牺牲的那些属性。
<section id="what-is-a-nosql-database-anyway" class="level2">
<h2><a href="#what-is-a-nosql-database-anyway">究竟什么是 NoSQL 数据库？</a></h2>
<a href="http://nosql-database.org/">NoSQL 数据库</a>将 NoSQL 定义为“下一代数据库，主要涉及到以下几点特征：非关系型、分布式、开源以及可横向扩展”。换句话说，这不是非常精确的定义。

它并不是专门针对 SQL 的。例如，<a href="http://hive.apache.org/">Hive</a> 的查询语言显然受到了 SQL 的启发。<a href="http://esper.codehaus.org/">Esper</a> 的查询语言也是如此，它对流而不是关系进行操作。另外，您知道过去 PostgreSQL 被命名为“Postgres”，并且使用“Quel”作为查询语言吗？虽然首先是 ORDBMS，但它现在同样有许多<a href="http://thebuild.com/blog/2013/07/02/postgresql-as-a-nosql-database/">特性使其具备不区分模式的文档存储能力</a>。

而且，与 ACID 特性也无关。<a href="http://hyperdex.org/">Hyperdex</a> 是 NoSQL 数据库的一个示例，旨在提供 ACID 事务。MySQL（当然是 SQL 数据库）对 ACID 的真正含义一直以来有着令人怀疑的解释。

关系？虽然大多数 NoSQL 数据库不支持与传统关系型数据库相同意义上的连接，并需要用户自行解决这一问题，但也有一些数据库能够提供支持。比如，<a href="http://www.rethinkdb.com/">RethinkDB</a>、<a href="http://hive.apache.org/">Hive</a> 和 <a href="http://pig.apache.org/">Pig</a> 等等。<a href="http://www.neo4j.org/">Neo4j</a> 是面向图形的数据库，当然会处理关系 — 它非常擅长遍历图形中的关系（即边）。在 Elasticsearch 中，可以使用<a href="/guide/reference/mapping/parent-field">父/子关系</a>进行“查询时”连接，也可以使用<a href="/guide/reference/mapping/nested-type">嵌套类型</a>进行“索引时”连接。

分布式？虽然存在一些分布式 SQL 数据库，也有<a href="https://github.com/petersirka/nosql">一些</a><a href="http://ejdb.org/">项目</a>旨在成为像 NoSQLite 一样的数据库，但更新一代的数据库往往采用某种分布形式。

总而言之，准确地定义 NoSQL，或者简单地说 Elasticsearch 是“文档存储”类型的 NoSQL 数据库，都没有意义。在撰写本文时，<a href="http://nosql-database.org/">nosql-database.org</a> 列出了其中的 20 多个属性。

在接下来的部分中，我们将了解一些重要属性，以及 Elasticsearch 如何实现或不实现这些属性。

</section><section id="transactions" class="level2">
<h2><a href="#transactions">无事务</a></h2>
Lucene（Elasticsearch 在它的基础上构建而成）有事务的概念。相反，Elasticsearch 没有典型意义上的事务。无法回滚已提交的文档，而且您不能提交一组文档，并对全部文档都编制索引或都不编制索引。然而，Elasticsearch 所拥有的是一个预写日志，旨在确保操作的持久性，而不必进行开销高昂的 Lucene 提交。此外，您还可以指定索引操作的一致性级别，即返回之前必须确认操作的副本数。默认为法定数量，即 $\lfloor\frac{n}{2}\rfloor + 1$。

更改的可见性是在刷新索引时控制的，默认情况下每秒刷新一次，并且是逐个分片进行的。

乐观并发控制是通过指定已提交文档的版本来实现的。

Elasticsearch 追求的是速度。执行分布式事务是一项繁重的工作。不提供分布式事务会让很多事情变得更容易。只要我们能接受读取到的数据可能有些陈旧，而且所有人看到的是同一时间点的数据，那么 Elasticsearch 就可以利用缓存提供很多服务 — 这对于我们钟爱的极速性能来说是至关重要的。

</section><section id="schema-flexible" class="level2">
<h2><a href="#schema-flexible">模式灵活</a></h2>
Elasticsearch 不要求您预先指定模式。扔给 Elasticsearch 一个 JSON 文档，它就会进行一些有根据的猜测来推断这个文档的类型。Elasticsearch 可以很好地处理数字、布尔值和时间戳等数据。对于字符串，它会使用“标准”分析器，这通常很容易上手。

虽然 Elasticsearch 可以说是“无模式”的，从某种意义上说，您不必指定模式，但我们更愿意将其视为“模式灵活”。为了开发出色的搜索和/或分析，您确实需要对模式进行微调。Elasticsearch 有一系列功能强大的工具可以为您提供帮助，如动态模板、多字段对象等。我们在关于映射的一篇文章中对此进行了详细介绍。

</section><section id="relations-and-constraints" class="level2">
<h2><a href="#relations-and-constraints">关系和约束</a></h2>
Elasticsearch 是一种面向文档的数据库。需要对要搜索的整个对象图形编制索引，因此在对文档编制索引之前，必须对其进行反规范化处理。反规范化可提高检索性能（因为不需要查询连接），会使用更多的空间（因为必须多次存储数据），但要保持数据一致性和实时性则更加困难（因为任何数据更改都必须应用到所有实例中）。不过，对于一次写入频繁读取的工作负载，它的表现相当优异。

举例来说，假设您在数据库中存储了客户、订单和产品等数据，并且您想要通过产品名称和客户姓名来搜索订单。要解决这个问题，可以在为订单编制索引时把客户和产品的所有必要信息都加进来。这样的话，搜索起来就非常简单，但如果您想要更改某个产品的名称会出现什么情况呢？在进行了良好规范化的关系型设计中，您只需要更新相应的产品就可以搞定。这正是关系型数据库所擅长的。而在反规范化的文档数据库中，将不得不更新与该产品有关的所有订单。

换句话说，在面向文档的数据库（如 Elasticsearch）中，我们对文档进行映射和存储设计只是为了优化搜索和检索的性能。

在简介中已经提到，Elasticsearch 中可以使用<a href="/guide/reference/mapping/parent-field">父/子关系</a>进行“查询时”连接，也可以使用<a href="/guide/reference/mapping/nested-type">嵌套类型</a>进行“索引时”连接。我们会在以后的文章中对该主题进行深入介绍。在此我们推荐 Martijn van Groningen 的演讲“<a href="/cn/videos/bbuzz2013-document-relations-with-elasticsearch">Document relations with Elasticsearch</a>”（使用 Elasticsearch 记录关系）。

大多数关系型数据库还允许您通过指定约束来定义哪些数据需要保持一致性，哪些不需要保持一致性。比如，参照完整性和唯一性都是强制性的。您可以要求帐户变动的金额必须是正数，等等。面向文档的数据库往往不会这样做，Elasticsearch 也不例外。

</section><section id="robustness" class="level2">
<h2><a href="#robustness">稳健性</a></h2>
数据库应该稳定可靠，尤其是当它是您的权威记录系统时。理想情况下，耗费资源的查询应当可以取消，并且您肯定不希望数据库停止工作，除非您命令它停下来。

遗憾的是，Elasticsearch（及其组件）目前并不能很好地处理 <code>OutOfMemory</code> 错误。我们在<a href="/cn/blog/found-elasticsearch-in-production">生产环境中的 Elasticsearch - OutOfMemory 导致的崩溃</a>一文中更深入地介绍了这一点。因此，为 Elasticsearch 配置足够多的内存就显得非常重要，而且要在生产集群上谨慎运行那些无法预知将会耗费多少内存的查询。

不过，随着 Elasticsearch 越来越成熟，这个问题很可能会得到改善，但重要的是要记住，Elasticsearch 的目标是提升速度，所以它假设内存是充足的。

</section><section id="distributed" class="level2">
<h2><a href="#distributed">分布式</a></h2>
另请参阅：<a href="/cn/elasticsearch">生产环境中的 Elasticsearch - 网络</a>。

在创建 Elasticsearch 之前， Shay Banon 一直在开发 <a href="https://thedudeabides.com/articles/the_future_of_compass">Compass</a>。由于意识到很难将其转变成一个分布式的搜索引擎，他就从头开始创建了 Elasticsearch<a href="#fn1" class="footnoteRef" id="fnref1">1</a>。Elasticsearch 采用分布式且易于扩展的设计，可以在商用硬件上处理海量数据。

作为一个分布式的系统，Elasticsearch 的上手和使用都非常简单，但是分布式系统本身是很复杂的。关于这一点，我们在<a href="/cn/blog/found-elasticsearch-in-production">生产环境中的 Elasticsearch - 网络</a>一文中有更多的介绍，所以下面只是一个简短的摘要。

分布式系统天生的特性，意味着很多事情都可能会出错。因此，不同的数据库系统侧重于不同的优势：有些力争强大的安全保证，另外一些则致力于始终可用，即使某些时候（甚至多数时候）出现错误也在所不惜。而且，正如 <a href="http://aphyr.com/">Kyle Kingsbury</a> 在他关于 <a href="http://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-and-the-perils-of-network-partitions">perils of network partitions</a>（网络分区的危险）的优秀系列文章中所指出的那样，在出现问题时，实际上数据库系统并没有像它们所宣称的那样来处理问题。简言之，他发现，虽然分布式数据库在阳光明媚的日子里运行良好，但绝大部分数据库在遭受到<a href="http://aphyr.com/posts/288-the-network-is-reliable">大量可能的问题时所做的努力，都会以失败而告终</a>。

就一致性、可用性和分区容错性而言，Elasticsearch 是一个 CP 系统，对于“一致性”的定义相当不靠谱。如果您有一个只读工作负载，Elasticsearch 允许您通过不严格的“最小主节点”要求（即不需要法定数量）来实现 AP 行为。然而，通常情况下，您需要集群中的大多数节点是可用的。写入一个配置错误（无法保证大多数节点可用）的集群，即“脑裂”集群，可能会导致无法恢复的数据丢失。这绝不只特定于 Elasticsearch。

就扩展而言，一个索引可以被划分为一个或多个分片。这是在创建索引时指定的，不能更改。因此，随着预期的增长，应将一个索引合理地进行分片。随着越来越多的节点被添加到 Elasticsearch 集群中，它在重新分配和移动分片方面表现良好。因此，Elasticsearch 很容易横向扩展。

</section><section id="security" class="level2">
<h2><a href="#security">安全性</a></h2>
另请参阅：<a href="/cn/security">生产环境中的 Elasticsearch - 安全性</a>。

Elasticsearch 没有任何身份验证或授权特性。您可以这样认为：任何人只要能连接到您的 Elasticsearch 集群，就拥有了“超级用户”权限，尤其是在启用了 Elasticsearch 强大的脚本功能的情况下。

</section><section id="summary" class="level2">
<h2><a href="#summary">总结</a></h2>
如果本文描述的这些限制都不能阻止您，您当然可以将 Elasticsearch 用作主存储。使用 <a href="/cn/logstash">Logstash</a> 就是一个很好的例子。Logstash 是一个非常棒的工具，用来管理日志并把它们导入到 Elasticsearch 中，也许还可以将日志归档到其他地方以备不时之需。日志都是一次写入，多次读取的。不需要更新，不需要事务支持，也没有完整性约束等。

那么像 Postgres 这样带有<a href="http://www.postgresql.org/docs/current/static/textsearch.html">全文搜索</a>和 ACID 事务的系统呢？（其他示例包括 MySQL、MongoDB、Riak 等的全文检索能力。） 虽然您可以用 Postgres 来实现基本的搜索，但在性能和功能上与 Elasticsearch 都有很大的差距。正如我们在<a href="#transactions">事务</a>部分所提到的，Elasticsearch 会进行大量缓存，所以可能会“欺骗”我们，而且不关心多版本之间的并发控制和其他复杂的事情。搜索也远不止在一段文本中找到一个关键字那么简单：它涉及到运用领域特定的知识来实现良好的相关性模型，由此给出整个结果空间的一个全貌，并且能做拼写检查和自动补全之类的工作。而且，所有这些操作都要保证速度。

Elasticsearch 通常被用作其他数据库的补充。这类数据库系统更注重约束、正确性和稳健性，并且随时可进行事务更新，拥有主记录 – 这些记录随后会被异步推送到 Elasticsearch。（也可能是拉取，前提是您使用了 Elasticsearch 的某一种“river”。） 保持数据同步是我们打算将来撰文深入探讨的话题。在 Found 中，我们通常使用 PostgreSQL 和 ZooKeeper 作为真实数据的来源，我们将这些数据输入给 Elasticsearch 来提供出色的搜索体验。

就像所有其他事情一样，没有包治百病的灵丹妙药，没有一个数据库可以做到所有的事情。也许这种情况会永远持续下去，所以要清楚您的数据库的优点和弱点！

<div class="references">
	<h2><a href="/">参考资料</a></h2>
	Shay Banon：The future of compass & elasticSearch（Compass 和 Elasticsearch 的未来）– <a href="https://thedudeabides.com/articles/the_future_of_compass">https://thedudeabides.com/articles/the_future_of_compass</a>
	
</div>
</section><section class="footnotes">
<hr>
<ol>
	<li id="fn1">Shay Banon，The future of compass & elasticSearch（Compass 和 Elasticsearch 的未来）– <a href="https://thedudeabides.com/articles/the_future_of_compass">https://thedudeabides.com/articles/the_future_of_compass</a>。<a href="#fnref1">↩</a></li>
</ol>
</section>

Elasticsearch as a NoSQL Database

把 Elasticsearch 用作 NoSQL 数据库

借助 Kibana 高级分析功能，您能够解决时序和地理空间数据问题。了解如何使用公式计算比率、周同比增长率、偏差等指标，以及有哪些 Elastic Maps 技巧可用来解决时空问题。

Kibana 让您能够轻松地对自己的全部数据进行操作，释放数据的强大潜能——询问并解答问题以及遵循分析流程。很多时候，要想回答您的问题，都需要基于所查询的数据进行计算。借助公式，您可通过数学运算组合使用多个聚合字段，创建您独有的指标。
此外，跨时空探究并重新审视您的数据可赋予您强大能力，让您获得历史背景并理解有关现状的更多洞察。
在下面的部分，我们将会介绍 10 个示例问题；使用 Kibana 中的仪表板数据和地图可视化，借助公式、时间移位和跨时空探究数据，这些问题都能得到解答。您可以使用自己的数据或者 Kibana 的<a href="/guide/en/kibana/current/get-started.html#gs-get-data-into-kibana">样本数据集</a>跟着做。有问题？请前往<a href="https://discuss.elastic.co/c/elastic-stack/kibana/7">我们的论坛</a>。
不妨先看看下面的列表！
<ol>
	<li><a href="#proportion-of-errors">错误比例在上升吗？</a></li>
	<li aria-level="1"><a href="#performance-comparison-week">性能相较于上周怎么样？</a></li>
	<li aria-level="1"><a href="#compare-to-peers">该数据与同行相比怎么样？</a></li>
	<li aria-level="1"><a href="#effect-on-average">对我的均值影响最大的是什么？</a></li>
	<li aria-level="1"><a href="#historical-gain-loss">相较于历史数据，原始损益是多少？</a></li>
	<li aria-level="1"><a href="#gain-loss-percentage">以过往性能作为基准，损益的比例是多少？</a></li>
	<li aria-level="1"><a href="#time-slider">数据是如何变成现在这样的？</a></li>
	<li aria-level="1"><a href="#dashboard-maps-filter">我如何能够跨空间以互动方式探索仪表板？</a></li>
	<li aria-level="1"><a href="#per-unit-metric">该指标经过平均后是多少？</a></li>
	<li aria-level="1"><a href="#industry-specific-calculation">在上个期间，我们行业所特有的计算值（例如“净推荐值”）是多少？</a></li>
</ol><h2 id="proportion-of-errors">1) 错误比例在上升吗？</h2>比率用处很大，因为比率能够展示相对于整体而言所占的比例，也能够回答使用原始计数无法回答的问题：“我之所以在这个测量指标上看到增长，是因为我获得的整体数据变多了吗？” 构建比率的方法是筛选出您的一个子数据集，然后将其与您未经筛选的整体总值进行对比。可以尝试在自定义公式中将 KQL 作为筛选条件，来实时创建您的比率。
下面的示例显示了相对于全部的唯一身份用户，遇到 HTTP 错误代码（响应代码大于 HTTP 200）的唯一身份用户所占的比例。为了帮助得出更多洞察，该可视化将一天中的时间作为行，将一周中的日期作为列。如果您的数据中没有这些字段，您可以随时将它们作为<a href="/guide/en/kibana/7.14/lens.html#change-the-fields">运行时字段</a>添加进去。&nbsp;
<pre class="prettyprint">unique_count(clientip, kql='response.keyword > 200') / unique_count(clientip)
</pre><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf776a148cbf4da57/611c07125780ae139064541d/screenshot_formulas_kibana_blog_original.png" data-sys-asset-uid="bltf776a148cbf4da57" alt="Using formulas in Kibana Lens for ratios and visualizing with color-by-value. " style="display: block; margin: auto;">
按一天中的时间和一周中的日期列出的错误比率表格
<h3></h3>可视化练习：比率
当对比率进行可视化时，需应用百分比值格式。在您指标的名称中使用“比率”一词。如果您可视化的是诸如错误比率等指标，您不妨在表格中按照一天中的时间和一周中的日期来列出，这样可能会有所帮助。通过比率，均值可以提供有关整列内容的洞察（在本例中，一周中每天的平均错误率）。
<h2 id="performance-comparison-week">2) 性能相较于上周怎么样？</h2>同比增长率能够向您展示当前相对于过去的百分比；如是 100%，则表示保持原样。&nbsp;
下面的示例显示了相较于上周，带宽增长至 14 倍 (1400%)。
<pre class="prettyprint">median(bytes) / median(bytes, shift='1w')
</pre><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2713a1ba5ea42229/611c09df1e409f13bb3ba44d/image12.png" data-sys-asset-uid="blt2713a1ba5ea42229" alt="Formulas in Kibana Lens for showing change week over week over time." style="display: block; margin: auto;">
一段时间以来带宽变化的周同比增长率
可视化练习：同比增长率&nbsp;
对几乎任何可视化而言，同比增长率都特别实用。看一段时间内的同比增长率之所以实用，是因为能确定在一段时间内期间变化本身是否发生了变化。该计算会输出另一个百分比，所以不要忘记值的格式，如果您的数据在线状图上很少，则“线性”缺失值选项的视觉冲击感最小。
<h2 id="compare-to-peers">3) 该数据与同行相比怎么样？</h2>通过使用整体总和，您可以将任何数据展示为相对于总值的比例，从而更轻松地进行比较。&nbsp;
在下面的示例中，我们可以看到“ceph”图片产生了最多的数据，这里我们选择不看计数，而是选择把值看作百分比。
<pre class="prettyprint">count() / overall_sum( count() )
</pre><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt8c414cdf2e98d31f/611c0c285780ae1390645447/screenshot_formulas_overall_sum.png" data-sys-asset-uid="blt8c414cdf2e98d31f" alt="Formulas in Kibana Lens for visualizing percents of overall sums for comparisons" style="display: block; margin: auto;">
按容器图片分类的基础架构数据百分比
	
<h3></h3>可视化练习：占整体总和的百分比
通过使用公式创建一个相对于整体总值的百分比，您能够使用任何可视化来展示部分对整体数据，而之前只有树形图、饼图和圆环图能够提供此功能。如果您想确保每个数据点都可读，可以用一个水平柱形来显示占总体的百分比。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt014fe2712d600356/611c0d09d78aee13bd1dd63f/screenshot_kibana_treemaps.png" data-sys-asset-uid="blt014fe2712d600356" alt="Treemaps in Kibana" style="display: block; margin: auto;">树形图、圆环图和饼图虽然可以自动产生数据百分比，但可读性却不好
<h2 id="effect-on-average">4) 对我的均值影响最大的是什么？</h2>整体均值等函数可以让您与完整报告中所有值的平均值进行数学比较。&nbsp;
在这个示例中，我们可以看到哪一品类的表现优于全体销售的整体均值，其中两个服装品类的表现都优于整体均值。
<pre class="prettyprint">sum(taxless_total_price) - overall_average(sum(taxless_total_price))
</pre><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt4018992d1d09a456/611c0e2b906dcc139b6f3ee7/screenshot_kibana_formulas_deviation.png" data-sys-asset-uid="blt4018992d1d09a456" alt="Using formulas to visualize deviation of sum" style="display: block; margin: auto;">
各品类与平均销售额的偏差
	
可视化练习：偏差
对以 0 为中心点的指标进行可视化时，使用水平柱形尤为有用。不要忘记给指标起一个易理解的名称。&nbsp;
<h2 id="historical-gain-loss">5) 相较于历史数据，原始损益是多少？</h2>时移差异会与过去的同一指标进行对比。很有用的一种算法是您可以从当前值中减去过去值，从而得到一个以零为中心的可视化——正值表示在过去的基础上有增长。&nbsp;
这里的例子是 Kubernetes 节点相比于 6 小时前的平均 CPU 使用情况。这个示例使用除法将 CPU 纳核转变为核（注：一种很好的方法是通过<a href="/guide/en/kibana/7.14/lens.html#change-the-fields">运行时字段</a>将此数据作为一个额外的指标转换添加进去，以让其他用户能够在字段列表中找到，而不需要通过公式来实现。）。&nbsp;
<pre class="prettyprint">(
 average(kubernetes.node.cpu.usage.nanocores)
 - average(kubernetes.node.cpu.usage.nanocores, shift='6h')
) / 1000000000
</pre>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltaac0e361cd103df6/611c1257906dcc139b6f3f09/screenshot_kibana_time_shifts.png" data-sys-asset-uid="bltaac0e361cd103df6" alt="Time-shifted differences with formulas in Kibana" style="display: block; margin: auto;">
相较于 6 小时前节点 CPU 核利用情况的变化&nbsp;
	
可视化练习：时移差异和变更单位
当最“需要关注的”数字是位于可视化顶部的一个大值时，可以将数轴移到可视化的顶部，这能够起到一定的帮助作用。&nbsp;
<h2 id="gain-loss-percentage">6) 以过往性能作为基准，损益的比例是多少？</h2>变化百分比与时移差异稍有不同，能够允许您将增长看作过去值的百分比，而不是原始值之间的差异。讨论增长时，这种方法很流行。&nbsp;
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta85d9088f76ea470/611c12f9d78aee13bd1dd649/screenshot_percentage_change_calculation.png" data-sys-asset-uid="blta85d9088f76ea470" alt="Percentage change calculation" width="453" height="64" style="display: block; margin: auto; width: 453px; height: 64px;">
变化百分比计算的示例
下面的示例显示了 Kubernetes CPU 使用情况的变化百分比。&nbsp;
<pre class="prettyprint">(
 (
 average(kubernetes.node.cpu.usage.nanocores)
 - average(kubernetes.node.cpu.usage.nanocores, shift='3d')
 ) /
 (
 average(kubernetes.node.cpu.usage.nanocores, shift='3d')
 )
)
</pre><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc8522931fe56cc38/611c14c0cf33c613b2c06f66/screenshot_formulas_percentage_change.png" data-sys-asset-uid="bltc8522931fe56cc38" alt="Using formulas for percentage change" style="display: block; margin: auto;">
相较于 3 天前，节点 CPU 利用情况的变化百分比
	
可视化练习：变化百分比
如果使用“百分比”值格式，则您无需将该值乘以 100。如果有空间，值标签能为可视化提供辅助信息。&nbsp;
<h2 id="time-slider">7) 数据是如何变成现在这样的？</h2>地图是理解您数据的地理背景的最好方式。但地图就是一张快照——它可能代表过去 15 分钟的状况，也可能代表去年的状况。实际上，如果您以分钟为单位或者以天为单位，您的地图可能会讲述一个完全不同的故事。借助时间滑块，您可以回看指标并查看一段时间以来每个时间增量单位发生的变化。您可能会找到之前未被检测到的模式，或者发现一个需要深度调查的异常。时间滑块能够展示您的数据是如何到达它今天的位置的。&nbsp;
<div class="video embed-container" style="height: 319.725px;">
	<img class="vidyard-player-embed" src="https://play.vidyard.com/tz5urKCS9HMXBbTZtobNuS.jpg" data-uuid="tz5urKCS9HMXBbTZtobNuS" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" alt="Time slider in Elastic Maps" style="width: 100%; margin: auto; display: block;">
</div>Elastic Maps 中的时间滑块控制
<h2 id="dashboard-maps-filter">8) 我如何能够跨空间以互动方式探索仪表板？</h2>有时候，您的问题的答案取决于地点。如果您在为他人创作仪表板，可以考虑让用户将地图作为整个仪表板的一个筛选器。尝试搭配地图在仪表板上对关键指标进行可视化。这能够让任何人在进行空间筛选的同时对非空间指标进行可视化，是进行对比并找出异常的一种强大方法。
<div class="video embed-container" style="height: 319.725px; text-align: center;">
	<img class="vidyard-player-embed" src="https://play.vidyard.com/jnRaBhAWmZFCciyUwhwLtY.jpg" data-uuid="jnRaBhAWmZFCciyUwhwLtY" data-v="4" data-type="inline" data-autoplay="1" data-loop="1" data-disable_analytics="1" data-hidden_controls="1" data-muted="1" disable_analytics="1" alt="Filter your dashboard data using Maps" style="width: 100%; margin: auto; display: block;">
</div>将地图作为仪表板的一个筛选条件
<h2 id="per-unit-metric">9) 单位效率如何？</h2>可以使用自定义公式来减少汇总数据，从而得出单位指标。这一切都取决于您的数据进来时的样子，都有哪些指标，您数据中的“单位”是什么。&nbsp;
下面的示例显示了基于周期性间隔（例如每 30 秒）的云指标遥测数据。指标总数（例如 CPU 利用率）和总数所代表的事件数量（请求），再加上公式，能够让我们确定每个请求的平均 CPU 使用率，并完成很多事情，例如在负载增加时确定新指标在一段时间内的趋势以理解效率。在生成的可视化中，“波谷”表明系统在重负载下效率变高了。
<pre class="prettyprint">average(kubernetes.pod.cpu.usage.node.pct) //单个请求的
counter_rate(max(nginx.stubstatus.requests)) //平均指标
</pre><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt35d5dd9b4a00f08b/611c1fd060bb0f13c2eae200/screenshot_formulas_average_per_unit.png" data-sys-asset-uid="blt35d5dd9b4a00f08b" alt="Using formulas for finding average metrics per unit" style="display: block; margin: auto;">一段时间内单个请求的平均 CPU 利用率
可视化练习：单位
如果您使用单位指标，确保您在指标名称中包含所使用的指标聚合和“单位”二字。一种实用的方法是，可以在单独的仪表板面板和系列中对公式所包含的单位进行可视化。
<h2 id="industry-specific-calculation">10) 在上个期间，我们行业所特有的计算值（例如“净推荐值”）是多少？</h2>假设您所在组织采用了一个通过特定方法计算得出的特定指标。例如，如果您的数据包含调查问题，有些组织喜欢计算“净推荐值”，计算方法是用“推荐者”（在问题标尺上选择前两个选项）的百分比减去“贬损者”（在问题标尺上选择最后两个选项）的百分比，进而得出一个介于 -100% 和 100% 之间的分数。这种业务指标通过一个公式即可轻松得出，因为公式是在报告时进行计算的，所以您可以随着公司指标和定义的演变轻松地对公式进行重定义。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt81410bafead86c48/611d298ed107d613a27e8f48/screenshot_formula_industry_metric.png" data-sys-asset-uid="blt81410bafead86c48" alt="Calculating industry-specific metrics with formulas" style="background-color: initial; display: block; margin: auto;">

计算行业所特有的指标，例如净推荐值
	
<h2>您有自己的数据问题？</h2>注册 <a href="https://cloud.elastic.co/registration?elektra=10-common-questions-kibana-blog">Elastic Cloud 的免费试用计划</a>并尝试亲自解决这些示例中的问题，或免费<a href="/cn/downloads/">下载</a> Elastic Stack 的自管型版本。如果您有更多入门相关问题，请前往 <a href="https://discuss.elastic.co/c/elastic-stack/kibana/7">Kibana 论坛</a>，或者也可以查看 <a href="/guide/en/kibana/current/index.html">Kibana 文档指南</a>。&nbsp;

Lens-ga-blog-banner.png

Lens-ga-blog-thumbnail.png

10 common questions answered with formulas and time travel in Kibana

通过 Kibana 中的公式和时间旅行可解答的十大常见问题

tuning_tools.jpg

bm_25_tuning_pt2.jpg

Practical BM25 - Part 2: The BM25 Algorithm and its Variables

BM25 实用详解 - 第 2 部分：BM25 算法及其变量

<table style="background-image: initial;background-position-x: initial;background-position-y: initial;background-size: initial;background-repeat-x: initial;background-repeat-y: initial;background-attachment: initial;background-origin: initial;background-clip: initial;background-color: rgb(255, 255, 210);">
 <tbody>
 <tr>
 <td>编者按：&nbsp;这篇文章包含过时的信息。请参考<a href="/guide/index.html" target="_self">我们的文档</a>、<a href="/cn/blog" target="_self">我们最新的博文</a>和<a href="https://discuss.elastic.co" target="_self">我们的论坛</a>，了解最新和最棒的解决方案。谢谢。</td>
 </tr>
 </tbody>
 </table>
 Elasticsearch 中的索引究竟是什么？尽管这是一个非常基础的问题，但答案却出人意料的细致入微。
 <h3>基本定义</h3>
 索引的<a href="/guide/en/elasticsearch/reference/current/glossary.html#index" target="_self">定义</a>如下：
 <blockquote>索引就像关系型数据库中的“数据库”。它有一个映射，可以定义多种类型。 一个索引就是一个逻辑命名空间，可映射到一个或多个主分片，并且可以有零个或多个副本分片。</blockquote>
 对了。这个定义包含两个概念。首先，索引是某种类型的数据组织机制，允许用户以某种方式对数据进行分区。第二个概念与副本和分片有关，这是 Elasticsearch 用于在集群中分发数据的机制。
 下面我们先来看第一个概念：使用索引来组织数据。
 <h2>关系索引</h2>
 下面这种最简单、最熟悉的布局克隆了您期望从关系型数据库中获得的内容。您可以（非常粗略地）将索引想象成数据库。
 <ul>
 <li>MySQL => 数据库 => 表 => 列/行</li>
 <li>Elasticsearch => 索引 => 类型 => 带有属性的文档</li>
 </ul>
 一个 Elasticsearch 集群可以包含多个索引（数据库），而这些索引又包含多个类型（表）。这些类型包含多个文档（行），并且每个文档都具有属性（列）。
 比如，在汽车制造业场景中，您可能有一个 SubaruFactory 索引。在这个索引中，有三种不同的类型：
 <ul>
 <li>People</li>
 <li>Cars</li>
 <li>Spare_Parts</li>
 </ul>
 然后，每个类型都包含与该类型对应的文档（例如，Subaru Imprezza 文档位于 Cars 类型中。这个文档包含了关于那辆车的所有详细信息）。
 搜索和查询采用以下格式：http://localhost:9200/[index]/[type]/[operation]
 因此，要检索 Subaru 文档，我可以执行以下代码： <pre class="prettyprint lang-bash">$ curl -XGET localhost:9200/SubaruFactory/Cars/SubaruImprezza </pre>
 <h2>日志索引</h2>
 现在，实际情况是，索引/类型比我们习惯在 RDBM 中使用的数据库/表抽象概念灵活得多。您可以把它看成实用的数据组织机制，而且性能优势更大，具体取决于您设置数据的方式。
 为了展示一种截然不同的方法，很多人使用 Elasticsearch 进行日志记录。标准格式是为每一天分配一个新的索引。您的索引列表可能如下所示：
 <ul>
 <li>logs-2013-02-22</li>
 <li>logs-2013-02-21</li>
 <li>logs-2013-02-20</li>
 </ul>
 Elasticsearch 允许您同时查询多个索引，因此执行以下操作并不成问题：<pre class="prettyprint lang-bash">$ curl -XGET localhost:9200/logs-2013-02-22,logs-2013-02-21/Errors/_search?query="q:Error Message" </pre>
 这样可以同时搜索最近两天的日志。鉴于日志的性质（大多数日志从来不会有人查看，组织形式采用线性时间流），这种格式优势很大。为每个日志编制一个索引更符合逻辑，并且可提供更好的搜索性能。
 它类似于按时间范围对 RDBM 表进行分区，只是我们要为每个分区创建新的索引。这是一个会被 RDBM 嘲笑的概念，每天创建一个新的数据库？太疯狂了！
 索引是相当轻量级的数据组织机制，因此 Elasticsearch 很乐意让您创建数百个索引。
 <h2>用户索引</h2>
 另一种截然不同的方法是，为每个用户创建一个索引。假设您有一个社交网站，其中每个用户都有大量的随机数据。您可以为每个用户创建一个索引。网站结构可能如下所示：
 <ul>
 <li>Zach 的索引<ul>
 <li>Hobbies 类型</li>
 <li>Friends 类型</li>
 <li>Pictures 类型</li>
 </ul>
 </li>
 <li>Fred 的索引<ul>
 <li>Hobbies 类型</li>
 <li>Friends 类型</li>
 <li>Pictures 类型</li>
 </ul>
 </li>
 </ul>
 请注意，采用传统的 RDBM 方式如何轻松完成这种设置（例如，“用户”索引，包含 hobbies/friends/pictures 类型）。然后，将所有用户编入一个单一的巨大的索引中。
 但出于数据组织和性能考虑，有时需要对数据进行拆分。在这个场景中，我们假设每个用户都有大量数据，而且我们希望这些数据是分开的。这时，我们就可以使用 Elasticsearch 为每个用户创建一个索引。
 <h3>数据分布索引</h3>
 前三个示例讲的都是应如何在逻辑上将数据分开，从而实现自然有效地表示。
 但是，索引的定义还包括关于分片和副本的部分。在所有索引、类型和文档的下面，Elasticsearch 必须将数据存储在某个地方。这个功能存储在分片（主分片或副本分片）中。
 每个索引都是为一定数量的主分片和副本分片配置的。因此，以上面的“用户”为例，如果您为每个用户创建了一个索引，那么您也要为每个用户创建一组分片。
 这无所谓好坏，只是在规划集群时要考虑的一个问题。不同的分片布局有利于不同的性能要求。我有意把这一节写得很短，因为要真正介绍分片需要一篇单独的文章。
 请记住，索引不仅从逻辑上组织数据，而且还可以通过底层分片以物理方式组织数据。

What is an Elasticsearch Index?

Elasticsearch 索引是什么？

在本博文中，我们正式推出首版监督式 ML 和安全集成方案。这会为用户提供监督式 ML 解决方案包，以检测网络数据中的域名生成算法 (DGA) 活动。

blog-banner-security-detection.png

Security

blog-thumb-security-detection.png

Combining supervised and unsupervised machine learning for DGA detection

为 DGA 检测整合监督式和非监督式 Machine Learning

长期以来，对于 Elasticsearch 上的任务关键型应用程序而言，跨数据中心复制一直都是一项硬性要求，之前通过利用其他技术这一问题部分得到了解决。<a href="/cn/blog/follow-the-leader-an-introduction-to-cross-cluster-replication-in-elasticsearch" target="_self">在 Elasticsearch 6.7 中引入跨集群复制</a>后，无需再依赖其他技术便可跨数据中心、跨地区或者跨 Elasticsearch 集群来复制数据。 
跨集群复制 (CCR) 功能支持将特定索引从一个 ElasticSearch 集群复制到一个或多个 ElasticSearch 集群。除了跨数据中心复制之外，CCR 还有许多其他用例，包括数据本地化（将数据复制到距离用户/应用程序服务器更近的位置，例如，将产品目录复制到全球 20 个不同的数据中心），或者将数据从 Elasticsearch 集群复制到中央报告集群（例如，全球 1000 家银行分行都向其本地 Elasticsearch 集群写入数据，并复制回总部的集群用于报告）。
在本教程中，针对如何使用 CCR 进行跨数据中心复制，我们将简要介绍 CCR 基础知识，重点介绍架构选项和权衡事项，配置跨数据中心部署样例，并着重介绍一些管理命令。有关 CCR 技术层面的介绍，请参阅<a href="/cn/blog/follow-the-leader-an-introduction-to-cross-cluster-replication-in-elasticsearch?blade=tw&hulk=social" target="_self">追随领导者：Elasticsearch 中的跨集群复制简介</a>。
CCR 是一项<a href="/cn/subscriptions" target="_self">白金级功能</a>，可通过 30 天试用许可证进行体验，该许可证可通过<a href="/guide/en/elasticsearch/reference/6.7/start-trial.html" target="_self">开始试用 API</a> 激活，也可以<a href="/guide/en/kibana/6.7/managing-licenses.html" target="_self">直接从 Kibana</a> 激活。
<h2>跨集群复制 (CCR) 基础知识</h2>
<h4>复制是在索引级别（或基于索引模式）配置的</h4>
CCR 是在 Elasticsearch 中的索引级别配置的。通过在索引级别配置复制，可以使用大量的复制策略，包括一些索引在一个方向复制，一些索引在另一个方向复制，以及细粒度的跨数据中心架构。
<h4>复制索引是只读的</h4>
索引可以由一个或多个 Elasticsearch 集群进行复制。每个复制索引的集群都维护一份索引的只读副本。能够接受写操作的主动索引称为领导者。索引的被动只读副本称为追随者。并不存在选举新领导者的概念，因此，当领导者索引不可用（如集群/数据中心中断）时，应用程序管理员或集群管理员必须为写入显式选择另一个索引，而这个索引很可能位于另一个集群中。
<h4>CCR 的默认值适用于各种高吞吐量用例</h4>
如果不十分了解调整值会对系统产生怎样的影响，则不建议更改默认值。&nbsp;大多数选项可在 <a href="/guide/en/elasticsearch/reference/6.7/ccr-put-follow.html" target="_self">Create follower API</a> 中找到，例如<a href="/guide/en/elasticsearch/reference/6.7/ccr-put-follow.html#_request_body_2" target="_self">“max_read_request_operation_count”</a>或<a href="/guide/en/elasticsearch/reference/6.7/ccr-put-follow.html#_request_body_2" target="_self">“max_retry_delay”</a>。我们很快会发布一篇文章，专门介绍如何针对独特的工作负载调优这些参数。
<h4>安全性要求</h4>
如 <a href="/guide/en/elastic-stack-overview/6.7/ccr-getting-started.html" target="_self">CCR 入门指南</a>中所述，源集群中的用户必须具有“read_ccr”集群特权，以及“monitor”和“read”索引特权。在目标集群中，用户必须具有“manage_ccr”集群特权，以及“monitor”、“read”、“write”和“manage_follow_index”索引特权。另外，还可以使用集中身份验证系统，例如 <a href="/guide/en/elastic-stack-overview/6.7/ldap-realm.html" target="_self">LDAP</a>。
<h2>跨数据中心 CCR 架构样例</h2>
<h4>生产和 DR 数据中心</h4>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte3e58d8765ef9173/5cb841bac2ee674b3a63c78d/Screen_Shot_2019-04-04_at_10.21.55_AM.png" data-sys-asset-uid="blte3e58d8765ef9173" alt="Screen Shot 2019-04-04 at 10.21.55 AM.png" />
<figcaption>数据从生产数据中心复制到 DR 数据中心。如果生产数据中心不可用，则可以使用 DR 数据中心。</figcaption>
<h4>两个以上的数据中心</h4>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt64cf4e96748d2015/5cb841b57a1339d83e460a52/Screen_Shot_2019-04-04_at_10.22.09_AM.png" data-sys-asset-uid="blt64cf4e96748d2015" alt="Screen Shot 2019-04-04 at 10.22.09 AM.png" />
<figcaption>数据从数据中心 A 复制到多个数据中心（图中的 B 和 C）。数据中心 B 和 C 现在拥有数据中心 A 的索引的只读副本。</figcaption>
<h4>连锁复制</h4>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt381f47b744699f6a/5cb841afedd7b16b49a31657/Screen_Shot_2019-04-04_at_10.22.19_AM.png" data-sys-asset-uid="blt381f47b744699f6a" alt="Screen Shot 2019-04-04 at 10.22.19 AM.png" />
<figcaption>还可以跨多个数据中心进行连锁复制。在本例中，领导者索引位于数据中心 A。数据从数据中心 A 复制到数据中心 B，然后数据中心 C 从数据中心 B 的追随者索引进行复制，以创建一个连锁复制模式。</figcaption>
<h4>双向复制</h4>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2d3756089e4877ee/5cb841a806b45cc02a617323/Screen_Shot_2019-04-04_at_10.22.30_AM.png" data-sys-asset-uid="blt2d3756089e4877ee" alt="Screen Shot 2019-04-04 at 10.22.30 AM.png" />
<figcaption>由于复制是在索引级别配置的，因此，可以为每个数据中心维护一个领导者索引。应用程序可以写入每个数据中心内的本地索引，并跨多个索引读取，以全局查看所有信息。</figcaption>
<h2>跨数据中心部署教程</h2>
<h3>1.设置</h3>
在本教程中，我们使用的两个集群都位于本地计算机上。您可以将集群随意放在任何喜欢的位置。
<ul>
 <li>“us-cluster”：这是“美国集群”，将在端口 9200 上本地运行。我们会将文档从美国集群复制到日本集群。</li>
 <li>“japan-cluster”：这是“日本集群”，将在端口 8200 上本地运行。该日本集群将维护一个来自美国集群的复制索引。</li>
</ul>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltac104b2d0956b9f6/5cb841a4fbfd32503a2f15b6/Screen_Shot_2019-04-04_at_10.22.44_AM.png" data-sys-asset-uid="bltac104b2d0956b9f6" alt="Screen Shot 2019-04-04 at 10.22.44 AM.png" />
<h3>2.定义远程集群</h3>
当设置 CCR 时，Elasticsearch 集群必须知道其他 Elasticsearch 集群。这是一个单向要求，因为目标集群将保持与源集群的单向连接。我们将其他 Elasticsearch 集群定义为远程集群，并指定别名来描述它们。
我们需要确保“japan-cluster”知道“us-cluster”。CCR 中的复制是基于拉取模式的，不需要我们指定从“us-cluster”到“japan-cluster”的连接。
下面让我们通过“japan-cluster”上的 API 调用来定义“us-cluster”<pre class="prettyprint"># From the japan-cluster, we’ll define how the us-cluster can be accessed PUT /_cluster/settings { "persistent" : { "cluster" : { "remote" : { "us-cluster" : { "seeds" : [ "127.0.0.1:9300" ] } } } } } </pre>
（对于基于 API 的命令，建议使用 Kibana 中的开发工具控制台，访问路径为：Kibana -> Dev tools（开发工具）-> Console（控制台））
上述 API 调用使用别名“us-cluster”（可从“127.0.0.1:9300”访问）来定义远程集群。可以指定一个或多个种子，通常建议指定多个种子，以免在握手阶段种子不可用。
有关配置远程集群的更多详细信息，请参阅<a href="/guide/en/elasticsearch/reference/current/modules-remote-clusters.html" target="_self">关于定义远程集群的参考文档</a>。
另外，还要注意连接到“us-cluster”的端口 9300，“us-cluster”侦听的是端口 9200 上的 HTTP 协议（这是默认端口，是在 elasticsearch.yml 文件中为“us-cluster”指定的）。但是，复制是使用 Elasticsearch 传输协议（用于节点到节点通信）进行的；默认为端口 9300。
Kibana 中有一个用于远程集群的管理 UI，我们将在本教程中介绍用于 CCR 的 UI 和 API。要在 Kibana 中访问远程集群 UI，请单击左侧导航面板中的“Management”（管理）（齿轮图标），然后导航到 Elasticsearch 部分中的“Remote Clusters”（远程集群）。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0faf042ee2ad0350/5cb841e6ff38cb053a0b24e9/Screen_Shot_2019-03-27_at_2.17.24_PM.png" data-sys-asset-uid="blt0faf042ee2ad0350" alt="Screen Shot 2019-03-27 at 2.17.24 PM.png" />
<figcaption>Kibana 中的 Elasticsearch 远程集群管理 UI</figcaption>
<h3>3.创建要复制的索引</h3>
我们下面在“us-cluster”上创建一个名为“products”的索引，然后将这个索引从源“us-cluster”复制到目标“japan-cluster”：
在“us-cluster”上：<pre class="prettyprint"># Create product index PUT /products { "settings" : { "index" : { "number_of_shards" :1, "number_of_replicas" :0, "soft_deletes" : { "enabled" : true } } }, "mappings" : { "_doc" : { "properties" : { "name" : { "type" : "keyword" } } } } } </pre>
您可能已注意到“soft_deletes”设置。要使索引用作 CCR 的 Leader 索引，需要使用软删除（有关详细信息，请参阅<a href="/cn/blog/follow-the-leader-an-introduction-to-cross-cluster-replication-in-elasticsearch" target="_self">不知道历史记录的人</a>）：
soft_deletes：无论何时删除或更新现有文档，都会发生软删除。通过将这些软删除一直保留到可配置的限度，可以将操作历史记录保留在领导者分片上，并在重新处理操作历史记录时供追随者分片任务使用。
当追随者分片从领导者复制操作时，它会在领导者分片上留下标记，这样领导者就知道追随者在历史记录中的所在位置。这些标记下面的软删除操作可以逐渐消失。基于这些标记，领导者分片将会保留这些操作，直到分片历史记录保留租用期结束（默认为 12 个小时）。此期间确定了追随者在有可能远远落后并需要从领导者处重新引导之前可以离线的时间。
<h3>4.启动复制</h3>
至此，我们已经为远程集群创建了一个别名，并创建了一个我们要复制的索引，接下来我们启动复制。
在“japan-cluster”上：<pre class="prettyprint">PUT /products-copy/_ccr/follow { "remote_cluster" : "us-cluster", "leader_index" : "products" } </pre>
该端点包含“products-copy”，这是“japan-cluster”集群中复制索引的名称。我们将从以前定义的“us-cluster”集群中进行复制，并且要复制的索引名称在“us-cluster”集群上称为“products”。
请务必注意，复制索引是只读的，不能接受写操作。
好了，就这么简单！我们已配置了要从一个 Elasticsearch 集群复制到另一个集群的索引！
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte6a3b0302b262d44/5cb841e0fbfd32503a2f15bc/Screen_Shot_2019-03-27_at_2.18.37_PM.png" data-sys-asset-uid="blte6a3b0302b262d44" alt="Screen Shot 2019-03-27 at 2.18.37 PM.png" />
<figcaption>Kibana 中的 CCR 管理 UI</figcaption>
<h4>启动索引模式的复制</h4>
您可能已经注意到，对于基于时间的用例（即每天都有一个索引）或大量数据来说，上面的示例并不太适合。此外，CCR API 还包含定义<a href="/guide/en/elasticsearch/reference/6.7/ccr-put-auto-follow-pattern.html" target="_self">自动跟随模式</a>（即应复制哪些索引模式）的方法。
我们可以使用 CCR API 来定义自动跟随模式<pre class="prettyprint">PUT /_ccr/auto_follow/beats { "remote_cluster" : "us-cluster", "leader_index_patterns" : [ "metricbeat-*", "packetbeat-*" ], "follow_index_pattern" : "{{leader_index}}-copy" } </pre>
上面的 API 调用样例将复制开头为“metricbeat”或“packetbeat”的索引。
我们还可以使用 Kibana 中的 CCR UI 来定义自动跟随模式。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt63a2c6d6c293993d/5cb841dac2ee674b3a63c799/Screen_Shot_2019-03-27_at_2.20.07_PM.png" data-sys-asset-uid="blt63a2c6d6c293993d" alt="Screen Shot 2019-03-27 at 2.20.07 PM.png" />
<figcaption>Kibana 中针对自动跟随模式的 CCR 管理 UI</figcaption>
<h3>5.测试复制设置</h3>
至此，我们已经拥有从“us-cluster”复制到“japan-cluster”的产品索引。接下来，我们插入一个测试文档，验证它是否已被复制。
在“us-cluster”集群上：<pre class="prettyprint">POST /products/_doc { "name" :"My cool new product" } </pre>
现在，我们来查询一下“japan-cluster”，以确保文档已被复制：<pre class="prettyprint">GET /products-copy/_search </pre>
我们现在应该有一个文档，它是在“us-cluster”上编写的，并复制到“japan-cluster”。<pre class="prettyprint">{ "took" :1, "timed_out" : false, "_shards" : { "total" :1, "successful" :1, "skipped" :0, "failed" :0 }, "hits" : { "total" :1, "max_score" :1.0, "hits" : [ { "_index" : "products-copy", "_type" : "_doc", "_id" : "qfkl6WkBbYfxqoLJq-ss", "_score" :1.0, "_source" : { "name" :"My cool new product" } } ] } } </pre>
<h2>跨数据中心管理备注</h2>
我们下面介绍一下用于 CCR 的一些管理 API、可调设置，并概述在 Elasticsearch 中将复制索引转换为普通索引的方法。
<h3>用于复制的管理 API</h3>
在 Elasticsearch 中有许多有用的用于 CCR 的管理 API。它们可能有助于调试复制、修改复制设置或收集详细的诊断信息。<pre class="prettyprint"># Return all statistics related to CCR GET /_ccr/stats # Pause replication for a given index POST /<follower_index>/_ccr/pause_follow # Resume replication, in most cases after it has been paused POST /<follower_index>/_ccr/resume_follow { } # Unfollow an index (stopping replication for the destination index), which first requires replication to be paused POST /<follower_index>/_ccr/unfollow # Statistics for a following index GET /<index>/_ccr/stats # Remove an auto-follow pattern DELETE /_ccr/auto_follow/<auto_follow_pattern_name> # View all auto-follow patterns, or get an auto-follow pattern by name GET /_ccr/auto_follow/ GET /_ccr/auto_follow/<auto_follow_pattern_name> </pre>
有关 CCR 管理 API 的更多详细信息，请参阅 <a href="/guide/en/elasticsearch/reference/current/ccr-apis.html" target="_self">Elasticsearch 参考文档</a>。
<h3>将追随者索引转换为普通索引</h3>
我们可以使用上述管理 API 的子集，将追随者索引转换为在 Elasticsearch 中的能够接受写操作的普通索引。
在上述示例中，我们进行了相当简单的设置。请记住，“japan-cluster”上复制“products-copy”索引是只读的，它不能接受任何写操作。如果希望将“products-copy”索引转换为 Elasticsearch 中的普通索引（能够接受写操作），我们可以执行下列命令。请记住，原始索引（“products”）上的写操作可以继续，在将“products-copy”索引转换为普通 Elasticsearch 索引之前，可能需要先将写操作限定在“products”索引上。<pre class="prettyprint"># Pause replication POST /<follower_index>/_ccr/pause_follow # Close the index POST /my_index/_close # Unfollow POST /<follower_index>/_ccr/unfollow # Open the index POST /my_index/_open </pre>
<h2>继续探索 Elasticsearch 中的跨集群复制 (CCR)</h2>
我们编写本指南的宗旨是帮助您在 Elasticsearch 中开始使用 CCR，并希望在让您熟悉 CCR、了解各种 CCR API（包括 Kibana 中提供的 UI）和尝试使用该功能方面有所帮助。其他资源包括<a href="/guide/en/elasticsearch/reference/6.7/ccr-getting-started.html" target="_self">跨集群复制入门指南</a>和<a href="/guide/en/elasticsearch/reference/current/ccr-apis.html" target="_self">跨集群复制 API 参考指南</a>。
一如既往，请<a href="https://discuss.elastic.co/" target="_self">在我们的讨论论坛上留下反馈和问题</a>，我们一定尽快回答。

blog-banner-release-elasticsearch.png

blog-thumb-release-elasticsearch.png

Cross-Datacenter Replication with Elasticsearch Cross-Cluster Replication

使用 Elasticsearch 跨集群复制进行跨数据中心复制

ECK 基于 Operator 模式构建而成，能够扩展 Kubernetes 以支持对 Elasticsearch 和 Kibana 进行设置和管理，还能简化很多关键操作。

尽管仍在 α 测试阶段，近期<a href="/cn/blog/introducing-elastic-cloud-on-kubernetes-the-elasticsearch-operator-and-beyond" target="_self">有关 Elastic Cloud on Kubernetes (ECK) 的公告</a>还是在 Elasticsearch 社区和 Kubernetes 社区引发了人们浓厚的兴趣。ECK 由 Elastic Stack 的开发人员开发和提供支持，是在 Kubernetes 上部署 Elastic 的首选方式。本系列博文共有两篇，旨在带您逐步完成下面的过程：
<ol>
 <li>在 Kubernetes 集群（Minikube 或 GKE）中部署 ECK</li>
 <li>在 ECK 中部署 Elastic Stack</li>
 <li>在 ECK 中对 Elasticsearch 和 Kibana 进行缩放和升级</li>
 <li>部署一个由 Elastic APM 检测的范例应用程序，并将 APM 数据发送至由 ECK 托管的 Elasticsearch 集群</li>
 <li>将 Metricbeat 作为 DaemonSet 部署到 Kubernetes 中，并将 Metribeat 安全地连接至由 ECK 托管的 Elasticsearch 集群</li>
</ol>
按照博文进行操作后，您将会拥有一套如下图所示的系统。在第一篇博文中，我们专注于部署 ECK 和 Elastic Stack。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt581c3354e0ff2a19/5d669db03c79d92e49236cd1/eck-deployment-diagram-blog.png" data-sys-asset-uid="blt581c3354e0ff2a19" alt="ECK 部署关系图" style="display: block;margin-top: auto;margin-right: auto;margin-bottom: auto;margin-left: auto;" />
您还可以参考<a href="/guide/en/cloud-on-k8s/0.9/k8s-quickstart.html" target="_self">快速入门</a>页面或<a href="/cn/elasticsearch-kubernetes" target="_self">产品页面</a>，以了解有关 ECK 的最新信息。
<h2>创建您的 k8s 集群</h2>
您必须准备好一个 Kubernetes 集群，然后才能部署 ECK 和 Elastic Stack。在本篇博文中，Minikube 或 Google Kubernetes Engine (GKE) 都可以。我们还支持其他 Kubernetes 分发包，例如 <a href="/guide/en/cloud-on-k8s/0.9/k8s-openshift.html" target="_self">OpenShift</a>、Amazon EKS 和 Microsoft AKS。由于我们要部署 ECK、Elasticsearch、Kibana、APM Server 和一个范例应用程序，我建议您将集群配置为 16 GB 内存和 4 核处理器。您也可以将 Kubernetes 集群配置为 12 GB 内存，但 16 GB 肯定能为您带来流畅的使用体验。
<h3>Minikube</h3>
如果您准备使用 Minikube，请按照<a href="https://kubernetes.io/docs/tasks/tools/install-minikube/#install-minikube" target="_self">安装说明</a>进行安装。安装完毕后，使用所需的资源对 Minikube 进行配置并将其启动：<pre class="prettyprint">minikube config set memory 16384 minikube config set cpus 4 minikube start </pre>
借助 Kubernetes 仪表板，您能够十分便捷地对 Kubernetes 集群进行监测和管理。您通过一条命令便可为 Minikube 启用仪表板：<pre class="prettyprint">minikube dashboard </pre>
会自动打开一个浏览器窗口，并显示 Kubernetes 仪表板。就这么简单——您可以进行下一步了。
<h3>Google Kubernetes Engine (GKE)</h3>
如想使用 GKE，请按照 Google <a href="https://cloud.google.com/kubernetes-engine/" target="_self">文档</a>来配置您的集群。我的 GKE 集群包括一个节点，该节点的配置为 15 GB 内存，4 个 vCPU。您可以选择小一些的集群，但是内存不得小于 12 GB。而且，如要使用 GKE，您需要 <a href="https://cloud.google.com/sdk/gcloud/" target="_self">gcloud 命令行工具</a>。
您的 GKE 集群设置完毕并运行后，使用下方命令来连接至您的集群并设置所需的权限。对于 GKE，您必须拥有集群管理员权限。确保将 project name（项目名称）、zone name（区域名称）、cluster name（集群名称）和 user ID（用户 ID）替换为您的信息：<pre class="prettyprint">gcloud config set project elastic-sa gcloud config set compute/zone us-central1-a gcloud config set container/cluster aquan gcloud auth login gcloud container clusters get-credentials aquan --zone us-central1-a --project elastic-sa kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user=adam.quan@elastic.co kubectl create clusterrolebinding adam.quan-cluster-admin-binding --clusterrole=cluster-admin --user=adam.quan@elastic.co </pre>
最后，我们将要使用 Kubernetes 命令行工具与 Minikube 或 GKE 进行交互。按照<a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/" target="_self">指南</a>安装 kubectl。确保您所安装的 kubectl 为 1.11 或更新版本。
至于本篇博文所使用的项目，您可从这个 <a href="https://github.com/adamquan/ECK" target="_self">GitHub 存储库</a>下载。
<h2>部署 Elasticsearch Operator</h2>
只需一条命令便可部署 ECK，您相信吗？就是这样——只需运行下方命令便可部署最新的 ECK 0.9.0（截至撰写本文时）。无比简单快捷。<pre class="prettyprint">kubectl apply -f https://download.elastic.co/downloads/eck/0.9.0/all-in-one.yaml </pre>
部署完成后，您可以使用下方命令监测来自 Operator 的日志并确保一切顺利。片刻之间，便能部署完并运行 ECK 。<pre class="prettyprint">kubectl -n elastic-system logs -f statefulset.apps/elastic-operator </pre>
<h2>部署 Elastic Stack</h2>
既然现在 ECK 已在运行，我们可以开始部署 Elastic Stack 了，也是仅需一条命令。查看 <a href="https://github.com/adamquan/ECK/blob/master/apm_es_kibana.yaml" target="_self">apm_es_kibana.yaml</a> 并了解配置 Kibana 和 APM Server 有多么简单；配置完后，Kibana 和 APM Server 便可使用 elasticsearchRef 彼此进行通信。
您可以通过很多方法<a href="/guide/en/cloud-on-k8s/0.9/k8s-elasticsearch-specification.html" target="_self">对部署进行自定义</a>，例如：
<ul>
 <li>Pod 模板</li>
 <li>节点配置</li>
 <li>虚拟内存</li>
 <li>自定义 HTTP 证书</li>
 <li>安全设置</li>
</ul>
使用下方命令部署堆栈：<pre class="prettyprint">kubectl apply -f apm_es_kibana.yaml </pre>
通过 kubectl 或者 Kubernetes 仪表板了解 Elasticsearch、Kibana 和 APM Server 的状态，并确保所有均为绿色和可用状态：<pre class="prettyprint">kubectl get elasticsearch,kibana,apmserver </pre>
所有三个组件均变为绿色即表示您的 Elasticsearch 集群已部署完毕并正常运行，可以向其中采集数据了。ECK 可帮助我们完成很多任务。稍停一下，我们看一下 ECK 到底对我们的集群进行了哪些操作：
<ul>
 <li>为 ECK 开启了安全功能。通过 ECK 部署的所有 Elastic Stack 资源均默认受到安全保护。内置的基本身份验证用户 elastic 已通过 TLS 进行配置，而且往返于 Elasticsearch 集群的以及 Elasticsearch 集群内的网络流量均通过 TLS 受到安全保护。</li>
 <li>证书：默认情况下，会针对每个集群使用一个自签名 CA 证书。还可以配置自定义 HTTPS 证书。</li>
 <li>默认服务暴露：会自动为您的集群和 Kibana 创建一项 ClusterIP 服务。如有需要，您当然可以将其配置为 LoadBalancer 类型。</li>
</ul>
现在 Elasticsearch、Kibana 和 APM Server 都已正常运行，我们从 Kibana 中看一下。
<h2>访问 Kibana</h2>
默认情况下，Kibana 会暴露为一项可从集群内部访问集群 IP 的服务，但 Kibana 不会暴露至互联网。然而，您可以使用下方的端口转发命令让您的笔记本电脑可以访问 Kibana：<pre class="prettyprint">kubectl port-forward service/kibana-sample-kb-http 5601 </pre>
登录 Kibana 之前，我们需要获得默认 elastic 用户的凭据。您可以运行 kubectl get secret，然后检查密钥以找出密钥的 JSON 路径。下面是我们案例的正确密钥和路径：<pre class="prettyprint">echo `kubectl get secret elasticsearch-sample-es-elastic-user -o=jsonpath='{.data.elastic}' | base64 --decode` </pre>
Elastic 用户的密码已显示出来。将其复制并保存至记事本中。
现在，打开浏览器并连接至 https://localhost:5601。由于我们使用的是自签名证书，您将需要接受浏览器的安全警告。使用 Elastic 用户和您刚检索到的密码登录 Kibana。您将会来到 Kibana 主页。我们的集群已完全部署完毕啦！
<h2>缩放和升级</h2>
在 ECK 中缩放和升级 Elasticsearch 集群的过程十分简单，只需编辑部署配置并通过 kubectl 加以应用即可。
<h3>缩放</h3>
编辑您的部署清单 apm_es_kibana.yaml，在下面部分中将 elasticsearch 容器的内存大小从 3 GB 调整为 2 GB 即可：<pre class="prettyprint"> containers: - name: elasticsearch resources: limits: memory: 3Gi </pre>
保存文件并通过这条命令对节点进行缩放：<pre class="prettyprint">kubectl apply -f apm_es_kibana.yaml </pre>
立即切换至 Kubernetes 控制台，您在这里会看到创建了几个 Elasticsearch Pod。ECK 正在缩放 Elasticsearch 节点，而且实现了零中断。很快您就会发现新的 Pod 开始运行，而原始 Pod 也会消失。原始 Pod 的数据也畅通无阻地转移了过来。
您当然还可以通过其他方式对集群规模进行缩放，例如向其中添加更多节点。无论采用什么方式，通过简单的一条 kubectl apply 命令就能搞定。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9ce4b89f5a75638c/5d669de848f9131ee05db04e/eck-deployment-pod-creation-blog.png" data-sys-asset-uid="blt9ce4b89f5a75638c" alt="正在创建 Elasticsearch 集群" style="display: block;margin-top: auto;margin-right: auto;margin-bottom: auto;margin-left: auto;" />
<h3>升级</h3>
现在，我们将集群升级至 7.2.0，只需简单地在部署清单文件 apm_es_kibana.yaml 中将 Elasticsearch、Kibana 和 APM Server 的版本从 7.1.0 更改为 7.2.0 即可。保存并通过下面的命令应用升级：<pre class="prettyprint">kubectl apply -f apm_es_kibana.yaml </pre>
相似地，从 Kubernetes 控制台中您可以看到 ECK 正在流畅地对 Elasticsearch、Kibana 和 APM Server 进行升级，而且实现了零中断。
升级过程完成后，验证并确认您所运行 Elastic Stack 的版本是 7.2.0。您现在完全相信 ECK 的强大能力了吧？希望如此。
<h2>总结</h2>
希望您喜欢 Elastic Cloud on Kubernetes 的快速入门过程，并且认识到这一过程有多么简单。在本篇博文的<a href="/cn/blog/getting-started-with-elastic-cloud-on-kubernetes-data-ingestion" target="_self">第 2 部分</a>，我们将会部署一个由 APM 检测的简单应用程序，并让其将 APM 数据发送至我们由 ECK 托管的集群。我们还会在 Kubernetes 中部署 Metricbeat，以将指标数据发送至集群。

eck-announcement-banner.png

eck-deployment-blog-thumb.jpg

Getting started with Elastic Cloud on Kubernetes: Deployment

Elastic Cloud on Kubernetes 入门：部署

适用于解决 Elasticsearch 内存分配问题的技巧和资源。

大家好啊！随着 Elastic 扩展我们的 Elasticsearch Service Cloud 产品和自动上线流程，我们已经将 Elastic Stack 的受众范围从运营团队全员扩展到了数据工程师、安全团队和顾问。作为一名 Elastic 支持工程师，我很喜欢与更多具有不同背景、用例甚至更广的用户进行互动。&nbsp;
随着服务对象的增多，我接触到了更多关于管理资源分配方面的问题，特别是晦涩难懂的分片堆比和避免触发熔断器的问题，不免让人无从理解。我也是心有戚戚焉！在开始使用 Elastic Stack 时，我也遇到了同样的问题。这是我第一次介绍如何管理 Java 堆和时序数据库分片，以及如何扩展自己的基础架构。
当我加入 Elastic 团队时，我除了喜欢阅读文档之外，还喜欢看我们的博客和教程，以便让我自己很快上手。但我入职的第一个月过得并不轻松，因为我要将理论知识与用户通过工单接连发送给我的各种错误联系起来。最后，和其他支持工程师一样，我发现所报告的错误中有不少都属于分配问题的症状，通过相同的七个链接便可让用户快速提升成功管理资源分配的能力。
在以下部分中，我将以支持工程师的身份，介绍我们发送给用户的主要分配管理理论链接、我们看到的主要症状，以及我们指引用户去哪里更新自己的配置来解决资源分配问题。
<h2>理论</h2>
作为一款使用 Java 开发的应用程序，Elasticsearch 需要从系统的物理内存中分配部分逻辑内存（堆）。这部分内存最大不超过物理 RAM 的一半，<a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html#compressed_oops" target="_self">上限为 32GB</a>。设置较高的堆利用率通常是为了<a href="https://www.elastic.co/guide/en/cloud/current/ec-memory-pressure.html#ec-memory-pressure-causes" target="_self">应对</a>耗费资源的查询和较大的数据存储。<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/circuit-breaker.html#parent-circuit-breaker" target="_self">父级熔断器</a>默认在堆利用率为 95% 时触发，但我们建议在堆利用率<a href="https://www.elastic.co/cn/blog/found-understanding-memory-pressure-indicator#conclusion" target="_self">持续达到 85%</a> 时，就应该扩展一下资源了。&nbsp;
我强烈建议阅读以下由我们团队撰写的概述性文章，以了解更多信息：
<ul>
 <li aria-level="1"><a href="https://www.elastic.co/cn/blog/a-heap-of-trouble" target="_self">一“堆”麻烦</a></li>
 <li aria-level="1"><a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html" target="_self">堆：大小调整和交换</a></li>
 <li aria-level="1"><a href="https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster" target="_self">我在 Elasticsearch 集群内应该设置多少个分片？</a></li>
</ul>
<h2>配置</h2>
Elasticsearch 开箱即用的<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.11/important-settings.html#heap-size-settings" target="_self">默认设置</a>会根据节点角色和内存总量自动调整 JVM 堆的大小。但是，您也可以根据需要通过以下三种方式直接进行配置：
1. 直接在本地 Elasticsearch 文件的 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.11/advanced-configuration.html#setting-jvm-heap-size" target="_self">config &gt; jvm.options</a> 文件中<pre class="prettyprint">## JVM 配置 ################################################################ ## 重要说明：JVM 堆大小 ################################################################ … #Xms 表示总堆空间的初始大小 #Xmx 表示总堆空间的最大大小 -Xms4g -Xmx4g </pre>
2. 作为 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.12/docker.html#docker-cli-run-prod-mode" target="_self">docker-compose</a> 中的 Elasticsearch 环境变量<pre class="prettyprint">version: '2.2' services: es01: image: docker.elastic.co/elasticsearch/elasticsearch:7.12.0 environment: - node.name=es01 - cluster.name=es - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" - discovery.type=single-node ulimits: memlock: soft: -1 hard: -1 ports: - 9200:9200 </pre>
3. 通过我们的 Elasticsearch Service &gt;“Deployment”（部署）&gt;<a href="https://www.elastic.co/guide/en/cloud/current/ec-customize-deployment-components.html#ec-cluster-size" target="_self">“Edit”（编辑）视图</a>。注意：滑动条分配的是物理内存，约有一半会分配给堆。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt85a09eec61be50dc/60832291b775555b377675af/blog-elasticsearch-memory.png" data-sys-asset-uid="blt85a09eec61be50dc" alt="blog-elasticsearch-memory.png" />
<h2>故障排查</h2>
如果您的集群当前遇到性能问题，则很可能是以下常见问题所致
<ul>
 <li aria-level="1">配置问题：过度分片，无 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html" target="_self">ILM</a> 策略</li>
 <li aria-level="1">引入的高数据量：高请求速度/负载，叠加耗费资源的查询/写入</li>
</ul>
所有以下 cURL/API 请求都可以在 Elasticsearch Service &gt;“API Console”（API 控制台）中作为 Elasticsearch API 的 cURL 发出，或者在 Kibana &gt;“Dev Tools”（开发工具）下进行。
<h3>过度分片</h3>
数据索引<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html" target="_self">存储在子分片</a>中，这些子分片会在维护以及搜索/写入请求期间使用堆。分片大小的<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.x/size-your-shards.html#shard-size-recommendation" target="_self">上限应设为 50GB</a>，数量上限应设为<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.x/size-your-shards.html#shard-count-recommendation" target="_self">通过以下公式确定的值</a>：<pre class="prettyprint">shards = sum(nodes.max_heap) * 20 </pre>
以上面的 Elasticsearch Service 为例，在两个区域中具有 8GB 的物理内存（将总共分配两个节点）<pre class="prettyprint">#node.max_heap 8GB of physical memory / 2 = 4GB of heap #sum(nodes.max_heap) 4GB of heap * 2 nodes = 8GB #max shards 8GB * 20 160 </pre>
然后将这个结果与 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-allocation.html" target="_self">_cat/allocation</a> 进行交叉比较<pre class="prettyprint">GET /cn/_cat/allocation?v=true&amp;h=shards,node shards node 41 instance-0000000001 41 instance-0000000000 </pre>
或者以 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html" target="_self">_cluster/health</a> 作为比较对象<pre class="prettyprint">GET /cn/_cluster/health?filter_path=status,*_shards { "status": "green", "unassigned_shards": 0, "initializing_shards": 0, "active_primary_shards": 41, "relocating_shards": 0, "active_shards": 82, "delayed_unassigned_shards": 0 } </pre>
因此，这个部署有 82 个分片，而建议最多可有 160 个分片。如果计数高于建议值，则您可能会遇到接下来两个部分中介绍的症状（请见下文）。
如果有任何分片报告（active_shards 或 active_primary_shards 除外）数字大于 0，那么您就找到了导致性能问题的主要配置原因。
如果这方面报告了问题，最常见的情况将是 unassigned_shards&gt;0。如果这些分片是主要分片，则集群将报告状态：红色；如果只是副本分片，它将报告状态：黄色。（这就是<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html#dynamic-index-settings" target="_self">在索引上设置副本分片</a>的重要之处，这样一来，如果集群遇到问题，它可以恢复数据而避免数据丢失。）
假设我们有一个状态：黄色，带有一个未分配的分片。为了进行调查，我们将通过 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-shards.html" target="_self">_cat/shards</a> 来查看哪个索引分片出现问题<pre style="white-space: pre;display: -webkit-box;" class="prettyprint">GET _cat/shards?v=true&amp;s=state index shard prirep state docs store ip node logs 0 p STARTED 2 10.1kb 10.42.255.40 instance-0000000001 logs 0 r UNASSIGNED kibana_sample_data_logs 0 p STARTED 14074 10.6mb 10.42.255.40 instance-0000000001 .kibana_1 0 p STARTED 2261 3.8mb 10.42.255.40 instance-0000000001 </pre>
因此，这将会用到我们的非系统索引日志，因为这个日志有一个未分配的副本分片。让我们运行一下 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.12/cluster-allocation-explain.html" target="_self">_cluster/allocation/explain</a> 来看看是什么导致了问题（专业提示：如果您向支持部门上报问题，我们做的就是这个操作）<pre style="white-space: pre;display: -webkit-box;" class="prettyprint">GET _cluster/allocation/explain?pretty&amp;filter_path=index,node_allocation_decisions.node_name,node_allocation_decisions.deciders.* { "index": "logs", "node_allocation_decisions": [{ "node_name": "instance-0000000005", "deciders": [{ "decider": "data_tier", "decision": "NO", "explanation": "node does not match any index setting [index.routing.allocation.include._tier] tier filters [data_hot]" }]}]} </pre>
这个错误消息指向 data_hot，它是<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html" target="_self">索引生命周期管理</a> (ILM) 策略的一部分，并指明我们的 ILM 策略与当前的索引设置不一致。在本例中，这个错误的原因是在没有指定热温节点的情况下设置了热温 ILM 策略。（我需要保证让某些操作出现失败，以便为大家强行展示错误示例。看看你们对我都做了些什么😂。）
顺便说一下：如果您在没有任何未分配分片的情况下运行这个命令，则会出现 400 错误，提示找不到任何未分配的分片进行解释，因为没有错误要报告。
如果您遇到非逻辑原因（例如，分配期间节点离开群集等临时网络错误），则可以使用 Elastic 方便好用的 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-reroute.html" target="_self">_cluster/reroute</a>。
<pre class="prettyprint">POST /cn/_cluster/reroute </pre>

这个无需定制的请求可启动一个异步后台进程，以尝试分配所有当前状态为 UNASSIGNED 的分片。（千万不要像我一样，不等它完成就联系开发人员；我原以为它瞬间就可以完成，上报时他们正好可以说什么错误都没有，因为什么问题都消失了。）
<h3>熔断器</h3>
最大限度地增加堆分配可能会导致对集群的请求发生超时或出错，并且会经常导致集群出现熔断器异常。熔断器会导致类似以下的 elasticsearch.log 事件：<pre class="prettyprint">Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [num/numGB], which is larger than the limit of [num/numGB], usages [request=0/0b, fielddata=num/numKB, in_flight_requests=num/numGB, accounting=num/numGB] </transport_request></pre>
要进行调查，请查看您的 heap.percent，方法是查看 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-nodes.html" target="_self">_cat/nodes</a><pre class="prettyprint">GET /cn/_cat/nodes?v=true&amp;h=name,node*,heap* #heap = JVM (logical memory reserved for heap) #ram = physical memory name node.role heap.current heap.percent heap.max tiebreaker-0000000002 mv 119.8mb 23 508mb instance-0000000001 himrst 1.8gb 48 3.9gb instance-0000000000 himrst 2.8gb 73 3.9gb </pre>
或者，如果您先前已启用它，也可以通过导览至 Kibana &gt;“Stack Monitoring”（堆栈监测）来进行调查。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb3f4f2c5cdb2823c/608322c4eed217453bf28487/blog-elasticsearch-memory-2.png" data-sys-asset-uid="bltb3f4f2c5cdb2823c" alt="blog-elasticsearch-memory-2.png" />
如果您确认将会触发内存熔断器，则可以考虑临时增加堆容量，为自己腾出空间进行调查。在调查根本原因时，请通过集群代理日志或 elasticsearch.log 查找先前的连续事件。您要寻找的是
<ul>
 <li aria-level="1">最耗费资源的查询，尤其是：<ul>
 <li aria-level="2">高存储桶聚合<ul>
 <li aria-level="3">&nbsp;当我发现搜索在运行查询之前会根据搜索大小或存储桶维度临时分配堆的某个端口时，我感到非常傻，所以设置 10,000,000 确实让我的运营团队感到非常沮丧。</li>
 </ul>
 </li>
 <li aria-level="2">非优化的映射<ul>
 <li aria-level="3">第二个让我感到愚蠢的原因是，我认为进行分层报告会比扁平化的数据搜索更好（其实不然）。</li>
 </ul>
 </li>
 </ul>
 </li>
 <li aria-level="1">请求量/速度：通常是批量或异步查询</li>
</ul>
<h3>进行扩展的时间</h3>
如果这不是您第一次触发熔断器，或者您怀疑这会是一个持续存在的问题（例如，堆利用率持续保持在 85％，那么就是考虑扩展资源的时候了）；您需要仔细看一下作为长期堆指示器的 <a href="https://www.elastic.co/cn/blog/found-understanding-memory-pressure-indicator" target="_self">JVM 内存压力</a>情况。您可以在 Elasticsearch Service &gt;“Deployment”（部署）中<a href="https://www.elastic.co/guide/en/cloud/current/ec-memory-pressure.html" target="_self">进行查看</a>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt42b0179b9a3b7782/608323041cac355a10f6d157/blog-elasticsearch-memory-3.png" data-sys-asset-uid="blt42b0179b9a3b7782" alt="blog-elasticsearch-memory-3.png" />
或者，您也可以根据 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-nodes-stats.html" target="_self">_nodes/stats</a> 信息进行计算，<pre class="prettyprint">GET /cn/_nodes/stats?filter_path=nodes.*.jvm.mem.pools.old {"nodes": { "node_id": { "jvm": { "mem": { "pools": { "old": { "max_in_bytes": 532676608, "peak_max_in_bytes": 532676608, "peak_used_in_bytes": 104465408, "used_in_bytes": 104465408 }}}}}}} </pre>
其中<pre class="prettyprint">JVM Memory Pressure = used_in_bytes / max_in_bytes </pre>
这种情况的一个潜在症状是：elasticsearch.log 中的垃圾收集器 (gc) 事件发生的频率高且持续时间长<pre class="prettyprint">[timestamp_short_interval_from_last][INFO ][o.e.m.j.JvmGcMonitorService] [node_id] [gc][number] overhead, spent [21s] collecting in the last [40s] </pre>
如果您确认是这种情况，就需要考虑一下，要么扩展集群，要么减少对集群的需求。您需要调查/考虑：
<ul>
 <li aria-level="1">增加堆资源（堆/节点，节点数）</li>
 <li aria-level="1">减少分片（删除不必要的/旧的数据，<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/getting-started-index-lifecycle-management.html" target="_self">使用 ILM</a> 将数据放入<a href="https://www.elastic.co/cn/blog/hot-warm-architecture" target="_self">温/冷存储</a>中，以便<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-shrink.html" target="_self">缩小数据</a>，对于无需担心丢失问题的数据，关闭副本分片）</li>
</ul>
<h2>结论</h2>
哇！从我在 Elastic 支持中见到的情况来看，用户提交的工单中最常见问题包括：未分配的分片、不平衡的分片堆、熔断器、大量垃圾收集和分配错误。所有这些都是核心资源分配管理对话的症状。希望您现在也对相关理论和解决步骤有了一些了解。
不过，如果您现在仍无法解决问题，请随时与我们联系。我们将竭诚为您提供帮助！您可以通过 <a href="http://discuss.elastic.co/" target="_self">Elastic Discuss</a>、<a href="https://join.slack.com/t/elasticstack/shared_invite/zt-o4sdlhb7-OGXEcy4iry_CsxVyJLGYag" target="_self">Elastic 社区 Slack</a>、咨询、培训和支持团队与我们联系。
为我们能够作为非运维人员（以及热爱运维的人）自行管理 Elastic Stack 资源分配欢呼！

blog-banner-circuit-buildings.jpg

Getting started

blog-thumb-circuit-buildings.jpg

Managing and troubleshooting Elasticsearch memory

管理 Elasticsearch 内存并进行故障排查

几周前，<a href="https://twitter.com/elastic/status/1202400283931734016">我们宣布推出了我们的社区：Slack 工作区</a>。虽然我们已经拥有很棒的平台（如 <a href="http://discuss.elastic.co/">Discuss</a> 和 <a href="https://www.elastic.co/cn/elasticon/">Elastic{ON} Tour</a>）&nbsp;和<a href="http://community.elastic.co/">社区计划</a>来与用户互动，但这个新的 <a href="https://elasticstack.slack.com/">Slack 工作区</a>可为我们的社区提供一种富有趣味的互动方式，同时也是用户随时了解 Elastic Stack 中最新动态的全新渠道。
因此，无论您是在为自己开发中的 Beats 模块寻求帮助，还是在试着为一个新的 Kibana 插件宠物项目寻找测试人员，甚至只是想找一下您所在城市最近组织的聚会，Slack 工作区都是一个进行提问、获得答案以及进行社区协作的好地方。
在我们的 Slack 频道中，加入的用户来自世界各地，他们可以就 #elasticsearch、#app-search 和 #logs 等各种产品和解决方案进行互动。此外，我们还有 #usergroup-organizers 频道，您可以在其中与我们的全球社区组织者互动。
因此，如果您希望在 Elastic 社区中更加活跃，而且您的频道列表中也有空间，请使用以下链接加入 Slack 小组：<a href="https://ela.st/slack">https://ela.st/slack</a>。
如有任何疑问或建议，请在我们的 #slack-moderators 频道中联系我们。
 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta137a2f6e3b0cde7/5e2b6feee147ae4537d91fa6/elastic-slack-blog-welcome-body.jpg" data-sys-asset-uid="blta137a2f6e3b0cde7" alt="" style="display: block; margin: auto; width: 600px">

elastic-slack-blog-welcome-banner.png

elastic-slack-blog-welcome-thumb.png

Join our Elastic Stack workspace on Slack

加入我们在 Slack 上的 Elastic Stack 工作区

Kibana 提供了强大的功能，可用来搜索和可视化 Elasticsearch 中存储的数据。为了实现可视化，Kibana 会查找 Elasticsearch 映射中定义的字段，并将其作为选项呈现给构建图表的用户。但是，如果忘了在架构中将重要的值定义为独立的字段，会出现什么情况？或者，如果要合并两个字段并将其视为一个字段，该怎么办？这时 Kibana 脚本字段就派上用场了。 脚本字段最早出现于 Kibana 4 初期。起初问世时，脚本字段的唯一定义方法是依托 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-expression.html" target="_self">Lucene 表达式</a>，Elasticsearch&nbsp;专门利用这种脚本语言处理数值。因此，脚本字段只能在一部分用例中发挥作用。在 5.0 中，Elasticsearch 引入了 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-painless.html" target="_self">Painless</a>，这是一种安全、功能强大的脚本语言，可对各种数据类型进行操作。因此，Kibana 5.0 中的脚本字段功能要强大得多。在本博文的其余部分，我们将向您介绍如何为常见用例创建脚本字段。为此，我们将依托 <a href="https://www.elastic.co/guide/en/kibana/5.0/tutorial-load-dataset.html" target="_self">Kibana 入门教程</a>&nbsp;的数据集，并使用在 <a href="https://cloud.elastic.co/" target="_self">Elastic Cloud</a> 中运行的 Elasticsearch 和 Kibana 实例。您可以免费快速完成相应实例的部署。以下视频将向您介绍如何在 Elastic Cloud 中快速部署个人的 Elasticsearch 和 Kibana&nbsp;实例，并将示例&nbsp;数据集&nbsp;加载至该实例中。&nbsp; <div class="video embed-container" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/6gWkzXXhT69tUa7uRtvJ96.jpg" data-uuid="6gWkzXXhT69tUa7uRtvJ96" data-v="4" data-type="inline" width="677"/></div><h2>脚本字段如何运作</h2>Elasticsearch 允许您为每个请求指定脚本字段。Kibana 在这一方面进行了改进，您只需在“管理”部分中定义一次脚本字段，以后即可在 UI 的多个位置使用该字段。请注意，虽然 Kibana 将脚本字段与其他配置一起存储在 .kibana 索引中，但该配置是 Kibana 特有的，并且 Kibana 脚本字段不会向 Elasticsearch 的 API 用户公开。在 Kibana 中定义脚本字段时，您可以选择脚本语言，即从 Elasticsearch 节点安装的所有启用了动态脚本的语言中进行选择。默认情况下，5.0 提供“表达式”和 “Painless”两种脚本语言，2.x 仅提供“Painless”这一种脚本语言。您可以安装其他脚本语言并为其启用动态脚本，但不建议这样做，因为其他脚本语言无法充分<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-security.html" target="_self">沙盒化</a>&nbsp;并且已弃用。脚本字段一次对一个 Elasticsearch 文档进行操作，但可引用文档中的多个字段。因此，建议使用脚本字段合并或转换单个文档中的多个字段，但不能基于多个文档执行计算（例如时间序列计算）。Painless 和 Lucene 表达式均可用于 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/doc-values.html" target="_self">doc_values</a>&nbsp;中存储的字段。因此，对于字符串数据，您需要将字符串存储在数据类型关键字中。基于 Painless 的脚本字段也不能直接对 _source 进行操作。在“管理”部分中定义脚本字段后，用户可以像处理 Kibana 其余部分的其他字段那样，与脚本字段进行交互。脚本字段会自动显示在 Discover 字段列表中，并且可在 Visualize 中用于创建可视化。Kibana 只有在查询时才会将脚本字段定义传递给 Elasticsearch 进行计算。生成的数据集与从 Elasticsearch 返回的其他结果合并，并以表格或图表的形式呈现给用户。截至本文撰写时，使用脚本字段存在若干已知限制。您可以将 Kibana 可视化生成器中多数可用的 Elasticsearch 聚合应用于脚本字段，而最需要注意的例外情形是<a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html" target="_self">重要词聚合</a>。此外，您还可以在 Discover、Visualize 和仪表板中通过筛选栏对脚本字段进行筛选，但您需要认真编写适当的脚本以返回定义明确的值，如下所示。在使用脚本字段时，还须参阅下方的“最佳实践”部分，确保不会破坏环境的稳定性。下列视频演示了如何使用&nbsp;Kibana 创建脚本字段。<div class="video embed-container" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/SKHYsZcKZHq9u7GTNGWPaL.jpg" data-uuid="SKHYsZcKZHq9u7GTNGWPaL" data-v="4" data-type="inline" width="677"/></div><h2>脚本字段示例</h2>这一部分将介绍常见场景中 Kibana 的 Lucene 表达式和 Painless 脚本字段的几个示例。如上所述，这些示例是基于&nbsp;<a href="https://www.elastic.co/guide/en/kibana/5.0/tutorial-load-dataset.html" target="_self">Kibana 入门教程</a>的数据集开发的，并假设您使用的是 Elasticsearch 和 Kibana 5.1.1，因为早期版本存在若干与特定类型脚本字段筛选和排序相关的已知问题。在大多数情况下，脚本字段应该能够即点即用，因为 Elasticsearch 5.0 默认启用 Lucene 表达式和 Painless。唯一例外是，脚本需要基于正则表达式解析字段，为此，您需要在 elasticsearch.yml 中进行以下设置，为 Painless 启用正则表达式匹配：script.painless.regex.enabled: true<h3>对单个字段执行计算</h3><ul><li>示例：计算单位从字节变为千字节</li><li>语言：&nbsp;表达式</li><li>返回类型：&nbsp;数字</li></ul><pre class="prettyprint"> doc['bytes'].value / 1024 </pre>注意：请记住，Kibana 脚本字段一次只能处理一个文档，因此无法在脚本字段中进行时间序列计算。 <h3>产生数字的日期计算</h3><ul><li>示例：&nbsp;将日期解析为时刻</li><li>语言：表达式</li><li>返回类型：&nbsp;数字</li></ul>Lucene&nbsp;表达式提供了一整套即点即用的<a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-expression.html#_date_field_api" target="_self">日期处理函数</a>。但是，由于 Lucene 表达式仅返回数值，因此我们必须使用 Painless 返回基于字符串的星期几（如下所示）。<pre class="prettyprint"> doc['@timestamp'].date.hourOfDay </pre>注意：以上脚本将返回 1-24 <pre class="prettyprint">doc['@timestamp'].date.dayOfWeek </pre>注意：以上脚本将返回 1-7 <h3>合并两个字符串值</h3><ul><li>示例：&nbsp;合并源和目标或合并名字和姓氏</li><li>语言：&nbsp;Painless</li><li>返回类型：&nbsp;字符串</li></ul><pre class="prettyprint"> doc['geo.dest.keyword'].value + ':' + doc['geo.src.keyword'].value </pre> 注意：由于脚本字段需要对 doc_values 中的字段进行操作，因此我们使用上述字符串的 .keyword 版本。<h3>引入逻辑</h3><ul><li>示例：对于字节数超过 10000 的任何文档，返回标签“大量下载”</li><li>语言：Painless</li><li>返回类型：字符串</li></ul><pre class="prettyprint"> if (doc['bytes'].value > 10000) { return "big download"; } return ""; </pre>注意：引入逻辑时，请确保每个执行路径均有明确定义的返回语句和返回值（非 NULL）。例如，上述脚本字段用于 Kibana 筛选器时，如果最后没有返回语句或该语句返回 NULL，则会失败并出现编译错误。另请记住，Kibana 脚本字段不支持将逻辑分解为函数。&nbsp;<h3 dir="ltr">返回子字符串 </h3><ul><li>示例：返回 URL 中最后一个斜线之后的部分</li><li>语言：Painless</li><li>返回类型：字符串</li></ul><pre class="prettyprint"> def path = doc['url.keyword'].value; if (path != null) { int lastSlashIndex = path.lastIndexOf('/'); if (lastSlashIndex > 0) { return path.substring(lastSlashIndex+1); } } return ""; </pre>注意：尽可能避免使用正则表达式提取子字符串，因为 indexOf() 运算消耗的资源更少，也更不易出错。&nbsp;<h3 dir="ltr">使用正则表达式匹配字符串，并对匹配项执行操作 </h3><ul><li>示例：如果在字段“referer”中找到子字符串“error”，则返回字符串“error”，否则返回字符串“no error”。</li><li>语言：Painless</li><li>返回类型：字符串</li></ul><pre class="prettyprint">if (doc['referer.keyword'].value =~ /cn/error/) { return "error" } else { return "no error" } </pre>注意：简化的正则表达式语法可用于基于正则表达式匹配的条件语句。&nbsp;<h3 dir="ltr">匹配字符串并返回匹配项 </h3><ul><li>示例：返回域，即“host”字段中最后一个点之后的字符串。</li><li>语言：Painless</li><li>返回类型：字符串</li></ul><pre class="prettyprint">def m = /^.*\.([a-z]+)$/.matcher(doc['host.keyword'].value); if ( m.matches() ) { return m.group(1) } else { return "no match" } </pre>注意：通过 regex matcher() 函数定义对象，您可以提取并返回多组与该正则表达式匹配的字符。&nbsp;<h3 dir="ltr">匹配数字并返回匹配项 </h3><ul><li>示例：返回 IP 地址的前八位字节（存储为字符串）并将其视为数字。</li><li>语言：Painless</li><li>返回类型：数字</li></ul><pre class="prettyprint"> def m = /^([0-9]+)\..*$/.matcher(doc['clientip.keyword'].value); if ( m.matches() ) { return Integer.parseInt(m.group(1)) } else { return 0 } </pre>注意：必须在脚本中返回正确的数据类型。即使匹配了数字，正则表达式匹配也会返回字符串，因此应在返回时将其显式转换为整数。&nbsp;<h3 dir="ltr">产生字符串的日期计算 </h3><ul><li>示例：将日期解析为星期几，然后解析为字符串</li><li>语言：Painless</li><li>返回类型：字符串</li></ul><pre class="prettyprint">LocalDateTime.ofInstant(Instant.ofEpochMilli(doc['@timestamp'].value), ZoneId.of('Z')).getDayOfWeek().getDisplayName(TextStyle.FULL, Locale.getDefault()) </pre>注意：Painless 支持 Java 的所有原生类型，因此提供对这些类型的原生函数的访问权限，例如 <a href="https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#getDayOfWeek--" target="_self">LocalDateTime()</a>，可用于执行更高级的日期计算。<h2 dir="ltr">最佳实践 </h2>如您所见，Painless 脚本语言提供了强大的功能，可以通过 Kibana 脚本字段从 Elasticsearch 中存储的任意字段提取有用信息。然而，功能越强大，责任越重大。&nbsp;我们在下方概述了一些有关使用 Kibana 脚本字段的最佳实践。<ul><li>始终使用开发环境试验脚本字段。由于脚本字段一经保存在 Kibana“管理”部分即会变成活动状态（例如，出现在所有用户的索引模式的“Discover”屏幕），因此您不应直接在生产环境中开发脚本字段。我们建议您首先在开发环境中试用语法，评估脚本字段对暂存中的实际数据集和数据量的影响，然后才将其运用到生产环境中。&nbsp;</li><li>若您确信脚本字段可为用户提供价值，则可以考虑修改采集方式，以便在索引时针对新数据提取该字段。这将节省 Elasticsearch 在查询时的处理工作量，为 Kibana 用户加快响应时间。此外，您还可以使用 Elasticsearch 中的 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/docs-reindex.html" target="_self">_reindex</a> API 重新索引现有数据。</li></ul>

Using Painless in Kibana scripted fields

在 Kibana 脚本字段中使用 Painless

<a href="https://www.lenovo.com.cn">联想</a>是一家世界 500 强公司，年营收超过 450 亿美元。联想在运营领域面临着一个令人头疼的工程难题。一个规模很小的 BT/IT 团队负责维护这家硬件生产商用于日志分析的 MySQL 数据库。规模扩大至每天处理两亿条日志后，数据库性能开始下降并妨碍联想制定新的业务举措，例如联想亟需一款店内研究程序来监测客户在零售店内如何使用联想硬件设备。&nbsp;&nbsp;
操留学是联想 PCSD&nbsp;BT/IT 部门的一名团队负责人。他发现 Elasticsearch 是一套理想的解决方案，能够快速解决他们在扩展过程中遇到的运营问题。 
<blockquote>“主要是能够减少工作量。之前使用诸如 MySQL 等传统的关系型数据库时，我们需要投入大量时间进行优化和调整，才能实现我们现在使用 Elasticsearch 达到的效果和性能。”&nbsp; ------- 操留学，PCSD BT/IT 部 | 联想
</blockquote><h2>通过日志分析获得商业智能</h2>联想改用 Elasticsearch 后，操留学所带领的团队能够有更多时间专注于可对业务决策产生影响的项目。&nbsp;
联想在中国区共有 5,000 家零售店和合作店，这些店铺展示联想出品的各种样机，例如电脑、手机、平板电脑等等。借助 Elasticsearch，操留学的团队得以腾出时间研究零售店的顾客如何与店内的硬件设备进行实际交互，进而帮助推动销量。这些店铺每天共产生 4 亿多条日志，如果没有 Elasticsearch，这个重大的指标类项目绝对不可能完成。&nbsp;
联想希望帮助决策者和店铺经理回答下列问题：
<ul>
	<li>顾客进入店内时，他们对哪些产品和功能感兴趣？为什么感兴趣？</li>
	<li>在店铺内，如何通过调整产品摆放位置来提高顾客兴趣？</li>
	<li>人们对零售店中的哪些商品更感兴趣？</li>
	<li>不同地区的消费者对联想产品的兴趣偏好是否有所不同？</li>
</ul><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte97133423215054f/5c98d4ec98d5092a05465ee1/lenovo-phone.jpg" data-sys-asset-uid="blte97133423215054f" alt="lenovo-phone.jpg">
通过数据便能回答这些和其他问题，而操留学的团队则负责将这些数据采集到联想的 Elasticsearch 集群内。这一新的指标工具可以提供实时洞见，让联想知道零售店的消费者会花多长时间体验联想最新产品，例如，与笔记本电脑触摸屏之间的交互，或者在键盘上输入内容。 
更重要的是，店铺能够按照一定策略在店铺内摆放硬件和其他在售产品，这样，联想便能实时跟踪这些产品的受欢迎程度，并确定产品在店内的最佳摆放位置。
由于拥有了这些指标，零售店和销售团队能够进行分析并根据需要调整库存。
总而言之一句话，Elasticsearch 通过提供数据帮助多个职能部门作出战略性业务决策，而之前使用 MySQL 时，由于 MySQL 负载过大，根本不能提供这些数据。&nbsp;
<h2>全新 Elastic 用例：产品演示指标</h2>公司成功推出硬件零售监测程序之后，联想的工程师开展了一个新的基于 Elasticsearch 的项目，来确定产品销量与从产品展示活动中所收集实时数据之间的关系。正是由于有了 Elasticsearch，联想才能通过这种新方法获得有关大众消费者兴趣和行为的新鲜洞见。&nbsp;
“这一应用程序可以转化为有关消费者购买习惯的商业智能，这样联想便有机会领先市场推出新一代的优秀产品。”操留学说道。&nbsp;

Lenovo-FullBleed.jpg

Lenovopicture.jpg

Lenovo: A Unified View of Sales Across China through Log Analysis

联想：通过日志分析统一查看中国区的整体销售情况

<a href="/cn/blog/security-for-elasticsearch-is-now-free" target="_self">从 Elastic Stack 6.8 和 7.1 开始</a>，我们在默认分发包中免费提供多项安全功能，例如 TLS 加密通信、基于角色的访问控制 (RBAC)，等等。在此篇博文中，我们将会讲解如何启用这些功能来确保您的 Elasticsearch 集群的安全。 为了给您提供一个实际示例来演示如何确保 Elastic Stack 实施项目的安全，我们将会在本地机器上创建一个两节点 Elasticsearch 集群并进行安全设置。要实现这一点，我们首先需要在两个节点之间配置 TLS 通信。然后，我们会为 Kibana 实例（用于分析并可视化集群中的数据）启用安全功能。再然后，我们会在 Kibana 中配置基于角色的访问控制，从而确保用户只能看到他们获授权能够看到的内容。 尽管关于安全功能的运行过程还有很多内容，但现在我们仅会介绍入门所需知识。阅读完本篇博文后，我们推荐您查看<a href="/guide/en/elasticsearch/reference/7.1/configuring-security.html" target="_self"> Elastic Stack 安全功能的相关文档</a>，其中包含能帮助到您的<a href="/guide/en/elastic-stack-overview/7.1/security-getting-started.html" target="_self">实用示例</a>。快速提示：我们将会在本地集群完成所有这些操作，这是因为尽管这些功能从 6.8 和 7.1 开始默认提供，但这些功能在我们的 <a href="/cn/cloud/elasticsearch-service/subscriptions" target="_self">Elasticsearch Service</a> 中一直都是标配。 <h2>安装 Elasticsearch 和 Kibana</h2>在这个示例中，我将会在运行 Linux 的笔记本电脑上进行安装。请根据您的具体环境相应调整下列步骤。 <h3>步骤 1：下载 Elasticsearch 和 Kibana</h3>您需要做的第一件事是<a href="/cn/downloads?elektra=products&storm=main" target="_self">下载</a> Elasticsearch 和 Kibana 6.8+ 或 7.1+ 版本的默认分发包。由于我们已将安全功能添加到 7.1 或 6.8 的默认分发包中，所以如果使用的是旧版本，您需要进行升级。 <h3>第 2 步：提取 Elasticsearch 和 Kibana</h3>在这个例子中，我已下载 elasticsearch-7.1.0-linux-x86_64.tar.gz 和 kibana-7.1.0-linux-x86_64.tar.gz。下载完毕之后，您需要将其中的内容提取出来。 <h3>第 3 步：创建两个 Elasticsearch 节点</h3> 如要创建一个两节点集群，您需要创建两个 Elasticsearch 目录副本，其中一个名为 master（主节点），另一个名为 node（节点）。完成这一步之后，您将会看到下列文件和文件夹： <pre class="prettyprint">elasticsearch-7.1.0 elasticsearch-7.1.0-node elasticsearch-7.1.0-linux-x86_64.tar.gz kibana-7.1.0-linux-x86_64 elasticsearch-7.1.0-master kibana-7.1.0-linux-x86_64.tar.gz </pre><h2>配置 TLS 和身份验证</h2>我们要做的第一件事是生成证书，通过这些证书便能允许节点安全地通信。您可以使用企业 CA 来完成这一步骤，但是在此演示中，我们将会使用一个名为 elasticsearch-certutil 的命令，通过这一命令，您无需担心证书通常带来的任何困扰，便能完成这一步。 <h3>步骤 1：在 Elasticsearch 主节点上配置 TLS</h3>您可以使用 cd 命令更改至 master 目录，然后运行下列命令： <pre class="prettyprint">bin/elasticsearch-certutil cert -out config/elastic-certificates.p12 -pass "" </pre>接下来，使用您最常用的文本编辑器打开文件 config/elasticsearch.yaml。将下列代码行粘贴到文件末尾。 <pre class="prettyprint">xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack.security.transport.ssl.verification_mode: certificate xpack.security.transport.ssl.keystore.path: elastic-certificates.p12 xpack.security.transport.ssl.truststore.path: elastic-certificates.p12 </pre>保存文件，现在我们便可以启动主节点了。运行命令 bin/elasticsearch。这一可执行文件必须保持运行，现在可以将此终端放在一边。 <h3>第 2 步：Elasticsearch 集群密码</h3>一旦主节点开始运行，便可以为集群设置密码了。在新终端中，我们必须通过 cd 命令更改至主节点目录。然后我们运行命令 bin/elasticsearch-setup-passwords auto。这将会为不同的内部堆栈用户生成随机密码。或者，您也可以跳过 auto 参数，改为通过 interactive 参数手动定义密码。请记录这些密码，我们很快就会再次用到这些密码。 <h3>第 3 步：在 Elasticsearch 节点上配置 TLS</h3>现在，打开一个新终端，并使用 cd 命令更改至我们的节点目录。在我的例子中，其被命名为 elasticsearch-7.1.0-node。 我们最简单的做法是将主节点的配置目录完全复制到节点的配置目录中。 <pre class="prettyprint">cp ../elasticsearch-7.1.0-master/config/* config/ </pre>您还应该将 node.master: false 配置选项添加到 config/elasticsearch.yml 文件中。我在这里不会详细解释，但是您可以在我们的<a href="/guide/en/elasticsearch/reference/7.1/modules-discovery-bootstrap-cluster.html" target="_self">集群文档</a>中找到更多详细信息。除了简单地复制整个配置文件之外，还有一个备选方法，那就是只复制证书文件，然后将 xpack.security.* 键设置为与主节点一模一样。 然后我们通过运行 bin/elasticsearch 来启动节点。我们将看到其加入集群。而且，如果看一下主节点的终端窗口，我们会看到有一条消息显示已有一个节点加入集群。现在，我们的两节点集群便开始运行了。 <h3>第 4 步：在 Kibana 中实现安全性</h3>我们要做的最后一件事是配置 Kibana。再次打开另一个终端窗口（我保证，这是最后一次了）。我们需要为 Kibana 用户添加密码。我们可以从之前 setup-passwords 命令的输出内容中找到密码。 我们使用 cd 命令更改至 Kibana 目录，然后使用您的文本编辑器打开 config/kibana.yml 文件。找到类似下面的代码行 <pre class="prettyprint">#elasticsearch.username: "user" #elasticsearch.password: "pass" </pre>对 username 和 password 字段取消注释，方法是删除代码行起始部分的 # 符号。将 "user" 更改为 "kibana"，然后将 "pass" 更改为 setup-passwords 命令告诉我们的任何 Kibana 密码。保存文件，然后我们便可通过运行 bin/kibana 启动 Kibana 了。 <h2>在 Kibana 中配置基于角色的访问控制 (RBAC)</h2>一旦 Kibana 开始运行，我们便可以切换至网页浏览器并打开 <a href="http://localhost:5601/login?next=%2F#?_g=()" target="_self">http://localhost:5601</a>。它将再次要求提供登录信息，我们将会使用 elastic 超级用户进行登录，密码来自 setup-passwords 命令。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt33ef6ef8666f75bc/5ce2480b32fd88a3767ede65/elasticsearch-security-blog-1.jpg" data-sys-asset-uid="blt33ef6ef8666f75bc" alt="登录 Kibana"/>如果是像这个例子中的全新安装情况，Kibana 将询问您是否希望加载一些样本数据。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6617bf668ec635cd/5ce2483c7182ba9776722fee/elasticsearch-security-blog-2.jpg" data-sys-asset-uid="blt6617bf668ec635cd" alt="向 Kibana 中加载样本数据"/>在本示例中，我们将会加载航班和网络日志这两个样本数据。加载完毕后，单击表示配置的齿轮图标。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltae0b05ad48832121/5ce2486e2f06657f7b6c9907/elasticsearch-security-blog-3.jpg" data-sys-asset-uid="bltae0b05ad48832121" alt="导航至 Kibana 中的管理"/>现在我们就创建角色。找到并单击 roles（角色）选项。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt90c2f3cfca9d44fc/5ce2493908d3fd9e7671c281/elasticsearch-security-blog-4.jpg" data-sys-asset-uid="blt90c2f3cfca9d44fc" alt="Kibana 中的 Roles（角色）"/>单击 Create role（创建角色）。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3746b50792f5e2c0/5ce2497308d3fd9e7671c287/elasticsearch-security-blog-5.jpg" data-sys-asset-uid="blt3746b50792f5e2c0" alt="创建一个新角色"/>我们将第一个角色命名为 read_logs。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6fcd624d7201821d/5ce24a7632fd88a3767ede75/elasticsearch-security-blog-6.jpg" data-sys-asset-uid="blt6fcd624d7201821d" alt="创建 read_logs 角色"/>向下滚动至 Index Privileges（索引权限）字段并选择日志索引。然后我们将其指定为 read 权限。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc3c087f105d52fa6/5ce24a87ccfda8847b20bb43/elasticsearch-security-blog-7.jpg" data-sys-asset-uid="bltc3c087f105d52fa6" alt="配置角色权限"/>将安全功能设置完毕之后，您可能想要仔细研究 Spaces 功能，但在这篇博文中，我们将会跳过此部分。如需了解有关 Spaces（在 Kibana 中整理数据并确保数据安全的一项出色功能）的更多信息，请查看我们的 <a href="/guide/en/kibana/7.1/xpack-spaces.html" target="_self">Kibana Spaces 文档</a>或者这篇<a href="/cn/blog/introducing-kibana-spaces-for-organization-and-security" target="_self"> Kibana Spaces 介绍博文</a>。 现在我们创建另一个名为 read_flight 的角色。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf26a34f5ff885981/5ce24abc1df9c928761cd92d/elasticsearch-security-blog-8.jpg" data-sys-asset-uid="bltf26a34f5ff885981" alt="创建 read_flight 角色"/>我们为航班索引分配 read 权限。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt3e1d9d93aba1294c/5ce24acd2d8f163476ebd44b/elasticsearch-security-blog-9.jpg" data-sys-asset-uid="blt3e1d9d93aba1294c" alt="配置角色"/>现在，我们将要创建两名用户并为他们分配这两个角色。选择左侧的 Users（用户）链接，然后单击Create new user（创建新用户）按钮。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc557d504a8ac1f95/5ce24aee7182ba9776722ff9/elasticsearch-security-blog-10.jpg" data-sys-asset-uid="bltc557d504a8ac1f95" alt="创建新用户"/>我们将这名用户命名为 flight_user，并设置密码。无需设置全名和电子邮件地址。我们需要为这名用户分配read_flight 角色，而且我们还需要为其分配 kibana_user 角色（因为该用户将会查看 Kibana 中的数据）。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7adcce531abcc45a/5ce24b00932da9737b2628c6/elasticsearch-security-blog-11.jpg" data-sys-asset-uid="blt7adcce531abcc45a" alt="创建航班用户"/>单击创建，然后我们为 log_user 再完成一遍上述操作。这次我们需要添加 read_logs 和 kibana_user 角色。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt805d2eb40672403d/5ce24b13ccfda8847b20bb4b/elasticsearch-security-blog-12.jpg" data-sys-asset-uid="blt805d2eb40672403d" alt="创建日志用户"/>大功告成，两名新用户已经设置完毕。现在我们可以将 elastic 用户退出登录。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb07056dabca17b82/5ce24ba52d8f163476ebd451/elasticsearch-security-blog-13.jpg" data-sys-asset-uid="bltb07056dabca17b82" alt="将 elastic 用户退出登录"/>然后，我们可使用 log_user 登录。然后单击 dashboards（仪表板）图标，我们可以看到现在有两个仪表板，一个为航班，另一个为网络日志。 	<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltfb2217281f933c85/5ce24bc53d021e2d76457546/elasticsearch-security-blog-14.jpg" data-sys-asset-uid="bltfb2217281f933c85" alt="查看您的仪表板"/>如果单击 Logs（日志）仪表板，您将会看到演示日志数据。如果返回并尝试查看航班仪表板，虽然我们可以看到仪表板，却不会看到任何数据。在这里便可以使用 Kibana Spaces 以确保安全，因为这一功能可确保仅允许特定用户查看特定仪表板。 现在您可以将 log_user 退出登录，然后使用 flight_user 重新登录。 如果打开日志仪表板，这次我们不会看到任何数据。我们甚至会看到错误消息，因为 Kibana 无法访问日志索引。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6f857fe2c548af9e/5ce24be67182ba9776722fff/elasticsearch-security-blog-15.jpg" data-sys-asset-uid="blt6f857fe2c548af9e" alt="通过 RBAC 限制数据访问"/>现在如果查看航班仪表板，我们看到这次可以访问航班数据了。 <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt89b48cc8a9e81e31/5ce24bfb3d021e2d7645754e/elasticsearch-security-blog-16.jpg" data-sys-asset-uid="blt89b48cc8a9e81e31" alt="通过 RBAC 提供的数据访问权限"/>恭喜您！现在我们已将这个两节点集群配置完毕，还配置了两名对索引数据拥有受限访问权限的用户。 <h2>总结</h2>Elastic Stack 中的安全功能用途十分广泛，还有很多我们并未在本篇博文中讲到的内容。本篇博文的目的是引导您入门。将来我们还会发布大量内容，讲解其中的多项安全功能，以及使用这些功能的方法。同时，我们还有很多关于 Elastic Stack 运行原理和其他功能的文档和博文。 <ul><li><a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/configuring-stack-security.html" target="_self">Fundamentals of Securing Elasticsearch（Elasticsearch 安全保护基础）培训</a></li><li><a href="/guide/en/elasticsearch/reference/current/configuring-security.html" target="_self">Elasticsearch 安全功能文档</a></li><li><a href="/cn/blog/elasticsearch-security-configure-tls-ssl-pki-authentication" target="_self">TLS 配置博文</a></li><li><a href="/cn/blog/introducing-kibana-spaces-for-organization-and-security" target="_self">Kibana Spaces 博文</a></li></ul>您还可以<a href="https://discuss.elastic.co/" target="_self">在我们的公共论坛上寻求帮助</a>。 祝您搜索愉快！

Getting started with Elasticsearch security

Elasticsearch 安全功能入门

Elasticsearch 是一个功能十分丰富的平台，支持各种用例，能够在数据整理和复制策略方面提供很大的灵活性。然而，这一灵活性有时也会带来困扰，让您在前期难以确定如何最好地将数据整理为索引和分片，如果您刚上手使用 Elastic Stack，这一点可能更明显。如果未能做出最佳选择，尽管这在开始的时候可能不会造成问题，但随着数据量越来越大，便有可能会引发性能问题。集群中的数据越多，要纠正这一问题就越难，这是因为有时必须对大量数据进行重新索引。据我们了解，当用户遇到性能问题时，原因通常都可回溯至数据的索引方式以及集群中的分片数量。对于涉及多租户和/或用到时序型索引的用例，这一点尤为突出。与用户讨论这一问题时，无论是在活动或聚会中面对面讨论，还是在<a href="https://discuss.elastic.co" target="_self">论坛</a>上讨论，我们遇到的一些最常见问题就是“我应该设置多少个分片？”以及“我应该设置多大的分片？”这篇博文旨在帮您集中解答这些问题，并为涉及时序型索引（例如日志或安全分析）的用例提供实用指南。<h2 dir="ltr">什么是分片？</h2>开始之前，我们需要明确一下基本知识以及在后面部分会用到的术语。Elasticsearch 中的数据会整理为<a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/_add_an_index.html" target="_self">索引</a>。每个索引又由一个或多个分片组成。每个分片都是一个 Lucene 索引实例，您可以将其视作一个独立的搜索引擎，它能够对 Elasticsearch 集群中的数据子集进行索引并处理相关查询。数据写到分片上之后，会定期发布到磁盘上不可更改的新 Lucene 段中，此时，数据便可用于查询了。这称为刷新。相关原理的详细介绍，请参见 <a href="https://www.elastic.co/guide/en/elasticsearch/guide/current/inside-a-shard.html" target="_self">Elasticsearch：权威指南</a>。随着段数越来越多，这些段会定期合并为更大的段。这一过程称为<a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/index-modules-merge.html" target="_self">合并</a>。由于所有段都是不可更改的，这意味着在索引期间所用磁盘空间通常会上下浮动，这是因为只有合并后的新段创建完毕之后，它们所替换的那些段才能删掉。合并是一项极其耗费资源的任务，尤其耗费磁盘 I/O。分片是 Elasticsearch 在集群内分发数据的单位。Elasticsearch 在对数据进行再平衡（例如发生故障后）时移动分片的速度取决于分片的大小和数量，以及网络和磁盘性能。<table><tbody><tr><td>提示： 避免分片过大，因为这样会对集群从故障中恢复造成不利影响。尽管并没有关于分片大小的固定限值，但是人们通常将 50GB 作为分片上限，而且这一限值在各种用例中都已得到验证。</td></tr></tbody></table><h2 dir="ltr">按照保留期限进行索引</h2>由于段是不可更改的，所以<a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/update-doc.html" target="_self">更新文档</a>时必须要求 Elasticsearch 首先找到既有文档，然后将其标为已删除，并添加更新后版本。<a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/delete-doc.html" target="_self">删除文档</a>时同样也要求先找到文档，再将其标为已删除。有鉴于此，已删除文档<a href="/cn/blog/lucenes-handling-of-deleted-documents" target="_self">仍将继续占用磁盘空间和系统资源，直至将它们合并</a>，而合并过程也会消耗大量系统资源。通过 Elasticsearch，用户可以十分高效地从文件系统中直接删除整个索引，而无需单独删除所有记录。这是迄今为止从 Elasticsearch 中删除数据的最高效方法。<hr/>提示：但凡可能，尽量使用<a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/time-based.html" target="_self">时序型索引</a>来管理数据保留期。根据保留期限对数据分组，将它们存储到索引中。通过时序型索引，用户还能随着时间推移轻松调整主分片和副本分片的数量，这是因为用户可针对要生成的下个索引进行这方面的更改。这样便能简化对不断变化的数据量和数据要求的适应过程。<hr/><h2 dir="ltr">索引分片不是免费的吗？</h2>对于每个 Elasticsearch 索引，映射和状态的相关信息都存储在集群状态中。这些信息存储在内存中，以便快速访问。因此，如果集群中的索引和分片数量过多，这会导致集群状态过大，如果映射较大的话，尤为如此。这会导致更新变慢，因为所有更新都需要通过单线程完成，从而在将变更分发到整个集群之前确保一致性。<hr/>提示：为了减少索引数量并避免造成过大且无序的映射，可以考虑在同一索引中存储类似结构的数据，而不要基于数据来源将数据分到不同的索引中。很重要的一点是在索引/分片的数量和每个单独索引的映射大小之间实现良好平衡。由于<a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/finite-scale.html#finite-scale" target="_blank">集群状态</a>会加载到每个节点（包括主节点）上的堆内存中，而且堆内存大小与索引数量以及单个索引和分片中的字段数成正比关系，所以还需要同时监测主节点上的堆内存使用量并确保其大小适宜，这一点很重要。<hr/>每个分片都有一部分数据需要保存在内存中，这部分数据也会占用堆内存空间。这包括存储分片级别以及段级别信息的数据结构，因为只有这样才能确定数据在磁盘上的存储位置。这些数据结构的大小并不固定，不同用例之间会有很大的差别。段相关开销有一个重要特征，那就是其并不与段的大小呈严格正比关系。这意味着，与较小的段相比，对于较大的段而言，其单位数据量所需的开销要小一些。二者之间的差异可能会十分巨大。为了能够在单个节点上存储尽可能多的数据，下面两点至关重要：管理堆内存使用量；尽可能减少开销。节点的堆内存空间越多，其能处理的数据和分片就越多。从集群角度来说，索引和分片都不是免费的，因为每个索引和分片都会产生一定的资源开销。<hr/>提示：分片过小会导致段过小，进而致使开销增加。您要尽量将分片的平均大小控制在至少几 GB 到几十 GB 之间。对时序型数据用例而言，分片大小通常介于 20GB 至 40GB 之间。提示：由于单个分片的开销取决于段数量和段大小，所以通过 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/indices-forcemerge.html" target="_self">forcemerge</a> 操作强制将较小的段合并为较大的段能够减少开销并改善查询性能。理想状况下，应当在索引内再无数据写入时完成此操作。请注意：这是一个极其耗费资源的操作，所以应该在非高峰时段进行。提示：每个节点上可以存储的分片数量与可用的堆内存大小成正比关系，但是 Elasticsearch 并未强制规定固定限值。这里有一个很好的经验法则：确保对于节点上已配置的每个 GB，将分片数量保持在 20 以下。如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片，但是在此限值范围内，您设置的分片数量越少，效果就越好。一般而言，这可以帮助集群保持良好的运行状态。（编者按：从 8.3 版开始，我们大幅减小了每个分片的堆使用量，因此对本博文中的经验法则也进行了相应更新。请按照以下提示了解 8.3+ 版本的 Elasticsearch。）新提示：为数据节点上每个索引的每个字段留出 1kB 的堆空间，还要为开销留出额外的空间 每个映射字段的具体资源使用情况取决于其类型，但经验法则是，每个数据节点持有的每个索引的每个映射字段允许大约 1kB 的堆开销。您还必须为 Elasticsearch 的基线使用以及工作负载（例如索引、搜索和聚合）留出足够的堆空间。额外留出 0.5GB 的堆足以满足许多合理的工作负载，如果您的工作负载非常轻，可能需要更少的空间，而工作负载繁重的话可能需要更多空间。例如，如果一个数据节点持有来自 1000 个索引的分片，每个索引包含 4000 个映射字段，那么您应该为字段留出大约 1000 × 4000 × 1kB = 4GB 的堆空间，并为其分配另外 0.5GB 的堆空间用于工作负载和其他开销，因此该节点需要至少 4.5GB 的堆大小。<hr/><h2 dir="ltr">分片大小对性能有何影响？</h2>在 Elasticsearch 中，每个查询都是在单个分片上以单线程方式执行的。然而，可以同时对多个分片进行处理，正如可以针对同一分片进行多次查询和聚合一样。这意味着，最低查询延时（假设没有缓存）将取决于数据、查询类型，以及分片大小。尽管查询很多个小分片会加快单个分片的处理速度，但是由于有很多任务需要进入队列并按顺序加以处理，所以与查询较少的大分片相比，这种方法并不一定会加快查询速度。如果有多个并发查询，拥有很多小分片还会降低查询吞吐量。<hr/>提示：从查询性能的角度来看，确定最大分片大小的最佳方法是<a href="/cn/elasticon/conf/2016/sf/quantitative-cluster-sizing" target="_self">使用具有实际意义的数据和查询进行基准测试</a>。进行基准测试时，务必确保所使用的查询和索引负载能够代表节点在生产环境中需要处理的内容，因为只针对单一查询进行优化可能会得出错误结果。<hr/><h2 dir="ltr">我应该如何管理分片大小呢？</h2>使用时序型索引时，按照传统方法，每个索引都关联至固定时间段。按天索引是一种十分常见的方法，通常用来存储保留期较短的数据或者用来存储较大的每日数据量。此类索引允许用户在很细的粒度层面管理保留期，也方便用户根据每天不断变化的数据量轻松进行调整。对于拥有较长保留期的数据，尤其如果每日数据量并不能保证用完每日索引，通常可按周索引或按月索引，以便提高分片大小。长期来看，这有助于减少存储在集群中的索引和分片数量。<hr/>提示：如果使用时序型索引来存储固定期限内的数据，用户应根据保留期和预计数据量对每个索引覆盖的期限进行调整，从而确保达到目标分片大小。<hr/>如果能够很好地预估数据量并且数据量变化缓慢，则固定期限式时序型索引的效果很好。如果索引速度变化很快，则很难保持统一的目标分片大小。为了能够更好地应对此类情形，可以采用所推出的 <a href="/cn/blog/managing-time-based-indices-efficiently" target="_self">Rollover（汇总）和 Shrink（压缩）API</a>。这些 API 能够让用户更加灵活地管理索引和分片，尤其是时序型索引。通过 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/indices-rollover-index.html" target="_self">rollover index API</a>（汇总索引 API），用户能够指定每个索引应该存储的文档数量，以及/或者最长可在多长时间内向索引内写入文档。一旦超出这些条件，Elasticsearch 可触发新索引创建操作以继续写入数据，而不会造成中断。通过这种方法，每个索引不再覆盖特定的时间段，数据可在索引达到具体大小后转到新索引，这样用户可以更加轻松地确保所有索引都达到均等的分片大小。由于使用此 API 时事件时间戳与事件所在的索引之间并无明显联系，所以如需更新数据，需要先搜索才能完成每次更新，而这会大大降低更新效率。<hr/>提示：如果您拥有不可更改的时序型数据，并且数据量在一段期间内会巨幅变化，可以考虑使用 rollover index API（汇总索引 API）通过动态调整每个索引所覆盖的时间段来实现最佳的目标分片大小。这为用户提供了很大的灵活性，并且在数据量难以预测时，还有助于避免分片过大或过小。 <hr/>通过 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.5/indices-shrink-index.html" target="_self">shrink index API</a>（压缩索引 API），您能够将现有索引压缩到拥有较少主分片的新索引中。如果在索引时希望不同节点上的分片覆盖均等的时间段，但是这会导致分片过小，则您可以考虑在索引内再无数据写入时使用此 API 来降低主分片数量。这会形成较大的分片，能够更好地满足长期存储数据的需求。 <hr/>提示：如果您希望每个索引既要对应至特定时间段，同时还想将索引过程分散到大量节点上，可以考虑使用 Shrink（压缩）API 来在索引内再无数据写入时减少主分片数量。如果开始时配置了过多的分片，您也可以使用此 API 来减少分片数量。 <hr/><h2 dir="ltr">结论</h2>本篇博文针对在 Elasticsearch 中管理数据的最佳方法提供了一些建议和使用指南。如想深入了解，可以参阅“Elasticsearch：权威指南”中的<a href="https://www.elastic.co/guide/en/elasticsearch/guide/2.x/scale.html" target="_self">扩容设计</a>一节，尽管此部分内容已经发布一段时间了，但却仍然值得一读。虽讲了这么多，关于如何最好地在索引和分片之间分配数据，很多决策仍取决于用例的具体情况，有时的确很难确定如何最好地应用现有建议。如需更多深入的个人建议，您可通过我们的<a href="/cn/subscriptions" target="_self">商用订阅服务</a>与我们进行交流，我们的支持和咨询团队能够帮助您加快项目进度。如果想公开讨论自己的用例，您也可以向<a href="/cn/community" target="_self">我们的社区</a>和公共<a href="https://discuss.elastic.co" target="_self">论坛</a>寻求帮助。 这篇博文最初于 2017 年 9 月 18 日发布。于 2022 年 7 月 6 日更新。

elasticsearch-sharding-fullbleed.jpg

elasticsearch-sharding-thumbnail.jpg

How many shards should I have in my Elasticsearch cluster?

我在 Elasticsearch 集群内应该设置多少个分片？

fullbleed2.jpg

canvas_metric_thumb.jpg

Canvas: Metric and Markdown Elements

Canvas：Metric 和 Markdown 元素

体验 Elastic Security 7.9，其具备内置的反恶意软件和数据收集、预建的云保护、增强的分析人员工作流、扩展的数据收集和分析。

Elasticsearch Platform

ELK Stack

Elastic Cloud

可观测性

安全性

搜索

按行业

按解决方案

客户聚焦

开发人员

保持联系

学习

帮助

Elastic 客户成功团队

精选信息

Elastic 客户成功手册

如何升级

资源

立即在 Elastic Cloud 上试用

关注我们

关于我们

加入我们

合作伙伴

信任和安全性

投资者关系

卓越奖

关于我们

加入我们

合作伙伴

信任和安全性

投资者关系

卓越奖