elastic-apm-distributed-tracing-large.jpg

Elastic Cloud

Real user monitoring

Observability

elastic-apm-distributed-tracing-small.png

A Sip of Elastic RUM (Real User Monitoring)

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

我们非常高兴在 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-banner-generic-elastic.png

blog-thumb-generic-elastic.png

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

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

<html><head></head><body>&#x8FD9;&#x7BC7;&#x6587;&#x7AE0;&#x603B;&#x7ED3;&#x4E86;&#x5728; <a href="/cn/elasticon/conf/2018/sf">Elastic {ON} 2018</a> &#x4E0A;&#x7684;&#x7528;&#x6237;&#x53D1;&#x8A00;&#x3002;&#x60F3;&#x4E86;&#x89E3;&#x5230;&#x66F4;&#x591A;&#x8FD9;&#x6837;&#x7684;&#x8BB2;&#x5EA7;&#x5417;&#xFF1F;&#x67E5;&#x770B;&#x4F1A;&#x8BAE;&#x6863;&#x6848;&#x6216;&#x4E86;&#x89E3; <a href="/cn/elasticon">Elastic {ON} Tour</a> &#x4F55;&#x65F6;&#x4F1A;&#x5230;&#x60A8;&#x9644;&#x8FD1;&#x7684;&#x57CE;&#x5E02;&#x4E3E;&#x529E;&#x3002;

<a href="https://ottomotors.com/">OTTO Motors</a> &#x662F; <a href="https://www.clearpathrobotics.com/">Clearpath Robotics</a> &#x65D7;&#x4E0B;&#x7684;&#x4E00;&#x5BB6;&#x516C;&#x53F8;&#xFF0C;&#x4E3B;&#x8981;&#x8BBE;&#x8BA1;&#x3001;&#x5236;&#x9020;&#x548C;&#x64CD;&#x4F5C;&#x81EA;&#x52A8;&#x9A7E;&#x9A76;&#x5DE5;&#x4E1A;&#x8F66;&#x8F86;&#x3002;&#x4ED6;&#x4EEC;&#x7684;&#x76EE;&#x6807;&#x662F;&#x4F7F;&#x7528;&#x673A;&#x5668;&#x4EBA;&#x6280;&#x672F;&#x6765;&#x6DD8;&#x6C70;&#x4EBA;&#x4E3A;&#x64CD;&#x4F5C;&#x3002;&#x4ED6;&#x4EEC;&#x7684;&#x79FB;&#x52A8;&#x673A;&#x5668;&#x4EBA;&#x961F;&#x5728; 40 &#x591A;&#x4E2A;&#x56FD;&#x5BB6;/&#x5730;&#x533A;&#x8FD0;&#x884C;&#xFF0C;&#x53EF;&#x5E2E;&#x52A9;&#x516C;&#x53F8;&#x5B9E;&#x73B0;&#x4F5C;&#x4E1A;&#x81EA;&#x52A8;&#x5316;&#xFF0C;&#x5305;&#x62EC;&#x4E00;&#x4E9B;&#x5BF9;&#x4EBA;&#x7C7B;&#x6709;&#x5371;&#x9669;&#x7684;&#x4F5C;&#x4E1A;&#x3002;

&#x64CD;&#x4F5C;&#x5982;&#x6B64;&#x591A;&#x7684;&#x673A;&#x5668;&#x4EBA;&#x9700;&#x8981;&#x4E00;&#x4E2A;&#x80FD;&#x591F;&#x5FEB;&#x901F;&#x8BC6;&#x522B;&#x95EE;&#x9898;&#x3001;&#x63D0;&#x9AD8;&#x5F00;&#x53D1;&#x901F;&#x5EA6;&#x3001;&#x4EE5;&#x6210;&#x672C;&#x4EF7;&#x5B9E;&#x73B0;&#x89E3;&#x51B3;&#x65B9;&#x6848;&#x5DE5;&#x4E1A;&#x5316;&#x4EE5;&#x53CA;&#x80FD;&#x8F7B;&#x677E;&#x8FDE;&#x63A5;&#x7269;&#x8054;&#x7F51;&#x6280;&#x672F;&#x7684;&#x7BA1;&#x7406;&#x7CFB;&#x7EDF;&#x3002;OTTO Motors &#x8FD8;&#x9AD8;&#x5EA6;&#x4F9D;&#x8D56;&#x667A;&#x80FD;&#x8DEF;&#x5F84;&#x89C4;&#x5212;&#xFF0C;&#x8FD9;&#x9700;&#x8981;&#x5BF9;&#x5927;&#x91CF;&#x7684;&#x6570;&#x636E;&#x70B9;&#x8FDB;&#x884C;&#x5B9E;&#x65F6;&#x5904;&#x7406;&#xFF0C;&#x624D;&#x80FD;&#x8BA9;&#x5355;&#x4E2A;&#x673A;&#x5668;&#x4EBA;&#x548C;&#x673A;&#x5668;&#x4EBA;&#x961F;&#x77E5;&#x9053;&#x5982;&#x4F55;&#x4ECE; A &#x70B9;&#x524D;&#x5F80; B &#x70B9;&#x3002;

OTTO Motors &#x9700;&#x8981;&#x4E00;&#x4E2A;&#x5B8C;&#x6574;&#x7684;&#x5806;&#x6808;&#x89E3;&#x51B3;&#x65B9;&#x6848;&#xFF0C;&#x8BE5;&#x89E3;&#x51B3;&#x65B9;&#x6848;&#x53EF;&#x4EE5;&#x5728;&#x4E0D;&#x82B1;&#x8D39;&#x5DE8;&#x5927;&#x8D39;&#x7528;&#x6216;&#x4E0D;&#x9700;&#x8981;&#x6784;&#x5EFA;&#x65B0;&#x6280;&#x672F;&#x7684;&#x60C5;&#x51B5;&#x4E0B;&#x8FDB;&#x884C;&#x6D4B;&#x8BD5;&#xFF0C;&#x5E76;&#x4E14;&#x53EF;&#x4EE5;&#x5F88;&#x5BB9;&#x6613;&#x5730;&#x63A5;&#x5165;&#x516C;&#x53F8;&#x5185;&#x90E8;&#x5DF2;&#x7ECF;&#x5728;&#x4F7F;&#x7528;&#x7684;&#x73B0;&#x6709;&#x8F6F;&#x4EF6;&#x3002;&#x5728;&#x5BFB;&#x627E;&#x7B26;&#x5408;&#x6240;&#x6709;&#x8FD9;&#x4E9B;&#x6807;&#x51C6;&#x7684;&#x89E3;&#x51B3;&#x65B9;&#x6848;&#x65F6;&#xFF0C;OTTO Motors &#x56E2;&#x961F;&#x5BF9;&#x5F62;&#x5F62;&#x8272;&#x8272;&#x7684;&#x7269;&#x8054;&#x7F51;&#x89E3;&#x51B3;&#x65B9;&#x6848;&#x8FDB;&#x884C;&#x4E86;&#x8C03;&#x67E5;&#x3002;OTTO Motors &#x7684;&#x524D;&#x57FA;&#x7840;&#x67B6;&#x6784;&#x7ECF;&#x7406; Greg Jacobs &#x8BF4;&#xFF1A;&#x201C;&#x6211;&#x4EEC;&#x60F3;&#x8981;&#x4E00;&#x79CD;&#x80FD;&#x5FEB;&#x901F;&#x6295;&#x5165;&#x4F7F;&#x7528;&#x7684;&#x89E3;&#x51B3;&#x65B9;&#x6848;&#x3002;&#x8C03;&#x67E5;&#x53D1;&#x73B0;&#xFF0C;Elastic &#x662F;&#x6211;&#x4EEC;&#x6700;&#x597D;&#x7684;&#x5207;&#x5165;&#x70B9;&#x3002; &#x201D;

&#x6700;&#x7EC8;&#xFF0C;OTTO Motors &#x7684;&#x56E2;&#x961F;&#x9009;&#x62E9;&#x4E86; <a href="/cn/products">Elastic Stack</a>&#xFF0C;&#x539F;&#x56E0;&#x6709;&#x4E09;&#x4E2A;&#xFF1A;

<ol>
	<li>Elastic &#x516C;&#x53F8;&#x7684;&#x4EA7;&#x54C1;&#x6709;&#x968F;&#x65F6;&#x53EF;&#x7528;&#x7684; HTTP/JSON API&#x3002;&#x6709;&#x4E86; Elastic Stack&#xFF0C;&#x6211;&#x4EEC;&#x53EF;&#x4EE5;&#x5F88;&#x8F7B;&#x677E;&#x5730;&#x5C06;&#x6570;&#x636E;&#x8F93;&#x5165;&#x670D;&#x52A1;&#xFF0C;&#x56E0;&#x4E3A;&#x5B83;&#x4E0E;&#x5176;&#x4ED6;&#x5DF2;&#x7ECF;&#x5728;&#x4F7F;&#x7528;&#x7684;&#x73B0;&#x6709;&#x5185;&#x90E8;&#x4EA7;&#x54C1;&#x548C;&#x670D;&#x52A1;&#x914D;&#x5408;&#x5F97;&#x5F88;&#x597D;&#x3002;&#x6B64;&#x5916;&#xFF0C;Elastic &#x63D0;&#x4F9B;&#x4E86;&#x6613;&#x4E8E;&#x4F7F;&#x7528;&#x7684;&#x5BA2;&#x6237;&#x7AEF;&#x5E93;&#x548C;&#x4E30;&#x5BCC;&#x7684;&#x6570;&#x636E;&#x6536;&#x96C6;&#x9009;&#x9879;&#x3002;</li>
	<li>&#x53EA;&#x9700;&#x8981;&#x4E00;&#x53F0;&#x8BA1;&#x7B97;&#x673A;&#x7528;&#x6765;&#x5B89;&#x88C5;&#x548C;&#x8FD0;&#x884C; Elastic Stack&#xFF0C;&#x5F00;&#x7BB1;&#x5373;&#x7528;&#xFF0C;&#x5E76;&#x4E14;&#x662F;&#x4E00;&#x4E2A;&#x72EC;&#x7ACB;&#x7684;&#x7CFB;&#x7EDF;&#xFF0C;&#x4E0D;&#x9700;&#x8981;&#x5EFA;&#x9020;&#x5176;&#x4ED6;&#x4EFB;&#x4F55;&#x4E1C;&#x897F;&#x5C31;&#x53EF;&#x4EE5;&#x8FD0;&#x884C;&#x3002;&#x4ECE;&#x5B89;&#x88C5;&#x8D77;&#xFF0C;&#x5C31;&#x5F88;&#x5BB9;&#x6613;&#x5F00;&#x59CB;&#x3001;&#x63A2;&#x7D22;&#x3001;&#x4F7F;&#x7528; Elastic Stack &#x63A5;&#x5165;&#x4E1C;&#x897F;&#x3001;&#x5E76;&#x968F;&#x7740; OTTO Motors &#x9700;&#x6C42;&#x7684;&#x589E;&#x957F;&#x800C;&#x6269;&#x5C55;&#x3002;
</li>
	<li>KIbana &#x662F;&#x57FA;&#x4E8E;&#x7F51;&#x7EDC;&#x7684;&#xFF0C;&#x975E;&#x5E38;&#x6613;&#x4E8E;&#x4F7F;&#x7528;&#xFF0C;&#x5E76;&#x4E14;&#x96C6;&#x6210;&#x826F;&#x597D;&#xFF0C;&#x4F9B;&#x5404;&#x79CD;&#x6700;&#x7EC8;&#x7528;&#x6237;/&#x7528;&#x4F8B;&#x4F7F;&#x7528;&#xFF0C;&#x8FD9;&#x4F7F;&#x5F97;&#x5B83;&#x5728;&#x6574;&#x4E2A;&#x516C;&#x53F8;&#x90FD;&#x5F88;&#x6709;&#x7528;&#x3002;</li>
</ol>
Greg Jacobs &#x518D;&#x6B21;&#x5F3A;&#x8C03;&#xFF1A;&#x201C;[Elastic Stack] &#x662F;&#x6211;&#x4EEC;&#x79CD;&#x4E0B;&#x7684;&#x79CD;&#x5B50;&#x3002;&#x4F46;&#x662F;&#x5B83;&#x4E0D;&#x4F1A;&#x53D8;&#x6210;&#x4E00;&#x4E2A;&#x6709;&#x56F4;&#x5899;&#x7684;&#x82B1;&#x56ED;&#x3002;&#x5B83;&#x5C06;&#x4E0E;&#x6240;&#x6709;&#x5176;&#x4ED6;&#x4E1C;&#x897F;&#x4E00;&#x8D77;&#x8FD0;&#x4F5C;&#x3002;&#x201D;

&#x4E3A;&#x6B64;&#xFF0C;OTTO Motors &#x5728;&#x5C06; Elastic Stack &#x7528;&#x4E8E;&#x7269;&#x8054;&#x7F51;&#x5E94;&#x7528;&#x4E4B;&#x5916;&#x8FD8;&#x90E8;&#x7F72;&#x5B83;&#x6765;&#x5E2E;&#x52A9;&#x8F6F;&#x4EF6;&#x5F00;&#x53D1;&#x8D28;&#x91CF;&#x4FDD;&#x8BC1;&#x3001;&#x4FE1;&#x606F;&#x6280;&#x672F;&#x5B89;&#x5168;&#x4EE5;&#x53CA;&#x4E3A;&#x63A2;&#x7D22;&#x6027;&#x62A5;&#x544A;&#x6784;&#x5EFA;&#x4EEA;&#x8868;&#x677F;&#x3002;&#x4F8B;&#x5982;&#xFF0C;OTTO Motors &#x6D4B;&#x8BD5;&#x673A;&#x5668;&#x4EBA;&#x7684;&#x81EA;&#x52A8;&#x5316;&#x7CFB;&#x7EDF;&#x5236;&#x4F5C;&#x865A;&#x62DF;&#x7801;&#x5934;&#x96C6;&#x88C5;&#x7BB1;&#x6765;&#x521B;&#x5EFA;&#x6FC0;&#x5149;&#x96F7;&#x8FBE;&#x6570;&#x636E;&#xFF0C;&#x7136;&#x540E;&#x673A;&#x5668;&#x4EBA;&#x5C06;&#x8FD9;&#x4E9B;&#x6570;&#x636E;&#x8BFB;&#x53D6;&#x4E3A;&#x771F;&#x5B9E;&#x969C;&#x788D;&#x7269;&#x3002;Elastic &#x8FD8;&#x5141;&#x8BB8; OTTO Motors &#x6267;&#x884C;&#x673A;&#x5668;&#x4EBA;&#x53EF;&#x4EE5;&#x77AC;&#x95F4;&#x5B8C;&#x6210;&#x7684;&#x9AD8;&#x901F;&#x6A21;&#x62DF;&#x3002;&#x8FD9;&#x4F7F;&#x5F97; OTTO Motors &#x80FD;&#x591F;&#x4EE5;&#x6BD4;&#x6B63;&#x5E38;&#x901F;&#x5EA6;&#x5FEB;&#x6570;&#x767E;&#x500D;&#x751A;&#x81F3;&#x6570;&#x5343;&#x500D;&#x7684;&#x901F;&#x5EA6;&#x8FD0;&#x884C;&#x673A;&#x5668;&#x4EBA;&#x961F;&#x7BA1;&#x7406;&#x8F6F;&#x4EF6;&#xFF0C;&#x540C;&#x65F6;&#x4F7F;&#x7528; Elastic &#x516C;&#x53F8;&#x63D0;&#x4F9B;&#x7684; <a href="/cn/products/beats/metricbeat">Metricbeat</a> &#x548C;&#x5176;&#x4ED6;&#x5DE5;&#x5177;&#x6765;&#x6D4B;&#x8BD5;&#x7CFB;&#x7EDF;&#x5185;&#x7684;&#x95EE;&#x9898;&#x3002;

<img src="https://lh6.googleusercontent.com/i9nWIHbOx3HBbAS7KyOk2mcyO5ubzM77OKPzvEqmEDZZN1RnKzoLrRUpAvbsTYgMi-6tq3Ira2fU2R7I5AOXZCZgr58L5Ij805DBN-hBK3FBs5Q3WqInbqTYIt3eg7w5IU7cykSA" width="741" height="404" alt="" style="width: 741px; height: 404px; display: block; margin: auto;">

&#x8FD0;&#x884C;&#x4E00;&#x5927;&#x7FA4;&#x673A;&#x5668;&#x4EBA;&#x4F1A;&#x4EA7;&#x751F;&#x5927;&#x91CF;&#x7684;&#x6570;&#x636E;&#xFF0C;&#x8FD9;&#x4E9B;&#x6570;&#x636E;&#x88AB;&#x8F93;&#x5165;&#x5230; Elastic &#x6570;&#x636E;&#x5E93;&#x3002;OTTO Motors &#x673A;&#x5668;&#x4EBA;&#x6536;&#x96C6;&#x7684;&#x6570;&#x636E;&#x91CF;&#x662F;&#x60CA;&#x4EBA;&#x7684;&#xFF1A;&#x673A;&#x5668;&#x4EBA;&#x961F;&#x4E2D;&#x6BCF;&#x4E2A;&#x673A;&#x5668;&#x4EBA;&#x6BCF; 10 &#x79D2;&#x949F;&#x6709; 5000 &#x591A;&#x4E2A;&#x6570;&#x636E;&#x70B9;&#x3002;&#x8FD9;&#x5305;&#x62EC;&#x4E2D;&#x592E;&#x5904;&#x7406;&#x5668;&#x65F6;&#x95F4;&#x3001;&#x65E0;&#x7EBF;&#x4FE1;&#x53F7;&#x3001;&#x7535;&#x673A;&#x6E29;&#x5EA6;&#x3001;&#x5BFC;&#x822A;&#x7EC6;&#x8282;&#x7B49;&#x3002;&#x4ED6;&#x4EEC;&#x4F7F;&#x7528; Elastic &#x5C06;&#x6240;&#x6709;&#x6570;&#x636E;&#x6C47;&#x603B;&#x5230; 30 &#x5206;&#x949F;&#x7684;&#x62A5;&#x544A;&#x7A97;&#x53E3;&#x4E2D;&#x3002; 

OTTO Motors &#x8FD8;&#x4F7F;&#x7528; Elastic &#x7684;&#x76D1;&#x6D4B;&#x529F;&#x80FD;&#x6765;&#x521B;&#x5EFA;&#x5B9A;&#x5236;&#x4EEA;&#x8868;&#x677F;&#xFF0C;&#x4EE5;&#x53D1;&#x73B0;&#x9690;&#x85CF;&#x7684;&#x8D8B;&#x52BF;&#xFF0C;&#x67E5;&#x770B;&#x54EA;&#x4E9B;&#x6307;&#x6570;&#x53D7;&#x5230;&#x6700;&#x5927;&#x51B2;&#x51FB;&#xFF0C;&#x5E76;&#x4E86;&#x89E3;&#x54EA;&#x4E9B;&#x53D7;&#x5230;&#x7528;&#x6237;&#x7684;&#x6B22;&#x8FCE;&#x3002;

OTTO Motors &#x6848;&#x4F8B;&#x7684;&#x6838;&#x5FC3;&#x662F;&#x9488;&#x5BF9;&#x6574;&#x4E2A;&#x5806;&#x6808;&#x7684;&#x9700;&#x6C42;&#x548C;&#x5BF9;&#x5E94;&#x7684;&#x89E3;&#x51B3;&#x65B9;&#x6848;&#x3002;&#x60F3;&#x4E86;&#x89E3; OTTO Motors &#x5982;&#x4F55;&#x4F7F;&#x7528; Elastic Stack &#x4F7F;&#x4ED6;&#x4EEC;&#x7684;&#x673A;&#x5668;&#x4EBA;&#x5728;&#x5168;&#x7403;&#x8303;&#x56F4;&#x5185;&#x5DE5;&#x4F5C;&#x5F97;&#x66F4;&#x597D;&#x5417;&#xFF1F;&#x89C2;&#x770B;&#x6765;&#x81EA; <a href="/cn/elasticon/conf/2018/sf">Elastic {ON} 2018</a> &#x7684;<a href="/cn/elasticon/conf/2018/sf/the-quick-starter-stack-for-robotics-iot-and-big-data">&#x673A;&#x5668;&#x4EBA;&#x3001;&#x7269;&#x8054;&#x7F51;&#x548C;&#x5927;&#x6570;&#x636E;&#x5FEB;&#x901F;&#x5165;&#x95E8;&#x7CFB;&#x5217;</a>&#x3002;&#x5728;&#x8BE5;&#x5EA7;&#x8C08;&#x4F1A;&#x4E2D;&#xFF0C;&#x60A8;&#x5C06;&#x8BE6;&#x7EC6;&#x4E86;&#x89E3;&#x5230; Elastic Stack &#x662F;&#x5982;&#x4F55;&#x5B9E;&#x73B0;&#x7EF4;&#x62A4;&#x548C;&#x53D1;&#x5C55;&#x667A;&#x80FD;&#x81EA;&#x52A8;&#x9A7E;&#x9A76;&#x673A;&#x5668;&#x4EBA;&#x961F;&#x4F0D;&#x6210;&#x3002;

<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>
</body></html>

Otto Motors Robot.jpg

Otto Lifting Boxes.jpg

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

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

<html><head></head><body>Elastic &#x901A;&#x8FC7;&#x534F;&#x4F5C;&#x6765;&#x5B8C;&#x6210;&#x5404;&#x9879;&#x5DE5;&#x4F5C;&#x3002;
&#x6211;&#x4EEC;&#x7684;&#x5DE5;&#x7A0B;&#x5E08; 24 &#x5C0F;&#x65F6;&#x4E0D;&#x505C;&#x5730;&#x5DE5;&#x4F5C;&#xFF08;&#x786E;&#x5B9E;&#x5982;&#x6B64;&#xFF0C;&#x56E0;&#x4E3A;&#x6211;&#x4EEC;&#x662F;&#x4E00;&#x5BB6; <a href="/cn/about/our-source-code">&#x5206;&#x5E03;&#x5F0F;&#x516C;&#x53F8;</a>&#xFF09;&#x6765;&#x5F00;&#x53D1;&#x65B0;&#x4EA7;&#x54C1;&#x548C;&#x529F;&#x80FD;&#x3002;&#x8FD9;&#x662F;&#x4E00;&#x9879;&#x5DE8;&#x5927;&#x7684;&#x5DE5;&#x4F5C;&#xFF0C;&#x9700;&#x8981;&#x4ED4;&#x7EC6;&#x5173;&#x6CE8;&#x7EC6;&#x8282;&#x3002;&#x4F46;&#x662F;&#x4E0D;&#x7BA1;&#x6211;&#x4EEC;&#x6709;&#x591A;&#x5C0F;&#x5FC3;&#xFF0C;&#x6211;&#x4EEC;&#x90FD;&#x65E0;&#x6CD5;&#x505A;&#x5230;&#x5B8C;&#x7F8E;&#xFF0C;&#x5BF9;&#x4E8E;&#x4EFB;&#x4F55;&#x50CF;&#x6211;&#x4EEC;&#x8FD9;&#x6837;&#x590D;&#x6742;&#x7684;&#x5F00;&#x6E90;&#x9879;&#x76EE;&#xFF0C;&#x6211;&#x4EEC;&#x4ECD;&#x7136;&#x9700;&#x8981;&#x793E;&#x533A;&#x7684;&#x5E2E;&#x52A9;&#x6765;&#x4F7F;&#x5B83;&#x53D8;&#x5F97;&#x66F4;&#x597D;&#x3002;
&#x5728;<a href="/cn/blog/solving-the-small-but-important-issues-with-fix-it-fridays">&#x4F7F;&#x7528; Fix-It Friday &#x89E3;&#x51B3;&#x5C0F;&#x4F46;&#x91CD;&#x8981;&#x7684;&#x95EE;&#x9898;</a>&#x4E2D;&#xFF0C;&#x6211;&#x4EEC;&#x8BA8;&#x8BBA;&#x4E86;&#x793E;&#x533A;&#x7684;&#x8D21;&#x732E;&#x5982;&#x4F55;&#x63A8;&#x52A8;&#x6211;&#x4EEC;&#x4E0D;&#x65AD;&#x6210;&#x529F;&#x5F00;&#x53D1;&#x4EA7;&#x54C1;&#x3002;&#x4F5C;&#x4E3A;&#x4E00;&#x4E2A;&#x5F00;&#x6E90;&#x9879;&#x76EE;&#x7684;&#x4E00;&#x5927;&#x597D;&#x5904;&#x662F;&#xFF0C;&#x6211;&#x4EEC;&#x6709;&#x4E00;&#x4E2A;&#x5E9E;&#x5927;&#x7684;&#x5F00;&#x53D1;&#x8005;&#x793E;&#x533A;&#xFF0C;&#x4ED6;&#x4EEC;&#x4F1A;&#x5BFB;&#x627E;&#x6F0F;&#x6D1E;&#xFF0C;&#x5E76;&#x6025;&#x5207;&#x5730;&#x7B49;&#x627E;&#x5230;&#x5835;&#x4F4F;&#x6F0F;&#x6D1E;&#x7684;&#x673A;&#x4F1A;&#x3002;
&#x5982;&#x679C;&#x60A8;&#x662F;&#x793E;&#x533A;&#x7684;&#x65B0;&#x6210;&#x5458;&#xFF0C;&#x5E76;&#x4E14;&#x662F;&#x7B2C;&#x4E00;&#x6B21;&#x63D0;&#x4EA4;&#x60A8;&#x7684; Pull Request (PR)&#xFF0C;&#x6216;&#x8005;&#x5BF9;&#x8FD9;&#x4E2A;&#x8FC7;&#x7A0B;&#x7684;&#x5DE5;&#x4F5C;&#x65B9;&#x5F0F;&#x6709;&#x7591;&#x95EE;&#xFF0C;&#x90A3;&#x4E48;&#x60A8;&#x6765;&#x5BF9;&#x4E86;&#x5730;&#x65B9;&#xFF01;&#x5728;&#x8FD9;&#x7BC7;&#x6587;&#x7AE0;&#x4E2D;&#xFF0C;&#x6211;&#x4EEC;&#x5C06;&#x6982;&#x8FF0; pull request &#x662F;&#x5982;&#x4F55;&#x5E2E;&#x52A9; Elastic &#x8FD0;&#x4F5C;&#x7684;&#xFF0C;&#x6211;&#x4EEC;&#x6536;&#x5230; pull request &#x65F6;&#x5982;&#x4F55;&#x8FDB;&#x884C;&#x5904;&#x7406;&#xFF0C;&#x4EE5;&#x53CA;&#x5982;&#x4F55;&#x907F;&#x514D;&#x53EF;&#x80FD;&#x59A8;&#x788D;&#x60A8;&#x7684;&#x5EFA;&#x8BAE;&#x5F97;&#x5230;&#x91C7;&#x7EB3;&#x7684;&#x5E38;&#x89C1;&#x9519;&#x8BEF;&#x3002;
<h2>&#x90A3;&#x4E48;&#xFF0C;&#x6211;&#x5982;&#x4F55;&#x63D0;&#x4EA4; Pull Request&#xFF1F;</h2><span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;" id="docs-internal-guid-91b61f53-7fff-cb5b-0a28-1f104a35591a"><img src="https://lh5.googleusercontent.com/GMhcYAoGehxmwwALqJn1bOH0B0hj6NqdyktF3Kbb-lvGvzfXE5t3uQRFiSyXRg9kBuJstwQGCX1X3PHVwFZhaUJDyoBuCgLhRpEOpEtz1qKhQIoUhSrT-nbcE5JPL5se5JTz7fgT" style="border: none; transform: rotate(0.00rad); -webkit-transform: rotate(0.00rad);" width="624" height="275">
&#x63D0;&#x4EA4; PR &#x4E4B;&#x524D;&#xFF0C;&#x60A8;&#x9700;&#x8981;&#x5728; GITHUB &#x5B58;&#x50A8;&#x5E93;&#x4E2D;&#x521B;&#x5EFA;&#x4E00;&#x4E2A;&#x5206;&#x53C9;&#xFF0C;&#x5E76;&#x5BF9;&#x4EE3;&#x7801;&#x8FDB;&#x884C;&#x66F4;&#x6539;&#x3002;&#x8FD9;&#x901A;&#x5E38;&#x662F;&#x5728;&#x60A8;&#x81EA;&#x5DF1;&#x7684; GitHub &#x5E10;&#x6237;&#x4E0B;&#x5B8C;&#x6210;&#x7684;&#xFF0C;&#x5B83;&#x4F1A;&#x4E3A;&#x60A8;&#x521B;&#x5EFA;&#x4E00;&#x4E2A;&#x6E90;&#x5B58;&#x50A8;&#x5E93;&#x7684;&#x526F;&#x672C;&#x3002;&#x6211;&#x4EEC;&#x6240;&#x6709;&#x7684;&#x9879;&#x76EE;&#x90FD;&#x5B58;&#x5728;&#x5B83;&#x4EEC;&#x81EA;&#x5DF1;&#x7684; GitHub &#x5B58;&#x50A8;&#x5E93;&#x4E2D;&#x3002;GitHub&#x4E0A;&#x7684; <a href="https://github.com/elastic">Elastic &#x7EC4;&#x7EC7;&#x9875;&#x9762;</a>&#x4E0A;&#x63D0;&#x4F9B;&#x4E86;&#x6211;&#x4EEC;&#x5B58;&#x50A8;&#x5E93;&#x7684;&#x5B8C;&#x6574;&#x5217;&#x8868;&#x3002;&#xA0;&#x4E00;&#x65E6;&#x521B;&#x5EFA;&#x4E86;&#x5B58;&#x50A8;&#x5E93;&#x7684;&#x5206;&#x652F;&#x5E76;&#x66F4;&#x6539;&#x4E86;&#x4EE3;&#x7801;&#xFF0C;&#x7CFB;&#x7EDF;&#x4F1A;&#x8BE2;&#x95EE;&#x60A8;&#x662F;&#x5426;&#x8981;&#x521B;&#x5EFA; PR&#xFF0C;&#x5E76;&#x5C06;&#x5EFA;&#x8BAE;&#x7684;&#x66F4;&#x6539;&#x63A8;&#x9001;&#x5230;&#x4EA7;&#x54C1;&#x5B58;&#x50A8;&#x5E93;&#x7684;&#x4E3B;&#x5206;&#x652F;&#x3002;&#x4F8B;&#x5982;&#xFF0C;<a href="https://github.com/elastic/elasticsearch">Elasticsearch &#x5B58;&#x50A8;&#x5E93;</a>&#xFF0C;&#x5982;&#x4E0B;&#x6240;&#x793A;&#x3002;&#x4E3A;&#x4E86;&#x7B80;&#x5355;&#x8D77;&#x89C1;&#xFF0C;&#x6211;&#x4EEC;&#x5C06;&#x5728;&#x8FD9;&#x7BC7;&#x6587;&#x7AE0;&#x4E2D;&#x5C55;&#x793A; Elasticsearch &#x5B58;&#x50A8;&#x5E93;&#x4E2D;&#x7684;&#x4F8B;&#x5B50;&#x3002; <span style="font-size:11pt;font-family:Arial;color:#000000;background-color:#ffff00;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;" id="docs-internal-guid-8a6df0e2-7fff-2901-adc2-929be1f031b1"><img src="https://lh6.googleusercontent.com/KMOIoaP5tmhOwWNHgohNqEQAzZDSwmybbrTV37hjP9LDyypLpgNbEX3dpy2Vjup0rHmn7U-70ZksfO9x0Qpu1Rf50CSAANOPDe3jJAuFuB4uwKnzVTlKe10-oMS7rxOIfC3VWqas" style="border: none; transform: rotate(0.00rad); -webkit-transform: rotate(0.00rad);" width="624" height="336">
<span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;" id="docs-internal-guid-50820ac8-7fff-7e8f-0150-4c37402d1987"><img src="https://lh4.googleusercontent.com/iMtJ4lUD5WthzIkg7yYBVYnPF5Uj62LYfSMlpjCLlFVJd6g11Y0ThUHIt02aJ-HF__EZ7MtV85_fDLB2JWFxaNJtjDZY8aXkMamOwqPEhXETTa2Zx6-oK2VEoZKsUB_Ima5mo1vK" style="border: none; transform: rotate(0.00rad); -webkit-transform: rotate(0.00rad);" width="624" height="84">
&#x5F53;&#x60A8;&#x70B9;&#x51FB;&#x201C;New pull request&#x201D;&#xFF08;&#x65B0;&#x5EFA; pull request&#xFF09;&#x65F6;&#xFF0C;&#x60A8;&#x4F1A;&#x9996;&#x5148;&#x770B;&#x5230;&#x6211;&#x4EEC;&#x7684; <a href="https://github.com/elastic/elasticsearch/blob/master/.github/PULL_REQUEST_TEMPLATE.md">pull request &#x6A21;&#x677F;</a>&#x3002;
<span style="font-size:11pt;font-family:Arial;color:#000000;background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;" id="docs-internal-guid-6405c365-7fff-bd99-7c63-695f3f7df9c3"><img src="https://lh5.googleusercontent.com/jqFQ_9-1qLywNsVoVueU5zIjB3uViVbQzSFRO1n2SQNZKzKxhgp7htJGIbC7z8XEeDbw0qgQHMlGd2AzHnwfMmxUbWhRSoICkANrsrczW9WsY6uSSxm2-305L4bdvPYWR1qUzzCd" style="border: none; transform: rotate(0.00rad); -webkit-transform: rotate(0.00rad);" width="624" height="247">
&#x8FD9;&#x4E2A;&#x6A21;&#x677F;&#x5C06;&#x4E3A;&#x60A8;&#x63D0;&#x4F9B;&#x6307;&#x5BFC;&#xFF0C;&#x5E2E;&#x52A9;&#x60A8;&#x7684; PR &#x901A;&#x8FC7;&#x7B2C;&#x4E00;&#x6B21;&#x5BA1;&#x67E5;&#xFF0C;&#x6240;&#x4EE5;&#x4E00;&#x5B9A;&#x8981;&#x901A;&#x8BFB;&#xFF0C;&#x56E0;&#x4E3A;&#x6BCF;&#x4E2A;&#x4EA7;&#x54C1;&#x90FD;&#x6709;&#x81EA;&#x5DF1;&#x7684;&#x6807;&#x51C6;&#x548C;&#x6587;&#x6863;&#x3002;&#x6A21;&#x677F;&#x4F1A;&#x7ED9;&#x60A8;&#x6307;&#x5BFC;&#xFF0C;&#x5E2E;&#x52A9;&#x60A8;&#x7684; PR &#x901A;&#x8FC7;&#x7B2C;&#x4E00;&#x6B21;&#x5BA1;&#x67E5;&#x3002;
&#x63D0;&#x4EA4;&#x65F6;&#x786E;&#x4FDD;&#x907F;&#x514D;&#x8FD9;&#x4E9B;&#x5E38;&#x89C1;&#x9519;&#x8BEF;&#xFF1A;
<ul>
	<li>&#x63D0;&#x4EA4;&#x91CD;&#x590D;&#x9879; - &#x9996;&#x5148;&#xFF0C;&#x6839;&#x636E;&#x60A8;&#x7684;&#x4EE3;&#x7801;&#x8981;&#x4FEE;&#x590D;&#x7684;&#x9519;&#x8BEF;&#xFF0C;&#x641C;&#x7D22;&#x6709;&#x6CA1;&#x6709;&#x6253;&#x5F00;&#x7684; PR &#x5DF2;&#x7ECF;&#x5728;&#x89E3;&#x51B3;&#x8FD9;&#x4E2A;&#x95EE;&#x9898;&#x3002;&#x526F;&#x672C;&#x901A;&#x5E38;&#x88AB;&#x62D2;&#x7EDD;&#x3002;</li>
	<li>&#x4E0D;&#x5305;&#x62EC;&#x6D4B;&#x8BD5; - &#x5305;&#x542B;&#x4EE3;&#x7801;&#x66F4;&#x6539;&#x7684; PR &#x5E94;&#x5305;&#x62EC;&#x8BF4;&#x660E;&#x65B0;&#x4EE3;&#x7801;&#x884C;&#x4E3A;&#x7684;&#x6D4B;&#x8BD5;&#x3002;&#x7406;&#x60F3;&#x60C5;&#x51B5;&#x4E0B;&#xFF0C;&#x8FD9;&#x4E2A;&#x6D4B;&#x8BD5;&#x5E94;&#x8BE5;&#x91CD;&#x73B0; PR &#x6B63;&#x5728;&#x4FEE;&#x590D;&#x7684;&#x95EE;&#x9898;&#xFF0C;&#x8FD9;&#x6837;&#x6D4B;&#x8BD5;&#x5728;&#x6CA1;&#x6709;&#x4EE3;&#x7801;&#x7684;&#x60C5;&#x51B5;&#x4E0B;&#x4F1A;&#x5931;&#x8D25;&#xFF0C;&#x800C;&#x5728;&#x5E94;&#x7528;&#x4EE3;&#x7801;&#x65F6;&#x901A;&#x8FC7;&#x3002;</li>
	<li>&#x4EC5;&#x4E3B;&#x5206;&#x652F; - &#x786E;&#x4FDD;&#x4EFB;&#x4F55;&#x66F4;&#x6539;&#x4EE3;&#x7801;&#x7684; PR &#x5747;&#x9488;&#x5BF9;&#x76F8;&#x5173;&#x76EE;&#x5F55;&#x4E2D;&#x7684;&#x4E3B;&#x5206;&#x652F;&#x63D0;&#x51FA;&#x3002;</li>
</ul>&#x5B8C;&#x6210;&#x6A21;&#x677F;&#x4E2D;&#x5217;&#x51FA;&#x7684;&#x6240;&#x6709;&#x8981;&#x6C42;&#x540E;&#xFF0C;&#x5355;&#x51FB;&#x201C;&#x521B;&#x5EFA; Pull Request&#x201D;&#x3002;&#x73B0;&#x5728;&#x4E00;&#x5207;&#x51C6;&#x5907;&#x5C31;&#x7EEA;&#x4E86;&#x3002;
<h2>&#x5206;&#x95E8;&#x522B;&#x7C7B;&#x548C;&#x6DFB;&#x52A0;&#x6807;&#x7B7E;</h2>&#x6211;&#x4EEC;&#x7684;&#x7B2C;&#x4E00;&#x6B65;&#x662F;&#x786E;&#x4FDD; PR &#x7B26;&#x5408;&#x4E00;&#x4E2A;&#x597D;&#x8BF7;&#x6C42;&#x7684;&#x6807;&#x51C6;&#xFF08;&#x5982;&#x4E0A;&#x6240;&#x8FF0;&#xFF09;&#xFF0C;&#x5982;&#x679C;&#x7B26;&#x5408;&#xFF0C;&#x5C31;&#x7ED9; PR &#x8D34;&#x4E0A;&#x6807;&#x7B7E;&#xFF0C;&#x8FD9;&#x6837;&#x4F1A;&#x6709;&#x5408;&#x9002;&#x7684;&#x5BA1;&#x6838;&#x8005;&#x6765;&#x67E5;&#x770B;&#xFF0C;&#x4EE5;&#x4FBF;&#x8FDB;&#x4E00;&#x6B65;&#x8BC4;&#x4F30;&#x3002;&#x6807;&#x7B7E;&#x53EF;&#x80FD;&#x5305;&#x62EC; <code>&gt;bug</code>&#x3001;<code>&gt;&#x529F;&#x80FD;</code>&#x7B49;&#x7B49;&#x3002;&#x4E00;&#x65E6; Pull Request &#x6709;&#x4E86;&#x6807;&#x7B7E;&#xFF0C;&#x5B83;&#x5C31;&#x4F1A;&#x88AB;&#x5206;&#x914D;&#x7ED9;&#x9002;&#x5F53;&#x7684;&#x5B50;&#x56E2;&#x961F;&#x6765;&#x5904;&#x7406;&#x3002;&#x5728;&#x8FD9;&#x4E4B;&#x540E;&#xFF0C;&#x5904;&#x7406;&#x8BF7;&#x6C42;&#x662F;&#x8D1F;&#x8D23;&#x8BE5;&#x9886;&#x57DF;&#x7684;&#x56E2;&#x961F;&#x8FDB;&#x884C;&#x3002;
<span style="font-size:11pt;font-family:Arial;color:#000000;background-color:#ffff00;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre;white-space:pre-wrap;" id="docs-internal-guid-968959a4-7fff-f9ab-e145-babc47a96875"><img src="https://lh5.googleusercontent.com/TqRYJlBBY2ZYFsk7K_IyNnKbBVAiR2Wyd6fMhePgIEMuFMtUN-pqzqnoaCbHAOo9bu6wyxsYq9qlfesHKzhWBSQ_cEbBBmMiHsJSng5oMstndym0lY2ySAkznTDU0UMiMZnTjuEm" style="border: none; transform: rotate(0.00rad); -webkit-transform: rotate(0.00rad);" width="624" height="409">
<h2>&#x5F00;&#x59CB;&#x8FDB;&#x7A0B;</h2>&#x4E00;&#x65E6; PR &#x88AB;&#x8D34;&#x4E0A;&#x6807;&#x7B7E;&#xFF0C;&#x5B83;&#x5C31;&#x4F1A;&#x88AB;&#x6211;&#x4EEC;&#x7684;&#x4E00;&#x4E2A;&#x5F00;&#x53D1;&#x8005;&#x9886;&#x53D6;&#x3002;&#x6211;&#x4EEC;&#x4F1A;&#x5C3D;&#x5FEB;&#x56DE;&#x590D;&#x8BF7;&#x6C42;&#x8005;&#xFF0C;&#x4E0D;&#x8FC7;&#x6211;&#x4EEC;&#x8BF7;&#x60A8;&#x5728;&#x63D0;&#x4EA4; PR &#x65F6;&#x6709;&#x8010;&#x5FC3;&#xFF0C;&#x56E0;&#x4E3A;&#x7531;&#x4E8E;&#x8BF7;&#x6C42;&#x7684;&#x7EA7;&#x522B;&#x548C;&#x6DF1;&#x5EA6;&#x5404;&#x4E0D;&#x76F8;&#x540C;&#xFF0C;&#x6B63;&#x786E;&#x5904;&#x7406;&#x8BF7;&#x6C42;&#x53EF;&#x80FD;&#x9700;&#x8981;&#x4E00;&#x4E9B;&#x65F6;&#x95F4;&#x3002;&#xA0;<h2>&#x63D0;&#x4EA4;&#x6587;&#x4EF6;&#x53D8;&#x66F4;</h2>&#x6CE8;&#x610F;&#xFF1A;&#x6211;&#x4EEC;&#x8FD8;&#x6536;&#x5230;&#x8BB8;&#x591A;&#x4FEE;&#x6539;&#x6216;&#x8BF7;&#x6C42;&#x4FEE;&#x6539;&#x6211;&#x4EEC;&#x6587;&#x6863;&#x7684; PR&#x3002;&#x8FD9;&#x4E2A;&#x8FC7;&#x7A0B;&#x6BD4;&#x4EE3;&#x7801;&#x66F4;&#x6539;&#x7B80;&#x5355;&#x5F97;&#x591A; &#x2014; &#x53EA;&#x9700;&#x8981;&#x5728; Elastic &#x6587;&#x6863;&#x9875;&#x9762;&#x4E0A;&#x70B9;&#x51FB;&#x201C;&#x7F16;&#x8F91;&#x201D;&#xFF0C;&#x8FDB;&#x884C;&#x66F4;&#x6539;&#xFF0C;&#x7136;&#x540E;&#x63D0;&#x4EA4;&#x8BF7;&#x6C42;&#x3002;&#x4E0D;&#x9700;&#x8981;&#x5206;&#x53C9;&#x9879;&#x76EE;&#xFF0C;&#x4E5F;&#x4E0D;&#x9700;&#x8981;&#x6D4B;&#x8BD5;&#x3002;&#x6211;&#x4EEC;&#x7528;&#x201C;&gt;doc&#x201D;&#x6807;&#x8BB0;&#x8FD9;&#x4E9B; PR&#xFF0C;&#x5E76;&#x5C3D;&#x5FEB;&#x5904;&#x7406;&#x3002;
<h2>&#x901A;&#x5E38;&#xFF0C;&#x6211;&#x4EEC;&#x6709;&#x66F4;&#x591A;&#x7684;&#x5DE5;&#x4F5C;&#x8981;&#x505A;</h2>PR &#x901A;&#x5E38;&#x9700;&#x8981;&#x5728;&#x51C6;&#x5907;&#x5408;&#x5E76;&#x4E4B;&#x524D;&#x8FDB;&#x884C;&#x8C03;&#x6574;&#x3002;&#x6B64;&#x65F6;&#xFF0C;PR &#x53D8;&#x6210;&#x4E86;&#x4E00;&#x4E2A;&#x534F;&#x4F5C;&#x7A7A;&#x95F4;&#xFF0C;&#x793E;&#x533A;&#x6210;&#x5458;&#x5728;&#x8FD9;&#x91CC;&#x8FDB;&#x884C;&#x8BA8;&#x8BBA;&#xFF0C;&#x63D0;&#x51FA;&#x6539;&#x53D8;&#xFF0C;&#x5E76;&#x505A;&#x51FA;&#x66F4;&#x591A;&#x6539;&#x8FDB;&#x3002;
&#x5728;&#x5BA1;&#x67E5;&#x8FC7;&#x7A0B;&#x4E2D;&#xFF0C;&#x6211;&#x4EEC;&#x5BF9;&#x4F1A; PR &#x8FDB;&#x884C;&#x6D4B;&#x8BD5;&#xFF0C;&#x6D4B;&#x8BD5;&#x7ED3;&#x679C;&#x53EF;&#x4EE5;&#x5728; GitHub &#x4E0A;&#x770B;&#x5230;&#x3002;&#x6709;&#x65F6;&#xFF0C;&#x5373;&#x4F7F;&#x63D0;&#x4EA4;&#x7684;&#x6D4B;&#x8BD5;&#x6709;&#x6548;&#xFF0C;&#x5F53;&#x5E94;&#x7528; PR &#x4E2D;&#x7684;&#x66F4;&#x6539;&#x65F6;&#xFF0C;&#x6D4B;&#x8BD5;&#x4E5F;&#x53EF;&#x80FD;&#x4F1A;&#x5931;&#x8D25;&#x3002;&#x4E0D;&#x8FC7;&#xFF0C;&#x8FD9;&#x5E76;&#x4E0D;&#x662F;&#x6700;&#x540E;&#x7684;&#x7ED3;&#x679C;&#x3002;&#x6211;&#x4EEC;&#x5C06;&#x5E2E;&#x52A9;&#x8D21;&#x732E;&#x8005;&#x4FEE;&#x590D;&#x8D21;&#x732E;&#x7684;&#x4EE3;&#x7801;&#xFF0C;&#x4EE5;&#x4FBF;&#x6240;&#x6709;&#x6D4B;&#x8BD5;&#x90FD;&#x901A;&#x8FC7;&#x3002;
&#x4EE3;&#x7801;&#x98CE;&#x683C;&#x4EE5;&#x53CA;&#x4EE3;&#x7801;&#x548C;&#x547D;&#x540D;&#x7EA6;&#x5B9A;&#xFF0C;&#x4E5F;&#x662F;&#x6211;&#x4EEC;&#x5728;&#x8FD9;&#x4E2A;&#x9636;&#x6BB5;&#x5173;&#x6CE8;&#x7684;&#x95EE;&#x9898;&#x3002;&#x63D0;&#x4EA4; Pull Request &#x7684;&#x7528;&#x6237;&#x5E94;&#x8BE5;&#x6CE8;&#x610F;&#xFF1A;&#x4ED6;&#x4EEC;&#x7684;&#x4EE3;&#x7801;&#x4F1A;&#x81F3;&#x5C11;&#x7ECF;&#x8FC7;&#x4E00;&#x8F6E;&#x5BA1;&#x67E5;&#x3002;&#x4EE3;&#x7801;&#x4ECE;&#x6765;&#x90FD;&#x4E0D;&#x662F;&#x5B8C;&#x7F8E;&#x7684;&#xFF08;&#x751A;&#x81F3;&#x6211;&#x4EEC;&#x7684;&#x4EE3;&#x7801;&#x90FD;&#x4E0D;&#x5B8C;&#x7F8E;&#xFF01;&#xFF09;&#x5E76;&#x5728;&#x63D0;&#x4EA4;&#x65F6;&#x51C6;&#x5907;&#x7528;&#x4E8E;&#x5408;&#x5E76; &#x2014; &#x56E0;&#x6B64;&#xFF0C;&#x5728;&#x6B64;&#x8FC7;&#x7A0B;&#x4E2D;&#x53EF;&#x80FD;&#x9700;&#x8981;&#x60A8;&#x7684;&#x5408;&#x4F5C;&#x3002;
<h2>&#x6211;&#x7684; PR &#x9700;&#x8981;&#x591A;&#x957F;&#x65F6;&#x95F4;&#x624D;&#x80FD;&#x88AB;&#x7EB3;&#x5165;&#xFF1F;</h2>&#x6BCF;&#x4E2A; PR &#x7684;&#x5904;&#x7406;&#x65F6;&#x95F4;&#x6709;&#x6240;&#x4E0D;&#x540C;&#x3002;&#x4E00;&#x884C;&#x7B80;&#x5355;&#x7684;&#x4EE3;&#x7801;&#x53EF;&#x80FD;&#x4F1A;&#x88AB;&#x5FEB;&#x901F;&#x5904;&#x7406;&#xFF0C;&#x4F46;&#x662F;&#x590D;&#x6742;&#x7684;&#x4EE3;&#x7801;&#x66F4;&#x6539;&#x4F1A;&#x7ECF;&#x8FC7;&#x591A;&#x8F6E;&#x5BA1;&#x67E5;&#x3002;&#x5982;&#x679C;&#x60A8;&#x89C9;&#x5F97;&#x60A8;&#x7684; PR &#x5DF2;&#x7ECF;&#x63D0;&#x4EA4;&#x4E86;&#x5F88;&#x957F;&#x65F6;&#x95F4;&#x4F46;&#x662F;&#x6CA1;&#x6709;&#x4EFB;&#x4F55;&#x52A8;&#x9759;&#xFF0C;&#x53EF;&#x4EE5;&#x5F00;&#x4E00;&#x5F20;&#x652F;&#x6301;&#x8BF7;&#x6C42;&#x6765;&#x63D0;&#x9192;&#x6211;&#x4EEC;&#x6B64; PR &#x4ECD;&#x5904;&#x4E8E;&#x6D3B;&#x8DC3;&#x72B6;&#x6001;&#x3002;
<h2>&#x7EB3;&#x5165;&#x4EE3;&#x7801;</h2>&#x5F53;&#x4E00;&#x5207;&#x51C6;&#x5907;&#x5C31;&#x7EEA;&#x65F6;&#xFF0C;&#x8BC4;&#x5BA1;&#x8005;&#x4F1A;&#x5728;&#x6279;&#x51C6;&#x64CD;&#x4F5C;&#x4E2D;&#x6DFB;&#x52A0;&#x4E00;&#x6761;&#x8BC4;&#x8BBA; &#x2014; &#x53EF;&#x80FD;&#x662F; LGTM&#xFF08;&#x201C;&#x6211;&#x89C9;&#x5F97;&#x4E0D;&#x9519;&#x201D;&#xFF09;&#x8BC4;&#x8BBA;&#xFF0C;&#x6216;&#x8005;&#x7C7B;&#x4F3C;&#x7684;&#x5185;&#x5BB9;&#x3002;PR &#x88AB;&#x63A5;&#x53D7;&#x540E;&#xFF0C;Elastic &#x5F00;&#x53D1;&#x4EBA;&#x5458;&#x4F1A;&#x5C06; pull request &#x5408;&#x5E76;&#x5230;&#x4E3B;&#x5206;&#x652F;&#x4E2D;&#xFF0C;&#x7136;&#x540E;&#x6839;&#x636E;&#x9700;&#x8981;&#x5C06;&#x66F4;&#x6539;&#x8FD4;&#x56DE;&#x5230;&#x5F00;&#x53D1;&#x5206;&#x652F;&#x3002;
&#x7B80;&#x800C;&#x8A00;&#x4E4B;&#xFF0C;&#x8FD9;&#x5C31;&#x662F;&#x5B83;&#x7684;&#x5DE5;&#x4F5C;&#x539F;&#x7406;&#x3002;&#x5F53;&#x7136;&#xFF0C;Pull Request &#x5404;&#x4E0D;&#x76F8;&#x540C;&#x3002;&#x8FD9;&#x4E2A;&#x8FC7;&#x7A0B;&#x53EF;&#x80FD;&#x975E;&#x5E38;&#x7B80;&#x5355;&#xFF0C;&#x4E5F;&#x53EF;&#x80FD;&#x5F88;&#x56F0;&#x96BE;&#x3002;&#x60A8;&#x6DF1;&#x5165;&#x4E86;&#x89E3;&#x8FD9;&#x4E00;&#x8FC7;&#x7A0B;&#x7684;&#x552F;&#x4E00;&#x65B9;&#x6CD5;&#x662F;&#x5377;&#x8D77;&#x8896;&#x5B50;&#x4EB2;&#x81EA;&#x64CD;&#x4F5C;&#x3002;
&#x51C6;&#x5907;&#x597D;&#x63D0;&#x4EA4;&#x60A8;&#x7684;&#x7B2C;&#x4E00;&#x4EFD; PR &#x62A5;&#x544A;&#x4E86;&#x5417;&#xFF1F;&#x6D4F;&#x89C8; <a href="https://github.com/elastic">GitHub&#x4E0A;&#x63D0;&#x4F9B;&#x7684; Elastic &#x5B58;&#x50A8;&#x5E93;</a>&#xFF0C;&#x719F;&#x6089;&#x8FD9;&#x4E9B;&#x6307;&#x5357;&#xFF0C;&#x5E76;&#x5C1D;&#x8BD5;&#x4E00;&#x4E0B;&#x3002;&#x5982;&#x679C;&#x60A8;&#x5BF9;&#x8FD9;&#x4E2A;&#x8FC7;&#x7A0B;&#x6709;&#x4EFB;&#x4F55;&#x8FDB;&#x4E00;&#x6B65;&#x7684;&#x7591;&#x95EE;&#xFF0C;&#x90A3;&#x4E48;&#x5C31;&#x53BB;&#x6211;&#x4EEC;&#x7684;<a href="https://discuss.elastic.co/">&#x8BA8;&#x8BBA;&#x8BBA;&#x575B;</a>&#xFF0C;&#x5E76;&#x521B;&#x5EFA;&#x4E00;&#x4E2A;&#x4E3B;&#x9898;&#xFF0C;&#x6211;&#x4EEC;&#x4F1A;&#x5F88;&#x4E50;&#x610F;&#x63D0;&#x4F9B;&#x5E2E;&#x52A9;&#x3002; </body></html>

Debug.jpg

Code request.jpg

How We Handle Pull Requests at Elastic

我们如何处理 Elastic Pull Request

体验 Elastic 解决方案的所有优势，同时还能继续使用您的 Splunk 采集技术。在本篇博文中，我们将会向您介绍一种实验性集成，该集成可自动将通过 Splunk 采集的数据映射至 Elastic Common Schema。

随着组织从其现有供应商迁移至 Elastic，将日志数据从其当前解决方案快速上线至 Elastic 中是最重要的业务事项之一。数据上线通常涉及必须调整采集架构并跨数据源实施配置变更。我们想确保正在试用或迁移至 Elastic 的用户能够快速采集数据，从而尽早看到 Elastic 解决方案的强大性能。因此，我们构建了一个集成，该集成可自动将通过 Splunk 采集的数据映射至 <a href="https://www.elastic.co/guide/en/ecs/current/index.html">Elastic Common Schema</a> (ECS)。
在这篇博文中，我们将会向您介绍这一实验性 Splunk 集成（在 Elastic Stack 的 <a href="/cn/blog/whats-new-elastic-7-12-0-schema-on-read-frozen-tier-autoscaling">7.12 版本</a>中推出）。这一集成允许您保留自己的 <a href="https://docs.splunk.com/Documentation/Forwarder/8.2.0/Forwarder/Abouttheuniversalforwarder">Splunk 通用转发器</a>和其他 Splunk 采集技术，然后利用 Splunk API 将数据采集到 Elastic 中。这一集成目前支持采集 Apache、AWS Cloudtrail、NGINX、Windows Event Channels 和 Zeek 日志，但我们计划大幅度扩展所支持的数据源。
<h2>此集成的工作原理是什么？</h2>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc1c391d63e198a6b/60b7a54fe5c1e71981818d7b/1-integration-chart-blog-splunk-integration.png" data-sys-asset-uid="bltc1c391d63e198a6b" alt="1-integration-chart-blog-splunk-integration.png" />
此集成会利用 Elastic Agent 中的 <a href="/guide/en/beats/filebeat/current/filebeat-input-httpjson.html">HTTP JSON 输入</a>来通过 Splunk REST API 运行一个 Splunk 搜索，然后从结果中提取原始事件。然后会使用 Elastic Agent 和既有的 <a href="/cn/integrations">Elastic 集成</a>来处理这些原始事件。
<h2>配置集成</h2>
在本篇博文中，我们将会配置 Zeek 集成来从 Splunk 中检索既有事件。
我们需要执行的第一步是安装 Elastic Agent。它很容易部署而且支持所有常见操作系统。您可以在<a href="/guide/en/fleet/current/elastic-agent-installation.html">此处</a>查看安装 Elastic Agent 并将其加入 Fleet 的步骤。
接下来，我们将会创建一个政策并添加 Zeek 集成。配置“第三方 REST API 输入”。您需要您的 Splunk Enterprise Server 的 URL 和凭据才能访问此 API。因为 Splunk 搜索是可定制的，所以搜索间隔也是可定制的。还可以添加标签来表明日志是通过 Splunk 转发过来的。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt64753a047a6cf7b1/60b7a576166608198786536f/2-integration-chart-blog-splunk-integration.png" data-sys-asset-uid="blt64753a047a6cf7b1" alt="2-integration-chart-blog-splunk-integration.png" />
如您在下面的截图中所见，我们已经将 Zeek 日志流式传输到 Splunk 中：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt55f79eed1822bcf9/60b7a5844d715a2522582ea5/3-integration-chart-blog-splunk-integration.png" data-sys-asset-uid="blt55f79eed1822bcf9" alt="3-integration-chart-blog-splunk-integration.png" /> 
因为启用了此 Splunk 集成，这些日志现在已经出现在 Elastic 中了：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2da2c58475f02ca9/60b7a58d4d715a2522582ea9/4-integration-chart-blog-splunk-integration.png" data-sys-asset-uid="blt2da2c58475f02ca9" alt="4-integration-chart-blog-splunk-integration.png" />
<h2>Splunk + Elastic Common Schema</h2>
现在来到了最棒的一部分，通过 Splunk 采集的所有数据都会自动映射至 <a href="/guide/en/ecs/current/index.html">Elastic Common Schema</a> (ECS)。这意味着您可以立即开始使用诸如 Elastic 安全和 Elastic 可观测性等 Elastic 解决方案，而无需操心需要手动将您的数据从 Splunk 的 <a href="https://docs.splunk.com/Documentation/CIM/4.19.0/User/Overview">Common Information Model</a> 映射至 ECS。&nbsp;
分析内容（例如 Machine Learning 作业、检测规则和可视化）都能正常运行！举个例子，下面是一个 Zeek 仪表板，其中完全填充了通过 Splunk 所采集的 Zeek 数据：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt32d105914a2b02f5/60b7a59b8bf36608f2c02c85/5-integration-chart-blog-splunk-integration.png" data-sys-asset-uid="blt32d105914a2b02f5" alt="5-integration-chart-blog-splunk-integration.png" />
我们希望试用 Elastic 的所有用户都能受益于这一集成。我们的目的是确保您花较少的时间来配置将数据采集至 Elastic 的过程，并允许您快速从我们的解决方案中收获价值。您可以在<a href="https://www.elastic.co/guide/en/observability/7.13/ingest-splunk.html">此处</a>查看与该集成相关的文档。我们十分热切地希望听到您有关这个 Splunk 集成的反馈。请在 <a href="https://discuss.elastic.co/">Elastic Discuss 论坛</a>上或者在 <a href="/cn/blog/join-our-elastic-stack-workspace-on-slack">Elastic Slack 工作空间</a>内告诉我们您的想法。而且如果您一直在期待着像这样的集成但还没有试用 Elastic，现在就是试用的绝佳机会：开始 <a href="https://cloud.elastic.co/registration?elektra=en-security-page">14 天免费试用</a>（无需信用卡），或免费<a href="/cn/downloads/">下载我们的产品</a>，用于您的本地部署。充分利用我们的<a href="/cn/training/elastic-security-quick-start">快速入门培训</a>，为您的成功保驾护航。

ecs-blog-image-banner.jpg

How-to & features

Migrating

Stack

Security

ecs-blog-thumb.jpg

Easily ingest data to Elastic via Splunk

通过 Splunk 轻松将数据采集到 Elastic 中

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

Elasticsearch

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

Kibana

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 可视化入门

Elasticsearch from the Bottom Up, Part 1

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

了解如何开始使用最新的 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

Deep dives

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，其具备内置的反恶意软件和数据收集、预建的云保护、增强的分析人员工作流、扩展的数据收集和分析。

blog-banner-release-security.png

blog-thumb-release-security.png

Elastic Security 7.9 delivers malware prevention for every endpoint, prebuilt cloud protections, and more

Elastic Security 7.9 新增反恶意软件、预建的云保护等

了解与现有 Elasticsearch 数据层相比，新冻结层的搜索性能如何，以及如何使用冻结层存储和搜索大量数据。

blog-banner-tree-icicles.jpg

Scaling

blog-thumb-tree-icicles.jpg

Querying a petabyte of cloud storage in 10 minutes

10 分钟内查询一个 PB 级的云存储

了解从自管型 Elasticsearch 迁移至 Elastic Cloud 有多容易。减少在配置、管理、扩展和升级方面花费的时间，让您有更多时间发掘 Elasticsearch 的强大功能。

我们看到越来越多的客户将本地部署工作负载迁移到云端。Elasticsearch 已经有好几年的历史，我们的用户和客户通常都在本地部署中自行管理。<a href="/cn/cloud">Elastic Cloud 上的 Elasticsearch Service</a>（我们的托管型 <a href="/cn/elasticsearch/service">Elasticsearch 服务</a>）运行于许多不同地区的 Amazon Web Services (AWS)、Google Cloud 和 Microsoft Azure 上，是使用 Elastic Stack 和我们的企业搜索、可观测性和安全解决方案的最佳方式。
如果您想改变自行管理 Elasticsearch 的现状，Elasticsearch Service 将负责以下事项：
<ul>
	<li>配置和管理底层基础架构</li>
	<li>创建和管理 Elasticsearch 集群</li>
	<li>扩展和缩减集群</li>
	<li>升级、打补丁和创建快照</li>
</ul>这会让您有更多的时间和精力去解决其他的挑战。
这篇博文探讨了迁移到 Elasticsearch Service 的方法，即通过为 Elasticsearch 集群创建快照，然后在 Elasticsearch Service 上还原快照来完成迁移。
<h2>创建集群快照</h2>从自管型 Elasticsearch 迁移到 Elasticsearch Service 时，首先要考虑的是您希望使用哪个云服务提供商以及要部署到的区域。这通常取决于您部署的现有工作负载、云策略以及一系列其他因素。
下面我们将介绍适用于迁移到 AWS 上的 Elasticsearch Service 的过程。之后，针对 Google Cloud 和 Azure 的迁移过程也将很快发布。
将 Elasticsearch 集群数据移动到另一个集群的最简单方法是：创建集群的快照，然后使用该快照将数据还原到新的 Elasticsearch Service 集群中。
执行集群快照的方法有多种。最简单的是执行一次性快照操作。
假设您的 Elasticsearch 不断地采集数据，一次性快照操作的缺点是，在创建快照和在新集群中还原快照之间存在时间延迟，这可能会造成数据丢失。为了最大限度地减少这种滞后，建议创建<a href="https://www.elastic.co/guide/en/elasticsearch/reference/7.10/getting-started-snapshot-lifecycle-management.html">快照生命周期策略</a>。如果您的 Elasticsearch 集群不经常采集数据，例如用于搜索用例，那么一次性快照完全可以胜任。
在创建本地集群快照之前，您需要配置将存储本地集群快照的 AWS S3 存储桶。在 AWS 上运行的新 Elasticsearch Service 集群将从该存储桶还原集群状态。
为此，需要完成以下几大步骤：
<ul>
	<li>配置云存储（在本例中为 AWS S3 存储桶）</li>
	<li>配置本地快照存储库</li>
	<li>设置快照策略</li>
	<li>在 Elasticsearch Service 上配置新集群</li>
	<li>配置 Elasticsearch Service 集群自定义快照存储库</li>
	<li>从本地快照还原 Elasticsearch Service 集群</li>
</ul><h2>配置云存储</h2><a href="https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html"></a><ol><a href="https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html"></a>
	<li><a href="https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html"></a><a href="https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html">创建 S3 存储桶</a>。S3 存储桶应位于为您的 Elasticsearch Service 集群所选的同一区域中： <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt8935ff7473d9beb0/5ff3995f1166ce7d2ed1b6f7/blog-on-prem-to-ec-aws-1.png" data-sys-asset-uid="blt8935ff7473d9beb0" alt="" style="display: block; margin: auto;"></li>
	<li><a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor">通过 JSON 选项卡创建 S3 存储桶策略</a>并<a href="https://www.elastic.co/guide/en/cloud/current/ec-aws-custom-repository.html#ec-aws-custom-repository">添加 S3 存储桶策略 JSON</a>（使用您的存储桶名称）： <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt142d493b1f46f263/5ff499298884c20ac3ca657a/blog-on-prem-to-ec-aws-1a.png" data-sys-asset-uid="blt142d493b1f46f263" alt="" style="display: block; margin: auto;"></li>
	<li>单击复查策略并为您的策略命名： <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt05212dc5cd32b31e/5ff4994ea00f8977b72365e5/blog-on-prem-to-ec-aws-1b.jpg" data-sys-asset-uid="blt05212dc5cd32b31e" alt="" style="display: block; margin: auto;"></li>
	<li><a href="https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html#access_policies_create-json-editor">创建 IAM 用户</a>并指定上面创建的 S3 存储桶策略： <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1a8e8e67a7c227ac/5ff4995ea703d10ab87eaf92/blog-on-prem-to-ec-aws-1c.png" data-sys-asset-uid="blt1a8e8e67a7c227ac" alt="" style="display: block; margin: auto;"></li>
	<li>单击下一步：权限，选择直接附加现有策略，然后查找您在上一步中创建的策略： <img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf88ad4e6e9137f66/5ff49984e7fdff751b7950db/blog-on-prem-to-ec-aws-1d.png" data-sys-asset-uid="bltf88ad4e6e9137f66" alt="" style="display: block; margin: auto;"></li>
	<li>确保勾选这个策略，然后单击下一步：标签。 您可以跳过添加标签这一步并单击创建用户。</li>
	<li>下载用户安全凭证。</li>
</ol><h2>配置本地快照存储库</h2><h3>1. 安装 S3 插件
</h3>通过在 Elasticsearch 主目录中的每个本地 Elasticsearch 节点上运行以下命令，在您的本地部署中安装 Elasticsearch S3 插件：
<pre class="prettyprint">sudo bin/elasticsearch-plugin install repository-s3
</pre>运行此命令后，您必须重新启动节点。
<h3>2. 配置 S3 客户端权限</h3>通过运行以下命令配置本地部署集群 S3 客户端权限：
<pre class="prettyprint">bin/elasticsearch-keystore add s3.client.default.access_key
</pre><pre class="prettyprint">bin/elasticsearch-keystore add s3.client.default.secret_key
</pre>这一步是必需的，这样本地集群才能获得将快照写入 S3 所需的凭证。Access_key 和 secret_key 可从上一步中创建的 IAM 用户处获得。
<h2>设置快照策略</h2><h3>1. 配置快照存储库</h3>通过在 <a href="https://www.elastic.co/guide/en/kibana/7.10/console-kibana.html">Kibana 开发工具</a>中运行以下命令，在本地集群中配置 S3 快照存储库。我们在这里告诉本地集群要将快照写入哪个 S3 存储桶。您刚刚创建的 IAM 用户应具有读写这个 S3 存储桶的权限。
<pre class="prettyprint">PUT _snapshot/<my_s3_repository>
{
 "type": "s3",
 "settings": {
 "bucket": "<bucket-name>"
 }
}
</pre><h3>2. 创建快照策略</h3>接下来，您将在本地集群中创建快照策略，将快照存储在新创建的 S3 存储桶中：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltbcbd67f92515dcef/5ff399f002fd0c7d345f3f4e/blog-on-prem-to-ec-aws-4.png" data-sys-asset-uid="bltbcbd67f92515dcef" alt="" style="display: block; margin: auto;">
您也可以在 Kibana 开发工具中创建一次性快照：
<pre class="prettyprint">PUT /_snapshot/<your repo_name>/<your_snapshotname>?wait_for_completion=true
{
 "indices": "*",
 "ignore_unavailable": true,
 "include_global_state": false
}
</pre>通过在开发工具中运行以下命令，验证快照是否正常运行：
<pre class="prettyprint">GET _snapshot/<your_repo_name>/_all
</pre><h2>在 Elasticsearch Service 上配置新集群</h2>一旦我们在 S3 上存储了快照，就可以在 Elasticsearch Service (<a href="https://cloud.elastic.co">cloud.elastic.co</a>) 上配置新集群了。您可以在此处选择最能反映您的现有工作负载、AWS 区域和 Elasticsearch 版本的用例。 
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1f2ac344fc6a7ff5/5ff39a1cb80b0a1a68fa1b8e/blog-on-prem-to-ec-aws-5.png" data-sys-asset-uid="blt1f2ac344fc6a7ff5" alt="" style="display: block; margin: auto;">
在 Elasticsearch Service 控制台中，配置集群密钥库设置：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf947e9a6eaf104c7/5ff39a30a00f8977b72361fb/blog-on-prem-to-ec-aws-6.png" data-sys-asset-uid="bltf947e9a6eaf104c7" alt="" style="display: block; margin: auto;">
我们需要配置以下两个设置：
<pre class="prettyprint">s3.client.default.access_key
s3.client.default.secret_key
</pre>这一步是必需的，这样 Elasticsearch Service 集群才能获得从 S3 存储桶读取快照的权限。这些密钥将与 IAM 用户安全凭证的作用相同。
<h2>配置 Elasticsearch Service 集群自定义快照存储库</h2>现在，我们必须在 Elasticsearch Service 集群上创建一个新的快照存储库。这会告诉 Elasticsearch Service 我们要还原的快照位于 S3 中的哪个位置。为此，请登录 Kibana，选择堆栈管理，然后导览到“快照和还原”设置。选择注册存储库：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5e29fd219930b396/5ff39a8a1ebd9777b16915f0/blog-on-prem-to-ec-aws-7.png" data-sys-asset-uid="blt5e29fd219930b396" alt="" style="display: block; margin: auto;">
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt779ffd3e39d1a89d/5ff39a908884c20ac3ca61a6/blog-on-prem-to-ec-aws-8.png" data-sys-asset-uid="blt779ffd3e39d1a89d" alt="" style="display: block; margin: auto;">
添加快照所在的存储桶名称：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt72da87c79799e9f5/5ff39aaf1ebd9777b16915f4/blog-on-prem-to-ec-aws-9.png" data-sys-asset-uid="blt72da87c79799e9f5" alt="" style="display: block; margin: auto;">
然后验证存储库是否已正确配置：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt2b5e3679e861ce44/5ff39ac2a7955d1a6a8925d8/blog-on-prem-to-ec-aws-10.png" data-sys-asset-uid="blt2b5e3679e861ce44" alt="" style="display: block; margin: auto;">
最后，确认 Elasticsearch Service 集群可以看到我们要还原的快照：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltbe9b4262a466a40b/5ff39adb1ebd9777b16915fc/blog-on-prem-to-ec-aws-11.png" data-sys-asset-uid="bltbe9b4262a466a40b" alt="" style="display: block; margin: auto;">
<h2>从快照还原 Elasticsearch Service 集群</h2>要还原快照，请在 Elasticsearch Service 控制台中前往 Elasticsearch Service 集群 API 控制台，执行以下三个命令。请注意，所有三个命令都在 API 控制台中以 POST 的形式执行。
<h3>关闭所有索引
</h3><pre class="prettyprint">*/_close?expand_wildcards=all
</pre>这一步是为了确保先关闭所有索引，这样在还原阶段就不会发生冲突：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdf5a2453c8da98c3/5ff39b1cb08361084bffca4b/blog-on-prem-to-ec-aws-12.png" data-sys-asset-uid="bltdf5a2453c8da98c3" alt="" style="display: block; margin: auto;">
<h3>还原快照</h3><pre class="prettyprint">/_snapshot/<your-repo-name>/<your-snapshot-name>/_restore
</pre>这个命令会还原快照：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0ea03e5e653d3df0/5ff39b2cb529867fcec273fd/blog-on-prem-to-ec-aws-13.png" data-sys-asset-uid="blt0ea03e5e653d3df0" alt="" style="display: block; margin: auto;">
<h3>打开所有索引</h3><pre class="prettyprint">*/_open?expand_wildcards=all
</pre>这个命令会打开所有索引：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf845ceca20417a26/5ff39b516aab641cd100e5a8/blog-on-prem-to-ec-aws-14.png" data-sys-asset-uid="bltf845ceca20417a26" alt="blog-on-prem-to-ec-aws-14.png">
<h2>验证快照还原</h2>验证您是否已使用所有索引还原了快照。进入 Kibana 并在开发工具中运行以下命令：
<pre class="prettyprint">GET _cat/indices
</pre>此时，您的新集群应该已经在 Elasticsearch Service 上运行，其中的数据与您从中创建快照的自管型集群中的数据相同。现在，您可以将 Beats 或 Logstash 等采集源重新指向新的 Elasticsearch Service 终端，并且可以在 Elastic Cloud 控制台中找到该终端。
<h2>立即迁移到 Elastic Cloud</h2>通过快照将自管型 Elasticsearch 集群迁移到 Elastic Cloud 上的 Elasticsearch Service 是一个比较容易的过程。虽然自行管理 Elasticsearch 很有趣，但 Elasticsearch Service 代您管理 Elasticsearch 集群的所有繁重工作，可让您有时间做更重要的事情。详细了解<a href="/cn/elasticsearch/service/migrate-to-elastic-cloud">迁移到 Elastic Cloud 的益处</a>，或立即注册 <a href="https://cloud.elastic.co/registration">14 天免费试用</a>。

blog-banner-cloud-aws.png

Cloud

blog-thumb-cloud-aws.png

How to migrate from self-managed Elasticsearch to Elastic Cloud on AWS

如何从自管型 Elasticsearch 迁移至 AWS 上的 Elastic Cloud

学习如何建立从 Google Operations 到 Elastic Stack 的数据流式传输管道，获得跨整个基础架构（从云端到本地部署）的统一资源性能视图。

Google Operations 套件（此前为 Stackdriver）是一个中央存储库，从 Google Cloud 资源接收日志、指标和应用程序跟踪数据。这些资源可以包括计算引擎、应用引擎、Dataflow、Dataproc 及其 SaaS 产品与服务，例如 BigQuery 等。&nbsp; 通过向 Elastic 传输该数据，就可以获得跨整个基础架构（从云端到本地部署）的统一资源性能视图。&nbsp;
本博文中，我们将建立一个从 Google Operations 到 <a href="/cn/elastic-stack">Elastic Stack</a> 的数据流式传输管道，便于您分析 Google Cloud 日志以及其他可观测性数据。本演示中，我们将使用 Filebeat <a href="/guide/en/beats/filebeat/7.9/filebeat-module-googlecloud.html">Google Cloud 模块</a>将 Google Cloud 数据传输到<a href="/cn/elasticsearch/service">免费试用版 Elastic Cloud</a> 中进行分析。大家要跟上哦！
<h2>高级别数据流</h2>本演示中，我们将从 Google Cloud 资源向 Google Cloud Operations 传输审计、防火墙和 VPC 流日志。接着我们将创建接收器、Pub/Sub 主题，由 Filebeat 订阅，并将数据传输到 Elastic Cloud，再使用 Elasticsearch 和 Kibana 做进一步的分析。此示意图提供了数据流概览，说明了数据进入我们集群的路径：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte779b78963dac852/5f773e52bd99c90e9ce906ef/google-operations-blog-data-path.png" data-sys-asset-uid="blte779b78963dac852" alt="进入我们 Elasticsearch 集群的数据流" "="">
<h2>Google Cloud 日志设置和配置</h2>Google Cloud 为启用服务日志提供一个富 UI，而这些日志都会在独立的控制台中进行配置。在下面的步骤中，我们将启用多个日志，创建接收器和主题，然后设置服务账号和凭据。
 <h3>VPC 流日志</h3>进入 VPC 网络页面，选择一个 VPC，然后从流日志下拉列表中单击配置，即可启用 VPC 流日志。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt928dde8480514330/5f773e7fdac9270efe35f682/google-operations-blog-vpc-flow-logs.png" data-sys-asset-uid="blt928dde8480514330" alt="流日志下拉列表" style="display: block; margin: auto; width: 500px;">
虽然价格不是特别昂贵，但运维本身也会增加成本，所以请根据自己的要求选择聚合时间间隔和采样速率。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt84e3bfe9410e4467/5f773e9ced21e20f14409075/google-operations-blog-flow-logs-agg-interval.png" data-sys-asset-uid="blt84e3bfe9410e4467" alt="VPC 流日志可能会增加成本" style="display: block; margin: auto; width: 500px;">
<h3>审计日志</h3>审计日志可以在 IAM 和管理菜单中进行配置：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1e4aef1279fdd55c/5f773eb6af58110efed268d7/google-operations-blog-audit-logs.png" data-sys-asset-uid="blt1e4aef1279fdd55c" alt="审计日志配置" style="display: block; margin: auto; width: 500px;">
<h3>防火墙日志</h3>最后，防火墙日志可在防火墙规则中进行控制：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta75222c53c133cb1/5f773eccbe6df80f0910b47f/google-operations-blog-firewall-logs.png" data-sys-asset-uid="blta75222c53c133cb1" alt="防火墙日志配置" style="display: block; margin: auto; width: 500px;">
<h3>日志接收器和 Pub/Sub</h3>配置完成各日志区域后，便可在日志查看器中为每个日志创建接收器：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt9831df9c6d913ebe/5f773ee09d46c20f09175a0c/google-operations-blog-logs-viewer.png" data-sys-asset-uid="blt9831df9c6d913ebe" alt="日志查看器" "="">
如下所示，为接收器服务选择 Cloud PubSub 主题。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1322ec4ebbb01464/5f773ef34b7a2b0e86b02ce0/google-operations-blog-sink-service.png" data-sys-asset-uid="blt1322ec4ebbb01464" alt="选择接收器服务" style="display: block; margin: auto; width: 500px;">
然后提供接收器名称和 Pub/Sub 主题，可以将其发送至已有主题，也可以创建新主题：
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt95686523f0af7ebd/5f773f06df178b0ea9847523/google-operations-blog-edit-sink.png" data-sys-asset-uid="blt95686523f0af7ebd" alt="编辑接收器" style="display: block; margin: auto; width: 500px;">
接收器和主题创建完成后，下面开始创建 Pub/Sub 主题订阅：

<table style="border:none; text-align:center; width:100%">
<tbody>
<tr>
	<td style="border:none; vertical-align:middle;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5257eae1ea6eea86/5f773f1ee69fa40ef3181b07/google-operations-blog-subscriptions.png" data-sys-asset-uid="blt5257eae1ea6eea86" alt="创建订阅" style="display: block; margin: auto; width: 500px;">
	</td>
	<td style="border:none; vertical-align:middle;"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt855e039c0aab327d/5f773f4af11ee70e9e14cee4/google-operations-blog-add_subscription-to-topic.png" data-sys-asset-uid="blt855e039c0aab327d" alt="增加主题订阅" style="display: block; margin: auto; width: 500px;">
	</td>
</tr>
</tbody>
</table>根据您的要求配置订阅。
<h3>服务账号和凭据</h3>最后但也很重要，我们要创建一个服务账号和凭据文件。
选择 Pub/Sub 编辑器角色；条件可选并可用于筛选主题。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blte974c709d3cb691b/5f773f5fe69fa40ef3181b0b/google-operations-blog-create-service-account.png" data-sys-asset-uid="blte974c709d3cb691b" alt="创建服务账号" style="display: block; margin: auto; width: 500px;">
服务账号创建完成后，我们将生成一个 JSON 密钥，上传至 Filebeat 主机，并存储在 Filebeat 配置目录 <code>/etc/filebeat</code> 中。Filebeat 将使用该密钥来验证服务账号。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt37d495d0e6d67ecc/5f773f77879de80eb41afe58/google-operations-blog-create-private-key.png" data-sys-asset-uid="blt37d495d0e6d67ecc" alt="创建私有密钥" style="display: block; margin: auto; width: 500px;">
现在我们已经完成了 Google Cloud 配置。
 <h2>安装和配置 Filebeat</h2>Filebeat 用于收集日志并传输到我们的 Elasticsearch 集群中。在本博文中，我们将使用 CentOS，但您也可以根据自己的操作系统安装 Filebeat，只需按照<a href="/guide/en/beats/filebeat/7.9/filebeat-installation-configuration.html">我们 Filebeat 文档中的简单步骤操作即可</a>。
 <h3>启用 Google Cloud 模块</h3>Filebeat 安装完成后，我们需要启用 <code>googlecloud</code> 模块：
<pre class="prettyprint">filebeat modules enable googlecloud
</pre>将此前创建的 JSON 凭据文件复制到 <code>/etc/filebeat/</code>，然后修改 <code>/etc/filebeat/modules.d/googlecloud.yml</code> 文件，使之匹配您的 Google Cloud 设置。
部分配置已完成；例如所有三个模块均已列出，所有需要的配置也已键入，您只需要根据自己的设置更新成相应的值即可。
<pre class="prettyprint"># 模块：googlecloud
# 文档：https://www.elastic.co/guide/en/beats/filebeat/7.9/filebeat-module-googlecloud.html
- module: googlecloud
 vpcflow:
 enabled: true
 # Google Cloud 项目 ID。
 var.project_id: els-dummy
 # 包含 VPC 流日志的 Google Pub/Sub 主题。Stackdriver 必须
 # 加以配置，将该主题用作 VPC 流日志的接收器。
 var.topic: els-gcp-vpc-flow-logs
 # 针对该主题的 Google Pub/Sub 订阅。Filebeat 将创建
 # 该订阅（如果订阅不存在）。
 var.subscription_name: els-gcp-vpc-flow-logs-sub
 # 针对服务账号的凭据文件，以及
 # 订阅读取授权。
 var.credentials_file: /etc/filebeat/kdr-gcp-logs-sa-editor-only.json
 firewall:
 enabled: true
 # Google Cloud 项目 ID。
 var.project_id: els-dummy
 # 包含防火墙日志的 Google Pub/Sub 主题。Stackdriver 必须
 # 加以配置，将该主题用作防火墙日志的接收器。
 var.topic: els-gcp-firewall-logs
 # 针对该主题的 Google Pub/Sub 订阅。Filebeat 将创建
 # 该订阅（如果订阅不存在）。
 var.subscription_name: els-gcp-firewall-logs-sub
 # 针对服务账号的凭据文件，以及
 # 订阅读取授权。
 var.credentials_file: /etc/filebeat/kdr-gcp-logs-sa-editor-only.json
 audit:
 enabled: true
 # Google Cloud 项目 ID。
 var.project_id: els-dummy
 # 包含审计日志的 Google Pub/Sub 主题。Stackdriver 必须
 # 加以配置，将该主题用作防火墙日志的接收器。
 var.topic: els-gcp-audit-logs
 # 针对该主题的 Google Pub/Sub 订阅。Filebeat 将创建
 # 该订阅（如果订阅不存在）。
 var.subscription_name: els-gcp-audit-logs-sub
 # 针对服务账号的凭据文件，以及
 # 订阅读取授权。
 var.credentials_file: /etc/filebeat/kdr-gcp-logs-sa-editor-only.json
</pre>最后是配置 Filebeat，使之指向您的 Kibana 和 Elasticsearch 终端。
可按照 <a href="/guide/en/beats/filebeat/7.9/setup-kibana-endpoint.html">Kibana</a> 和 <a href="/guide/en/beats/filebeat/7.9/elasticsearch-output.html">Elasticsearch</a> 终端文档，在 <code>filebeat.yml</code> 文件中设置 <code>setup.dashboards.enabled: true</code>，以便加载适用于 Google Cloud 的预创建仪表板。
请注意，Filebeat 提供各种配有预创建仪表板的模块。本博文中我们只看一下 Google Cloud 模块的情况，但您完全可以探索其他<a href="/guide/en/beats/filebeat/7.9/filebeat-modules.html">可用 Filebeat 模块</a>，了解可能适用于自己的资源。
 <h3>启动 Filebeat</h3>最后，我们可以启动 Filebeat，并添加 <code>-e</code> 旗标，使之轻松将日志输出至控制台：
<pre class="prettyprint">sudo service filebeat start -e
</pre><h2>Kibana 中的数据探索</h2>现在 Filebeat 正在向您的集群传输数据，我们在 Kibana 边栏导航中找到仪表板，如果有其他模块的仪表板，可以搜索 <code>google</code> 找到新启用模块的仪表板。本例中，我们将看到 Google Cloud“审计”仪表板。
此仪表板中您会看到源位置动态映射、随时间推移的事件结果、事件操作细目等可视化内容。通过这些预创建的交互型可视化内容，可非常直观地探索日志数据。如果是首次设置 Filebeat，或者运行较老版本的 Elastic Stack（Google Cloud 模块在 7.7 GA 版本中就已添加），则需要按照以下<a href="/guide/en/beats/filebeat/7.9/load-kibana-dashboards.html">说明</a>下载仪表板。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6f811a846debd0fe/5f7740b702e6b80ebf9002fa/google-operations-blog-kibana-dashboard.png" data-sys-asset-uid="blt6f811a846debd0fe" alt="Kibana 中的数据探索" "="">
此外，Elastic 还通过<a href="/cn/log-monitoring">日志监测应用程序</a>提供<a href="/cn/observability">可观测性</a>解决方案。日志索引可进行配置；默认值为 <code>filebeat-*</code> 和 <code>logs-*</code>。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt830f0aca061c7c87/5f7741214b7a2b0e86b02cfc/google-operations-blog-log-settings.png" data-sys-asset-uid="blt830f0aca061c7c87" alt="Logs 应用中的日志设置" "="">
在设置中配置完成正确的索引模式后，便可以在 Logs 应用中探索日志，其允许查看日志详细信息，更重要的是，还可以为异常行为定义 Machine Learning 工作、分类数据并<a href="/guide/en/kibana/7.9/alerting-getting-started.html">创建警报</a>。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc7b8470582955f9b/5f7760b6df178b0ea984762b/google-operations-blog-elastic-logs-app.png" data-sys-asset-uid="bltc7b8470582955f9b" alt="Elastic Logs 应用" style="display: block; margin: auto; width:500px;">
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt56a422d6f7648d6f/5f774764df178b0ea98475ab/google-operations-blog-edit-alert.png" data-sys-asset-uid="blt56a422d6f7648d6f" alt="编辑警报" style="display: block; margin: auto; width:500px;">
<h2>拓展 Google Operations (stackdriver) 日志</h2>上面我们讨论了如何为那些具有 Filebeat 模块的日志传输运维日志，但其他没有专属 Filebeat 模块的日志呢？接下来我们讨论如何将这些日志也传输到 Elastic 中，以便与其他日志数据一同查看。
从 Google Cloud 设置和配置角度而言，包括流在内的所有内容都没有变动。我们创建接收器、主题、订阅、sa 以及 JSON 密钥。差别仅在于 Filebeat 配置上。
后台运行时，模块的运行要依靠输入和预配置、来源级别解析以及某些情况下的采集管道。Filebeat 模块会简化常见日志格式的收集、解析和可视化，但对于 Filebeat 输入，有时则需要额外解析。
<code>googlecloud</code> 模块使用底层的 <code>google-pubsub</code> 输入，并提供一些模块特定的采集管道。它支持直接使用 <code>vpcflow</code>、<code>audit</code>和<code>防火墙</code>日志。
<h3>配置</h3>我们将使用 Filebeat 输入来订阅这些主题，而不是 Filebeat 模块。
向您的 <code>filebeat.yml</code> 文件中添加：
<pre class="prettyprint">filebeat.inputs:
- type: google-pubsub
 enabled: true
 pipeline: gcp-pubsub-parse-message-field
 tags: ["gcp-pubsub"]
 project_id: elastic-consulting
 topic: gcp-gke-container-logs
 subscription.name: gcp-gke-container-logs-sub
 credentials_file: /etc/filebeat/kdr-gcp-logs-sa-editor-only.json
</pre>我们在该输入中指定拉取的主题以及要使用的订阅。同时也指定随后会定义的凭据文件和采集管道。
<h3>采集管道</h3><a href="/guide/en/elasticsearch/reference/7.9/ingest.html">采集管道</a>就是一系列按照声明的相同顺序而执行的处理器。
Google Cloud Operations 是以 JSON 格式存储日志和消息体，也意味着只需要在管道中添加一个 JSON 处理器，就可以将消息字段中的数据提取到 Elasticsearch 的单独字段。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blta416fd4cd4b3311a/5f77425602e6b80ebf900304/google-operations-blog-edit-pipeline.png" data-sys-asset-uid="blta416fd4cd4b3311a" alt="编辑管道" style="display: block; margin: auto; width: 500px;">
在该管道中，我们有一个 JSON 处理器，其从文件<code>消息</code>字段中收集数据，并提取到称为<code>日志</code>的目标字段中。&nbsp;
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltee98254bbf66c245/5f774267e69fa40ef3181b27/google-operations-blog-configure-processor.png" data-sys-asset-uid="bltee98254bbf66c245" alt="配置处理器" style="display: block; margin: auto; width: 500px;">
同时还有一个 Failure 处理器，用于处理该管道中的异常，我们在这里附加一个标签。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt369049ad50d5adc7/5f774280bd99c90e9ce9071d/google-operations-blog-configure-on-failure-processor.png" data-sys-asset-uid="blt369049ad50d5adc7" alt="配置 on-failure 处理器" style="display: block; margin: auto; width: 500px;">
从 7.8 版本开始，就已经支持从 Kibana 的 UI 创建采集管道，路径为 Stack Management → Ingest Node Pipelines。如果使用的是较早期版本，可使用 API。以下是该管道适用的等效 API。
<pre class="prettyprint">PUT _ingest/pipeline/gcp-pubsub-parse-message-field 
{ 
 "version":1,
 "description":"Parse message field coming from Google pub Sub Input",
 "processors": [ 
 { 
 "json": { 
 "field": "message",
 "target_field": "log",
 "description":"Parse message field" 
 } 
 } 
 ],
 "on_failure": [ 
 { 
 "append": { 
 "field": "tags",
 "value": [ 
 "gcp-pubsub-message-parse-failure" 
 ],
 "description":"Append parsing failure to tag" 
 } 
 } 
 ] 
}
</pre>我们将保存此管道，只要在 google-pubsub 输入中配置有相同的管道，便可在 Kibana 中开始查看解析的日志。
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltadae0da0051c44ec/5f774299f11ee70e9e14cf0c/google-operations-blog-parsed-logs.png" data-sys-asset-uid="bltadae0da0051c44ec" alt="Kibana 中的解析日志" "="">
标记为红色的字段（消息字段）将解析到日志字段中，所有子字段将被进一步嵌套，标记为绿色。
也可以选择使用删除处理器，删除采集管道 JSON 中处理器之后的消息字段；如此可缩小文件大小。
<h2>总结</h2>以上就是本博文的全部内容，感谢阅读。如有问题，请在我们的<a href="https://discuss.elastic.co">讨论论坛</a>中进行交流；欢迎提问。或者可以在我们的点播网络研讨会中深入了解 <a href="/cn/webinars/introduction-elk-stack">Elastic 日志和可观测性</a>相关内容。
如果想要尝试本演示操作，可在 <a href="/cn/elasticsearch/service">Elastic Cloud 上注册免费试用版 Elasticsearch Service </a>或者<a href="/cn/start">下载最新版本</a>自行管理。

blog-banner-cloud-gcp.png

Monitoring

blog-thumb-cloud-gcp.png

Monitoring Google Cloud with the Elastic Stack and Google Operations

使用 Elastic Stack 和 Google Operations 监测 Google Cloud

深入了解最常见的将数据采集到 Elasticsearch 服务的方法，以及针对各种用例的设置帮助和建议。

对于数据搜索和分析来说，Elasticsearch 无处不在。开发人员和社区可利用 Elasticsearch 寻找寻找各种各样的用例，从<a href="/cn/app-search">应用程序搜索</a>和<a href="/cn/site-search">网站搜索</a>，到日志、<a href="/cn/infrastructure-monitoring">基础架构监测</a>、<a href="/cn/apm">APM</a> 和 <a href="/cn/siem">安全分析</a>，不一而足。虽然现在有针对这些用例的免费解决方案，但是开发人员首先需要将其数据提供给 Elasticsearch。
本文将描述几种最常见的将数据采集到 Elasticsearch 服务的方法。这可能是一个托管在 <a href="https://cloud.elastic.co">Elastic Cloud</a> 或其本地方案 <a href="/cn/ece">Elastic Cloud Enterprise</a> 上的集群。虽然我们主要关注于这些服务，但采集到自管型 Elasticsearch 集群的数据看起来几乎是相同的。唯一的变化是您处理集群的方式。
在我们深入探讨技术细节之前，提醒一下：如果您在阅读本文时遇到任何问题，请随时访问 <a href="https://discuss.elastic.co">discuss.elastic.co</a>。我们的社区非常活跃，您有望会在那里找到问题的答案。
接下来，我们开始使用以下方法来深入探讨数据采集：
<ul>
	<li>Elastic Beats</li>
	<li>Logstash</li>
	<li>语言客户端</li>
	<li>Kibana 开发工具</li>
</ul> <h2>采集到 Elasticsearch 服务</h2>Elasticsearch 提供了灵活的 RESTful API，用于与客户端应用程序通信。因此，REST 调用被用来采集数据、执行搜索和数据分析，以及管理集群及其索引。实际上，上述所有方法都依赖于这个 API 将数据采集到 Elasticsearch。
在本文后续介绍中，我们假设您已经创建了 Elasticsearch 服务集群。如果您还没有创建，请<a href="/cn/cloud/elasticsearch-service/signup">注册 Elastic Cloud 免费试用</a>。在您创建集群后，系统将会为您提供 Elastic 超级用户帐户的云 ID 和密码。云 ID 的格式如下：<code>cluster_name:ZXVy...Q2Zg==</code>。它对您集群的 URL 进行了编码，并且我们将会看到，它可简化数据采集。
 <h3>Elastic Beats</h3>Elastic Beats 是一组轻量型的数据采集器，可以方便地将数据发送给 Elasticsearch 服务。由于是轻量型的，Beats 不会产生太多的运行时开销，因此，可以在硬件资源有限的设备（如 IoT 设备、边缘设备或嵌入式设备）上运行和收集数据。如果您需要收集数据，但没有资源来运行资源密集型数据收集器，那么 Beats 会是您最佳的选择。这种无处不在（涵盖所有联网设备）的数据收集方式，让您能够快速检测到异常情况做出反应，例如系统范围内的问题和安全事件等。
当然，Beats 并不局限于资源有限的系统，它们还可用于具有更多可用硬件资源的系统。
 <h4>Beats 系列：概述</h4>Beats 有多种风格，可以收集不同类型的数据：
<ul>
	<li><a href="/cn/beats/filebeat">Filebeat</a> 支持您从以文件形式提供的源中读取、预处理和传送数据。尽管大多数用户使用 Filebeat 来读取日志文件，但它也支持任何非二进制文件格式。Filebeat 还支持许多其他数据源，包括 TCP/UDP、容器、Redis 和 Syslog。借助丰富的<a href="/guide/en/beats/filebeat/current/filebeat-modules.html">模块</a>，可以轻松针对 Apache、MySQL 和 Kafka 等常见应用程序的日志格式收集和解析相应的数据。</li>
	<li><a href="/cn/beats/metricbeat">Metricbeat</a> 可收集并预处理系统和服务指标。系统指标包括关于运行中进程的相关信息，以及 CPU/内存/磁盘/网络利用率方面的数据。这些<a href="/guide/en/beats/filebeat/current/filebeat-module-system.html">模块</a>可用于收集来自许多不同服务的数据，包括 Kafka、Palo Alto Networks、Redis，等等。</li>
	<li><a href="/cn/beats/packetbeat">Packetbeat</a> 可收集并预处理实时网络数据，从而支持应用程序监测、安全和网络性能分析。此外，Packetbeat 还支持以下协议：DHCP、DNS、HTTP、MongoDB、NFS 和 TLS。</li>
	<li><a href="/cn/beats/winlogbeat">Winlogbeat</a> 可从 Windows 操作系统捕获事件日志，包括应用程序事件、硬件事件，以及安全和系统事件。对于许多用例来说，从 Windows 事件日志中获得的大量信息非常有用。</li>
	<li><a href="/cn/beats/auditbeat">Auditbeat</a> 可检测对关键文件的更改并从 Linux 审计框架收集事件。不同的<a href="/guide/en/beats/auditbeat/current/auditbeat-modules.html">模块</a>简化了它的部署，这主要在安全分析用例中使用。</li>
	<li><a href="/cn/beats/heartbeat">Heartbeat</a> 利用探测来监测系统和服务的可用性。因此，Heartbeat 在许多场景中都很有用，比如基础架构监测和安全分析。ICMP、TCP 和 HTTP 都是受支持的协议。</li>
	<li><a href="/cn/beats/functionbeat">Functionbeat</a> 可从无服务器环境（如 AWS Lambda）中收集日志和指标。</li>
</ul>一旦您决定了在特定场景中要使用哪个 Beats，入门就像下节所描述的那样，非常简单。
 <h4>Beats 入门</h4>在这部分中，我们将以 Metricbeat 为例，学习如何开始使用 Beats。对于其他 Beats，步骤大同小异。针对您具体的 Beat 和操作系统，请参考本文档并按照下列步骤进行操作。
<ol>
	<li><a href="/cn/downloads/beats">下载并安装所需的 Beat</a>。安装 Beats 有很多种方法，但大多数用户都会选择使用为操作系统的包管理器提供的 Elastic 存储库 (DEB/RPM)，或者简单下载并解压缩所提供的 tgz/zip 包。</li>
	<li><a href="/guide/en/beats/metricbeat/current/configuring-howto-metricbeat.html">配置 Beat</a> 并<a href="/guide/en/beats/metricbeat/current/configuration-metricbeat.html">启用任何所需的模块</a>。</li>
</ol><ul>
	<li>例如，要收集系统上运行的关于 Docker 容器的指标，则通过 <code>sudo metricbeat modules enable docker</code> 启用 <a href="/guide/en/beats/metricbeat/current/metricbeat-module-docker.html">Docker 模块</a>（如果您使用包管理器安装）。如果您通过解压缩 tgz/zip 包安装，则使用 <code>/metricbeat modules enable docker</code>。</li>
	<li>云 ID 是一种简便的方法，用以指定收集的数据要发送到的 Elasticsearch 服务。将云 ID 和身份验证信息添加到 Metricbeat 配置文件 (Metricbeat .yml)：
	</li>
	<pre class="prettyprint">cloud.id: cluster_name:ZXVy...Q2Zg==
cloud.auth: "elastic:YOUR_PASSWORD"
 </pre>
	<ul>
		<li>如前所述，<code>cloud.id</code> 是在创建集群时提供给您的。<code>cloud.auth</code> 是一个冒号分隔的用户名和密码的串联，且已在 Elasticsearch 集群中被授予足够的权限。
		</li>
		<li>若要快速启动，可以使用在创建集群时提供的 Elastic 超级用户和密码。如果您使用包管理器安装，则可以在 <code>/etc/metricbeat</code> 目录下找到配置文件；如果您使用 tgz/zip 包安装，则在解压缩的目录下。</li>
	</ul>
</ul><ol start="3">
	<li><a href="/guide/en/beats/metricbeat/current/load-kibana-dashboards.html">将预装仪表板加载到 Kibana</a>。大多数 Beats 和它们的模块都带有预先定义好的 Kibana 仪表板。如果您使用包管理器安装，则通过 <code>sudo metricbeat setup</code> 将它们加载到 Kibana；如果使用 tgz/zip 包安装，则在解压缩的目录下运行 <code>./metricbeat setup</code>。</li>
</ol><ol start="4">
	<li><a href="/guide/en/beats/metricbeat/current/setting-up-and-running.html">运行 Beat</a>。如果您在基于 systemd 的 Linux 系统上使用包管理器安装，则使用 <a href="/guide/en/beats/metricbeat/current/running-with-systemd.html"><code>sudo systemctl start metricbeat</code></a>；如果您使用 tgz/zip 包安装，则使用 <code>./metricbeat -e</code></li>
</ol>如果一切正常，数据就会开始流入 Elasticsearch 服务。
 <h4>探索预装仪表板</h4>前往 Elasticsearch 服务中的 Kibana 来查看数据：
<ul>
	<li>在 Kibana Discover 中，选择 <code>metricbeat-*</code> 索引模式，您将能够看到已采集的各个文档。</li>
	<li>“Kibana 基础架构”选项卡通过以各种图表形式显示有关系统资源（CPU、内存、网络）的使用情况，让您能够以更图形化的方式检查系统和 Docker 指标。</li>
	<li>在 Kibana 仪表板中，选择任意带有 [Metricbeat System] 前缀的仪表板，以交互方式查看数据。</li>
</ul> <h3>Logstash</h3>Logstash 是一个强大而灵活的工具，可以读取、处理和传送任何类型的数据。Logstash 提供了许多功能，这些功能目前还不可用，或者通过 Beats 执行成本太高，比如通过对外部数据源执行查找来丰富文档。不管采用哪种方式，Logstash 的这种功能和灵活性都是有代价的。此外，Logstash 的硬件要求也显著高于 Beats。严格来说，Logstash 通常不应部署在低资源设备上。因此，在 Beats 功能不足以满足特定用例要求的情况下，可将 Logstash 用作其替代选择。
一种常见的架构模式是将 Beats 和 Logstash 组合起来：使用 Beats 来收集数据，并使用 Logstash 来执行 Beats 无法执行的任何数据处理。
 <h4>Logstash 概述</h4>Logstash 通过执行事件处理管道来工作，其中每个管道至少包含以下各项中的一个：
<ul>
	<li><a href="/guide/en/logstash/current/input-plugins.html">输入</a>从数据源读取数据。官方支持多种数据源，包括文件、http、imap、jdbc、kafka、syslog、tcp 和 udp。</li>
	<li><a href="/guide/en/logstash/current/filter-plugins.html">过滤器</a>以多种方式处理和丰富数据。在许多情况下，首先需要将非结构化的日志行解析为更加结构化的格式。因此，除其他功能外，Logstash 还在正则表达式的基础上提供了解析 CSV、JSON、键/值对、分隔的非结构化数据和复杂的非结构化数据的过滤器（<a href="/guide/en/logstash/current/plugins-filters-grok.html">grok 过滤器</a>）。Logstash 还提供了更多的过滤器，通过执行 <a href="/guide/en/logstash/current/plugins-filters-dns.html">DNS 查找</a>，添加<a href="/guide/en/logstash/current/plugins-filters-geoip.html">关于 IP 地址的地理信息</a>，或通过对<a href="/guide/en/logstash/current/plugins-filters-translate.html">自定义目录</a>或 <a href="/guide/en/logstash/current/plugins-filters-elasticsearch.html">Elasticsearch 索引</a>执行查找来丰富数据。通过这些附加的过滤器，能够对数据进行各种转换，例如重命名、删除、复制数据字段和值（<a href="/guide/en/logstash/current/plugins-filters-mutate.html">mutate 过滤器</a>）。</li>
	<li><a href="/guide/en/logstash/current/output-plugins.html">输出</a>将解析后并加以丰富的数据写入数据接收器，这是 Logstash 处理管道的最后阶段。虽然有许多输出插件可用，但这里我们主要讨论如何使用 <a href="/guide/en/logstash/current/plugins-outputs-elasticsearch.html">Elasticsearch 输出</a>将数据采集到 Elasticsearch 服务。</li>
</ul> <h4>Logstash 示例管道</h4>没有两个用例是相同的。因此，您可能必须开发符合自身特定数据输入和需求的 Logstash 管道。
我们提供了一个示例 Logstash 管道，该管道能够
<ul>
	<li>读取 Elastic 博客 RSS 源</li>
	<li>通过复制/重命名字段和删除特殊字符及 HTML 标记来执行一些简单的数据预处理</li>
	<li>将文档采集到 Elaticsearch</li>
</ul>步骤如下：
<ol>
	<li>通过<a href="/guide/en/logstash/current/installing-logstash.html">包管理器</a>或下载并解压 <a href="/guide/en/elasticsearch/reference/6.0/zip-targz.html">tgz/zip 文件</a>来安装 Logstash。</li>
	<li>安装 Logstash <a href="/guide/en/logstash/current/plugins-inputs-rss.html">rss 输入插件</a>，这可支持读取 RSS 数据源：<code>./bin/logstash-plugin install logstash-input-rss</code></li>
	<li>将下列 Logstash 管道定义复制到一个新文件，例如 ~/elastic-rss.conf:</li>
</ol><pre class="prettyprint">input { 
 rss { 
 url =&gt; "/blog/feed" 
 interval =&gt; 120 
 } 
} 
filter { 
 mutate { 
 rename =&gt; [ "message", "blog_html" ] 
 copy =&gt; { "blog_html" =&gt; "blog_text" } 
 copy =&gt; { "published" =&gt; "@timestamp" } 
 } 
 mutate { 
 gsub =&gt; [ 
 "blog_text", "&lt;.*?&gt;", "",
 "blog_text", "[\n\t]", " " 
 ] 
 remove_field =&gt; [ "published", "author" ] 
 } 
} 
output { 
 stdout { 
 codec =&gt; dots 
 } 
 elasticsearch { 
 hosts =&gt; [ "https://&lt;your-elsaticsearch-url&gt;" ] 
 index =&gt; "elastic_blog" 
 user =&gt; "elastic" 
 password =&gt; "&lt;your-elasticsearch-password&gt;" 
 } 
}
</pre><ol start="4">
	<li>在上面的文件中，修改参数主机和密码，以匹配您的 Elasticsearch 服务端点和 Elastic 用户密码。在 Elastic Cloud 中，您可以从部署页的详细信息中获取 Elasticsearch 端点 URL（复制端点 URL）。</li>
</ol><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt028c5e311d9933f2/5d72da8272e3f704311c0060/ingest-ess-deployment-blog.png" data-sys-asset-uid="blt028c5e311d9933f2" alt="部署页面详细信息" style="display: block; margin: auto;">

<ol start="5">
	<li>通过启动 Logstash 执行管道：./bin/logstash -f ~/elastic-rss.conf</li>
</ol>启动 Logstash 需要几秒钟的时间。您会在控制台上看到出现圆点 (.....)。每个点表示一个已采集到 Elasticsearch 的文档。
<ol start="6">
	<li>打开 Kibana。在 Kibana 开发工具控制台中，执行以下操作，以确认已经采集了 20 个文档：POST elastic_blog/_search</li>
</ol>有关更多详细信息，请参阅优秀的博客文章 <a href="/cn/blog/a-practical-introduction-to-logstash">Logstash 实用介绍</a>。全部详细信息，请参阅 <a href="/guide/en/logstash/current/index.html">Logstash 文档</a>。<h3>语言客户端</h3>在某些情况下，最好将数据采集与自定义应用程序代码集成。为此，我们建议使用一个<a href="/guide/en/elasticsearch/client/index.html">官方支持的 Elasticsearch 客户端</a>。这些客户端是抽象出数据采集低层细节的库，使您能够专注于特定应用程序的实际工作。Java、JavaScript、Go、.NET、PHP、Perl、Python 和 Ruby 都有官方客户端。有关您所选语言的所有详细信息和代码示例，请参阅相关文档即可。如果您的应用程序不是用上面所列语言编写的，则很可能会有<a href="/guide/en/elasticsearch/client/community/current/index.html">社区贡献的客户端</a>。<h3>Kibana 开发工具</h3>我们推荐的用于开发和调试 Elasticsearch 请求的工具是 <a href="/guide/en/kibana/current/console-kibana.html">Kibana 开发工具控制台</a>。开发工具公开了通用的 Elasticsearch REST API 的全部功能和灵活性，同时抽象出了底层 HTTP 请求的技术细节。不出所料，您可以使用开发工具控制台将原始 JSON 文档放到 Elasticsearch 中：<pre class="prettyprint">PUT my_first_index/_doc/1 
{ 
 "title" :"How to Ingest Into Elasticsearch Service",
 "date" :"2019-08-15T14:12:12",
 "description" :"This is an overview article about the various ways to ingest into Elasticsearch Service" 
}
</pre> <h3>其他 REST 客户端</h3>有了 Elasticsearch 提供的通用 REST 接口，您即可随心所欲地找到自己喜欢的 REST 客户端来与 Elasticsearch 通信并采集文档。虽然我们建议首先尝试上面提到的工具，但是有很多原因可能会让您考虑其他选择。例如，<a href="https://github.com/curl/curl">curl</a> 是一款经常作为最后手段使用的工具，用于开发、调试或与自定义脚本集成。<h2>结论</h2>将数据采集到 Elasticsearch 服务的方法不胜枚举。没有两种场景是相同的；选择具体的方法或工具来采集数据取决于您的特定用例、需求和环境。Beats 提供了一种方便、轻量级的开箱即用型解决方案，可以从许多不同的来源收集和采集数据。与 Beats 封装在一起的模块为许多常见数据库、操作系统、容器环境、Web 服务器、缓存等提供了数据获取、解析、索引和可视化的配置。这些模块可提供五分钟实现数据到仪表板的体验。因为 Beats 是轻量型的，所以非常适合资源受限的嵌入式设备，例如 IoT 设备或防火墙。另一方面，Logstash 是一种灵活的工具，可用于读取、转换和采集数据，提供了大量的过滤器、输入和输出插件。如果 Beats 的功能对于某些用例来说还不够，那么一种常见的架构模式是使用 Beats 来收集数据，并通过 Logstash 做进一步处理，然后再采集到 Elasticsearch 中。我们建议在直接从应用程序采集数据时使用官方支持的客户端库。Kibana 开发工具控制台非常适合开发和调试。最后，Elasticsearch REST API 为您提供了使用您喜欢的 REST 客户端的灵活性。准备好进一步深入了解了吗？推荐您阅读以下相关文章：<ul>
	<li><a href="/cn/blog/should-i-use-logstash-or-elasticsearch-ingest-nodes">我应该使用 Logstash 还是 Elasticsearch 采集节点呢？</a></li>
	<li><a href="/cn/blog/get-system-logs-and-metrics-into-elasticsearch-with-beats-system-modules">使用 Beats 系统模块将系统日志和指标获取到 Elasticsearch</a></li>
</ul>

ingest-ess-blog-banner.jpg

ingest-ess-blog-thumb.jpg

How to ingest data into Elasticsearch Service

如何将数据采集到 Elasticsearch 服务

hot-warm-cold-banner.jpg

hot-warm-cold-thumb.jpg

Implementing a Hot-Warm-Cold Architecture with Index Lifecycle Management

使用索引生命周期管理实现热温冷架构

了解 Elastic 可观测性如何使得监测和检测来自数千个运行成百上千微服务容器的上百万条日志中的异常变得轻而易举，同时 Kubernetes 还可以利用不断变化的 pod 计数扩展应用程序。一切尽在单一 UI。

作为逐渐崭露头角的事实标准容器编排技术，Kubernetes 已然成为了云端原生活动中不可或缺的一种技术手段。&nbsp;云端原生虽为软件开发赋予了速度、弹性和敏捷性，但也增加了复杂性（在成千上万或数百万个容器上有成百上千的微服务，运行于暂时和一次性的 pod）。监测如此复杂的分布式瞬态系统注定会困难重重，但重要性却不容忽视。幸运的是，Elastic 可以轻松化解这种难题，为 <a href="/cn/what-is/kubernetes-monitoring">Kubernetes 环境赋予可观测性</a>。&nbsp;

在本次 Kubernetes 可观测性教程系列中，我们将深度剖析如何<a href="/cn/webinars/application-observability-on-kubernetes-with-the-elastic-stack-hands-on-tutorial">对 Kubernetes 中运行的应用程序进行全方位监测</a>，包括：&nbsp;

<ul>
	<li>采集和分析日志</li>
	<li><a href="/cn/blog/kubernetes-observability-tutorial-k8s-metrics-collection-and-analysis">收集性能和健康指标</a></li>
	<li><a href="/cn/blog/kubernetes-observability-tutorial-k8s-monitoring-application-performance-with-elastic-apm">使用 Elastic APM 监测应用程序性能</a></li>
</ul>
在本次教程的结尾，您将拥有一个应用程序的工作示例，该应用程序会将其所有可观测性数据传输到用于监测和分析的 Elastic Stack。

<h2>为何选择 Elastic 可观测性用于 Kubernetes？</h2>
可观测性依赖三大“支柱性”数据块：日志、指标以及应用程序性能监测（简称为 APM）。阐述如何将不同工具和供应商拼凑在一起来打造 Kubernetes 监测“最佳组装产品”的文章数不胜数，不过这种集合了 3-6 种不同工具、供应商和技术的“非常规拼凑品”……&nbsp;

恐怕有点令人望而却步。<a href="/cn/observability">Elastic 可观测性</a>使用一种工具，即可将日志、指标和 APM 数据结合在一起，实现统一的可见性和分析。根据 APM 数据中面向用户的延迟异常（由 Machine Learning 检测）开始进行故障排除，切换到特定 Kubernetes pod 指标，查看该 pod 生成的日志、并将其与描述主机和网络上发生事件的指标和日志相关联，所有这些操作均可在同一用户界面完成。这种方式才是实现可观测性的正确解决之道！&nbsp;

虽然用户体验因此而变得更加便捷容易，但后台中却涉及到大量繁琐的工作，原因在于……

<h3>Kubernetes 日志目标并不固定</h3>
Kubernetes 通过向可用主机中部署容器执行编排。因此，这种方式自然会令应用程序组件分布到不同主机，根本无法事先获悉组件的目标位置。

Kubernetes pod 内运行的容器会生成日志（以 stdout 或 stderr）。作为以 pod id 命名的文件，这些日志被写到 kubelet 已知的位置。为了将日志与生成日志的组件或 pod 相关联，用户需要找到在当前主机中运行的组件 pod 及其 id 分别为何。

而令情况更加复杂的一点是，Kubernetes 可能会决定扩大或缩小应用程序，结果可能导致代表应用程序组件的 pod 计数产生变化。&nbsp;

<h3>Filebeat 恰好是非固定式目标的完美捕手</h3>
要收集 pod 日志，我们只需要将 <a href="/cn/beats/filebeat">Filebeat</a> 作为 DaemonSet，在 Kubernetes 集群中运行即可。Filebeat 可以配置为与本地 kubelet API 通信，获取在当前主机运行的 pod 列表，并收集这些 pod 生成的日志。利用所有相关 Kubernetes 元数据（例如 pod id、容器名、容器标签和注释等多种信息）对这些日志进行注释。&nbsp;

Filebeat 会使用这些注释来发现哪些组件正在 pod 中运行，然后可以决定对其正在处理的日志应用哪种日志记录模块。完全无需手动操作！使用 Filebeat 采集 Kubernetes 日志轻而易举。我们即将进入正题，但在开始前，请快速了解一项十分重要的说明：

<table style="background: #FFFFD2;">
<tbody>
<tr>
	<td>开始前：以下教程需要对 Kubernetes 环境进行设置。我们已经编写一篇<a href="/cn/blog/kubernetes-observability-tutorial-k8s-cluster-setup-demo-app-deployment">补充博文，指导您设置单节点 Minikube 环境和演示应用程序的流程</a>，从而运行其余活动。
	</td>
</tr>
</tbody>
</table>
<h2>使用 Filebeat 采集 Kubernetes 日志
</h2>
我们将<a href="/cn/elasticsearch/service">在 Elastic Cloud 上使用 Elasticsearch Service</a>。但此处所描述的所有操作都可在您自己的基础架构上部署的 Elastic 集群上使用，不管是自我管型，还是使用编排系统，例如 <a href="/cn/ece">Elastic Cloud Enterprise (ECE)</a> 或 <a href="/cn/elastic-cloud-kubernetes">Elastic Cloud on Kubernetes (ECK)</a>。可于以下 GitHub 存储库中找到本次教程的代码：<a href="https://github.com/michaelhyatt/k8s-o11y-workshop">http://github.com/michaelhyatt/k8s-o11y-workshop</a>

<h3>将 Filebeat 作为 DaemonSet 进行部署</h3>
根据 Kubernetes 主机，应该仅部署 Filebeat 的一个实例。部署后，Filebeat 会通过 kubelet API 与主机通信，从而检索有关运行 pod、所有元数据注释以及日志文件位置的信息。

DaemonSet 的部署配置定义，请参见文件 <code>$HOME/k8s-o11y-workshop/filebeat/filebeat.yml</code>。&nbsp;让我们来进一步了解代表 Filebeat 配置的部署描述符部分。

该部分将可能的字段总数从默认的 1000 提高到了 5000。Kubernetes 部署会引入大量的标签和注释，导致模式字段的数量可能超过默认的 1000。

<pre class="prettyprint">setup.template.settings:
 index.mapping.total_fields.limit:5000
</pre>
自动发现机制的设置会指示 Filebeat 使用 Kubernetes 自动发现，并依靠基于提示的自动发现，在注释上发挥作用。

<pre class="prettyprint">filebeat.autodiscover:
 providers:
 - type: kubernetes
 host: ${NODE_NAME}
 hints.enabled: true
</pre>
下一环节定义了将应用于该 Filebeat 实例捕获的所有日志的处理器链。首先，将利用来自 Docker、Kubernetes、主机和云服务提供商的元数据扩充事件。然后，<code>drop_event</code> 部分会基于内容和上述处理器创建的部分元数据字段筛选消息。当存在持续控制日志的干扰事件类型时，这会大有用处。注意逻辑<code>和</code>以及<code>或</code>如何用于构建匹配条件。

<pre class="prettyprint">processors:
 - add_cloud_metadata:
 - add_host_metadata:
 - add_docker_metadata:
 - add_kubernetes_metadata:
 - drop_event:
 when:
 or:
 - contains:
 message:"OpenAPI AggregationController:Processing item k8s_internal_local_delegation_chain"
 - and:
 - equals:
 kubernetes.container.name: "metricbeat"
 - contains:
 message:"INFO"
 - contains:
 message:"Non-zero metrics in the last"
 - and:
 - equals:
 kubernetes.container.name: "packetbeat"
 - contains:
 message:"INFO"
 - contains:
 message:"Non-zero metrics in the last"
 - contains:
 message: "get services heapster"
 - contains:
 kubernetes.container.name: "kube-addon-manager"
 - contains:
 kubernetes.container.name: "dashboard-metrics-scraper"
</pre>
<h2>使用注释的 Filebeat 模块和自动发现</h2>
我们在上文了解了自动发现将如何获得相应的模块应用到 stdout/stderr 中，将其解析为特定模块的格式。<a href="/guide/en/beats/filebeat/7.8/configuration-autodiscover-hints.html">请在 Filebeat 文档中了解有关自动发现的详情</a>。

现在我们来讲解如何在样例应用程序中配置不同组件，从而与 Kubernetes 基于提示的自动发现一同协作。

<h3>NGINX 示例</h3>
此处为来自 <code>$HOME/k8s-o11y-workshop/nginx/nginx.yml</code> 的代码片段，指示 Filebeat 将本 pod 的日志作为 NGINX 日志处理，其中 stdout 代表访问日志，stderr 代表错误日志：

<pre class="prettyprint">annotations:
 co.elastic.logs/module: nginx
 co.elastic.logs/fileset.stdout: access
 co.elastic.logs/fileset.stderr: error
</pre>
<h2>处理多行应用程序日志&nbsp;</h2>
基于提示的自动发现的另一示例是配置 Filebeat，将 petclinic 多行日志条目作为单一日志事件处理。这在组件记录多行消息时非常有用，例如代表单一事件的 Java 堆栈跟踪，但默认情况将根据行作为单一事件进行处理（以行尾为界限）。

此处为来自 <code>$HOME/k8s-o11y-workshop/petclinic/petclinic.yml </code>的代码片段，代表了 Filebeat 使用基于提示的自动发现来理解的多行事件处理配置：

<pre class="prettyprint">annotations:
 co.elastic.logs/multiline.pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}'
 co.elastic.logs/multiline.negate: "true"
 co.elastic.logs/multiline.match: "after"
</pre>
<a href="/guide/en/beats/filebeat/7.8/multiline-examples.html">有关多行事件处理的更多详情，请查阅 Filebeat 文档。</a>

<h2>分析 Elastic Stack 中的 Kubernetes 日志</h2>
现在日志已经采集进 Elasticsearch 之中，此刻便是充分开展利用的最佳时机。

<h3>使用 Kibana 中的 Logs 应用</h3>
Kibana 中的 <a href="/cn/log-monitoring">Logs 应用</a>可以对收集到 Elastic Stack 之中的所有日志进行搜索、筛选和跟踪。所有日志均可在 Logs 应用的某一工具中找到，无需使用 ssh 命令登录不同服务器或是使用 cd 命令进入目录并跟踪单个文件。&nbsp;

<ul>
	<li>使用关键词或纯文本搜索查看筛选日志。</li>
	<li>您可以使用时间选取器或边栏的时间线视图，来回移动时间。&nbsp;</li>
	<li>如果只想查看在 <code>tail -f</code> 样式之前的日志更新，只需单击 Streaming（流式处理）按钮，使用高亮突出显示您想要查看的那一部分重要信息即可。</li>
</ul>
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltab337a23afe950b4/5eec4a3f18cea32a006fc2d0/blog-k8s-o11y-logs-app.jpg" data-sys-asset-uid="bltab337a23afe950b4" alt="在 Kibana 中，搜索 Logs 应用中的 Filebeat 条目" style="display: block; margin: auto;">

<h3>开箱即用的 Kibana 可视化</h3>
当我们运行 Filebeat-setup 作业时，除了其他操作，这会<a href="/guide/en/beats/filebeat/7.8/view-kibana-dashboards.html">在 Kibana 中预创建一系列开箱即用的仪表板</a>。在我们的样例 petclinic 应用程序最终部署完成后，便可以导航至 MySQL、NGINX 开箱即用的 Filebeat 仪表板，并会发现 Filebeat 模块不仅会捕获日志，还会获取组件记录的指标。实现这些可视化功能，需要运行样例应用程序的 MySQL 和 NGINX 组件。

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7cd3cc05a1ab4047/5eec4a68dee8140c761c17c2/blog-k8s-o11y-logs-nginx.jpg" data-sys-asset-uid="blt7cd3cc05a1ab4047" alt="Kibana 中的开箱即用 NGINX 仪表板" style="display: block; margin: auto;">

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltee22cb8374d201b9/5eec4a7f8d39260a3ded6ead/blog-k8s-o11y-logs-mysql.jpg" data-sys-asset-uid="bltee22cb8374d201b9" alt="Kibana 中的开箱即用 MySQL 仪表板" style="display: block; margin: auto;">

<h3>Machine Learning 和检测日志记录异常&nbsp;</h3>
从 <a href="/cn/blog/elastic-stack-7-5-0-released">7.5 版本</a>开始，Elastic Stack 便支持检测应用程序组件日志速率中的异常情况。这一功能可用于检测：

<ul>
	<li>刚部署的新应用程序或日志来源</li>
	<li>由于推广（或攻击！）突然上升的日志记录活动</li>
	<li>日志传输突然停止，可能是由于代理或采集管道故障</li>
</ul>
我们在 Logs 应用中引入了<a href="/guide/en/kibana/7.8/xpack-ml-anomalies.html">日志速率异常检测功能</a>，让操作人员可以及时化解上述问题。在 Logs 应用中单击一下即可实现。

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt80e09349e72bb510/5eec4479146cc4629e1ad7a0/blog-k8s-o11y-logs-anomalies.png" data-sys-asset-uid="blt80e09349e72bb510" alt="Machine Learning 对日志数据的异常检测" style="display: block; margin: auto;">

<h3>使用日志条目分类，检测未知的异常问题</h3>
日志相关的 Machine Learning 的另一项有用的应用便是<a href="/guide/en/elastic-stack-overview/master/ml-configuring-categories.html">检测此前未观测到的新日志类型条目</a>。Machine Learning 可以极大程度地从日志条目中剥离所有数字和变量部分（例如时间戳、数值等），捕获余下部分，然后对日志条目的固定部分进行分类。然后尝试将其分组归类为存储桶，继续标记出现的新存储桶，代表此前未观测到的日志条目异常。

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc112d18649b0060a/5eec448f464b61607c65ef6f/blog-k8s-o11y-logs-classification.png" data-sys-asset-uid="bltc112d18649b0060a" alt="日志消息分类" style="display: block; margin: auto;">

<h3>开箱即用的 Machine Learning 作业 — NGINX</h3>
当我们在运行 Filebeat-setup 作业时，同时会预创建开箱即用的 Machine Learning 作业。如果予以激活，则其会开始检测 Filebeat 采集的 NGINX stdout 和 stderr 数据异常。

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt53427a2a80321ab7/5eec4a9f34f8f30c7cfb30a0/blog-k8s-o11y-logs-nginx-ml.jpg" data-sys-asset-uid="blt53427a2a80321ab7" alt="应用 Machine Learning 到 NGINX 日志" style="display: block; margin: auto;">

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc7a6facd6cc94767/5eec44d06b547b2c37e3af26/blog-k8s-o11y-logs-nginx-anomaly-viewer.jpg" data-sys-asset-uid="bltc7a6facd6cc94767" alt="NGINX 日志中的异常检测" style="display: block; margin: auto;">

<h2>总结</h2>
在本部分中，我们使用 Filebeat 及其模块，将 Kubernetes 日志采集到了 Elastic Stack 之中。通过在 Elastic Cloud 上注册免费试用的 <a href="/cn/cloud/elasticsearch-service/signup">Elasticsearch Service</a>，或<a href="/cn/start">下载</a> Elastic Stack 并自行托管，您可以立即开始监测自己的系统和基础架构。配置完成并开始运行后，您便可以利用 <a href="/cn/uptime-monitoring">Elastic 运行状态监测</a>对主机可用性进行监测，使用 <a href="/cn/apm">Elastic APM</a> 检测在主机上运行的应用程序。这样您便可以顺利朝着全方位可观测系统的发展方向行进，实现全新指标集群的完整集成。如果您遇到任何困难或问题，请跳转至我们的<a href="https://discuss.elastic.co/">讨论论坛</a>，我们时刻准备为您服务。

下篇博文：<a href="/cn/blog/kubernetes-observability-tutorial-k8s-metrics-collection-and-analysis">收集性能和健康指标</a>

Elasticsearch Platform

ELK Stack

Elastic Cloud

可观测性

安全性

搜索

按行业

按解决方案

客户聚焦

开发人员

保持联系

学习

帮助

了解 Elastic 的最新动态

选择一个 Beat。任何 Beat 皆可。

Filebeat

Packetbeat

Winlogbeat

Metricbeat

Heartbeat

Auditbeat

Functionbeat

需要帮助？我们会竭诚为您提供服务

关注我们

关于我们

加入我们

新闻稿

合作伙伴

信任和安全性

投资者关系

卓越奖

关于我们

加入我们

新闻稿

合作伙伴

信任和安全性

投资者关系

卓越奖