ElasticSearch-监控指南-全-

ElasticSearch 监控指南（全）

原文：zh.annas-archive.org/md5/294ade860b64879c0eecab4b1cde16c8

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

欢迎来到 监控 Elasticsearch！

有许多书籍和在线教程涵盖了 Elasticsearch API 和如何配置集群。但，直到现在，还没有一个全面、易于获取的资源用于监控和故障排除。我们发现，Elasticsearch 监控工具极大地提高了我们解决集群问题的能力，并极大地提高了集群的可靠性和性能。我们写这本书是为了分享这些用例及其产生的见解。

本书涵盖了如何使用几个流行的开源和商业 Elasticsearch 监控工具，包括 Elasticsearch-head、Bigdesk、Marvel、Kopf 和 Kibana。书中还包括了关于 Elasticsearch cat API 的部分以及如何使用 Nagios 进行通用系统监控。此外，我们还将讨论几个案例研究，通过这些工具解决 Elasticsearch 问题的实际示例。

我们认为，最好的学习方式是实践。在这本书中，我们将介绍如何设置一个示例 Elasticsearch 集群并加载数据。有时，我们会故意在集群中引入问题，以便我们可以看到如何使用我们的各种监控工具来追踪错误。在自己的集群中跟随这些示例将帮助您学习如何使用监控工具以及如何应对可能出现的新问题和未知问题。

在阅读本书后，我们希望您将更好地装备自己来运行和维护 Elasticsearch 集群。您也将更加准备好诊断和解决集群问题，例如节点故障、Elasticsearch 进程死亡、配置错误、分片错误、OutOfMemoryError 异常、慢查询和慢索引性能。

本书涵盖的内容

第一章, Elasticsearch 监控简介，概述了 Elasticsearch 并讨论了在监控集群或故障排除问题时需要注意的一些事项。

第二章, Elasticsearch 的安装和需求，涵盖了如何安装 Elasticsearch 和几个 Elasticsearch 监控工具。

第三章, Elasticsearch-head 和 Bigdesk，展示了如何配置一个多节点 Elasticsearch 集群以及如何使用监控工具 Elasticsearch-head 和 Bigdesk 来检查集群的健康状况和状态。

第四章, Marvel 仪表板，介绍了由 Elasticsearch 制造商创建的商业监控工具 Marvel。

第五章, 系统监控，涵盖了 Elasticsearch 工具 Kopf、Kibana、Elasticsearch cat API 以及几个 Unix 命令行工具。本章还演示了如何使用 Nagios 进行通用系统监控。

第六章，处理性能和可靠性问题，涵盖了在使用 Elasticsearch 时如何处理一些常见的性能和可靠性问题。它还包含了一些带有真实世界故障排除案例研究的案例。

第七章，节点故障和事后分析，深入分析了你的集群的历史性能以及如何深入调查和从系统故障中恢复。它还包含了一些带有真实世界案例研究的案例。

第八章，展望未来，通过讨论 Elasticsearch 5 的未来以及一些即将发布的监控工具来结束本书。

你需要这本书的以下内容

要跟随这本书中的示例，你需要一个真实或虚拟化的三节点 Elasticsearch 集群。你可能还需要两个其他节点来运行 Marvel 和 Nagios，分别在第四章，Marvel 仪表板和第五章，系统监控中介绍。在 Elasticsearch 集群的节点上运行 Marvel 和 Nagios 是可能的，但在生产集群中你不应该这样做。查看 VMWare Player (www.vmware.com/products/player) 和 VirtualBox (www.virtualbox.org/wiki/Downloads) 以建立自己的虚拟五节点环境，或使用 Amazon EC2 (aws.amazon.com/ec2/) 在云中构建集群。

对于你的 Elasticsearch 节点，你需要 64 位版本的 Windows、Mac OS X 或 Linux 以及 Java 运行时环境的最新版本。在这些主机上，CPU 速度并不那么重要，但我们建议每个节点至少有 512 MB 的内存。我们在这本书的所有示例中都使用 Ubuntu 14.04 和 Oracle Java 7，但任何现代操作系统以及 OpenJDK 或 Oracle Java 7 和 8 都可以用于运行示例。唯一的例外是 Nagios，它需要在 Linux 上运行。

你将需要以下软件包：

Java 7 或 Java 8 (www.oracle.com/technetwork/java/javase/downloads/index.html)
Elasticsearch 2.3.2 (www.elastic.co/downloads/past-releases/elasticsearch-2-3-2)
Elasticsearch-head (github.com/mobz/elasticsearch-head)
Bigdesk (bigdesk.org/)
Marvel—免费用于开发，生产使用需订阅费 (www.elastic.co/downloads/marvel)
Kibana (www.elastic.co/downloads/kibana)
Kopf (github.com/lmenezes/elasticsearch-kopf)
Nagios (www.nagios.org/downloads/)

所有这些软件包都是免费和开源的，除了 Marvel，它仅限于开发中使用免费。

最后，本书中的几个示例使用curl (curl.haxx.se/) 命令行工具对 Elasticsearch 进行 REST 调用，并且可选地使用 Python 2.7 来美化打印结果。

本书面向对象

这本书是为使用 Elasticsearch 的软件开发人员、DevOps 工程师和系统管理员而编写的。我们将介绍 Elasticsearch 的基础知识，以便安装和配置一个简单的集群，但我们不会深入探讨 Elasticsearch API。因此，对 Elasticsearch API 的基本理解可能有所帮助，尽管不是必需的，以便理解这本书。

约定

在这本书中，您将找到许多文本样式，用于区分不同类型的信息。以下是一些这些样式的示例及其含义的解释。

文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 昵称将按以下方式显示：“现在我们将安装 Marvel 到elasticsearch-marvel-01。”

代码块设置如下：

cluster.name: my_elasticsearch_cluster
node.name: "elasticsearch-node-01"
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["elasticsearch-node-02", "elasticsearch-node-03"]

当我们希望您注意代码块中的特定部分时，相关的行或项目将以粗体显示：

cluster.name: my_elasticsearch_cluster
node.name: "elasticsearch-node-01"
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["elasticsearch-node-02","elasticsearch-node-03"]

任何命令行输入或输出都按以下方式编写：

# sudo service elasticsearch start

新术语和重要词汇将以粗体显示。屏幕上看到的单词，例如在菜单或对话框中，在文本中显示如下：“点击下一步按钮将您带到下一个屏幕。”

注意

警告或重要注意事项将以如下方式显示。

小贴士

小技巧和技巧看起来像这样。

读者反馈

我们始终欢迎读者的反馈。请告诉我们您对这本书的看法——您喜欢什么或不喜欢什么。读者反馈对我们来说非常重要，因为它帮助我们开发出您真正能从中获得最大收益的图书。

要向我们发送一般性反馈，请简单地发送电子邮件至 <feedback@packtpub.com>，并在邮件主题中提及书名。

如果您在某个主题上具有专业知识，并且您有兴趣撰写或为图书做出贡献，请参阅我们的作者指南www.packtpub.com/authors。

客户支持

现在您已经是 Packt 图书的骄傲拥有者，我们有一些事情可以帮助您从您的购买中获得最大收益。

下载示例代码

您可以从www.packtpub.com的账户下载本书的示例代码文件。如果您在其他地方购买了此书，您可以访问www.packtpub.com/support并注册，以便将文件直接通过电子邮件发送给您。

您可以通过以下步骤下载代码文件：

使用您的电子邮件地址和密码登录或注册我们的网站。
将鼠标指针悬停在顶部的支持标签上。
点击代码下载 & 错误清单。
在搜索框中输入书籍名称。
选择您想要下载代码文件的书籍。
从下拉菜单中选择您购买此书的来源。
点击代码下载。

您还可以通过点击 Packt Publishing 网站上书籍网页上的代码文件按钮来下载代码文件。您可以通过在搜索框中输入书籍名称来访问此页面。请注意，您需要登录到您的 Packt 账户。

文件下载完成后，请确保您使用最新版本的以下软件解压或提取文件夹：

Windows 上的 WinRAR / 7-Zip
Mac 上的 Zipeg / iZip / UnRarX
Linux 上的 7-Zip / PeaZip

本书代码包也托管在 GitHub 上，网址为github.com/PacktPublishing/Monitoring-Elasticsearch。我们还有来自我们丰富的图书和视频目录的其他代码包，可在github.com/PacktPublishing/找到。查看它们吧！

下载本书的彩色图像

我们还为您提供了一个包含本书中使用的截图/图表彩色图像的 PDF 文件。彩色图像将帮助您更好地理解输出中的变化。您可以从www.packtpub.com/sites/default/files/downloads/MonitoringElasticsearch_ColorImages.pdf下载此文件。

错误清单

尽管我们已经尽最大努力确保内容的准确性，但错误仍然可能发生。如果您在我们的某本书中发现错误——可能是文本或代码中的错误——如果您能向我们报告这一点，我们将不胜感激。通过这样做，您可以节省其他读者的挫败感，并帮助我们改进本书的后续版本。如果您发现任何错误清单，请通过访问www.packtpub.com/submit-errata，选择您的书籍，点击错误提交表单链接，并输入您的错误详细信息来报告它们。一旦您的错误清单得到验证，您的提交将被接受，错误清单将被上传到我们的网站或添加到该标题的错误部分下的现有错误清单中。

要查看之前提交的勘误表，请访问 www.packtpub.com/books/content/support，并在搜索字段中输入书籍名称。所需信息将在勘误部分显示。

盗版

互联网上对版权材料的盗版是一个跨所有媒体的持续问题。在 Packt，我们非常重视我们版权和许可证的保护。如果您在互联网上发现我们作品的任何形式的非法副本，请立即提供位置地址或网站名称，以便我们可以追究补救措施。

请通过 <copyright@packtpub.com> 联系我们，并提供涉嫌盗版材料的链接。

我们感谢您在保护我们作者和我们提供有价值内容的能力方面所提供的帮助。

问题

如果您在这本书的任何方面遇到问题，您可以通过 <questions@packtpub.com> 联系我们，我们将尽力解决问题。

第一章：Elasticsearch 监控简介

Elasticsearch 是一个分布式且水平可扩展的全文搜索引擎，具有内置的数据冗余。它是一个强大且极其有用的工具。然而，与任何分布式系统一样，随着节点和数据量的增加，可能会出现问题。

Elasticsearch 监控工具提供的信息可以极大地提高您解决集群问题的能力，从而显著提高集群的可靠性和性能。本章概述了 Elasticsearch，并讨论了为什么以及如何监控集群。

具体来说，本章涵盖了以下主题：

Elasticsearch 概述
监控 Elasticsearch
资源丰富和问题解决

Elasticsearch 概述

本节提供了 Elasticsearch 的高级概述，并讨论了一些相关的全文搜索产品。

了解更多关于 Elasticsearch 的信息

Elasticsearch 是一个基于 Apache Lucene 构建的免费开源全文搜索引擎。开箱即用，Elasticsearch 支持水平扩展和数据冗余。2010 年发布后，Elasticsearch 迅速在全文搜索领域获得了认可。其可伸缩性功能帮助该工具在 Apache Solr 等类似技术中获得了市场份额。

Elasticsearch 是一个持久化文档存储和检索系统，它类似于数据库。然而，它在许多方面与 MySQL、PostgreSQL 和 Oracle 等关系型数据库不同：

分布式：Elasticsearch 在多个数据节点上存储数据和执行查询。这提高了可伸缩性、可靠性和性能。
容错：数据在 Elasticsearch 集群的多个节点之间进行复制，因此如果一个节点宕机，数据仍然可用。
全文搜索：Elasticsearch 建立在 Lucene 全文搜索技术之上，这使得它能够理解和搜索自然语言文本。
JSON 文档存储：Elasticsearch 将文档存储为 JSON，而不是存储在表的行中。
NoSQL：Elasticsearch 使用基于 JSON 的查询语言，而不是 SQL 查询语言。
非关系型：与关系型数据库不同，Elasticsearch 不支持跨表的连接。
分析：Elasticsearch 具有内置的分析功能，例如单词聚合、地理空间查询和脚本语言支持。
动态映射：在 Elasticsearch 中，映射类似于关系型数据库世界中的模式。如果一个文档字段的数据类型没有明确定义，Elasticsearch 会动态地为它分配一个类型。

数据分布、冗余和容错

图 1.1至图 1.4解释了 Elasticsearch 如何在多个节点之间分配数据以及它如何自动从节点故障中恢复：

图 1.1：Elasticsearch 数据分布

在这个图中，我们有一个由三个节点组成的 Elasticsearch 集群：elasticsearch-node-01、elasticsearch-node-02和elasticsearch-node-03。我们的数据索引被分成三部分，称为分片。这些分片被标记为0、1和2。每个分片都进行了复制；这意味着所有分片都有一个冗余副本。集群被涂成绿色，因为集群处于良好状态；所有数据分片和副本都是可用的。

假设elasticsearch-node-03主机发生硬件故障并关闭。以下图示显示了在此场景下集群会发生什么：

图 1.2：节点故障

图 1.2显示了elasticsearch-node-03发生故障，集群进入黄色状态。这种状态意味着集群中至少有一个分片的副本是活跃的，但并非所有分片副本都是活跃的。在我们的例子中，1和2分片的副本在失败的节点elasticsearch-node-03上。黄色状态还警告我们，如果发生另一个硬件故障，可能并非所有数据分片都将可用。

当elasticsearch-node-03节点宕机时，Elasticsearch 将自动在剩余的节点上重新构建1和2分片的冗余副本；在我们的例子中，这是elasticsearch-node-01和elasticsearch-node-02。这在下图中显示：

图 1.3：集群恢复中

一旦 Elasticsearch 完成数据副本的重建，集群再次进入绿色状态。现在，所有数据和分片都可以用于查询。

图 1.4：集群恢复

在图 1.3和1.4中展示的集群恢复过程在 Elasticsearch 中是自动发生的。不需要额外的配置或用户操作。

全文搜索

全文搜索指的是对自然语言文本文档执行关键字查询。文档可以是任何东西，例如报纸文章、博客文章、论坛帖子或推文。实际上，许多流行的报纸、论坛和社交媒体网站，如《纽约时报》、Stack Overflow 和 Foursquare，都使用 Elasticsearch。

假设我们要将以下文本字符串存储在 Elasticsearch 中：

We demand rigidly defined areas of doubt and uncertainty!

用户可以通过使用关键字，如需求或怀疑，在 Elasticsearch 中进行搜索以找到此文档。Elasticsearch 还支持词干提取。这意味着如果我们搜索单词define，Elasticsearch 仍然会找到此文档，因为defined的词根是define。

这段文本以及一些额外的元数据可以按照以下方式存储在 Elasticsearch 中，格式为 JSON：

{
    "text" : "We demand rigidly defined areas of doubt and uncertainty!",
    "author" : "Douglas Adams",
    "published" : "1979-10-12",
    "likes" : 583,
    "source" : "The Hitchhiker's Guide to the Galaxy",
    "tags" : ["science fiction", "satire"]
}

如果我们让 Elasticsearch 动态地为这个文档分配一个映射（想想模式），它看起来会是这样：

{
    "quote" : {
        "properties" : {
            "author" : {
                "type" : "string"
            },
            "likes" : {
                "type" : "long"
            },
            "published" : {
                "type" : "date",
                "format" : "strict_date_optional_time||epoch_millis"
            },
            "source" : {
                "type" : "string"
            },
            "tags" : {
                "type" : "string"
            },
            "text" : {
                "type" : "string"
            }
        }
    }
}

注意，Elasticsearch 能够识别出published字段看起来像日期。

搜索此文档的 Elasticsearch 查询如下所示：

{
    "query" : {
        "query_string" : {
            "query" : "demand rigidly"
        }
    },
    "size" : 10
}

关于 Elasticsearch 映射和搜索 API 的详细信息超出了本书的范围，但你可以通过以下链接的官方 Elasticsearch 文档了解更多信息：

Elasticsearch 映射：www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html
Elasticsearch 搜索 API：www.elastic.co/guide/en/elasticsearch/reference/current/search-search.html

注意

Elasticsearch 不应成为你的主要数据存储。它不提供传统 SQL 数据存储的原子性、一致性、隔离性和持久性（ACID）保证，也不提供其他 NoSQL 数据库（如 HBase 或 Cassandra）的可靠性保证。尽管 Elasticsearch 具有内置的数据冗余和容错能力，但最佳实践是在单独的数据存储中存档数据，以便在需要时将数据重新索引到 Elasticsearch 中。

相似的技术

本节解释了众多开源全文搜索引擎中的一些，并讨论了它们与 Elasticsearch 的匹配情况。

Apache Lucene

Apache Lucene (lucene.apache.org/core/) 是一个开源的全文搜索 Java 库。如前所述，Lucene 是 Elasticsearch 的底层搜索技术。Lucene 还提供了 Elasticsearch 的分析功能，如文本聚合和地理空间搜索。如果你在 Java 中进行小规模的全文搜索，或者正在构建自己的全文搜索引擎，直接使用 Apache Lucene 是一个不错的选择。

使用 Elasticsearch 而不是 Lucene 的好处如下：

使用 REST API 而不是 Java API
JSON 文档存储
水平可扩展性、可靠性和容错性

另一方面，Lucene 更加轻量级和灵活，可以构建需要从头开始集成全文搜索的定制应用程序。

注意

Lucene.NET 是 C#编写的库的流行.NET 版本

Solr

Solr 是建立在 Apache Lucene 之上的另一个全文搜索引擎。它具有与 Elasticsearch 相似的搜索、分析和扩展能力。对于大多数需要全文搜索引擎的应用程序，选择 Solr 和 Elasticsearch 主要取决于个人喜好。

Ferret

Ferret 是一个用于 Ruby 的全文搜索引擎。它与 Lucene 类似，但功能不如 Lucene 丰富。它通常更适合那些不需要搜索引擎（如 Elasticsearch 或 Solr）的强大（或复杂）功能的应用程序。

监控 Elasticsearch

监控分布式系统很困难，因为随着节点数量、用户数量和数据量的增加，问题将会开始出现。

此外，错误可能不会立即明显。通常，集群会继续运行并尝试自动从错误中恢复。如前所述的 图 1.2、1.3 和 1.4 所示，一个节点失败了，但 Elasticsearch 在我们没有采取任何行动的情况下将自己恢复到了 绿色 状态。除非进行监控，否则此类故障可能会被忽视。这可能会对系统性能和可靠性产生不利影响。节点越少，处理查询的能力就越弱，并且，如前例所示，如果另一个节点失败，我们的集群将无法返回到 绿色 状态。

我们希望跟踪的 Elasticsearch 集群方面包括以下内容：

集群健康和数据可用性
节点故障
Elasticsearch JVM 内存使用情况
Elasticsearch 缓存大小
系统利用率（CPU、内存和磁盘）
查询响应时间
查询速率
数据索引时间
数据索引速率
索引和分片数量
索引和分片大小
系统配置

在这本书中，我们将讨论如何理解这些变量在上下文中的含义，以及理解它们如何帮助我们诊断、恢复和预防集群中的问题。当然，不可能预先阻止所有 Elasticsearch 错误。然而，通过积极监控我们的集群，我们将对何时出现问题有一个很好的了解，并能够更好地采取纠正措施。

在接下来的章节中，我们将讨论从基于网络的集群监控工具到 Unix 命令行工具和日志文件监控的所有内容。本书涵盖的一些特定工具如下：

Elasticsearch-head
Bigdesk
Marvel
Kopf
Kibana
Nagios
Unix 命令行工具

这些工具将为我们提供有效诊断、解决和预防 Elasticsearch 问题所需的信息。

资源丰富性和问题解决能力

监控工具可以很好地告诉你集群中正在发生什么，并且它们经常可以指出是否存在问题。然而，这些工具不会给你一个解决问题的方案。解决问题需要批判性思维、关注细节和坚持不懈。本书讨论的一些问题解决主题如下：

总是尝试重现问题
时刻留意配置和用户错误
在测试之前，只做一次配置更改

本书还提供了一些实际案例研究，帮助您将监控工具提供的信息转化为解决 Elasticsearch 问题的见解。

摘要

本章为您概述了 Elasticsearch 以及为什么需要积极监控集群。为了总结本章要点：

Elasticsearch 是一个开源的、可扩展的、快速且容错的搜索引擎
Elasticsearch 是建立在 Apache Lucene 之上的，Apache Solr 同样使用这个库
监控工具将帮助我们更好地了解我们的集群，并让我们知道何时出现问题时
监控工具虽然很有帮助，但真正诊断和修复集群问题还得靠我们自己

在下一章中，我们将介绍如何启动一个简单的 Elasticsearch 集群并加载数据，以及如何安装几个监控工具。

第二章：Elasticsearch 的安装和需求

Java 运行时环境（JRE）是运行 Elasticsearch 的唯一要求。

官方 Elasticsearch 文档建议您使用 Oracle Java 8（更新 20 或更高版本），或 Oracle Java 7（更新 55 或更高版本）。一旦您选择了 JRE 的版本，我们建议您的所有节点使用相同的版本以保持兼容性。在集群中使用不同版本的 Java 或使用比此处指定的版本更早的 Java 版本可能会导致数据损坏。一旦您选择了 Elasticsearch 的版本，您的集群中的所有节点都应使用相同的版本。

虽然可以在 Windows 和 Linux 上运行 Elasticsearch，但本书专注于在 Linux 环境中单独使用它。Elasticsearch 文档以 Linux 为中心，Elasticsearch 社区的大部分人都在 Linux 上运行该软件。然而，没有理由生产集群的 Elasticsearch 不能在 Windows 上运行。

本章将特别介绍 Ubuntu、CentOS 和 Red Hat Enterprise Linux (RHEL) 的安装说明，但任何 Linux 发行版都适用。读者应使用 64 位操作系统而不是 32 位操作系统，因为前者允许为 JRE 分配更多内存。

本章涵盖以下主题：

安装 Elasticsearch
配置 Elasticsearch
安装监控工具（Elasticsearch-head、Bigdesk 和 Marvel）
集群需求

安装 Elasticsearch

在撰写本书时，Elasticsearch 2.3.2 是当前的稳定版本，Elasticsearch 5 正在 alpha 测试中。对于生产集群，我们建议使用 2.3.2 版本，一旦可用，应迅速更新到 5 通用可用（GA）版本。请注意，虽然 Elasticsearch 5 与在 Elasticsearch 2.x 中创建的索引兼容，但在 1.x 版本发布后也进行了一些 API 变更和功能弃用。在升级之前，读者应考虑到这些重要变更。有关从 2.x 升级到 5 的更多详细信息，可以在 Elastic 网站上的以下 URL 找到：

以下是一些显著的 API 变更：

Elasticsearch 1.x 的索引必须首先升级到 2.x，然后才能最终迁移到版本 5
已弃用的 filtered、or 和 and 查询已被 bool、must 和 should 查询所取代
string 映射已被 text 和 keyword 字段所取代
index 映射属性现在设置为 true / false 而不是 analyzed / not_analyzed / no
Percolate API 的重大变更
_id 值限制为 512 字节

虽然本书中的示例使用的是 2.3.2 版本的 Elasticsearch，但所有示例都应与即将推出的 5.0 版本兼容。

最新版本的 Elasticsearch 可在 www.elastic.co/downloads/elasticsearch 以 .zip、.tar.gz、.rpm 和 .deb 格式获取。Elasticsearch 的安装方式无关紧要，但我们推荐 Ubuntu 用户使用 .deb 安装程序，CentOS 或 RHEL 用户使用 .rpm 安装程序，其他 Linux 发行版用户或需要更定制化设置的用户使用 .tar.gz 或 .zip 版本，Elasticsearch 还提供官方的 yum 和 apt-get 仓库。

本章中的示例假设用户使用 .rpm 或 .deb 安装程序或通过官方的 yum 或 apt-get 仓库安装了 Elasticsearch。对于使用 .zip 和 .tar.gz 安装程序的用户也应类似。

DEB/RPM 安装

首先，从 elastic.co 下载最新版本的包：

在 Ubuntu 或 Debian 兼容系统上运行以下命令以安装 DEB 包：

wget https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-2.3
.2.deb
sudo dpkg -i elasticsearch-2.3.2.deb

在 CentOS、RHEL 或其他兼容系统上运行以下命令以安装 RPM 包：

wget https://download.elastic.co/elasticsearch/elasticsearch/elasticsearch-2.3.2.noar
ch.rpm
sudo rpm -i elasticsearch-2.3.2.noar
ch.rpm

yum 和 apt-get 仓库

官方的 yum 和 apt-get 仓库是安装 Elasticsearch 的好方法。然而，请确保您使用的是官方仓库。许多第三方 yum 和 apt-get Elasticsearch 仓库可供选择，但它们可能没有最新的稳定版本。

Ubuntu/Debian 和 apt-get

使用 apt-get 安装 Elasticsearch 的步骤如下：

要通过 apt-get 启用仓库，首先添加 gpg 密钥：

wget -qO - https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -

然后，通过以下方式添加仓库：

echo "deb http://packages.elastic.co/elasticsearch/2.3/debian stab
le
 main" | sudo tee -a /etc/apt/sources.list.d/elasticsearch-2.3.list

最后，使用您的包管理器安装以下内容：
```
sudo apt-get install elast
icsearch
```

CentOS/RHEL 和 yum

对于 yum，请按照以下步骤操作：

添加 gpg 密钥：

rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

然后，在 /etc/yum.repos.d/elasticsearch.repo 创建一个新的 yum 仓库，内容如下：

[elasticsearch-2.3]
name=Elasticsearch 2.3.X repository
baseurl=http://packages.elastic.co/elasticsearch/2.3/centos
gpgcheck=1
gpgkey=http://packages.elastic.co/GPG-KEY-elasticsearch
enabled=1

使用以下命令安装软件包：
```
sudo yum install e
lasticsearch
```

验证

使用以下命令启动 Elasticsearch：

sudo /etc/init.d/elasticsearch start

然后，验证安装，通过以下方式测试 Elasticsearch 是否正在运行并加载：

curl localhost:9200

您应该得到以下响应：

{
 "status" : 200,
 "name" : "Inertia",
 "cluster_name" : "Elasticsearch",
 "version" : {
 "number" : "2.3.2",
 "build_hash" : " b9e4a6acad4008027e4038f6abed7f7dba346f94",
 "build_timestamp" : "2016-04-21T16:03:47Z ",
 "build_snapshot" : false,
 "lucene_version" : "5.5.0"
 },
 "tagline" : "You Know, for Search"
}

要验证我们能否将数据写入 Elasticsearch，请使用以下命令：

curl -XPUT 'http://localhost:9200/twitter/user/lababidi' -d '{ "name" : "Mahmoud Lababidi" }'

这将返回以下内容：

{"_index":"twitter","_type":"user","_id":"lababidi","_version":1,"created":true}

我们获取数据，如下所示：

curl -XGET 'http://localhost:9200/twitter/user/lababidi?pretty=true'

这将返回以下输出：

{
 "_index" : "twitter",
 "_type" : "user",
 "_id" : "lababidi",
 "_version" : 1,
 "found" : true,
 "_source":{ "name" : "Mahmoud Lababidi" }
}

作为合理性检查，尝试一个不存在的记录：

curl -XGET 'http://localhost:9200/twitter/user/kimchy?pretty=true'

这应该返回预期的 false 对于 found：

{
 "_index" : "twitter",
 "_type" : "user",
 "_id" : "kimchy",
 "fo
und" : false
}

配置文件

值得注意的是 Elasticsearch 的安装位置，特别是配置文件和日志文件。例如，在 Ubuntu 上，运行以下命令：

dpkg -L Elasticsearch

这将显示安装将日志放在 /var/log/elasticsearch，配置文件放在 /etc/elasticsearch。Elasticsearch 的任何设置（与日志无关）都在 elasticsearch.yml 中，而 logging.yml 负责日志处理。

我们将在本书的后续部分进一步探讨这些文件及其相应的设置。

配置 Elasticsearch 集群

本节将涵盖一些基本的 Elasticsearch 配置，以及一些将对您的集群性能产生积极影响的更改。

大多数 Elasticsearch 配置更改都将应用于 elasticsearch.yml。对于我们在 Ubuntu 上的 Elasticsearch 安装，此文件位于 /etc/elasticsearch/elasticsearch.yml。Elasticsearch 内部配置更改应用于 elasticsearch.yml。环境变量可以在应用程序的启动脚本中设置。对于我们在 Ubuntu 上的 Elasticsearch 2.3.2 安装，这些文件位于以下位置：

内部配置位于

/etc/elasticsearch/elasticsearch.yml
环境变量配置位于

/etc/default/elasticsearch

集群名称

关于 Elasticsearch 的一个美妙之处在于构建集群的简便性。如果同一局域网（LAN）上的 Elasticsearch 节点将配置变量 cluster.name 设置为相同的值，它们将自动相互形成集群。

例如，如果我们将在我们的集群中存储来自 Twitter 的推文，我们可能希望将 cluster.name 设置为 twitter_development。稍后，我们可能希望创建另一个名为 twitter_production 的集群来存储所有生产数据。

要修改此设置，编辑 Elasticsearch.yml 文件并查找 cluster.name 设置。将此值更改为：cluster.name: twitter_development。

cluster.name 的默认值是 elasticsearch。在独立开发中使用它是可以的，但如果你在局域网（LAN）上与其他开发者一起使用，请小心使用。如果你使用默认的 cluster.name 值启动一个新的 Elasticsearch，而你的网络上的其他人也在使用默认配置运行 Elasticsearch，你将注意到他们的 Elasticsearch 实例中的数据将开始在你的机器上复制。

内存配置

Elasticsearch 建议将堆大小设置为机器可用 RAM 的一半，但不超过 30.5 GB。我们使用的是 16 GB RAM 的机器，因此我们将堆大小设置为 8 GB。此配置更改是在 /etc/default/elasticsearch 中的 ES_HEAP_SIZE 环境变量中进行的：

ES_HEAP_SIZE=8g

打开文件限制

Linux 限制了进程一次可以打开的文件描述符数量。这个限制存在是因为每次进程打开一个文件描述符时，都会使用一点内存。如果没有对打开文件数量的限制，一个进程可能会打开足够的文件，导致整个系统内存耗尽并崩溃。

默认情况下，此限制设置为 1024，这对于 Elasticsearch 来说太低了。官方 Elasticsearch 文档建议将此值提高到 32k 或 64k 以增加打开文件的数量。

最大文件限制

最新的.rpm和.deb安装程序将自动将 Elasticsearch 的最大打开文件限制增加到65535。然而，如果您使用较旧的.deb或.rpm版本，或者从 tarball 运行 Elasticsearch，您将必须手动增加限制。

要检查分配给当前用户的最大打开文件数，请运行以下命令：

$ ulimit -n 
65535

用户最多有65535个文件。然而，这并不意味着 Elasticsearch 被分配了这么多文件。这可能意味着 Elasticsearch 以不同的用户身份运行，或者是以不同的环境设置启动的。

要检查分配给 Elasticsearch 的最大打开文件数，请运行以下命令：

curl -XGET 'http://localhost:9200/_nodes?os=true&process=true&pretty=true'

结果应该看起来像这样：

{
 "ok" : true,
 "cluster_name" : "Elasticsearch",
 "nodes" : {
 "-P1cQt9lThejPG_rj-reKw" : {
 "name" : "Korg",
 ...
 "process" : {
 "refresh_interval" : 1000,
 "id" : 1407,
 "max_file_descriptors" : 1024
 }
 }
 }

我们看到max_file_descriptors被设置为1024，因此我们需要将其增加。如果您的输出显示65535，请跳到下一节。

确保这是针对适当的节点；这个curl命令将显示您集群中所有节点的max_file描述符。

在 Ubuntu Linux 上更新最大文件描述符

编辑/etc/security/limits.conf文件，并在文件末尾添加以下行：

*  soft  nofile 65536
*  hard  nofile 65536

小贴士

*符号表示所有用户。您也可以将其设置为仅运行 Elasticsearch 进程的用户。

启用可插拔认证模块

如果我们通过 SSH 连接到 Linux 服务器，我们必须确保 PAM 认证已启用。如果您使用 Ubuntu 或 CentOS/RHEL，这些说明是相同的。要做出此配置更改，编辑sshd_config文件：

sudo vim /etc/ssh/sshd_config

确保这一行存在：

UsePAM yes

然后，重新启动您的 SSH 服务器：

sudo service ssh restart

验证打开文件限制

注销并重新登录以使这些更改生效，然后重新启动 Elasticsearch 服务器：

exit
ssh <yo
ur_username>@<your_server>
sudo service elasticsearch restart

最后，务必验证这些更改是否生效。仅验证ulimit -n返回65536是不够的。还必须确保 Elasticsearch 用户已正确启动，并具有增加的最大打开文件限制：

curl -XGET 'http://localhost:9200/_nodes?os=true&process=true&pretty=true'

这应该导致以下结果：

{
 "ok" : true,
 "cluster_name" : "Elasticsearch",
 "nodes" : {
 "-P1cQt9lThejPG_rj-reKw" : {
 "name" : "Korg",
 ...
 "process" : {
 "refresh_interval" : 1000,
 "id" : 1407,
 "max_file_descriptors" : 65536
 }
 }
 }

这次我们看到max_file_d escriptors被设置为65536。

禁用交换

在您的操作系统或 Elasticsearch 进程中禁用内存交换是很重要的。

要在系统重新启动之前禁用交换，请运行以下命令：

sudo swapoff -a

要在系统重新启动后禁用交换，编辑/etc/fstab文件，并注释掉包含swap一词的任何行。对我们来说，这看起来像以下这样：

# /dev/xvdb   none         swap    sw 
 0 0

要仅禁用 Elasticsearch 的交换，您首先必须使用ES_HEAP_SIZE设置 Elasticsearch 堆大小，并以 root 用户将进程的最大锁定内存设置为ulimited。如果您使用.rpm或.deb安装程序，这两个设置都可以在/etc/init.d/elasticsearch启动脚本中更改。具体来说，取消注释并更新以下行，如下所示：

（我的机器有 512MB 的内存，所以我将ES_HEAP_SIZE设置为256m。）

# Set ES_HEAP_SIZE to 50% of available RAM, but no more than 31gES_HEAP_SIZE=256m

有一点更远：

# Maximum amount of locked memory
MAX_LOCKED_MEMORY=unlimited

接下来，编辑您的 elasticsearch.yml 文件，并添加以下行：

bootstrap.mlockall: true

然后，重启您的 Elasticsearch 节点：

sudo service elasticsearch restart

最后，通过运行以下命令来验证此设置是否成功：

curl http://localhost:9200/_nodes/process?pretty

您应该看到以下内容：

"mlockall"
 : true

这是响应。

了解您的集群

Elasticsearch 有许多不同的组件，确保所有组件正常运行可能会变得有些复杂。幸运的是，有一些优秀的开源监控工具可供您使用，以帮助您监控您的集群。本节将介绍如何在您的集群上安装一些最受欢迎和最有用的监控工具，接下来的两个章节将更详细地介绍这些工具。

安装 Elasticsearch-head

Elasticsearch-head 是一个简单、免费、开源的工具，它提供了对您的集群的高级检查。它是管理集群和监控集群健康状况时最常用的工具之一。Elasticsearch-head 只需要在您的集群中的一个节点上安装。然而，我们建议在所有节点上安装它以提高冗余性。它作为 Elasticsearch 插件安装。

如果您有互联网连接，您可以使用 Elasticsearch 的 plugin 工具安装 Elasticsearch-head，如下所示：

sudo /usr/share/elasticsearch/bin/plugin install mobz/elasticsearch-head

plugin 脚本的位置可能会有所不同。

下一个命令假设您使用 .rpm 或 .deb 文件安装了 Elasticsearch，但如果您不确定插件脚本在您的安装中的位置，请尝试运行以下命令：

sudo updatedb
locate elasticsearch | grep plugin$

对于我来说，这返回以下内容：

/usr/share/elasticsearch/bin/plugin

如果您的 Elasticsearch 实例没有互联网连接，您可以下载 Elasticsearch-head 插件，将其传输到您的服务器，并使用以下方法进行安装。

从一个有互联网连接的机器上，我们使用以下方法：

wget https://github.com/mobz/elasticsearch-head/archive/ma
ster.zip -O Elasticsearch-head.zip
scp Elasticsearch-head.zip your_server:~/

从 Elasticsearch 服务器，我们使用以下方法：

sudo /usr/share/elasticsearch/bin/plugin install file:///path/to/Elasticsearch-head.zip

如果您运行的是旧版本的 Elasticsearch，您可能需要在打开 Elasticsearch-head 之前重启您的节点：

sudo service elasticsearch restart

通过访问 http://elasticsearch-server:9200/_plugin/head/（对于测试环境，elasticsearch-server 可能是 localhost）来试用此插件。您应该看到以下内容：

安装 Bigdesk

Bigdesk 是一个免费的开源 Elasticsearch 插件，它允许您查看您集群的 CPU、内存和磁盘使用情况。这是一个很好的工具，可以深入挖掘集群的性能问题，并且与 Elasticsearch-head 类似，它只需要在您的集群中的一个节点上安装。我们仍然建议在所有节点上安装它以提高冗余性。

这是安装 Bigdesk 的方法。

在线安装如下：

sudo /usr/share/elasticsearch/bin
/plugin install AIsaac08/bigdesk

离线安装有多个方法。

从一个有互联网连接的机器上，使用以下方法：

wget https://github.com/AIsaac08/bigdesk/zipball/master -O bigdesk.zip
scp bigdesk.zip your_server:~/

从 Elasticsearch 服务器，使用以下方法：

sudo /usr/share/elasticsearch/bin/plugin install file:///path/to/bigdesk.zip

与 Elasticsearch-head 类似，如果您运行的是旧版本的 Elasticsearch，您可能需要在打开 Bigdesk 之前重启您的节点：

sudo service elasticsearch restart

通过访问http://elasticsearch-server:9200/_plugin/bigdesk/（对于测试环境，elasticsearch-server 可能是 localhost）尝试插件。你应该会看到以下内容：

Marvel

Marvel 是由 Elasticsearch 制作者创建的一个强大的监控工具。在开发中使用它是免费的，但在生产中使用则需要订阅费用。Marvel 由以下两个组件组成：

Marvel 代理（需要 Marvel 许可证）。
Marvel 仪表板（需要 Kibana）。

要安装 Marvel 代理：

在线安装如下：

sudo /usr/share/elasticsearch/bin/plugin install license
sudo /usr/share/elasticsearch/bin/plugin install marvel-agent

离线安装如下：

wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/plugin/license/2.3.3/license-2.3.3.zip
wget https://download.elastic.co/elasticsearch/release/org/elasticsearch/plugin/marvel-agent/2.3.3/marvel-agent-2.3.3.zip

sudo bin/plugin install file:///absolute/path/to /license-2.3.3.zip
sudo bin/plugin install file:///absolute/path/to/marvel-agent-2.3.3.zip

安装 Marvel 代理后重启 Elasticsearch：

sudo service elasticsearch restart

要安装 Marvel 仪表板，请按照以下步骤操作：

首先，安装 Kibana：

wget https://download.elastic.co/kibana/kibana/kibana-4.5.1-linux-x64.tar.gz
tar xzvf kibana-4.5.1-linux-x64.tar.gz

接下来，将 Marvel 仪表板作为 Kibana 插件安装：

cd kibana-4.5.1
wget https://download.elasticsearch.org/elasticsearch/marvel/marvel-2.3.3.tar.gz
bin/kibana plugin --install marvel --url file:///tmp/marvel-2.3.3.tar.gz

启动 Kibana：
```
./bin/kibana
```
通过访问http://server-name:5601/（对于测试环境，server-name可能是localhost）打开 Marvel 仪表板。你应该会看到以下内容：

集群要求

你集群的要求——节点的数量以及每个节点的硬件规格——取决于以下几个因素：

数据总量
数据摄取率
平均记录大小
数据映射
正在运行的查询类型
系统性能要求

没有一个通用的公式可以确定特定 Elasticsearch 用例的集群要求。最佳方法是仔细测试性能，同时改变变量，如分片大小、集群中的节点数量和硬件配置，直到找到最佳解决方案。本节重点介绍在配置你的集群时应考虑的高级指南。

在生产环境中运行至少三个节点是一个好主意，并将数据复制设置为1，这将要求 Elasticsearch 在集群中维护每个分片的一个副本。这种配置将确保如果一个节点宕机，你的集群不会丢失任何数据。

Elasticsearch 通常比 CPU 密集型更注重内存。任何现代 64 位处理器都可能是运行 Elasticsearch 的足够选择。一般来说，这更倾向于更多的处理器核心而不是更快的时钟速度。

集群中的每个节点应至少有 512 MB 的 RAM，其中一半应分配给 Elasticsearch。Elasticsearch 文档建议不要将超过 30.5 GB 的内存分配给 Elasticsearch 节点，因为当堆大小小于 30.5 GB 时，JVM 会压缩内部存储的内存地址，但当分配的堆大小超过 30.5 GB 时，就不再能这样做。一个很好的经验法则是每个节点总内存不超过 64 GB。此外，在确定集群的总内存需求时，你可能会需要的总系统内存比总索引大小少得多，但具体数量将取决于你的使用情况。

当考虑为 Elasticsearch 集群选择存储时，优先选择内部硬盘而非网络附加存储（NAS）解决方案。使用固态硬盘代替传统硬盘将大大提升整体系统性能。

摘要

本章涵盖了 Elasticsearch 的安装、配置、监控工具和集群需求。例如 Elasticsearch-head、Bigdesk 和 Marvel 等工具都为监控您的集群和分析其性能奠定了基础。然而，您仍然需要知道要关注哪些方面以及如何找到它们。在下一章中，我们将进一步探讨 Elasticsearch-head 和 Bigdesk，并讨论在监控 Elasticsearch 集群时这些工具中需要关注的重要事项。

第三章：Elasticsearch-head 和 Bigdesk

本章讨论了 Elasticsearch 监控插件 Elasticsearch-head 和 Bigdesk，以及 Elasticsearch cat API。这些实用工具用于评估集群状态和诊断问题：

Elasticsearch-head：此工具用于了解集群的整体健康状况、单个节点状态以及理解您的索引
Bigdesk：此工具用于查看集群中各个节点的内存、磁盘和 CPU 使用情况
Elasticsearch cat API：此 API 允许您在不安装任何插件的情况下访问 Elasticsearch 的许多内部指标

具体来说，本章探讨了以下内容：

配置 Elasticsearch 集群
将示例数据加载到 Elasticsearch 中
使用 Elasticsearch-head
使用 Bigdesk
Elasticsearch cat API

集群设置

本节介绍配置一个三节点 Elasticsearch 集群并将其加载 Twitter 数据的过程。

集群配置

设置 Elasticsearch 集群很简单。集群中的所有节点应位于同一本地网络，并安装了相同版本的 Java 和 Elasticsearch。对于我们的集群，我们将使用三个 Ubuntu Linux 14.04 虚拟主机：elasticsearch-node-01、elasticsearch-node-02和elasticsearch-node-03。

在所有主机上安装 Elasticsearch 后，按照以下方式更新每个主机的elasticsearch.yml配置文件：

elasticsearch-node-01的配置如下：

cluster.name: my_elasticsearch_cluster
node.name: "elasticsearch-node-01"
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["elasticsearch-node-02", "elasticsearch-node-03"]
index.routing.allocation.disable_allocation: false
cluster.routing.allocation.enable : all

elasticsearch-node-02的配置如下：

cluster.name: my_elasticsearch_cluster
node.name: "elasticsearch-node-02"
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["elasticsearch-node-01", "elasticsearch-node-03"]
index.routing.allocation.disable_allocation: false
cluster.routing.allocation.enable : all

elasticsearch-node-03的配置如下：

cluster.name: my_elasticsearch_cluster
node.name: "elasticsearch-node-03"
discovery.zen.ping.multicast.enabled: false
discovery.zen.ping.unicast.hosts: ["elasticsearch-node-01", "elasticsearch-node-02"]
index.routing.allocation.disable_allocation: false
cluster.routing.allocation.enable : all

接下来，按照前一章中的说明，在集群中的所有节点上安装 Elasticsearch-head。

现在，重新启动所有节点，通过访问http://elasticsearch-node-01:9200/_plugin/head/的 Elasticsearch-head 来验证集群是否正确形成。

您应该看到类似以下内容，其中列出了集群的所有节点在左侧列：

示例数据

现在我们已经有一个集群在运行，让我们用 Twitter 数据填充它。我们使用 Twitter 数据作为示例，因为它容易大量获取，并且它是一个持续流动的信息流，类似于许多现实世界的数据集。

使用 Elasticsearch 的stream2es实用工具获取 Twitter 数据。此实用工具可在github.com/elastic/stream2es找到：

如果您已经有了 Twitter 账户，请创建一个新的 Twitter 账户或登录您的 Twitter 账户。
在support.twitter.com/articles/110250将您的手机号码与账户关联。
在apps.twitter.com/app/new创建一个新的 Twitter 应用程序。

小贴士

对于网站，如果您没有域名，可以放置一个占位符值，例如http://example.com。
在 密钥和访问令牌 选项卡中记下你的 消费者密钥（API 密钥） 和 消费者密钥（API 密钥）：
```
./stream2es twitter --authorize --key CONSUMER_KEY --secret CONSUMER_SECRET
```
授权应用。
输入验证码。

创建 Twitter 映射：

curl -XPUT 'http://localhost:9200/twitter/' -d '{
 "settings" : {
 "index" : {
 "number_of_shards" : 3,
 "number_of_replicas" : 1
 }
 }
}'

收集推文：

./stream2es twitter --target http://localhost:9200/twitter/status --settings '{
 "settings" : {
 "index" : {
 "number_of_shards" : 3,
 "number_of_replicas" : 2
 }
 }
}'

查看正在进入的推文：

curl -XGET "http://localhost:9200/twitter/_search?size=0&pretty"

在让 stream2es 运行一段时间后，我们得到以下结果：

{
 "took" : 63,
 "timed_out" : false,
 "_shards" : {
 "total" : 3,
 "successful" : 3,
 "failed" : 0
 },
 "hits" : {
 "total" : 150765,
 "max_score" : 0.0,
 "hits" : [ ]
 }
}

现在我们已经用一些示例数据填充了我们的集群，我们可以讨论如何使用 Elasticsearch-head、Bigdesk 和 Elasticsearch cat API。

Elasticsearch-head

在第二章中，我们介绍了并安装了 Elasticsearch-head，现在我们将开始检查其功能。

概览选项卡

在 Elasticsearch-head 中的第一个选项卡是概览选项卡。此选项卡回答以下问题：

集群中有多少个节点？
集群是否处于健康状态？
是否所有集群数据都可用？
集群中有多少个索引，它们有多大？
集群中有多少数据？

用户还可以使用此选项卡执行一些基本的行政操作（创建索引、删除索引等）。

在加载了上一节中的示例 Twitter 数据后，我们的概览选项卡看起来如下：

我们可以看到有三个节点正在运行：

elasticsearch-node-01
elasticsearch-node-02
elasticsearch-node-03

我们还有一个包含我们新加载的 Twitter 数据的活跃索引。从这一页，我们可以得知以下信息：

Twitter 索引占用 456 MB
Twitter 索引包含 150,765 个文档

集群状态

一个 Elasticsearch 集群可以处于以下三种状态之一：

绿色：所有数据都可用，所有分片副本都已分配。

注意

之前的截图显示我们目前处于 绿色 状态。
黄色：所有数据都可用，但并非所有副本都已分配：
- 这通常发生在只有一个节点的集群中，当你有大于 0 的副本大小时，或者在多节点集群中，节点宕机后立即发生。
- 如果你的集群中某个节点宕机，在所有副本分片重新分配后，黄色 状态会自行解决。
- Elasticsearch 将在默认的 1 分钟等待时间后自动尝试重新分配分片，以查看有问题的节点是否重新出现。
红色：并非所有数据都可用，并非所有分片都已分配。
- 这种状态需要立即关注。这通常是由于集群中同时发生多个节点故障，例如同时重启、电源故障或网络故障所引起的。
- 解决这种状态的最佳方法是让集群中所有宕机的节点重新启动。
- 注意，即使在 红色 状态下，Elasticsearch 仍然会返回查询结果。然而，查询计数将不准确。

为了演示目的，我们将关闭 elasticsearch-node-02 和 elasticsearch-node-03，以了解集群在不同状态下的样子：

关闭elasticsearch-node-02:

ssh elasticsearchn-node-02
sudo /etc/init.d/elasticsearch stop

刷新 Elasticsearch-head。我们应该看到类似以下的内容：

注意，elasticsearch-node-02不再存在，并且集群处于黄色状态。

记住，黄色状态表示所有数据仍然可用。更多的节点故障可能会导致红色状态或数据不可用。

等待几分钟之后，Elasticsearch 将开始将这些分片重新分配到剩余的主机：

在重新分配完成后，集群将恢复到绿色状态：

让我们进行实验，将集群状态转换为红色：

将elasticsearch-node-02重新启动，并等待直到elasticsearch-node-02分配了几个分片。
一旦发生这种情况，关闭elasticsearch-node-02和elasticsearch-node-03，不要给集群时间重新分配分片。

您可以在 Elasticsearch-head 中选择每个相应节点旁边的关闭操作，或者通过命令行进行：

ssh elasticsearchn-node-02
sudo /etc/init.d/elasticsearch stop
ssh elasticsearchn-node-03
sudo /etc/init.d/elasticsearch stop

关闭这些节点并刷新 Elasticsearch-head 后，我们会看到类似以下的内容：
注意，只有 Twitter 索引中的1和2分片被分配，而分片0是未分配的。因此，索引大小和文档数量分别从 456 MB 减少到 305 MB，从 150,765 减少到 100,573。
一旦我们重启elasticsearch-node-02和elasticsearch-node-03，集群将恢复并返回到绿色状态。

节点和索引操作

在每个节点和索引的名称旁边，您会看到标记为信息和操作的下拉菜单。这些下拉菜单中的每个链接都对应于各种 Elasticsearch API 调用：

信息链接会返回所有包含有关您的索引或节点状态的详细信息的JSON文档
操作链接提供了方便的方法来操作您的集群

下面的表格将更详细地介绍这些链接中的每一个：

目标（索引或节点）	类型（操作或信息）	名称（例如，“节点状态”）	Elasticsearch API 方法	描述
节点	信息	集群节点信息	`GET /_nodes`	这提供了节点的 Elasticsearch 配置、已安装的插件以及服务器可用的内存、CPU 和磁盘空间。
节点	信息	节点状态	`GET /_nodes/stats?all=true`	这提供了存储在节点上的 Elasticsearch 文档的数量和统计信息。还提供了 JVM、网络和文件系统指标。
节点	操作	关闭	`POST /_cluster/nodes/<NODE_ID>/_shutdown`	这将在指定的节点上关闭 Elasticsearch 进程。
索引	信息	索引状态	`GET /_status`	这提供了有关指定索引的信息，例如状态、文档数量、大小以及各种其他指标。
索引	信息	索引元数据	`GET /_cluster/state`	这提供了索引的映射、别名和设置。
索引	操作	新建别名...	`POST /_aliases`	这将创建一个新的索引别名。
索引	操作	刷新	`POST /<INDEX_NAME>/_refresh`	这将刷新索引。
索引	操作	刷新	`POST /<INDEX_NAME>/_flush`	这将刷新索引。
索引	操作	优化...	`POST /<INDEX_NAME>/_optimize`	这将优化索引。
索引	操作	网关快照	`POST /<INDEX_NAME>/_gateway/snapshot`	这将获取索引的快照。
索引	操作	测试分析器	`GET /<INDEX_NAME>/_analyze?text=TEXT`	这将使用索引的默认文本分析器分析传入的文本。
索引	操作	关闭	`POST /<INDEX_NAME>/_analyze`	这将关闭一个打开的索引。
索引	操作	打开	`POST /<INDEX_NAME>/_open`	这将打开一个关闭的索引。
索引	操作	删除	`POST /<INDEX_NAME>/_delete`	这将删除索引。

备注

刚才列出的信息操作（集群节点信息、节点统计、索引状态和索引元数据）提供了大量关于集群状态和数据持有情况的信息。然而，查看这些项目的 JSON 响应可能会有些令人眼花缭乱。

Bigdesk 是我们将在本章中探讨的下一个工具。Bigdesk 和我们在下一章将要探讨的工具 Marvel 都采用了许多这些指标，并以易于阅读的图表和图形的形式展示出来。

索引标签页

索引标签页提供了集群中索引的列表、它们的磁盘大小使用情况和每个索引中的文档数量。它也是一种创建新索引的方式。

备注

此标签页不提供关于索引的任何额外信息，除了在概览标签页中提供的信息。

浏览器标签页

此标签页允许你浏览、查看和运行基本过滤查询，针对索引中的文档。以下截图是浏览器标签页中文档视图的一个示例：

结构化查询标签页

结构化查询标签页是一个高级查询构建器，用于探索索引中的文档。当你想要构建一个复杂的查询而不需要写出完整的 JSON 请求体时，此标签页非常有用。

以下截图显示了使用此界面创建的示例查询和结果：

任意请求标签页

任意请求标签页允许你在集群上运行任意的API调用，并在JSON中查看结果。以下截图显示了示例聚合查询：

官方网站

想要了解更多关于 Elasticsearch-head 的信息，请访问插件网站mobz.github.io/elasticsearch-head/。

Bigdesk

Bigdesk 是一个用于查看集群的各个 JVM 和操作系统级别指标的工具。如果你的集群运行缓慢或遇到异常错误，Bigdesk 是一个检查任何异常的好地方。

在遵循上一章的安装说明后，通过访问http://elasticsearch-node-01:9200/plugin/bigdesk/来访问 Bigdesk。初始着陆页面看起来如下：

类似于 Elasticsearch-head，这个页面显示了你的集群节点和集群健康状态。点击顶部行中列出的任何节点以显示其单个指标：

在此截图中，我们选择了elasticsearch-node-02并正在查看JVM指标。本节中的一个显著图表是Heap Mem。如果你接近最大已提交堆内存量，你将希望通过将ES_HEAP_SIZE设置为最多你可用内存的一半来增加你的堆内存。

在下面，我们可以看到操作系统指标，具体如下：

CPU 使用率
内存使用
交换空间使用
平均负载

在操作系统指标下方，我们来到进程级别指标，包括以下内容：

打开的文件描述符
进程内存使用
CPU 使用率

如果你在经历慢查询或慢数据索引操作时，可以参考操作系统和进程指标图表，以了解性能瓶颈。

继续向下滚动页面，我们会看到一些更显著的图表，包括：

缓存大小
索引操作
文件系统活动

缓存大小图表是此截图中的重要数据。根据你运行的查询类型，ID、Filter和Field缓存可能会填满。如果它们变得过大，检查你的查询以进行可能的修改，以保持缓存大小。

Bigdesk 图表对于查找配置错误也很有用。例如，如果我们打算将我们的节点配置为使用32GB的内存和最多65535个打开的文件描述符，但JVM Heap Mem图表只显示247MB的已提交内存，而Process File Descriptors图表显示文件限制为1024，我们将知道我们没有正确配置节点。

注意

想了解更多关于 Bigdesk 的信息，请访问插件网站bigdesk.org/。

Elasticsearch cat API

将Elasticsearch cat API视为前面提到的Elasticsearch Cluster和Indices APIs的简化版本。cat API 以易于阅读、以制表符分隔的格式返回结果，与集群和索引 API 返回的 JSON 不同。

API 方法的完整列表可在www.elastic.co/blog/introducing-cat-api找到，但以下是一些亮点，我们将在以下部分进行介绍。

背景

Elasticsearch-head 和 Bigdesk 主要由 Elasticsearch API 驱动：

集群 API: www.elastic.co/guide/en/elasticsearch/reference/1.7/cluster.html.
索引 API: www.elastic.co/guide/en/elasticsearch/reference/1.7/indices.html.

这两个 API 提供了大量关于 Elasticsearch 内部工作原理的信息。然而，它们也返回了复杂的 JSON 文档，难以快速解读。例如，以下是调用索引统计 API 的一个片段：

curl -XGET "http://elasticsearch-node-01:9200/_stats?pretty"
{
 ...
 "_all" : {
 "primaries" : {
 "store" : {
 "size_in_bytes" : 477638305,
 "throttle_time_in_millis" : 0
 },
 ...

很可能不会立即清楚 size_in_bytes 的 477638305 值等于 455 MB。

计数

此端点提供整个集群的文档计数：

curl -XGET http://elasticsearch-node-01:9200/_cat/count?v

这给出了输出：

epoch      timestamp count
1445910583 21:49:43  150765

注意

将 v 选项传递给 cat API 会显示标题行。

输出列表示以下内容：

epoch: 这表示 Unix 时间戳
timestamp: 这表示一天中的时间
count: 这表示集群中的文档数量

健康

此端点显示集群的健康颜色代码：

curl -XGET http://elasticsearch-node-01:9200/_cat/health?v

这给出了输出：

epoch      timestamp cluster                    status node.total node.data shards pri relo init unassign pending_tasks 
1445910646 21:50:46  my_elasticsearch_cluster green           3         3      6   3    0    0        0 
 0

这些列表示以下内容：

epoch: 这表示 Unix 时间戳
timestamp: 这表示一天中的时间
cluster: 这表示集群名称
status: 这表示集群状态（green、yellow 或 red）
node.total: 这表示集群中的节点数量
node.data: 这表示集群中的数据节点数量
shards: 这表示集群中总分片数量
pri: 这表示主分片数量（与副本分片相对）
relo: 这表示当前正在重新定位的分片数量
init: 这表示当前正在初始化的分片数量
unassign: 这表示未分配分片数量
pending_tasks: 这表示集群任务队列中的任务数量

索引

此端点提供集群中所有索引的列表、文档计数和大小：

curl -XGET http://elasticsearch-node-01:9200/_cat/indices?v

这给出了输出：

health status index pri rep docs.count docs.deleted store.size pri.store.size 
green  open   twitter   3   1     150765            0      911mb        455.5mb

此输出为集群中的每个索引一行。输出列表示以下内容：

health: 这是索引健康状态（green、yellow 或 red）
status: 这表示索引是打开还是关闭
index: 这是索引名称
pri: 这是主分片数量
rep: 这是复制级别（1 表示所有分片都复制一次）
docs.count: 这是此索引中的文档数量
docs.deleted: 这是已删除文档的数量
store.size: 这是总索引大小
pri.store.size: 这是索引（无副本）的大小

分片

此端点提供索引分片列表及其分布情况：

curl -XGET http://elasticsearch-node-01:9200/_cat/shards?v

这给出了输出：

index   shard prirep state    docs   store ip           node 
twitter 0     r      STARTED 50192 150.2mb 127.0.1.1    elasticsearch-node-03 
twitter 0     p      STARTED 50192 150.2mb 192.168.56.1 elasticsearch-node-01 
twitter 1     p      STARTED 50305   152mb 127.0.1.1    elasticsearch-node-03 
twitter 1     r      STARTED 50305   152mb 127.0.1.1    elasticsearch-node-02 
twitter 2     p      STARTED 50268 153.2mb 127.0.1.1    elasticsearch-node-02 
twitter 2     r      STARTED 50268 153.2mb 192.168.56.1 elasticsearch-node-01

此输出中的每一行代表集群中的一个单个分片。列表示以下内容：

index: 这是索引名称
shard: 这是碎片编号
prirep: 如果是主碎片则为p，如果是副本则为r
state: 这是碎片的可用性
docs: 这是该碎片中的文档数量
store: 这是碎片在磁盘上的大小
ip: 这是碎片所在的服务器 IP 地址
node: 这是碎片所在的服务器名称

摘要

本章讨论了如何配置和将数据加载到三节点 Elasticsearch 集群中。此外，还介绍了如何使用 Elasticsearch-head、Bigdesk 和 cat API 监控集群。

下一章将讨论 Marvel——官方 Elasticsearch 监控工具。

第四章：Marvel 仪表板

前两章介绍了 Elasticsearch-head 和 Bigdesk，这两个开源监控工具。本章将介绍 Marvel，这是一个用于监控 Elasticsearch 的非免费工具。

与 Elasticsearch-head 和 Bigdesk 不同，Marvel 会持续捕获并保存性能指标到一个索引中。这使得用户可以参考历史数据进行分析，而不仅仅是实时数据分析。在本章中，我们将更详细地探讨以下主题：

设置 Marvel
升级 Marvel
配置 Marvel
Marvel 索引配置
Marvel 仪表板
监控节点故障

设置 Marvel

有关如何安装 Marvel 代理和 Marvel Kibana 仪表板的说明，请参阅第二章，Elasticsearch 的安装和需求。

Marvel 将其指标数据存储在 Elasticsearch 中。有可能将这些指标与生产数据存储在同一个 Elasticsearch 集群中；然而，这是不可取的，因为：

Marvel 的数据索引可能会变得非常大，在生产环境中，你不会希望这些索引影响你的主集群的性能。
如果主集群遇到问题，将 Marvel 放在单独的集群中将允许你更容易地诊断这些问题。
如果 Marvel 运行在普通数据节点上，它可能会意外地被配置为收集其自己的指标索引上的数据。例如，如果你登录到 Marvel 仪表板并开始查询 Marvel 索引，这些查询将被记录回 Marvel 索引。这可能不是预期的行为。

由于这些原因，本章介绍了如何设置一个单独的 Elasticsearch 集群来存储 Marvel 指标数据。我们上一章中的主 Elasticsearch 集群包含三个数据节点：elasticsearch-node-01、elasticsearch-node-02和elasticsearch-node-03。我们将添加一个新的集群，包含一个 Elasticsearch 节点来存储 Marvel 的数据。

按照以下步骤创建一个新的 Elasticsearch 集群来存储 Marvel 数据：

在一个名为elasticsearch-marvel-01的新主机上，按照第二章中的说明，使用Elasticsearch 的安装和需求安装 Elasticsearch 2.3.2。

通过编辑elasticsearch.yml配置文件来配置 Elasticsearch，使其看起来像这样：

index.routing.allocation.disable_allocation: false
cluster.routing.allocation.enable : all
marvel.agent.enabled: false
cluster.name: my_monitoring_cluster
node.name: elasticsearch-marvel-01
bootstrap.mlockall: true
discovery.zen.ping.multicast.enabled: false

在elasticsearch-marvel-01上安装 Elasticsearch-head:

 sudo /usr/share/elasticsearch/bin/plugin 
 install mobz/elasticsearch-head

在三个主要 Elasticsearch 节点（elasticsearch-node-01、elasticsearch-node-02和elasticsearch-node-03）上安装 Marvel 代理。登录到每个主机并运行以下命令来安装 Marvel：
```
 sudo /usr/share/elasticsearch/bin/plugin install license
 sudo /usr/share/elasticsearch/bin/plugin install marvel-agent
```
小贴士

如第二章中所述，确保在安装 Marvel 后重启每个节点，以便启动 Marvel 代理。

将以下配置行添加到原始三个 elasticsearch-node-0* 节点上的 elasticsearch.yml：

marvel.agent.exporters:
 my_monitoring_cluster:
 type: http
 host: ["http://elasticsearch-marvel-01:9200"]

对于具有三个节点的较大 Marvel 集群，例如，配置行可能看起来像这样：

marvel.agent.exporters:
 my_monitoring_cluster:
 type: http
 host: ["elasticsearch-marvel-01:9200", "elasticsearch-marvel-02:9200", "elasticsearch-marvel-03:9200"]

根据第二章中找到的说明，在 elasticsearch-marvel-01 上安装 Kibana 和 Marvel Kibana 插件，Elasticsearch 的安装和需求。

通过编辑 config/kibana.yml 来配置 Marvel Kibana 插件，使其看起来像这样：

server.port: 5601
server.host: "0.0.0.0"
elasticsearch.url: http://elasticsearch-marvel-01:9200

使用以下命令从 Kibana 安装目录启动 elasticsearch-marvel-01 上的 Kibana：
```
bin/kibana
```
此命令的输出应如下所示：
通过访问 http://elasticsearch-marvel-01:5601/app/marvel 在浏览器中访问 elasticsearch-marvel-01 上的 Marvel 仪表板，如以下截图所示：
滚动页面并单击 显示历史记录 或 隐藏历史记录 按钮（如下一张截图所示）以查看 twitter 索引的分片活动：
在 elasticsearch-marvel-01 上打开 Elasticsearch-head 并通过访问 http://elasticsearch-marvel-01:9200/_plugin/head/ 查看 Marvel 自动创建的索引：

.marvel-2015.12.20 索引包含 Marvel 收集的历史数据。默认情况下，Marvel 每天创建一个新的索引来存储其数据。

注意

服务器时间同步

所有 Elasticsearch 主机上的时钟必须同步，否则 Marvel 不会显示任何数据。时钟同步取决于服务器配置。在 Ubuntu 主机集群上，请在所有节点上运行以下命令以同步它们的时钟：

sudo ntpupdate pool.ntp.org

升级 Marvel

Marvel 可以滚动升级。这意味着节点是一个接一个地升级，而不是必须关闭整个集群以执行升级。对于具有监控集群和生产集群的环境，请在升级生产集群之前先在监控集群上升级 Marvel。

要升级 Marvel Agent，请在监控集群（在这种情况下，仅为 elasticsearch-marvel-01）的所有节点上运行以下步骤，然后对于生产集群（elasticsearch-node-01、elasticsearch-node-02 和 elasticsearch-node-03）中的每个节点：

可选：在所有节点上禁用分片分配。

小贴士

禁用分片分配将使升级更快，因为当节点因升级而关闭时，集群不会尝试将分片重新分配到其他节点。

运行以下命令：
```
curl -XPUT elasticsearch-host-01:9200/_cluster/settings 
-d '{
 "transient" : {
 "cluster.routing.allocation.enable" : "none"
 }
 }' 
```
停止 Elasticsearch：
```
sudo /etc/init.d/elasticsearch stop
```
删除旧的 Marvel 插件：
```
bin/plugin remove marvel-agent
```
安装新的 Marvel 插件：
```
plugin install marvel-agent 
```
启动 Elasticsearch：
```
sudo /etc/init.d/elasticsearch start 
```
检查日志以查找错误：
```
tail -f /var/log/elasticsearch/*
```

一旦集群中的所有节点都升级完成，重新启用分片分配：

curl -XPUT elasticsearch-host-01:9200/_cluster/settings -d '{ 
 "transient" : { 
 "cluster.routing.allocation.enable" : "all" 
 } 
}'

对生产集群重复所有这些步骤。

要升级 Marvel Kibana 仪表板，请在 elasticsearch-marvel-01 上运行以下命令
使用以下命令卸载旧的 Marvel Kibana 插件：
```
bin/kibana plugin --remove marvel
```
安装新的 Marvel Kibana 插件。在此示例中，我们升级到 Marvel 2.3.2：
```
bin/kibana plugin install marvel
/2.3.2
```

配置 Marvel

本节介绍如何配置 Marvel 代理和数据索引。具体来说，我们包括：

设置 Marvel 数据存储位置
指定要监控的索引
安全设置
数据导出频率
Marvel 索引配置

Marvel 代理配置设置

本节介绍如何配置 Marvel 代理。通过编辑每个我们监控的节点上的 elasticsearch.yml 文件来配置代理。

marvel.agent.exporters 设置确定代理将把其指标发送到何处。默认情况下，Marvel 代理将导出数据到它安装上的同一个 Elasticsearch 实例。在我们的示例集群中，我们导出数据到 elasticsearch-marvel-01，配置值看起来像这样：

marvel.agent.exporters:
  my_monitoring_cluster:
    type: http
    host: ["http://elasticsearch-marvel-01:9200"]

marvel.agent.exporters 设置的其他选项包括：

marvel.agent.exporters:
  your_exporter_name:
    type: http # Set to local or http
    host: [ "http://host-01:9200", "http://host-02:9200" ]
    # List of hosts to send data to over http or https

    auth:
      username: basic_auth_username # optional           
      password: basic_auth_password # optional

    connection:
      timeout: 6s # optional: connection timeout 
      read_timeout: 60s # optional: response timeout.
      keep_alive: true # persistent connections 

    ssl:
      hostname_verification: true # https only: verify host certificate
      protocol: TLSv1.2 # https only: protocol
      truststore.path: /path/to/file # https only:  
.jks truststore
      truststore.password: password # https only: .jks truststore password
      truststore.algorithm: SunX509 # https only: .jks truststore algorithm

    index:
      name:
        time_format: YYYY.MM.dd 
        # marvel index suffix.  
        # Set to a value like YYYY.MM to create new 
        # indices monthly instead of daily

其他 elasticsearch.yml 配置选项在此处描述：

选项	默认值	描述
`marvel.enabled`	`true`	控制是否从该节点导出监控数据。
`marvel.agent.interval`	`10s`	监控数据导出的时间间隔。可以设置为 `-1` 以完全禁用数据导出。
`marvel.agent.indices`	`_all List of`	从中导出数据的索引。支持通配符 ``、添加 `+` 和减去 `-` 操作符。例如，要仅从以 `twitter_` 开头的节点导出数据，但排除索引 `twitter_development`，我们将此参数设置为 `+twitter_,-twitter_development`。
`marvel.agent.cluster.state.timeout`	`10m`	收集集群状态的超时时间。
`marvel.agent.cluster.stats.timeout`	`10m`	收集集群统计信息超时时间。
`marvel.history.duration`	`7d`	Marvel 索引保留的时间长度。`marvel-agent` 将自动删除超过此值的旧索引。设置为 `-1` 以禁用自动索引删除。

在对 elasticsearch.yml 进行任何更改后，重新启动 Elasticsearch：

sudo /etc/init.d/elasticsearch restart

Marvel 索引配置

本节介绍如何配置 Marvel 使用的分片数、副本数以及其他索引设置。默认情况下，每个 Marvel 索引使用一个分片和一个副本：

要查看 Marvel 使用的默认设置，请运行：

curl -XGET "http://elasticsearch-marvel-01:9200/_template/marvel?pretty"

这将返回一个大的 JSON 对象。重要的设置包括 marvel.order、marvel.template 和 marvel.settings：

{
 "marvel" : {
 "order" : 0,
 "template" : ".marvel*",
 "settings" : {
 "index.mapper.dynamic" : "true",
 "index.marvel.index_format" : "6",
 "index.analysis.analyzer.default.type" : "standard",
 "index.number_of_replicas" : "1",
 "index.number_of_shards" : "1",
 "index.analysis.analyzer.default.stopwords" : "_none_"
 },
 ...
}

对于大型 Marvel 集群，考虑将分片数增加到不超过集群中主机数的数量以获得最佳性能。例如，对于四节点 Marvel 监控集群，使用以下命令将分片数增加到四个：
```
curl -XPOST  "http://elasticsearch-marvel-01:9200/_template/marvel_01?pretty" -d '{
 "template": ".marvel*",
 "order": 1,
 "settings": {
 "number_of_shards": 4
 }
}'
```

注意

注意模板设置为.marvel*，以便仅更改 Marvel 的索引。此外，order设置为1，因此此模板marvel_01将比默认模板marvel具有更高的优先级。

现在，当检查 Marvel 设置时，我们应该看到：

curl -XGET "http://elasticsearch-marvel-01:9200/_template/marvel_01?pretty"
{
 "marvel_01" : {
 "order" : 1,
 "template" : ".marvel*",
 "settings" : {
 "index.number_of_shards" : "4"
 },
 "mappings" : { },
 "aliases" : { }

}
}

理解 Marvel 仪表板

本节介绍如何使用 Marvel 仪表板更好地了解集群的状态。

为了使监控我们的集群更有趣，我们将使用stream2es程序将更多 Twitter 数据流式传输到其中，并使用本节中描述的自定义 bash 脚本对索引运行随机查询。

查看第三章，Elasticsearch-head 和 Bigdesk，获取有关如何安装和使用stream2es的详细说明，但为了快速参考，请使用以下命令启动stream2es：

./stream2es twitter --target http://elasticsearch-node-01:9200/twitter/status

接下来，我们将通过运行针对twitter索引的随机查询来模拟用户交互。创建一个名为run_queries.sh的新 bash 脚本，内容如下：

#!/bin/sh

# Path to dictionary file
DICTIONARY_PATH=/usr/share/dict/words
ELASTICSEARCH_URI=http://elasticsearch-node-01:9200/twitter

# Total dictionary words
TOTAL_WORDS=`wc -l $DICTIONARY_PATH | awk '{print $1}'`

while :
do
    # Pick a random word
    WORD_INDEX=`python -c "import random;print random.randint(1,$TOTAL_WORDS)"`
    WORD=`sed "${WORD_INDEX}q;d" $DICTIONARY_PATH`

    # Run query
    echo "Querying elasticsearch $ELASTICSEARCH_URI for $WORD "
    curl -XGET "${ELASTICSEARCH_URI}/_search?q=$WORD"

    # Sleep for one second before running the next query
    echo
    echo "Press [CTRL+C] to stop.."
    sleep 1
done

此脚本每秒查询 Elasticsearch 的twitter索引，使用随机字典单词。

注意

您可能需要在某些 Linux 系统上安装字典才能使此功能正常工作。在 Ubuntu 上，要获取美式英语或英式英语单词的字典，请运行以下命令。

对于美式英语：

sudo apt-get install wamerican

对于英式英语：

sudo apt-get install wbritish

现在使run_queries.sh脚本可执行：

chmod +x run_queries.sh

最后，运行run_queries.sh脚本，每秒对集群进行随机查询。

./run_queries.sh

运行stream2es和run_queries.sh几分钟之后，打开 Marvel 并导航到概览仪表板，以探索这些脚本对我们集群的影响。

概览仪表板

概览仪表板是 Marvel Kibana 仪表板的登录页面。运行stream2es命令和前面提到的run_queries.sh脚本几分钟之后，此仪表板看起来可能如下所示：

这是前一张截图中的标签：

No.	描述
1	仪表板标题。
2	其他 Marvel 仪表板。
3	页面自动刷新间隔。
4	时间过滤器。默认为过去 1 小时。
5	包括集群状态、节点数量、总内存和文档数量的集群信息。
6	当前和历史搜索速率。示例用例：查看搜索流量如何影响集群。
7	当前和历史搜索延迟。示例用例：诊断查询运行缓慢的原因。
8	当前和历史索引速率。示例用例：诊断为何批量索引操作失败。
9	当前和历史索引延迟。示例用例：诊断索引操作为何缓慢。
10	分片活动。在分片恢复时提供分片的状态。

注意

注意，run_queries.sh每秒只运行一个查询，但搜索请求率图表显示平均每秒大约有三个查询。这是因为每次运行查询时，实际上是在针对所有三个数据节点运行。搜索请求率图表显示了所有数据节点每秒的平均查询数。

Marvel 的任何图表都可以通过点击并拖动图表来按时间范围进行过滤，如图所示：

这里是上一张截图中的标签：

数量	描述
1	点击并拖动任何图表以按时间过滤图表。

应用过滤器后，Marvel 图表和集群信息横幅将更新以显示选定时间点的集群状态。在以下截图中，我们可以看到在选定的时间段内集群处于黄色状态：

索引仪表板

索引仪表板允许您检查特定索引的历史数据，包括：

搜索率
索引率
索引大小
内存
文档计数
字段数据大小

索引仪表板与概览仪表板非常相似，只是页面底部的索引列表不同，如以下截图所示：

这里是前一张截图中的标签：

数量	描述
1	集群中所有索引的列表。

点击此页面的底部twitter索引，将我们带到显示该特定索引历史和实时指标的页面：

这里是上一张截图中的标签：

数量	描述
1	索引详情。
2	索引的历史和实时搜索率。
3	历史和实时索引率。
4	历史和实时索引大小。
5	历史和实时 Lucene 内存大小。
6	历史和实时文档计数。
7	历史和实时字段数据大小。示例用例：诊断`OutOfMemoryError`异常。
8	此索引的分片分布。点击任何节点可转到下一节中描述的节点详情页面。

节点仪表板

节点仪表板提供了集群健康和节点利用情况的概览，以及特定节点的历史和实时统计数据。此仪表板用于检查 Elasticsearch 问题，例如：

集群中关闭的节点
磁盘空间不足的节点
CPU 和内存使用量高的节点

打开节点仪表板将带我们到以下页面：

此截图显示了集群中所有节点的概述，以及一些实时指标。这个页面的一个优点是，如果节点宕机，此页面将识别出该节点曾经是集群的一部分，但目前处于离线状态。另一方面，Elasticsearch-head 根本不会显示离线的节点。

点击特定的节点将打开一个仪表板，显示该主机的数据。下一张截图显示了elasticsearch-node-02的节点统计信息：

此页面显示了所选节点的几个历史和实时指标：

搜索延迟：对搜索性能的历史分析。
索引延迟：对数据索引性能的历史分析。
JVM 堆使用率：高堆使用率可能表明 Java OutOfMemoryError异常。
CPU 利用率：高 CPU 利用率可能由多种因素引起，但一些常见的原因是运行复杂的查询和分片移动。
系统负载平均：此指标是衡量节点平均工作量的指标。此值理想情况下应小于节点的 CPU 核心数。
段数量：Lucene 段的数量。这个统计数据会因集群而异，但如果值增加到高于正常水平，尝试运行集群优化。
分片图例：显示哪些分片分配给了此节点。

监控节点故障

如前所述，Marvel 即使在节点离开集群后也会跟踪节点。这对于需要跟踪大量节点的大型集群来说非常有用。

我们将通过关闭elasticsearch-node-01来演示 Marvel 节点仪表板如何显示节点故障：

# From elasticsearch-node-01
sudo service elasticsearch stop

Marvel 的节点仪表板现在看起来是这样的：

我们可以看到 Marvel 指出elasticsearch-node-01曾经是集群的一部分，但目前处于离线状态。

Elasticsearch-head 另一方面，显示集群处于黄色状态，但并未表明elasticsearch-node-01曾经是集群的一部分：

注意

Elasticsearch-head 仅显示elasticsearch-node-02和elasticsearch-node-03，不显示elasticsearch-node-01。

摘要

本章介绍了如何安装和配置 Marvel 代理以及 Marvel Kibana 仪表板。此外，还介绍了为 Marvel 设置一个二级监控集群以存储其指标的方法。最后，本章讨论了各种 Marvel Kibana 仪表板页面，并从高层次上讨论了如何使用这些页面来诊断集群问题。下一章将讨论另一个监控工具 Kopf，并更详细地介绍如何使用 Kibana。

第五章. 系统监控

前两章重点介绍了 Elasticsearch 监控工具，包括 Elasticsearch-head、Bigdesk 和 Marvel。本章将介绍另一个监控工具，Kopf。我们还将从通用系统监控的角度讨论 Elasticsearch、Logstash 和 Kibana（ELK）、Nagios 以及各种 GNU/Linux 命令行工具。

本章涵盖以下主题：

使用 Kopf 监控 Elasticsearch
配置 Elasticsearch、Logstash 和 Kibana（ELK）堆栈以进行系统日志文件聚合和分析
使用 Nagios 对集群进行系统级监控
用于系统和进程管理的 GNU/Linux 命令行工具

使用 Kopf

Kopf 是一个类似于 Elasticsearch-head 的基于 Web 的集群管理工具，但外观更现代，并具有一些不同的功能。使用 Kopf，用户可以检查节点和索引的状态，运行 REST 查询，并执行基本的管理任务。

安装 Kopf

Kopf 支持从 Elasticsearch 0.90.x 版本开始。使用以下表格确定哪个 Kopf 版本最适合你的集群：

Elasticsearch 版本	Kopf 分支
0.90.x	0.90
1.x	1.0
2.x	2.0

要安装 Kopf，请按照以下步骤操作：

使用以下命令在集群中至少一个节点上安装 Kopf 作为 Elasticsearch 插件，将 {branch} 替换为前表中 branch 列的值：
```
$ sudo /usr/share/elasticsearch/bin/plugin install lmenezes/elasticsearch-kopf/{branch}
```
此示例将在 elasticsearch-node-01 上安装 Kopf。由于此节点运行 Elasticsearch 2.3.2，命令将如下所示：
```
$ sudo /usr/share/elasticsearch/bin/plugin install lmenezes/elasticsearch-kopf/2.0
```
要打开 Kopf，浏览到：
```
http://elasticsearch-node-01:9200/_plugin/kopf/
```
你应该看到类似以下内容：

Kopf 集群页面

编号描述

1 标题栏和集群状态

2 集群摘要

3 显示过滤器

4 节点和索引操作

5 索引

6 节点

7 分片分配

编号	描述
1	标题栏和集群状态
2	集群摘要
3	显示过滤器
4	节点和索引操作
5	索引
6	节点
7	分片分配

此页面的绿色标题栏表示集群处于 绿色 状态。同样，如果集群进入黄色或红色状态，标题栏将相应地变为黄色或红色。

所有 Kopf 仪表板页面也显示了此截图顶部的指标，包括节点数、索引、分片、文档和总索引大小。

集群页面

上一节中的截图显示了 Kopf 集群页面。Elasticsearch 集群的节点、索引和分片分配都列在此页面上。此页面还提供以下管理功能：

关闭和打开索引
优化索引
刷新索引
清除索引缓存
删除索引
禁用/启用分片分配
查看索引设置
查看索引映射

与 Elasticsearch-head 中的 集群概览 选项卡类似，Kopf 的集群页面是诊断 Elasticsearch 问题时的一个好起点。它将通知你集群状态，节点是否已关闭，以及节点是否有高堆/磁盘/CPU/负载。

节点页面

如下截图所示的节点页面提供了集群中所有节点的负载、CPU 使用率、JVM 堆使用率、磁盘使用率和运行时间：

Kopf 节点页面

此页面，就像集群页面一样，是诊断 Elasticsearch 问题时的良好起点。

rest 页面

Kopf 的 rest 页面是一个通用的工具，可以运行任意查询针对 Elasticsearch。您可以使用此页面运行 Elasticsearch API 中的任何查询。以下截图显示了在 Elasticsearch 集群上运行一个简单的搜索 API 查询：

Kopf rest 页面

rest 页面对于从测试查询语法到检索集群指标的所有事情都很有用，并有助于衡量和优化查询性能。例如，如果某个特定查询运行缓慢，请使用 rest 页面测试查询的不同变体，并确定哪些查询组件具有最高的性能影响。

工具名称	描述
创建索引	创建索引并分配一些分片、副本、映射和其他设置
集群设置	配置集群、路由和恢复设置
别名	查看现有和创建新的索引别名
分析	测试和验证索引分析器
过滤器	查看现有和创建新的过滤器查询
加热器	查看现有和创建新的索引加热查询
快照	在本地文件系统、URL、S3、HDFS 或 Azure 上创建新的索引快照
索引模板	查看现有和创建新的索引模板
Cat API	运行所有可能的 Elasticsearch API “Cat”方法的一个子集
热点线程	查询 Elasticsearch 的“热点”线程

使用 Logstash 和 Kibana

Logstash 是一个用于从不同来源聚合和标准化日志文件并将其存储在 Elasticsearch 集群中的实用工具。一旦日志存储在 Elasticsearch 中，我们将使用 Kibana，这是 Marvel 用户界面所基于的工具，来查看和探索我们的聚合日志。

ELK

Elasticsearch 社区将 Elasticsearch、Logstash 和 Kibana 工具组合称为 ELK 堆栈。本节展示了如何将 NGINX 服务器日志加载到 ELK 中，但还有许多其他潜在的使用案例。

ELK 可以帮助我们通过以下方式探索 NGINX 服务器日志：

随时间可视化服务器流量
在地图上按位置绘制服务器访问
通过资源扩展（HTML、JS、CSS 等）、IP 地址、字节数或用户代理字符串搜索日志
发现导致内部服务器错误的网络请求
在分布式拒绝服务攻击中寻找攻击者

ELK 的其他用途包括：

在 Web 应用程序中记录所有 Elasticsearch 查询以供未来性能分析
将服务器系统日志聚合到一个位置以进行分析和可视化
从数据处理或摄取管道进行日志操作以供未来分析和审计

安装

尽管此示例将直接将 Logstash 的聚合日志数据存储到 Elasticsearch 中，但确保这些聚合日志不会影响生产集群的性能是很重要的。为了避免这种潜在的性能问题，我们将配置 Logstash 将日志路由到辅助监控集群；在我们的案例中，这是 elasticsearch-marvel-01 节点。

安装 Logstash

Logstash 所在的主机并不重要，因为它可以将日志重定向到任何 Elasticsearch 实例。由于 Kibana 将安装在 elasticsearch-marvel-01 上，因此我们也将 Logstash 安装在那里：

从 elasticsearch-marvel-01 运行以下命令：

sudo mkdir /opt/log
stash
sudo chown -R `whoami` /opt/log
stash
cd /opt/log
stash
wget https://download.elastic.co/logstash/logstash/logstash-2.1.1.t
ar.gz
tar xzvf logstash-2.1.1.t
ar.gz
cd logstash-2
.1.1/

加载 NGINX 日志

现在，让我们使用 Logstash 将一些示例 NGINX 日志加载到 Elasticsearch 中。虽然 Logstash 对许多不同的日志类型（Apache、Linux 系统日志等）具有内置的解析器，但它并不原生支持 NGINX 日志。这意味着用户必须明确告诉 Logstash 如何处理这些文件。为了解决这个问题，请按照以下步骤操作：

在 /opt/logstash/logs 放置一些示例 NGINX 日志文件：
```
$ ls -1 /opt/logstash/logs | head –n20
```
Logstash 的 NGINX 日志文件

在 elasticsearch-marvel-01 上 /opt/logstash/patterns/nginx.grok 创建一个新文件，内容如下：

NGINXACCESS %{IPORHOST:remote_addr} - %{USERNAME:remote_user} \[%{HTTPDATE:timestamp}\] %{QS:request} %{INT:status} %{INT:body_bytes_sent} %{QS:http_referer} %{QS:http_user_agent}

然后在 /opt/logstash/logstash.conf 创建一个 Logstash 配置文件，内容如下：

input {
  file {
    type => "nginx"
    path => "/opt/logstash/logs/access.log*"
    start_position => "beginning"
    sincedb_path => "/dev/null"
  }
}

filter {
  if [type] == "nginx" {
  grok {
    patterns_dir => "./patterns"
    match => {
        "message" => "%{NGINXACCESS}"
    }
  }
  date {
    match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
  }
  geoip {
    source => "remote_addr"
  }

  }
}

output {
  elasticsearch { hosts => ["elasticsearch-marvel-01:9200"] }
}

此配置告诉 Logstash 从文件系统读取所有 access.log* 文件，使用我们新定义的 nginx 格式，识别我们 NGINX 格式使用的时戳列，告诉 Logstash 对访问者的 IP 地址使用 Geo IP 查找，并最终告诉 Logstash 将日志保存到 elasticsearch-marvel-01:9200 的 Elasticsearch 主机实例。

注意

在 www.elastic.co/guide/en/logstash/current/configuration.html 了解更多关于 Logstash 配置文件格式的信息。

现在运行 Logstash，指定配置文件：
```
cd /opt/logstash
./logstash-2.1.1/bin/logstash agent -f logstash.conf 
```
几分钟后，Logstash 将将所有数据加载到 Elasticsearch 中。在 Kopf 中创建的新索引现在应该可以查看。

下一个部分将专注于在 Kibana 中探索数据。

从 Kopf 查看 Logstash 索引

注意

如果从 logstash.conf 配置文件中删除 geoip 配置设置，此过程将更快。

安装 Kibana

按照以下步骤在您的系统上安装 Kibana：

确定从 www.elastic.co/downloads/kibana 下载的 Kibana 适当版本。由于此示例使用 Elasticsearch 2.3.2，我们将安装 Kibana 4.5.4。

在/opt/kibana/目录中下载并解包elasticsearch-marvel-01上的 Kibana：

sudo mkdir /opt/kibana
sudo chown -R `whoami` /opt/kibana/
cd /opt/kibana/
wget https://download.elastic.co/kibana/kibana/kibana-4.5.0-linux-x64.tar.gz
tar xzvf kibana-4.5.0-linux-x64.tar.gz
cd kibana-4.5.0-linux-x64/

编辑 Kibana 的conf/kibana.yml文件，将其指向正确的 Elasticsearch 主机。在这种情况下，更改如下：

# The Elasticsearch instance to use for all your queries.
elasticsearch_url: "http://localhost:9200"

到：

# The Elasticsearch instance to use for all your queries.
elasticsearch_url: "http://elasticsearch-marvel-01:9200"

现在启动 Kibana：
```
./bin/kibana
```
访问http://elasticsearch-marvel-01:5601/以查看 Kibana 登录页面。它应该看起来像以下截图：

配置 Kibana
注意logstash-*已经默认选中，因此只需点击创建按钮继续。
导航到发现选项卡以开始探索您的日志数据：

在 Kibana 中搜索数据

您可能一开始看不到任何数据。这是因为所有加载数据都超过 15 分钟了。
点击页面右上角的日期范围过滤器，默认设置为最后 15 分钟。现在选择一个更合适的范围，例如本月。现在你应该开始看到一些结果：

查看本月的日志数据

default _source列有点难以阅读，因此指定页面左侧的一些列：http_user_agent、remote_addr和status。点击这些选定的任何一列将运行一个聚合查询，显示每个字段的常见值：

应用搜索过滤器到 Kibana 结果

可视化页面允许我们创建任意数据可视化。例如，我们将创建两个示例可视化：一个瓦片地图来绘制数据集中的地理位置 IP 地址，以及一个垂直条形图来显示日志文件中不同 HTTP 状态码的计数。请按照以下步骤操作：

首先，配置瓦片地图可视化，如图所示：

Kibana 结果的地理空间可视化
点击保存以保存您的更改，并创建垂直条形图：

按 HTTP 状态码细分
保存此图表后，转到仪表板页面，以便在同一页面上显示两个组件。
通过点击添加可视化按钮选择两个组件。将它们在仪表板上移动以调整大小和重新排序，直到得到类似以下内容：

Kibana 仪表板视图

注意

通过访问官方 Elasticsearch 文档了解有关 Kibana 和 Logstash 的更多信息：

使用 Nagios

Nagios 是一个系统监控和警报工具。本节将重点介绍配置一个简单的 Nagios 安装，该安装监控我们的 Elasticsearch 集群中的节点以及这些节点上的 Elasticsearch 进程。如果一个节点或进程关闭，Nagios 将向我们发送警报。

在 Elasticsearch 集群之外的主机上安装 Nagios 是个好主意，以避免由于系统中的其他事情（如高 Elasticsearch 负载）而影响监控过程。为 Nagios 创建一个新的主机并命名为elasticsearc h-nagios-01.

安装 Nagios

除了专门的 Nagios 主机elasticsearch-nagios-01之外，还需要在所有 Elasticsearch 集群节点上安装Nagios 远程插件执行器（NRPE）服务器，以监控 Elasticsearch 进程。按照以下步骤操作：

在每个 Elasticsearch 节点上运行以下命令：elasticsearch-node-01、elasticsearch-node-02、elasticsearch-node-03和elasticsea``rch-marvel-01：
```
sudo apt-get install nagios-nrpe-server
```
然后在新的主机elasticsearch-nagios-01上安装 Nagios：
```
sudo apt-get install nagios3 nagios-nrpe-plugin
```
此过程将要求您输入密码。请确保您记住它。

现在，需要一个 Nagios 插件来确保 Elasticsearch 正在运行。有多个插件可供选择，但本书使用 GitHub 上可用的简单脚本：github.com/orthecreedence/check_elasticsearch。

要在elasticsearch-nagios-01上下载和安装此脚本，请运行：

wget https://raw.githubusercontent.com/orthecreedence/check_elasticsearch/master/check_elasticsearch
chmod +x check_elasticsearch
sudo cp check_elasticsearch /usr/lib/nagios/plugins/

接下来，添加一个 Nagios 命令来运行此插件。在elasticsearch-nagios-01上创建一个新文件，/etc/nagios-plugins/config/elasticsearch.cfg，内容如下：

# Check to ensure elasticsearch is running
define command{
        command_name    check_elasticsearch
        command_line    /usr/lib/nagios/plugins/check_elasticsearch -H $HOSTNAME$ -P 9200
        }

最后，指定要监控的 Nagios 服务器的主机。确保使用check_elasticsearch实用程序在这些主机上监控 Elasticsearch 进程，通过编辑配置文件/etc/nagios3/conf.d/localhost_nagios2.cfg：

define host{
        use                     generic-host            
        host_name               elasticsearch-node-01
        alias                   elasticsearch-node-01
        address                 192.168.56.111
        }

define host{
        use                     generic-host            
        host_name               elasticsearch-node-02
        alias                   elasticsearch-node-02
        address                 192.168.56.112
        }

define host{
        use                     generic-host            
        host_name               elasticsearch-node-03
        alias                   elasticsearch-node-03
        address                 192.168.56.113
        }

define host{
        use                     generic-host            
        host_name               elasticsearch-marvel-01
        alias                   elasticsearch-marvel-01
        address                 192.168.56.120
        }

define hostgroup {
        hostgroup_name  elasticsearch-servers
                alias           Elasticsearch servers
                members         elasticsearch-node-01, elasticsearch-node-02, elasticsearch-node-03, elasticsearch-marvel-01
        }

define contact{
        contact_name Elasticsearch Admin
        service_notification_period 24x7
        host_notification_period 24x7
        service_notification_options w,u,c,r,f
        host_notification_options d,u,r,f
        service_notification_commands notify-service-by-email
        host_notification_commands notify-host-by-email
        email admin@your-domain.com
        }

define service{
        use                             generic-service         ; Name of service template to use
        hostgroup_name                  elasticsearch-servers
        service_description             Elasticsearch
        check_command                   check_elasticsearch
        }

接下来，配置elasticsearch-node-01、elasticsearch-node-02、elasticsearch-node-03和elasticsearch-marvel-01，以允许我们的 Nagios 主机elasticsearch-nagios-01收集指标：
```
sudo vim /etc/nagios/nrpe.cfg
```
编辑allowed_hosts设置以包括elasticsearch-nagios-01的 IP 地址；在我们的例子中，这是192.168.56.130：
```
allowed_hosts=127.0.0.1,192.168.56.130
```
现在，在 Elasticsearch 集群的所有节点上重启 NRPE 服务器：
```
sudo service nagios-nrpe-server restart
```
最后，在elasticsearch-nagios-01上重启nagios3：
```
sudo service nagios3 restart
```
打开一个网页浏览器以查看 Nagios 网络管理门户，用户名为nagiosadmin，密码为之前输入的密码：
```
http://elasticsearch-nagios-01/nagios3
```
在 Nagios 收集所有节点上的指标几分钟之后，点击主机侧边栏链接以查看集群中所有节点的状态：

在 Nagios 中查看 Elasticsearch 主机
点击左侧菜单中的服务以查看每个节点上 Elasticsearch 进程的状态：

在 Nagios 中查看 Elasticsearch 状态

注意

注意，在elasticsearch-marvel-01中，Elasticsearch 进程处于黄色警告状态。这意味着集群处于黄色状态，因为 Marvel 集群中只有一个节点，并且不是所有分片都进行了复制。

现在，我们将演示当某个节点关闭并且我们在另一个节点上停止 Elasticsearch 进程时，Nagios 会做什么。

关闭elasticsearch-node-01并禁用elasticsearch-node-02上的 Elasticsearch：

ssh root@elasticsearch-node-01
shutdown -h now
ssh root@elasticsearch-node-02
service elasticsearch stop

下次 Nagios 轮询集群状态（这需要几分钟）时，以下内容将在 Nagios 网页仪表板的“服务”页面上显示：

Nagios 的错误报告

Nagios 现在显示elasticsearch-node-01已关闭，并且无法连接到elasticsearch-node-02上的 Elasticsearch 进程。Nagios 还显示elasticsearch-node-03上的 Elasticsearch 已进入红色状态，因为并非所有分片都可用。根据我们之前的配置，Nagios 将向admin@your-domain.com发送关于警告和错误的电子邮件。在启动elasticsearch-node-01并重新启动elast icsearch-node-02上的 Elasticsearch 后，一切将恢复正常。

系统和进程管理的命令行工具

命令行是系统监控的无价工具。在本节中，我们将介绍一些基本的 GNU/Linux 命令行工具，用于系统和进程管理。了解这些工具对于管理 Elasticsearch 集群在 GNU/Linux 上的人来说至关重要。

top

top命令列出了占用 CPU 和内存最高的进程。这个工具有助于确定是否有除了 Elasticsearch 之外的进程正在占用资源，或者检查 Elasticsearch 是否使用了异常的 CPU 或内存量。

top命令会自动刷新，所以你只需要运行一次并观察。

运行命令时，你应该看到以下结果：

top命令

提示

在top运行时按Shift+M以按使用最多内存的进程排序，而不是按 CPU。

tail

tail -f命令用于实时查看日志文件。使用它来查看 Elasticsearch 日志文件如下：

tail -f /var/log/elasticsearch/*

“跟踪”Elasticsearch 日志文件

grep

grep命令是一个通用的文本搜索工具。grep的一个有用应用是搜索日志文件目录中的特定字符串。要使用grep或搜索/var/log/elasticsearch中的所有已记录异常，请使用带有-r（递归）和-i（不区分大小写搜索）选项的以下命令：

grep -ir exception /var/log/elasticsearch/*.log

假设你的 Elasticsearch 日志文件中记录了一些异常，你应该会看到如下内容：

“grep”日志文件以查找异常

ps

使用ps命令和grep命令来查看特定进程是否正在运行。如果你在停止或启动 Elasticsearch（或其他进程）时遇到问题，这是一个有用的检查。

要检查 Elasticsearch 是否正在运行，请使用以下命令：

ps -ef | grep -i elasticsearch

如果 Elasticsearch 没有运行，此命令将不会输出任何内容。如果它在运行，你应该会看到如下内容：

使用 ps 查看 Elasticsearch 进程

kill

使用 kill 命令停止不会优雅关闭的进程。例如，要关闭之前列出的 Elasticsearch 进程，请运行以下命令：

sudo kill 2501

使用 ps 命令杀死 Elasticsearch 进程并验证

free

free 命令告诉我们系统中有多少内存正在使用。其用法如下：

free -m

运行此命令将产生类似以下的结果：

free 命令显示系统中的 RAM 量

此输出表示我们正在使用 333 MB 的可用 490 MB 内存存储。

du 和 df

du 和 df 命令告诉我们主机上有多少磁盘空间可用。使用 du 命令查看当前目录中存储了多少数据，如下所示：

cd /var/log/elasticsearch
du -h

你应该看到类似以下的结果：

du 命令计算目录的大小

在这种情况下，在 /var/log/elasticsearch/ 目录中有 15 MB 的日志文件。

使用 df 命令查看系统中有多少磁盘空间可用，如下所示：

df -h

你应该看到类似以下的结果：

elasticsearch-node-01 的磁盘使用情况

此处的输出表明 / 挂载点上还有 1.3G 的可用存储空间。

注意

注意，在这两个命令中，-h 标志代表可读性，意味着它们将以 KB、MB 或 GB 的形式输出值，而不是仅仅以字节为单位。

摘要

本章探讨了 Elasticsearch 监控工具 Kopf、Elasticsearch、Logstash 和 Kibana (ELK) 日志聚合堆栈、系统监控工具 Nagios 以及各种 GNU/Linux 命令行实用工具。

一些要点包括：

Kopf 是一个类似于 Elasticsearch-head 的 Elasticsearch 监控工具，但提供了一些不同的指标。
Elasticsearch、Logstash 和 Kibana (ELK) 堆栈是一个用于搜索、分析、丰富和可视化日志文件的工具。
考虑使用 Nagios 等工具监控 Elasticsearch 集群。Nagios 可以配置为在进程崩溃或节点本身崩溃时发送电子邮件通知。
通过使用一些 GNU/Linux 命令行工具，我们可以收集到与各种 Elasticsearch 监控工具提供的相同指标。

下一章将讨论解决 Elasticsearch 性能和可靠性问题的方法。本章讨论的监控工具将在解决即将到来的章节中概述的现实世界问题中非常有用。

第六章。性能和可靠性问题的故障排除

本章通过使用真实世界案例研究的案例研究，重点介绍 Elasticsearch 常见的性能和可靠性问题的故障排除。

本章将帮助回答以下问题：

我该如何配置我的 Elasticsearch 集群以优化性能？
我该如何防止OutOfMemoryError异常？
我的数据索引策略如何影响集群资源？
为什么我的查询运行得慢？
在索引大量数据时，我该如何保持查询性能？
我该如何配置索引以使用更少的磁盘空间？

系统配置

如第二章所述，Elasticsearch 配置可能导致许多性能和可靠性问题。快速提醒：您需要为您的集群进行的最重要的配置更改如下：

确保 Elasticsearch 堆大小（ES_HEAP）设置为可用系统内存的 1/2，但不超过 31 GB。请在/etc/defaults/elasticsearch中设置此值。
禁用内存交换。
通过在elasticsearch.yml中设置bootstrap.mlockall: true将 Elasticsearch 地址空间锁定到内存中。

请参阅第二章，Elasticsearch 的安装和需求，以获取如何设置这些值的更详细说明。

字段数据缓存

配置不当的 Elasticsearch 字段数据缓存通常是OutOfMemoryError异常的原因。

当运行sort或aggregation（或facet）查询时，Elasticsearch 会使用查询中所有不同的字段值填充缓存。这允许类似的后续查询执行得更快。然而，默认情况下，Elasticsearch 不会对缓存大小设置上限；因此，数据不会自动被驱逐。如果缓存导致总 JVM 内存填满超过ES_HEAP大小，节点将抛出OutOfMemoryError异常，并需要重新启动 Elasticsearch。

要限制字段数据缓存大小，请设置indices.fielddata.cache.size值：

indices.fielddata.cache.size: 30%

这将限制字段数据缓存大小为可用 JVM 堆空间的30%。

您也可以将此值设置为固定值。例如，将其设置为10gb将限制缓存大小不超过 10 千兆字节。您选择的价值将取决于集群和用例，但如果您看到由字段数据缓存溢出引起的OutOfMemoryError，设置此字段是个好主意。限制字段数据缓存的缺点是，如果查询需要重新填充被驱逐的字段数据缓存项，这可能会影响查询性能。

如果您在/var/log/elasticsearch/中看到OutOfMemoryError日志，您可以通过检查 Bigdesk 或 Marvel 来确认字段数据缓存是否是问题。

Bigdesk 中的字段数据缓存

Marvel Kibana 仪表板中的字段数据缓存看起来像这样：

Marvel 中的字段数据缓存

小贴士

不要更改indices.fielddata.cache.expire设置。这是一个过时的设置，用于使旧缓存值过期，并且它不会提供任何性能提升。Elasticsearch 开发人员表示，它将在未来的版本中弃用。

你还可以通过优化使用缓存的查询来减少字段数据缓存的影响。

例如，在我们的 Twitter 数据中，我们有一个timestamp_ms字段，它以毫秒精度存储推文的日期时间戳。因为一天中有86,400,000毫秒，如果我们收集了 24 小时内的5,000,000条推文，那么其中大部分推文很可能具有唯一的时间戳。如果我们运行一个按此字段排序的查询，它将用多达5,000,000个不同的时间戳填满字段数据缓存。这将迅速填满缓存。

更功能性的方法是将时间戳字段存储在秒或分钟精度。使用秒精度，字段数据缓存将减少从存储5,000,000个唯一时间戳到大约86,400个时间戳。使用分钟精度将减少到只有1,440个唯一时间戳。

即使将字段数据缓存大小限制为固定值，你也可能仍然会遇到与字段缓存相关的OutOfMemoryError异常。这可能是由于单个查询加载的字段数据缓存比分配的更多数据所致。

例如，如果字段数据缓存设置为 2 GB，但我们运行一个尝试将 2.5 GB 数据加载到缓存中的单个查询，可能会发生这种情况。可以通过编辑elasticsearch.yml中的字段数据断路器来解决这个问题。

字段数据断路器默认设置为总 JVM 堆大小的60%：

indices.breaker.fielddata.limit: 60%

这样，如果单个查询的字段数据超过堆的60%，断路器将会触发，导致查询抛出异常，而不是引发OutOfMemoryError。使用低于默认60%的百分比可能有助于解决即使字段数据缓存大小有限时出现的OutOfMemoryError异常。

分析查询

分析慢查询并提高其性能可能非常具有挑战性。本节探讨了如何寻找查询性能不佳的根本原因，并提供了一些不同的解决方案。

慢查询日志

如果你注意到查询性能不佳，请从慢查询日志开始。要启用慢查询日志，请编辑elasticsearch.yml文件，并将以下配置选项添加到集群中的所有节点：

index.search.slowlog.threshold.query.warn: 8s
index.search.slowlog.threshold.query.info: 4s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms

index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 750ms
index.search.slowlog.threshold.fetch.debug: 500ms
index.search.slowlog.threshold.fetch.trace: 250ms

index.indexing.slowlog.threshold.index.warn: 8s 
index.indexing.slowlog.threshold.index.info: 4s 
index.indexing.slowlog.threshold.index.debug: 2s 
index.indexing.slowlog.threshold.index.trace: 500ms
index.indexing.slowlog.level: info
index.indexing.slowlog.source: 5000

在所有节点上更新elasticsearch.yml后，重启集群。

此配置为三个操作启用了慢查询日志：

查询操作：这是 Elasticsearch 正在执行实际搜索以匹配查询的文档时的情况
获取操作：这是在 Elasticsearch 找到感兴趣的文档后从索引中获取相关文档时的情况
索引操作：这是在 Elasticsearch 中索引新文档时的情况

我们还为每个点设置了一个阈值级别：warn、info、debug和trace。这些级别标识了 Elasticsearch 将写入慢日志的点。例如，如果一个查询耗时六秒，根据我们之前的配置，该查询将以info级别记录。这些级别使得搜索特定阈值的查询成为可能。

以下是一个搜索慢日志中所有耗时超过八秒且以warn级别记录的查询的示例：

grep "\[WARN \]"  /var/log/elasticsearch/my_elasticsearch_cluster_*_slowlog.log*

耗时超过八秒的 Elasticsearch 慢日志

下一个部分将介绍一些额外的改进查询性能的方法。

提高查询性能

本节突出了 Elasticsearch 上某些查询缓慢的常见原因，并提供了提高性能的指导。

高基数字段

如前所述，对高基数字段（例如，精确到毫秒的日期）运行聚合或排序可能会填满 fielddata 缓存，导致OutOfMemoryError异常。然而，即使没有这些错误，运行聚合和排序也可能对性能产生不利影响。当涉及到日期时，通常存储和使用不太精确的日期以加快查询执行时间是一个好主意。

查询较小的索引

随着 Elasticsearch 索引的增大，查询性能将受到影响。提高性能的另一种方法是针对小索引运行查询。你可以通过将我们的数据存储在几个较小的索引中而不是一个大的索引中来实现这一点。

例如，对于 Twitter 数据，你可以更改摄取过程，每天创建一个新的索引来存储推文。这样，在运行时间限制查询时，我们只查询总索引的一个子集。

在这种情况下，索引模板很有帮助，因为它们会自动将数据映射应用到遵循特定命名约定的新索引上。

让我们使用twitter-YYmmdd命名约定为我们的日常 Twitter 索引创建一个新的索引模板。使用此模板，twitter-20160101索引将包含 2016 年 1 月 1 日所有的推文。使用以下cur l命令创建此模板：

curl -XPUT elasticsearch-node-01:9200/_template/templ
ate_1 -d '
{
 "template" : "twitter-*",
 "settings" : {
 "number_of_shards" : 5
 },
 "mappings" : {
 "twitter" : {
 "status" : { 
 ...
 }
 ...
 }
 }
}'

小贴士

注意twitter-*模板名称中使用的*星号通配符。这个通配符匹配 0 个或多个字符，因此它将匹配索引名称，例如twitter-20160101。

我们还可以创建一个索引别名，允许我们一次性查询多个或所有索引。

以下示例使用*通配符创建一个别名，以查询所有可用的 Twitter 数据：

curl -XPOST elasticsearch-node-01:9200/_aliases -d '{
 "actions" : [
 { "add" : { "index" : "twitter-*", "alias" : "all_twitter" } }
 ]
}'

通过尝试不同的索引大小来找到最适合您数据和设置的方案。在确定特定的索引大小之前，测试它们对性能的影响是很重要的，因为稍后更改索引策略将涉及重新索引所有数据。

如果您有一个五节点集群并且每天收集 10,000 条记录，那么按月而不是按日创建新索引是有意义的，这样可以减少索引数量并确保每个单独的索引不会太小。然而，在确定索引策略之前测试所有假设是很重要的。在做出这个决定之前，使用 Logstash 和 Kibana 等工具监控不同索引大小下的平均查询性能。

冷索引

有时，Elasticsearch 查询在第一次运行时速度较慢，但之后会显著加快。延迟发生是因为索引是“冷”的，并且 Elasticsearch 缓存中没有填充相关数据。运行查询几次后，Elasticsearch 会根据查询标准填充 fielddata 缓存和其他缓存。具有相似标准的后续查询将利用这些缓存值并因此运行得更快。

Elasticsearch 的“预热器”和“急切字段数据加载”通过确保用户第一次运行查询时，所需数据已经加载到内存中，从而解决了冷索引的问题。

索引可能因为多种原因而变冷：

新数据被索引
自动分片平衡和移动
Elasticsearch 节点重启
缓存已被手动清除

要展示慢聚合查询的性能提升，请使用以下命令：

curl -XPOST 'http://elasticsearch-node-01:9200/twitter/_cache/clear'

curl -XGET 'http://elasticsearch-node-01:9200/twitter/_search' -d '{
 "size" : 0,
 "query" : {
 "match_all" : {}
 },
 "aggs" : {
 "text" : {
 "terms" : {
 "field" : "text"
 }
 } 
 }
}' | python -m json.tool

结果如下：

{
 ...
 "took": 5864
 ...
}

如果我们再运行几次查询，我们将开始看到以下结果：

{
 ...
 "took": 529
 ...
}

这个查询最初花费了 5.8 秒来完成，但经过几次运行后，它只用了 0.529 秒。通过将常见查询添加到 Elasticsearch 预热器中，可以避免初始的慢查询，并且性能可以变得更加可预测。我们将通过再次清除索引缓存，然后使用 Elasticsearch 预热器 API 将我们的查询添加到 twitter 索引中，来展示这一点：

curl -XPOST 'http://elasticsearch-node-01:9200/twitter/_cache/clear'

curl -XPUT http://elasticsearch-node-01:9200/twitter/twitter/_warmer/text_agg_warmer?pretty -d '{
 "size" : 0,
 "query" : {
 "match_all" : {}
 },
 "aggs" : {
 "text" : {
 "terms" : {
 "field" : "text"
 }
 } 
 }
}'

我们可以通过检查 Kopf 的 http://elasticsearch-node-01:9200/_plugin/kopf 上的 REGISTERED WARMERS 页面并导航到更多 | 预热器 来验证预热查询是否已进入我们的索引。

这张截图显示了 Kopf 预热器页面上的预热查询：

在 Kopf 中查看查询预热器

预热器将在重启 Elasticsearch 后生效。再次运行查询以查看性能提升：

{
 ...
 "took": 418
 ...
}

这导致了超过 10 倍的速度提升，从 5.8 秒到 0.41 秒。我们在手动运行查询几次以填充来自 text 字段的数据的 fielddata 缓存后，看到了类似的增长。

我们还可以为特定的 Elasticsearch 字段启用急切字段数据加载：

curl -XPUT http://elasticsearch-node-01:9200/twitter/_mapping/twitter -d '{
 "text": {
 "type" : "string",
 "doc_values" : true,
 "fielddata" : {
 "loading" : "eager" 
 }
 }
}'

如果我们的 fielddata 缓存只有少数几个不同的值，将loading值设置为eager_global_ordinals以进行更多的内存优化。在启用预热查询或急切 fielddata 加载后，通过检查 Marvel 的节点或索引统计页面或 Bigdesk 的 fielddata 图表来验证 fielddata（在预热查询的情况下还包括过滤器缓存）是否已填充。

注意

你可以在www.elastic.co/guide/en/elasticsearch/reference/current/indices-warmers.htmlload-fielddata.html和www.elastic.co/guide/en/elasticsearch/guide/current/preload-fielddata.html了解更多关于预热器和急切字段数据加载的信息。

分片查询缓存

分片查询缓存为特定查询保存结果。与 fielddata 缓存不同，任何需要 fielddata 的查询都会加速，使用缓存的查询，我们必须运行完全相同的查询多次才能产生缓存命中。此外，整个查询结果都存储在查询缓存中。这与 fielddata 缓存不同，其中只存储查询结果的一部分。这意味着查询缓存将返回极快的结果。

分片查询缓存目前仅存储命中次数、聚合和搜索建议。它不存储实际的搜索结果或命中。此外，当运行缓存的查询时，需要search_type=count查询参数。这可能在未来的 Elasticsearch 版本中更新。

查询缓存默认为 JVM 堆的1%，但可以在elasticsearch.yml中更改：

indices.cache.query.size: 2%

缓存键是搜索请求的 JSON 正文。即使查询在逻辑上与缓存中已有的查询相同，如果存在空白或键顺序的差异，缓存也会将这些存储为两个不同的条目。

默认情况下禁用分片查询缓存。要在现有索引上启用它，请运行以下命令：

curl -XPUT elasticsearch-node-01:9200/twitter/_settings?pretty -d'{
 "index.cache.query.enable": true 
}'

或者当创建一个新的索引时，将相同的参数添加到settings部分：

curl -XPUT elasticsearch-node-01:9200/twitter -d'
{
 ...
 "settings": {
 "index.cache.query.enable": true
 },
 ...
}'

当使用查询缓存时，你将始终收到与运行非缓存的查询时相同的最新查询结果。这是因为当分片刷新并加载新数据时，缓存条目会自动失效。

再次运行文本聚合查询几次，这次使用查询缓存：

curl -XGET 'elasticsearch-node-01:9200/twitter/_search?search_type=count&query_cache=true' -d '{
 "size" : 2,
 "query" : {
 "match_all" : {}
 },
 "aggs" : {
 "text" : {
 "terms" : {
 "field" : "text"
 }
 } 
 }
}' | python -m json.tool

在运行几次此查询后，应出现如下性能结果：

{
 ...
 "took": 4
 ...
}

4ms的响应时间比仅使用 fielddata 缓存的418ms响应时间有所改进，并且与原始的5.8秒相比，对冷 Elasticsearch 索引的响应时间有巨大的改进。

注意

在www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html了解更多关于分片查询缓存的信息。

脚本查询

脚本查询是通过运行任意代码来操作或过滤查询遇到的每个命中项，从而查询索引的一种强大方式。然而，它们也非常昂贵，并且可能会损害大型索引的性能。

在可能的情况下，最好避免在需要及时返回结果的 Elasticsearch 查询中使用脚本。如果你发现自己正在使用它们，尝试思考如何重新结构你的数据，使它们不再必要。

注意

如果你在应用程序中使用脚本，请确保使用 doc["text"] 而不是 _source.text 来访问源文档字段；后者将访问磁盘上的记录，而前者从内存中访问。

仔细测试

仔细测试每个优化策略非常重要，以了解哪种策略最有效。如果你遇到慢查询，尝试在小规模上重现问题并测试不同的优化，直到找到一种有效的方法。确保你一次只测试配置或查询参数中的一个更改。此外，运行测试脚本足够长的时间，以考虑到垃圾收集、缓存驱逐等因素引起的性能的正常波动。

这种测试方法可能感觉繁琐，但它最终将提供对集群的更深入了解，并有助于长期避免对系统进行不必要的更改。

系统和数据架构

本节涵盖了提高整体系统性能、数据索引性能以及最大化存储空间的策略。

热温架构

对于时间序列数据，包括 Twitter 和其他社交媒体数据以及来自 Logstash 的数据，Elastic.co 建议设置他们称之为热-温架构。这种设置将节点分为三组。

主节点

理想情况下，分配三个节点作为主节点，这些节点不存储数据或执行查询。这些机器不需要非常强大；它们只是执行集群管理操作。

热节点

热节点持有最新的数据索引。所有数据写入都指向这些机器，它们可能是查询最频繁的节点。Elastic.co 建议为热节点配备固态硬盘（SSD）以获得更好的 I/O 性能。

热节点

在这种架构中，数据不会被写入热节点；相反，它们包含基于历史时间的数据。例如，如果我们每天创建一个新的 Twitter 索引，我们可以在七天后将索引从“热”移动到“温”。

要配置热节点，请将以下内容添加到 elasticsearch.yml：

node.box_type: hot

同样，对于温节点，添加以下内容：

node.box_type: warm

要确保新创建的索引分配给热节点，请在创建索引时使用以下配置：

curl -XPUT elasticsearch-node-01:9200/twitter-2016-03-06
{
 ...
 "settings": {
 "index.routing.allocation.require.box_type" : "hot"
 }
 ...
}

在七天后将它移动到温节点后，使用以下内容：

curl -XPOST elasticsearch-node-01:9200/twitter-2016-03-06/_settings -d '{
 "settings": {
 "index.routing.allocation.require.box_type" : "warm"
 }
}'

在www.elastic.co/blog/hot-warm-architecture上了解更多关于“热-温”架构的信息。

减少磁盘大小

本节介绍了如何在你的集群上节省磁盘空间。

压缩

在 Elasticsearch 2.0 及以上版本中，你可以提高索引的压缩级别以减少其在磁盘上的占用。遗憾的是，这也使得索引新数据变得更慢。

对于如前所述的 Hot-Warm 架构用例，在 Warm 节点上提高压缩级别是有意义的，因为它们比 Hot 节点承受的压力小。

要在 Elasticsearch 2.0+节点上提高压缩级别，请执行以下操作：

关闭索引。
将index.codec设置配置为best_compression。
重新打开索引。

curl -XPOST elasticsearch-node-01:9200/twitter/_close
curl -XPUT elasticsearch-node-01:9200/twitter/_settings -d '{
 "settings": {
 "index.codec": "best_compression"
 }
}'
curl -XP
OST elasticsearch-node-01:9200/twitter/_open

存储`_source`和已分析字段

默认情况下，Elasticesarch 将所有传递给它的文档存储在_source字段中，并将所有字段设置为analyzed。这意味着一些基本的分词器会在字段上运行。如果我们决定在我们的系统中将文档存储在其他地方，或者我们可以禁用_source字段并将我们想要检索的各个字段设置为store: true，这样可以节省一些磁盘空间。

对于分析字段，仔细考虑你将如何使用你的数据，如果你不需要对其进行分词，请将字段设置为index: not_analyzed。电子邮件地址、IP 地址、社交媒体用户名或其他我们不希望拆分的字段应设置为not_analyzed。

创建一个新的索引，禁用_source，并将一些字段设置为not_analyzed：

curl -XPOST elasticsearch-node-01:9200/newindex -d '{
 "mappings" : {
 "newtype" : {
 "_source" : {
 "enabled" : false
 },
 "properties" : {
 "username" : { 
 "type" : "string", 
 "index" : "not_analyzed",
 "store" : true
 },
 "text" : { 
 "type" : "string"
 }
 }
 }
 }
}'

很遗憾，禁用_source字段有一些相当大的缺点。除了在查询期间无法检索完整源之外，以下功能仅在启用_source时才受支持：

Elasticsearch 更新 API
Elasticsearch 高亮显示
许多重新索引数据的工具和策略

如果磁盘空间是一个主要问题，首先检查启用数据压缩是否能够满足你的存储需求，然后再禁用_source字段。

优化数据摄取

本节介绍了提高数据摄取的一些额外方法。在这些方法中，监控数据摄取速率非常重要，以确保变化对性能产生预期的效果。

如前所述，一次测试一个变化，并运行足够长的时间以获得有意义的成果。监控摄取性能的最佳位置是在 Marvel 的索引仪表板中选择感兴趣的索引。

以下截图显示了我们的twitter数据索引的 Marvel 索引仪表板：

Marvel 索引请求

在你对数据摄取操作进行更改时，监控此页面。这将允许你实时查看变化如何影响索引速率，并且你可以参考过去的索引速率指标。

批量索引操作

对于批量索引操作，测试不同的摄取大小，并在 Marvel 中监控它们，直到找到最佳大小。例如，在1MB、5MB、10MB、15MB和20MB上运行测试，直到找到最佳值。如果您运行每日摄取作业，考虑在非高峰时段运行它们，以便结果放缓影响较少的用户。

在将数据插入 Elasticsearch 后，用户能看到数据之前，索引必须刷新。默认情况下，刷新间隔设置为每秒一次。这意味着在索引一个文档后，它将在一秒内出现在搜索结果中。

在大规模索引操作期间，每秒刷新一次可能会损害性能。如果您的系统不需要在索引后立即显示新结果，将刷新率降低到10s或30s是有价值的。

将刷新率设置为-1将完全禁用刷新。这对于非常大的、一次性的或不太频繁的周期性索引操作非常有用。记住，之后要启用索引刷新。

要禁用索引刷新，请使用以下命令：

curl -XPUT elasticsearch-node-01:9200/twitter/_settings -d '{
 "index" : {
 "refresh_interval" : "-1"
 }
}'

之后启用索引刷新：

curl -XPUT elasticsearch-node-01:9200/twitter/_settings -d '{
 "index" : {
 "refresh_interval" : "5s"
 }
}'

每次索引刷新时都会运行预热查询。另一个选项是保持索引刷新开启，在大规模索引操作期间禁用预热查询，然后在索引作业完成后重新启用预热。

禁用索引预热：

curl -XPUT elasticsearch-node-01:9200/twitter/_settings -d '{
 "settings" : {
 "index.warmer.enabled" : "false"
 }
}'

重新启用索引预热：

curl -XPUT elasticsearch-node-01:9200/twitter/_settings -d '{
 "settings"
 : {
 "index.warmer.enabled" : "true"
 }
}'

驱动器配置

在“热-温”架构部分中，我们提到 SSD 非常适合数据索引性能。即使您不使用“热-温”架构，也考虑在您的 Elasticsearch 集群的数据节点上使用 SSD。

如果 SSD 不是选项之一，考虑使用配置为RAID 0的快速硬盘（10,000+ RPM）。记住，RAID 0 是为了性能而不是可靠性，但 Elasticsearch 的数据副本足以保证数据可靠性。

最好避免在网络上存储数据。如果您在虚拟机上运行 Elasticsearch 集群，请确保它们使用本地磁盘进行存储。

案例研究

本节提供了一些实际的问题场景和解决方案，以使用 Elasticsearch。

节点配置

您有一个五节点生产集群，每个节点总共有32GB的内存，其中16GB分配给了 Elasticsearch。最近，您注意到一个问题：每隔几天，node-05会无预警地离开集群。在这个节点上重启 Elasticsearch 可以暂时解决问题，但几天后节点会再次从集群中掉出。我们如何着手调查这个问题？

下次出现此错误时，在重启节点之前检查 Elasticsearch 日志：

tail -n 500  /var/log/elasticsearch/*.log

您在日志文件中注意到 Elasticsearch 正在抛出OutOfMemoryError异常，如下所示：

Caused by: java.lang.OutOfMemoryError: Java heap space
        at org.apache.lucene.store.DataOutput.copyBytes(DataOutput.java:273)
        at org.apache.lucene.util.fst.FST.<init>(FST.java:342)
        at org.apache.lucene.util.fst.FST.<init>(FST.java:321)

您知道耗尽 fielddata 可能会导致OutOfMemoryError异常，因此检查elasticsearch.yml文件后，您发现以下内容：

# indices.fielddata.cache.size: 30%

缓存设置被注释掉了。取消注释这一行并重启 Elasticsearch 节点。这看起来似乎解决了问题。然而，两周后，node-05又出现了另一个OutOfMemoryError。在重启节点后，登录 Bigdesk 以获取洞察。点击node-05，你将看到以下情况：

Bigdesk 中的 JVM 内存

看起来 Elasticsearch 并没有使用太多可用内存，但这可能是因为节点刚刚重启。

注意，node-05可用的最大堆内存只有大约250MB。考虑到主机有32GB的系统内存，这很奇怪。在这个时候，你想要确保ES_HEAP变量被正确设置。打开以下文件：

/etc/default/elasticsearch

你将看到以下情况：

# ES_HEAP_SIZE=16g

看起来这个配置，比如indices.fielddata.cache.size，也被注释掉了。取消注释这一行并重启 Elasticsearch 将节点的总可用内存提升到16GB，并消除了OutOfMemoryError异常。

如前所述，节点配置错误是导致 Elasticsearch 性能不佳或崩溃的最常见原因之一。在做出配置更改后，验证每个配置更改是很重要的。

查询优化

你在公司的一个内部企业级 Elasticsearch Web 应用程序中发现了问题。一大早，Web 应用程序加载查询结果需要很长时间。只有在运行几个查询后，性能才开始提升。

为了解决这个问题，查看慢日志。在某个节点中，你看到一条运行时间为4.7秒的查询，作为日志中的INFO事件：

[2016-02-29 16:52:43,569][INFO ][index.search.slowlog.query] [elasticsearch-node-03] [twitter][1] took[4.7s], took_millis[4709], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[3], source[{"size":0,"query":{"match_all":{}},"aggs":{"screen_name":{"terms":{"field":"user.screen_name"}},"text":{"terms":{"field":"text"}}}}], extra_source[],

注意

慢日志不一定会在所有节点上写入条目，所以请检查每个主机的日志。

使用python -m json.tool来美化打印查询：

echo '{"size":0,"query":{"match_all":{}},"aggs":{"screen_name":{"terms":{"field":"user.screen_name"}},"text":{"terms":{"field":"text"}}}}' | python -m json.tool

你将看到以下内容：

{
 "aggs": {
 "screen_name": {
 "terms": {
 "field": "user.screen_name"
 }
 },
 "text": {
 "terms": {
 "field": "text"
 }
 }
 },
 "query": {
 "match_all": {}
 },
 "size": 0
}

这个aggs参数可能意味着这个查询大量使用了字段数据缓存。诊断这个查询并找出导致性能问题的原因。

首先，清除字段数据缓存以确保结果一致：

curl -XPOST 'http://elasticsearch-node-01:9200/twitter/_cache/clear'

现在，按照以下方式运行查询：

curl -XGET 'http://elasticsearch-node-01:9200/twitter/_search' -d '{
 "size" : 0,
 "query" : {
 "match_all" : {}
 },
 "aggs" : {
 "screen_name" : {
 "terms" : {
 "field" : "user.screen_name"
 }
 },
 "text" : {
 "terms" : {
 "field" : "text"
 }
 } 
 }
}' | python -m json.tool

结果将如下：

{
 ...
 "took": 4183
 ...
}

在运行查询几次以确保所需值在字段数据缓存中后，查询大约在.6秒内完成。这是一个相当好的改进。请使用 Bigdesk 或 Marvel（参考图像中的 Bigdesk 和 Marvel 的字段数据缓存）验证字段数据缓存现在是否已填充。

字段数据缓存可能因为新数据的摄入或分片夜间迁移而被清空。为了解决这个问题，在 Elasticsearch 映射中启用user.screen_name和text字段的急切字段数据加载。

然而，这个查询的性能仍然不佳。再次检查慢日志，我们注意到它仍然触发一个TRACE事件：

[2016-02-29 16:54:20,069][TRACE][index.search.slowlog.query] [elasticsearch-node-03] [twitter][1] took[680ms], took_millis[680], types[], stats[], search_type[QUERY_THEN_FETCH], total_shards[3], source[{"size":0,"query":{"match_all":{}},"aggs":{"screen_name":{"terms":{"field":"user.screen_name"}},"text":{"terms":{"field":"text"}}}}], extra_source[],

为了找出为什么即使 fielddata 缓存已填充，这个查询仍然需要超过 0.5 秒来运行，将查询分解为单独的查询——一个运行text聚合，另一个运行screen_name聚合：

curl -XGET 'http://elasticsearch-node-01:9200/twitter/_search' -d '{
 "size" : 0,
 "query" : {
 "match_all" : {}
 },
 "aggs" : {
 "text" : {
 "terms" : {
 "field" : "text"
 }
 } 
 }
}' | python -m json.tool

这个查询运行大约需要.4秒：

curl -XGET 'http://elasticsearch-node-01:9200/twitter/_search' -d '{
 "size" : 0,
 "query" : {
 "match_all" : {}
 },
 "aggs" : {
 "screen_name" : {
 "terms" : {
 "field" : "user.screen_name"
 }
 } 
 }
}' | python -m json.tool

这个查询运行时间为.08秒；这比text聚合查询有巨大的改进。

既然我们已经确定text聚合是查询中的慢速部分，考虑移除该操作并寻找另一个能产生类似结果的解决方案。尽管这取决于聚合的使用目的，但在低基数字段上进行聚合可能是一个合适的解决方案。例如，如果text聚合用于构建词云，可以考虑使用entities.hashtags.text标签字段来获取类似的结果。

另一个选项是保留text聚合，但定期在后台运行并缓存结果。

最后，考虑在这个查询上使用分片查询缓存。由于没有返回查询（size=0），我们可以启用search_type=count和query_cache=true参数来缓存聚合结果。

网络应用程序性能

你正在开发一个网络应用程序，该应用程序在 Elasticsearch 索引中搜索 Twitter 数据。除了在搜索结果页面上显示推文外，你还想显示：

随时间推移的推文活动
结果中的顶级用户
结果中的顶级标签
顶级用户提及

我们可以使用 Elasticsearch 聚合来实现所有这些项目，但这些操作的成本远高于简单地运行一个搜索查询。

为了加快页面加载时间，我们将它分为两个 AJAX 请求：一个用于结果查询，另一个用于所有聚合查询。这两个查询都是 AJAX 请求，这意味着页面将立即加载。查询结果将随后出现，聚合结果将最后加载。因为聚合查询不返回任何命中项，我们可以设置参数search_type=count和query_cache=true来缓存聚合以供未来查询使用。

在翻页结果时，确保只查询命中项，而不是聚合结果。聚合结果将保持不变，无论查看的是哪一页数据。

摘要

本章讨论了在使用 Elasticsearch 时出现的一些常见性能和可靠性问题。为了重申本章的一些主要观点：

总是仔细检查 Elasticsearch 集群的配置以查找错误
设置 fielddata 缓存大小，特别是如果你看到OutOfMemoryError异常
使用慢日志来查找在您的集群上运行缓慢的查询
避免在高基数字段（如毫秒级时间戳）上进行聚合
注意你的数据索引策略，以确保没有索引变得过大
使用索引预热器或启用eager_global_ordinals以确保首次运行使用 fielddata 缓存的查询速度快
如果可能的话，在索引数据的节点上使用 SSD，并避免在网络上存储 Elasticsearch 索引。

最重要的是，在诊断 Elasticsearch 问题时，要仔细在每个阶段进行测试。例如，在再次运行查询之前，不要试图通过修改elasticsearch.yml、修改查询条件以及启用索引warmers来同时优化查询。一次测试一个变量，以便在决定如何修复问题之前精确地找出问题所在。

下一章讨论了如何在节点故障发生后如何理解和修复它们。

第七章：节点故障和事后分析

在上一章中，我们学习了如何通过使用带有真实世界案例研究的案例研究来排查在使用 Elasticsearch 时出现的常见性能和可靠性问题。本章探讨了节点和集群故障的一些常见原因。具体涵盖的主题如下：

如何确定故障的根本原因
如何对节点故障采取纠正措施
带有真实世界故障诊断案例的案例研究

诊断问题

Elasticsearch 节点故障可以以许多不同的方式表现出来。节点故障的一些症状如下：

节点在大量数据索引过程中崩溃
Elasticsearch 进程因未知原因停止运行
集群无法从黄色或红色状态恢复
查询请求超时
索引请求超时

当你的集群中的节点遇到这些问题时，可能会诱使你只是简单地重启 Elasticsearch 或节点本身，然后像什么都没发生一样继续。然而，如果不解决根本问题，问题很可能会在未来再次出现。如果你遇到上述情况，请按照以下方式检查你的集群健康：

使用 Elasticsearch-head 或 Kopf 检查集群健康
使用 Marvel 检查历史健康状态
检查 Nagios 警报
检查 Elasticsearch 日志文件
检查系统日志文件
使用命令行工具检查系统健康

这些步骤将有助于诊断集群中问题的根本原因。在本节中，我们将探讨导致节点故障的一些潜在原因，包括以下内容：

内存不足错误
系统内存不足
资源争用
磁盘空间耗尽

OutOfMemoryError 异常

如果节点抛出 OutOfMemoryError，立即的解决办法是重启它。然而，并不总是明显何时或为什么节点会遇到这个错误。症状包括以下：

分片故障
搜索查询失败
索引失败

通常，根本不会有任何立即的症状。不幸的是，检查 Elasticsearch-head、Marvel 和 Bigdesk 并不能直接告诉你是否发生了 OutOfMemoryError 异常，但它们可以给我们一些可能发生异常的预警信号。为了确保确实发生了 OutOfMemoryError 异常，请检查 Elasticsearch 日志。

分片故障

OutOfMemoryError 异常发生的一个迹象是查询响应中出现了分片故障。此响应在 _shards.failed 键中指示分片故障，并在 _shards.failures 中描述了故障。

以下示例查询显示了查询响应中分片故障的外观：

curl -XGET http://elasticsearch-node-01:9200/twitter/_search?size=0
{
 "_shards": {
 "failed": 1,
 "failures": [
 {
 "index": "twitter",
 "reason": "NodeDisconnectedException[[elasticsearch-node-03][inet[elasticsearch-node-03/192.168.56.113:9300]][indices:data/read/search[phase/query]] disconnected]",
 "shard": 1,
 "status": 500
 }
 ],
 "successful": 2,
 "total": 3
 },
 "hits": {
 ...
 "total": 10803
 },
 ...
}

注意，尽管在这个查询中分片失败了，但它仍然返回了结果。然而，因为总共有三个分片，而只有两个成功返回了数据，所以查询结果并不能代表索引中的所有数据。

有时，如果集群处于红色状态，例如，_shards 对象将指示成功分片数少于可用分片总数，但不会报告错误。看看以下代码，其中 _shards.successful 小于 _shards.total，但 _shards.failed 设置为 0：

{
 "_shards": {
 "failed": 0,
 "successful": 2,
 "total": 3
 },
 "hits": {
 ...
 "total": 10803
 },
 ...
}

在这两种情况下，hits.total 值仅代表我们实际总数据量的三分之二左右。

当我们遇到分片失败或分片未能成功返回数据时，使用 Elasticsearch-head 检查集群状态是个好主意。Elasticsearch-head 可能看起来如下：

在 Elasticsearch-head 中重新定位的分片

在此截图中，我们可以看到所有分片现在都是可用的，但集群仍在恢复中，并且没有分片分配给 elasticsearch-node-01。此时，我们可能还会注意到集群需要非常长的时间才能返回到绿色状态，或者可能永远不会返回到绿色状态。这个问题可能是由于一个没有堆空间的节点未能将其中的一个分片重新定位到具有更多内存的另一个节点。

接下来，打开 Elasticsearch-kopf 以获取我们节点更详细的信息：

在 Elasticsearch-kopf 中重新定位分片

在 Elasticsearch-kopf 中，我们看到 elasticsearch-node-01 和 elasticsearch-node-02 上的堆使用量很高，这是内存溢出错误异常发生的良好指标。检查日志，我们确认在 elasticsearch-node-01 上抛出了 OutOfMemoryError：

检查 Elasticsearch 日志显示 OutOfMemoryError

此外，我们还在日志文件中看到几个其他异常记录，这些异常是在 OutOfMemoryError 之后出现的，如下截图所示：

与 OutOfMemoryError 相关的 Elasticsearch 日志中的附加错误

继续检查日志文件，我们看到一个错误指示由于节点内存不足导致分片失败：

Elasticsearch 日志中的分片失败错误

慢查询

慢查询是内存溢出错误（OutOfMemoryError）发生的另一个迹象。在先前的例子中，使用 Unix less 命令在 elasticsearch-node-02 上检查慢查询日志文件显示以下内容：

less my_elasticsearch_cluster_index_search_slowlog.log.2016-04-28

慢查询可能表明发生了错误

在 elasticsearch-node-02 上检查 Elasticsearch 日志，我们可以验证捕获了 OutOfMemoryError：

验证 Elasticsearch 抛出了异常

解决 OutOfMemoryError 异常

如前所述，当你看到OutOfMemoryError错误时，最好重启节点以防止进一步的异常。然而，这只是一个临时的解决方案。同时修复导致错误的基本问题也很重要。请参阅第六章，性能和可靠性问题故障排除，了解更多关于解决OutOfMemoryError异常的策略。以下列出了一些策略：

限制字段数据缓存的大小
为字段数据缓存启用断路器
调整批量数据插入的大小和频率
减少总分片数
确保ES_HEAP_SIZE设置正确
确保机器有足够的物理内存可用

在日志中看到错误后，我们可以将它们的时间戳与 Marvel 关联起来，以查看错误发生时的活动类型。例如，假设我们看到了以下OutOfMemoryError：

在 2016 年 4 月 29 日 15:26:39 发生了 OutOfMemoryError 异常

我们可以检查4/29/2016 15:26:39时间段的 Marvel 活动。在这种情况下，我们将它设置为从2016-04-29 15:25:00到2016-04-29 15:27:30，如下面的截图所示：

在 Marvel 中更改日期范围

尽管我们看到在崩溃时索引中没有搜索活动，但随后是一个适度的索引速率，随后是索引活动的下降：

使用 Marvel 进行调查

降级可能发生在OutOfMemoryError之后，大量的索引负载可能导致了错误。

由于OutOfMemoryError异常可能不会非常频繁地发生，因此很难确定我们实施的修复措施是否成功解决了问题。为了确保问题完全解决，最好找到一种可靠地重现错误的方法。然后，调整 Elasticsearch 配置设置和负载，直到你不再看到该问题。通常可以通过建立一个具有类似配置和负载的简单单节点集群来重现问题，作为主集群中的一个节点。在前面的例子中，我们可能会尝试通过将文档以类似的速率索引到受控环境中的单节点测试集群来验证数据批量加载是否导致了异常。

Elasticsearch 进程崩溃

如果 Elasticsearch 进程意外停止运行，可能是操作系统将其终止了。在这些情况下，Elasticsearch 日志文件可能没有关于错误的任何有用信息，我们反而需要检查syslog：

sudo tail -n200 /var/log/syslog
View the last 200 lines of /var/log/syslog
...
Apr 29 14:56:00 elasticsearch-node-01 kernel: [39935.321257] Out of memory: Kill process 5969 (java) score 446 or sacrifice child
Apr 29 14:56:00 elasticsearch-node-01 kernel: [39935.321343] Killed process 5969 (java) total-vm:2361960kB, anon-rss:441676kB, file-rss:14392kB

如果 Elasticsearch 试图声明比可用内存更多的系统内存，这通常是由于ES_HEAP_SIZE设置不正确或其他进程的资源竞争造成的。如果你的集群遇到这个问题，并且集群上运行着其他内存密集型进程，那么将这些进程从 Elasticsearch 集群中移除可能是个好主意。为了验证 Elasticsearch 是否被操作系统强制停止，请检查/var/log/syslog中的syslog文件：

操作系统因内存不足而杀死了 Elasticsearch 进程

取以下行：

Apr 29 14:55:34 elasticsearch-node-01 kernel: [39909.742047] Out of memory: Kill process 5878 (java) score 446 or sacrifice child

这一行表示操作系统杀死了 Elasticsearch 进程。在这种情况下，我们不会在 Elasticsearch 日志文件中看到任何相应的日志条目。

磁盘空间

当一个节点耗尽磁盘空间时，它将留在集群中，仍然可以处理索引和搜索请求，但它会将其分片卸载到集群中的其他节点。当集群重新分配分片时，查询可能会运行缓慢或超时。一旦分片重新分配到集群中的其他节点，你可能会看到一些性能下降，因为集群正在使用一个更少的数据节点运行。

如果所有节点都配置了相同数量的空间，节点耗尽磁盘空间可能会很危险。如果一个节点耗尽空间，那么集群中的其他节点可能也接近磁盘空间不足。一旦集群将分片重新分配到集群中的其他节点，这可能导致这些节点也耗尽空间。这会导致连锁反应，最终导致整个集群崩溃。

我们可以使用 Kopf 或 Marvel 检查节点是否磁盘空间不足，或者通过配置 Nagios 警报。此外，我们还会在 Elasticsearch 日志中看到与磁盘空间不足相关的错误，如下面的截图所示：

Kopf 显示elasticsearch-node-01磁盘空间不足

解决问题

磁盘空间问题可以分为两大类：

Elasticsearch 中加载了过多的数据，正在占用磁盘空间。
除了 Elasticsearch 数据之外，还有其他东西正在占用磁盘空间，例如，一个大的日志文件。

要解决第一类问题，一个解决方案是通过向节点添加另一个驱动器或卷来增加节点的存储容量，并配置 Elasticsearch 使用该空间。例如，如果我们将在/data上挂载额外的存储，更新elasticsearch.yml配置文件如下：

path.data: /var/lib/elasticsearch,/data

在节点上重启 Elasticsearch。然后节点将把其数据分布在两个数据目录中。

对于第二类问题，如果原因是 Elasticsearch 外部，删除违规文件以清理磁盘空间就足够让 Elasticsearch 再次运行。不需要重启节点。

我们可以采取的一些额外措施以减少磁盘空间使用如下：

向集群中添加额外的节点。
减少分片副本数；例如，从两个副本减少到一个副本。
通过将大型索引拆分成较小的索引来确保单个分片不会变得太大。例如，而不是将所有 Twitter 数据存储在一个索引中，每个月创建一个新的索引来存储新数据。
启用数据压缩（参考第六章, 解决性能和可靠性问题）。

检查一些案例研究

本节讨论了一些 Elasticsearch 节点故障的真实场景以及如何解决这些问题。

ES 进程意外退出

几周前我们在 Marvel 上注意到我们的一个节点上的 Elasticsearch 进程宕机了。我们在该节点上重启了 Elasticsearch，一切似乎都恢复了正常。然而，在那一周稍后检查 Marvel 时，我们发现节点再次宕机了。我们决定查看 Elasticsearch 的日志文件，但没有发现任何异常。由于我们在 Elasticsearch 日志中没有看到任何异常，我们怀疑操作系统可能已经杀死了 Elasticsearch。在/var/log/syslog的syslog中检查，我们看到以下错误：

Out of memory: Kill process 5969 (java) score 446 or sacrifice child

这验证了操作系统杀死 Elasticsearch 是因为系统内存不足。我们检查了 Elasticsearch 的配置，没有发现任何问题。这个节点配置与集群中的其他节点相同。接下来，我们通过运行top命令检查与其他进程的资源争用，得到以下结果：

顶部显示资源争用

看起来这个节点上也在运行 MySQL 服务器，并且占用了大量的系统内存。我们怀疑与 MySQL 的资源争用可能是导致操作系统杀死 Elasticsearch 的原因。我们能够将 MySQL 数据库迁移到其自己的专用主机，在几周内没有再出现内存问题后，我们可以得出结论，这个问题已经解决了。

查询请求缓慢且超时

我们企业级 Elasticsearch 支持的 Web 应用程序的用户开始报告搜索功能缓慢，有时甚至完全不返回结果。我们能够通过在 Web 应用程序上运行一些搜索来验证这一点，并决定使用 Kopf 来调查这个问题。在 Kopf 中，我们注意到我们的一个节点elasticsearch-node-01的磁盘指示器是红色的，如下面的截图所示：

Kopf 显示elasticsearch-node-01磁盘空间不足

elasticsearch-node-01 的红色磁盘指示灯意味着我们的磁盘空间不足。此外，该节点上的所有分片都已重新分配到其他节点。通过查看 /var/log/elasticsearch/my_elasticsearch_cluster.log 中的 elasticsearch-node-01 日志，我们确认磁盘已满，因为看到了 设备上没有剩余空间 的消息。我们通过向集群中的所有节点添加额外的硬盘驱动器，并在 elasticsearch.yml 文件中配置 Elasticsearch 使用新空间来解决这个问题。

为了防止未来出现此类问题，我们决定按照第五章中找到的说明安装 Nagios，系统监控，以便在磁盘空间不足时发送电子邮件警报。

摘要

本章探讨了如何诊断节点故障，确定问题的根本原因，并采取纠正措施。我们学到的一些关键点是：

许多错误，从分片故障到查询性能缓慢，都是由 OutOfMemoryError 异常引起的。
当分片重新分配时，一个节点上的磁盘空间不足可能会导致其他节点也出现磁盘空间不足的情况。
在运行需要大量内存的其他服务的同时运行 Elasticsearch，可能会导致操作系统为了释放内存而杀死 Elasticsearch。

下一章将讨论 Elasticsearch 5.0，这是平台的下一个主要版本，它将为您概述将伴随 Elasticsearch 5.0 发布的各种新监控工具。

第八章. 展望未来

本章最后讨论了 Elasticsearch 的下一个主要版本，即 5.0，它相对于 2.3.2 是一个重大的升级。它引入了许多 API 增强以及几个性能和可靠性更新。许多这些变化，无论好坏，都将影响您与 Elasticsearch 集群的交互和监控。

本章我们将讨论的具体主题包括：

Elasticsearch 5 概述
升级到 Elasticsearch 5
监控 Elasticsearch 5

Elasticsearch 5 概述

Elasticsearch 5 将作为下一个主要软件发布版紧随 Elasticsearch 2。尽管这可能从时间顺序上令人震惊，但 Elastic.co 故意从版本 2 跳到 5，以更好地将更新后的 Elasticsearch 版本与 Kibana、Logstash、Marvel（在 5.0 中称为 Monitoring）和其他几个 Elastic.co 产品同步。这次更新将有助于确保集群上运行的所有 Elastic.co 软件既兼容又更新。

版本 5 中引入了数百项新变化，但一些相关的亮点包括：

Elasticsearch 2 API 与 Elasticsearch 5 之间的兼容性
Elasticsearch 2 的索引可以迁移到版本 5：
- Elasticsearch 1 的索引必须首先迁移到版本 2，然后再迁移到版本 5
Marvel 已更名为 Monitoring
Elasticsearch-Logstash-Kibana 堆栈更名为 Elastic Stack
插件 API 不再支持站点插件，包括 Elasticsearch-head、Bigdesk 和 Kopf 等插件
为了支持急切字段数据加载和基于磁盘的规范，已移除 warmers API
Lucene 版本从 5 升级到 6
几项配置更改，包括移除所有系统环境变量，如 ES_HEAP，以支持 Java VM 命令行参数
text 和 keyword 映射类型已被弃用，以支持 string 类型
bin/plugin 重命名为 bin/elasticsearch-plugin

注意

Elasticsearch-head、Bigdesk 和 Kopf 尚未更新以兼容 Elasticsearch 5。当它们升级时，它们将作为独立应用程序运行，类似于 Kibana。

性能和可靠性

Elasticsearch 5 引入了几项性能和可靠性改进，包括：

小文档的索引性能提高了 15-20%
Lucene 6 通过提高 25% 的搜索时间，并将数字、日期和地理空间字段的磁盘空间使用量减少 50% 来改进搜索时间
elasticsearch.yml 设置文件现在将进行严格的验证，这意味着如果存在配置错误，Elasticsearch 将无法启动
如果一个生产节点（意味着一个未绑定到 localhost 地址的节点）没有足够的文件句柄可用，或者没有权限通过 mlockall 设置锁定系统内存使用，它将抛出异常并且无法启动

数据丢失

Elasticsearch 2 存在一个广为人知的持续问题，在涉及网络问题和网络分区的情况下，Elasticsearch 在数据导入期间可能会丢失数据。

在网络分区期间写入 Elasticsearch 的数据将被确认，但并非所有数据实际上都会到达索引。Elasticsearch 团队已努力解决这个问题，并且在新版本中修复了许多——但并非所有——的 bug 实例。考虑到这一点，在构建基于 Elasticsearch 的应用程序时，无论是版本 2 还是版本 5，请考虑以下内容：

不要将 Elasticsearch 作为主数据存储使用。相反，根据您的数据大小和需求，使用数据库，如 HBase、Cassandra、PostgreSQL 或其他数据库。
一定要核实您主数据存储中的数据记录数量与 Elasticsearch 中的数量相匹配。
在数据丢失的情况下，制定一个重新索引数据的计划。

虽然数据丢失的可能性非常小，但潜在的影响是巨大的，因此制定行动计划非常重要。

升级到 Elasticsearch 5.0

Elasticsearch 5 版本即将发布。开始测试您的集群与新版本兼容性是个好主意。为了帮助升级过程，Elastic.co 提供了一款名为Elasticsearch 迁移助手的工具。将此工具作为 Elasticsearch 2.3 插件安装：

sudo /usr/share/elasticsearch/bin/plugin install https://github.com/elastic/elasticsearch-migration/releases/download/v2.0-alpha2/elasticsearch-migration-2.0-alpha2.zip

注意

Elasticsearch 迁移助手仅与 Elasticsearch 2.3 兼容。

安装插件后，通过访问http://elasticsearch-node-01:9200/_plugin/elasticsearch-migration/在浏览器中打开它，如下截图所示：

Elasticsearch 迁移助手

在使用 Elasticsearch 5 之前，集群检查诊断将显示必要的更新报告：

Elasticsearch 迁移助手配置检查报告

集群检查显示，在迁移到 Elasticsearch 5 之前，我们必须删除一些不兼容的插件，包括 Elasticsearch-head、Kopf 和 Marvel Agent。在升级之前，我们还需要更新一些系统和节点配置设置。

在修复所有这些配置问题后，我们可以使用 Elasticsearch 迁移助手启用弃用日志。此日志文件记录了每次我们调用将在版本 5 中弃用或删除的 Elasticsearch API 方法的时间。

以下截图显示了如何从 Elasticsearch 迁移助手启用弃用日志：

点击启用/禁用链接以激活弃用日志

一旦启用日志，它可以在以下位置找到：

/var/log/elasticsearch/<cluster_name>_deprecation.log

何时升级

在运行 Elasticsearch 迁移助手并纠正所有相关错误和警告后，您可以在开发环境中安全地升级到 Elasticsearch 5。现在您可以测试应用程序，以确保一切与新版本兼容。请密切关注弃用日志，并注意您需要修复的事情。

由于这是一个重大版本，您可能值得在生产通用可用性发布后的几个月内推迟生产升级。与任何新软件一样，Elasticsearch 5 的早期版本可能会有一些错误，这些错误将在它被普遍提供后不久得到修复。

监控 Elasticsearch 5

Elastic.co 在 Elasticsearch 5 中对监控工具套件进行了重新品牌化，包括 Elasticsearch-Logstash-Kibana (ELK)堆栈。现在 Marvel 更名为监控，并附带了一些额外的监控工具。ELK 堆栈现在仅称为Elastic Stack。

Elasticsearch X-Pack 是一套高级监控工具，Elastic.co 对其在生产环境中的运行收取年度费用。X-Pack 包括以下工具：

监控：之前为 Marvel
Shield：为 Elasticsearch 添加身份验证、访问控制和 HTTPS 支持
Watcher：类似于 Nagios，但具有一些 Elasticsearch 特定的功能，例如如果查询运行缓慢，则发送电子邮件警报
图：网络图数据可视化工具
报告：基于 Kibana 中的数据生成 PDF 报告

Kibana 和 Marvel 也获得了更新的外观和感觉，如下截图所示：

Kibana 更新外观和感觉

Marvel 现在以更新的外观和感觉进行监控

摘要

本章探讨了即将发布的 Elasticsearch 5 版本，讨论了升级到 5.0 版本，并简要介绍了 Elasticsearch X-Pack 中可用的新监控工具。本章的一些要点包括：

Elasticsearch 5 在性能和可靠性方面取得了一些重大进步，但也对 API 进行了一些破坏性更改。
Elasticsearch-head、Bigdesk 和 Kopf 目前与 Elasticsearch 5 不兼容。
Elasticsearch 5 是一个重大版本，从 2.0 版本升级可能不是一个简单的过程。在升级之前，请务必运行 Elasticsearch 迁移助手。
Elasticsearch X-Pack 为 Elasticsearch 5 提供了一套监控工具，但并非免费。

感谢您阅读《监控 Elasticsearch》。希望您学到了一些监控和故障排除 Elasticsearch 集群的新技巧。如果您只从这本书中带走了一件事，我希望它是对细节的严谨，以及在处理 Elasticsearch 时遇到问题时，在每个步骤都要进行测试。

如果你愿意回馈 Elasticsearch 社区，请考虑为 Elasticsearch-head、Bigdesk 或 Kopf 项目做出贡献。这些都是优秀的开源工具，让使用 Elasticsearch 的每个人的生活变得更轻松。正如本章所述，它们都需要重新架构和更新以与 Elasticsearch 5 兼容。

注意

你可以在这里了解更多关于以下主题的信息：

Elasticsearch-head: github.com/mobz/elasticsearch-head
Bigdesk: github.com/lukas-vlcek/bigdesk
Kopf: github.com/lmenezes/elasticsearch-kopf

此外，你也可以在 Twitter 上联系我：@dwnoble。

posted @ 2025-09-10 14:11 绝不原创的飞龙阅读(24) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

ElasticSearch-监控指南-全-

ElasticSearch 监控指南（全）

前言

本书涵盖的内容

你需要这本书的以下内容

本书面向对象

约定

注意

小贴士

读者反馈

客户支持

下载示例代码

下载本书的彩色图像

错误清单

盗版

问题

第一章：Elasticsearch 监控简介

Elasticsearch 概述

了解更多关于 Elasticsearch 的信息

数据分布、冗余和容错

全文搜索

注意

相似的技术

Apache Lucene

注意

Solr

Ferret

监控 Elasticsearch

资源丰富性和问题解决能力

摘要

第二章：Elasticsearch 的安装和需求

安装 Elasticsearch

DEB/RPM 安装

yum 和 apt-get 仓库

Ubuntu/Debian 和 apt-get

CentOS/RHEL 和 yum

验证

配置文件

配置 Elasticsearch 集群

集群名称

内存配置

打开文件限制

最大文件限制

在 Ubuntu Linux 上更新最大文件描述符

小贴士

启用可插拔认证模块

验证打开文件限制

禁用交换

了解您的集群

安装 Elasticsearch-head

安装 Bigdesk

Marvel

集群要求

摘要

第三章：Elasticsearch-head 和 Bigdesk

集群设置

集群配置

示例数据

小贴士

Elasticsearch-head

概览选项卡

集群状态

注意

节点和索引操作

备注

索引标签页

备注

浏览器标签页

结构化查询标签页

任意请求标签页

官方网站

Bigdesk

注意

Elasticsearch cat API

背景

计数

注意

健康