Skip to content

Latest commit

 

History

History
232 lines (136 loc) · 18.2 KB

10.md

File metadata and controls

232 lines (136 loc) · 18.2 KB

十、利用 ELK 栈进行监控

监控是任何环境中必不可少的一部分，无论是生产、质量保证还是开发；Elastic Stack(ELK Stack)通过允许来自不同来源的日志、指标和事件聚合到单个可索引位置:Elasticsearch，帮助简化了这项任务。

ELK 栈是三个不同软件的集合:

  • Elasticsearch
  • logstash(日志记录)
  • 姆纳人

在本章中，我们将解释每个组件的作用。

在本章中，我们将涵盖以下主题:定义 Elasticsearch 的主要功能

  • 探索集中式日志的概念
  • 基巴纳如何帮助整合其他组件

技术要求

以下是本章的技术要求列表:

理解监控的必要性

想象一下，您被要求向首席信息官提供历史数据，因为一个正在进行的项目需要整个生态系统平均使用多少 CPU 的信息，但企业从未投入时间来实施一个好的监控系统。因此，您唯一的选择是登录每个系统并运行本地命令，将结果记录到电子表格中，做一些数学运算以获得平均结果，在这一切之后，您意识到数据不再有效，您必须再次经历所有这些。这正是我们拥有 Elasticsearch 等监控系统的原因。同样的过程可能需要几分钟。不仅如此，您还将获得准确的数据和实时报告。让我们更多地了解什么是监控，以及作为架构师，为什么您应该认为它是有史以来最好的东西。

监控是指从任何给定的环境中获取原始数据，将其聚合、存储并以可理解的方式进行分析的过程。

所有环境都应该有某种形式的监控，从用于跟踪失败登录的简单日志文件，到负责分析来自成千上万台主机的数据的更健壮的系统。监控数据允许系统管理员在问题出现之前发现问题，并允许架构师根据数据为未来或正在进行的项目做出决策。

大家可能还记得第 1 章、设计方法论介绍中，我们讲过问对问题如何帮助设计更好的解决方案，同时给出正确的答案；例如，它可以帮助根据历史使用数据做出规模决策。向架构师提供使用数据有助于正确确定解决方案的规模。它们不仅利用未来的使用统计数据，还利用过去的实例，在这些实例中，使用高峰记录在高峰时间，例如周末。

让我们尝试将为什么需要监控归纳为四个主要方面:

  • 通过历史数据做出决策
  • 主动发现问题
  • 了解环境绩效
  • 预算计划

通过历史数据做出的决策

监控提供了回溯时间和分析使用趋势的能力，以帮助确定机会领域。例如，在第 1 章、设计方法介绍中呈现的场景中，客户需要能够维持每秒 10，000 次点击的 web 服务器解决方案。作为架构师，您请求访问他们现有解决方案中的使用数据，在查看了他们的使用趋势后，您确定每月第一周的使用量增加了 10 倍。

虽然用户可能不会在这段时间抱怨问题，但您应该考虑到，这种高使用率往往会在这段时间利用资源。从监控系统获取的数据可能会导致这样的决定，即需要分配给服务器的资源(例如，更多的中央处理器和内存)比以前计算的要多，或者需要向集群添加更多的服务器(如果可能的话)。

没有这些数据，没有人会知道由于峰值需要更多的资源。从峰值中辨别正常使用的能力有助于在设计和调整解决方案时做出正确的选择。

从同一个场景中，我们可以从历史数据使用情况中得出结论，当前解决方案在过去几个月中每秒钟保持了 10，000 次点击。这可能意味着客户能够始终获得期望的性能，但实际上他们需要的是一个能够处理使用高峰的解决方案，如前所述。

主动发现问题

想象一下，当你准备回家的时候，突然有人报告数据库服务器无法接收连接。您登录到服务器，注意到问题比最初报告的要严重得多。数据库中数据所在的磁盘现在都报告为故障磁盘。您仔细查看系统上的日志，注意到过去四个月报告了磁盘错误；然而，由于没有一个健全的监测系统，没有人知道有错误。现在，数据丢失了，您必须检索旧的备份，这需要几个小时才能恢复生产。

不幸的是，这种情况并不罕见，大多数情况下，信息技术是被动工作的，这意味着如果有东西坏了，有人会报告有东西坏了，然后有人会去修理坏了的东西。如果监控系统已经实现并配置为报告错误，这是完全可以避免的。这些磁盘本可以在发生灾难性故障之前更换。

在我们看来，能够在问题出现之前主动发现问题是监控系统最关键的方面之一。通过允许采取措施，在问题发生之前预测问题可能发生的位置有助于减少停机时间。例如，在前面的场景中，更换驱动器可以防止数据丢失。预测变化还有助于降低运营成本，防止因停机或故障造成的业务损失，并增加生产(或正常运行时间)。

了解环境绩效

在第 5 章、分析 Gluster 系统的性能 m 中，我们对 GlusterFS 实现进行了性能测试。有了监测系统，通过汇总历史数据和平均统计数据，可以简化获得业绩基线的过程。

通过查看历史数据，我们可以看到任何给定系统在一定时间内的平均性能，从而允许架构师定义什么是正常的，什么不是。通过获取基线，我们可以在更深层次上了解环境在一天、一周甚至一个月中的行为。例如，我们可以确定存储服务器在一天中的恒定吞吐量约为 200 MB/s，当用户在一天的前几个小时登录时，吞吐量会飙升至 300 MB/s。100 MB/s 的峰值起初似乎是一个问题，但从数据来看，这似乎是一种趋势，也是标准行为。

有了这些信息，我们知道基线约为 200 兆字节/秒，峰值为 300 兆字节/秒。当解决方案达到基准时，它的性能有望达到该规格。如果我们获得的结果低于这个数字，我们就知道有问题，需要进行调查以确定性能不佳的原因。这可能是解决方案的重新设计，也可能是配置的实际问题。另一方面，较高的数值表明即使在负载峰值下，该解决方案也可以按照规格运行。

没有这些数据，我们就不知道不稳定的行为是什么样子，也无法确认这是否是一个实际的问题，或者看看什么对环境来说是正常的。了解解决方案的性能和用途有助于发现可能不存在的问题。例如，考虑具有先前数字的情况，其中用户与存储服务器正常交互并且具有平均响应时间；但是，从监控数据中，我们观察到，即使在常规用户负载下，我们也只能获得 50 MB/s 的吞吐量。从用户的角度来看，一切似乎都很好，但当被询问时，他们确实报告说，即使响应时间很好，传输也比通常需要更长的时间，经过进一步调查，发现了一个问题，其中一个节点需要维护。

在前面的示例中，仅通过查看性能数据，就可以发现解决方案性能不足的情况，并采取措施避免停机和业务损失。这就是通过使用数据来了解环境的力量。

预算计划

数据使用趋势允许对预算规划进行更精细的控制，因为知道需要多少存储空间有助于避免没有提供足够空间的情况。

在第 1 章、设计方法介绍中，我们谈到了企业的采购流程，以及如何努力遵守时间表至关重要，因为这因公司而异。了解空间需求和使用情况对于这一过程至关重要，因为它可以帮助预测，例如，解决方案何时会耗尽空间，并可以帮助做出获取新存储空间的决策。

通过使用监控系统了解企业每天是否消耗 X 个存储量(也称为每日变化率)，可以让系统管理员和架构师预测企业在当前可用空间下可以运行多长时间。这还将使他们能够预测解决方案何时会耗尽空间，以便他们能够在存储耗尽之前采取行动，这是每个信息技术部门都应该避免的情况。

了解资源利用率对于任何业务都至关重要，因为它可以防止不必要的设备采购。使用数据来决定是否应该向现有环境中添加更多资源，通过选择在升级时要添加的正确设备数量来降低成本。当应用由于缺乏资源(或过时的硬件)而表现不佳时，情况就不一样了，因为没有数据来确认当前环境是否按预期运行，并且仍有一定的增长空间。

今天，监测的需要比以往任何时候都更加重要。随着信息技术环境中数据的几乎指数级增长，能够预测行为并主动采取行动可以通过数据驱动的决策来实现，这只有通过监控系统(如 ELK 栈)才能实现。

集中式日志

在深入探讨 ELK 栈的构成之前，让我们先探讨一下集中式日志的概念。

想象以下场景；环境中似乎存在安全漏洞，在一些服务器中发现了一些外观奇怪的文件。查看/var/log/secure文件，发现多个地址的 root 登录，想知道哪些系统受到了影响。只有一个问题——环境中有 5，000 多台 Linux 服务器，您必须登录每个系统并查看日志。对每台主机进行 grep 可能需要大约一分钟；直接查看系统日志需要 83 个多小时。

必须前往每个节点的这个问题可以通过将日志聚合到一个集中的位置来解决。虽然该行业的其他部门似乎正在走去中心化服务的路线，但将所有环境日志放在一个位置有助于简化任务，例如调查可能影响多个系统的事件。只需寻找一个位置就可以减少故障排除所需的时间，同时使管理员能够更有效地查找环境中的问题。

集中式日志体系结构如下所示:

来自多个应用的日志被发送到日志解析器(如 Logstash)，然后被移动到索引器(如 Elasticsearch)。每个主机都有一个代理，负责将日志传送给解析器。

解析器的工作是转换数据以便于索引，然后将数据发送给索引器。

在下一部分，我们将看看组成 ELK 栈的组件。

Elasticsearch 概述

现在，我们将深入探讨 ELK 栈的组件，我们将从最重要的组件开始:Elasticsearch。

Elasticsearch 基于一个名为 Lucene 的 Apache 项目。它的作用是索引数据并存储起来以备以后检索。Elasticsearch 从不同的来源接收数据，并将其存储在一个集中的位置，或者多个节点(如果它们被设置为集群)。对于这个设置，我们将使用 Logstash 作为数据源；但是，Elasticsearch 可以直接从 Beats 接收数据，我们将在后面讨论。Elasticsearch 的核心是一个分析和搜索引擎，能够非常快速地检索数据；由于数据一旦存储就会被索引，因此 Elasticsearch 将数据存储为 JSON 文档。

定义 Elasticsearch 的几个因素如下:

  • 快的
  • 可攀登的
  • 高度可用

快的

搜索几乎是实时的；这意味着，当您输入搜索词时，Elasticsearch 几乎会立即返回结果。这要感谢作为 JSON 存储的索引和数据。

可攀登的

只需向集群中添加更多节点，即可快速扩展 Elasticsearch 集群。

高度可用

当配置为集群时，Elasticsearch 在多个节点之间分配碎片，在一个或多个节点出现故障时创建碎片的副本。

碎片是 JSON 文档的一个片段。Elasticsearch 创建碎片的副本，并将它们分配到集群节点上。这使得群集能够承受灾难性故障，因为数据仍然以副本的形式存在。

logstash(日志记录)

大多数情况下，数据(如日志文件)的设计是为了让人类能够轻松理解事件的含义。这种类型的数据是非结构化的，因为机器不能轻易地索引事件，因为它们不遵循相同的结构或格式。以系统日志和 Apache 为例。虽然每个日志提供不同类型的事件，但是没有一个遵循相同的格式或结构，并且对于索引系统来说，这成为一个问题。这就是 Logstash 的用武之地。

Logstash 数据处理解析器能够同时从多个来源接收数据，然后通过将其解析为结构化形式来转换数据，然后将其作为索引的、易于搜索的数据发送到 Elasticsearch。

Logstash 的一个主要特性是有大量的插件可以用于像 Grok 这样的过滤器，允许更大的灵活性来解析和索引什么类型的数据。

神交

Grok 是 Logstash 中的一个插件；它从系统日志、MySQL、Apache 和其他网络服务器日志等来源获取非结构化数据，并将其转换为结构化和可查询的数据，以便轻松摄入 Elasticsearch。

Grok 将文本模式组合成与日志匹配的东西，例如数字或 IP 地址。这种模式如下:

%{SYNTAX:SEMANTIC}

这里，SYNTAX是匹配文本的模式的名称，SEMARY 是给文本段的标识符。

HTTP 事件的一个例子如下:

55.3.244.1 GET /index.html 15824 0.043

这方面的一个模式匹配可能如下:

%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}

因此，通过将所有这些放在一个实际的过滤器配置中，它看起来像这样:

input {
  file {
    path => "/var/log/http.log"
  }
}
filter {
  grok {
    match => { "message" => "%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes} %{NUMBER:duration}" }
  }
}

自定义模式

当运行一个定制的应用时，Logstash 将没有正确的模式来匹配语法和语义。Logstash 允许创建可以匹配自定义数据的自定义模式。可以使用前面示例中的相同逻辑来匹配数据。

基巴纳把一切都聚集在一起

Elasticsearch 是 ELK 栈的重要组成部分，Logstash 是解析和处理部分，而基巴纳是将其他所有内容聚合在一起的部分。

可视化数据的能力允许用户赋予他们的数据意义。只看原始数据，很难理解。Kibana 通过图形、地图和其他数据整形方法，可视化存储在 Elasticsearch 中的数据。

以下是从现场演示中快速浏览基巴纳的界面:

Kibana Dashboard

我们可以看到用多个显示不同指标的模块来解释数据是多么容易。

Kibana 可以轻松理解大型数据集。作为一个基于浏览器的应用，它可以从任何地方访问。这也允许仪表板和报告与他人轻松共享。它可以安装在 Elasticsearch 旁边；但是，对于较大的部署，将主机分配给基巴纳是一个很好的做法。此外，Kibana 运行在 Node.js 上，因此它可以安装在几乎每一个可以运行 Node.js 的系统上，从所有风格的 Linux 到 Windows 和 MacOS。

摘要

在这一章中，我们探讨了监控的必要性，并了解了从环境中获取数据、汇总数据并存储的过程，以便以后可以检索数据进行进一步分析。能够通过浏览数据来塑造数据并了解环境的行为有助于提高运营效率。

监控使我们能够在问题发生或成为更大的问题之前主动发现问题。这是通过观察趋势来实现的，也是实施和设计监控解决方案的最重要原因之一。我们还谈到了能够主动采取行动，以及这如何有助于减少停机时间和在问题上浪费金钱；通过给数据赋予形状可以实现的事情。

性能也是受益于数据分析的一个领域。您可能还记得前几章，在设计解决方案时，能够对性能进行基线化和度量可以实现粒度控制。有历史数据可以参考，有助于做出影响设计性能的决策，同时允许我们根据运行环境中的真实数据来规划预算。

我们讨论了为什么拥有一个集中的日志记录系统可以帮助简化管理任务的主要原因；从一个位置查看所有日志，而不是连接到环境中的每个系统，可以节省时间，并允许更快、更高效的调查。

我们还概述了构成 ELK 栈的每个组件。Elasticsearch 是数据存储和分析的主要部分。我们注意到它非常快，因为数据存储为 JSON 文档；该解决方案是可扩展的，因为节点可以轻松添加；并且它是高度可用的，因为数据分布在节点上。

Logstash 通过 GROK 等插件提供数据转换和过滤，它将一个SYNTAX与一个SEMANTIC匹配，例如，一个 IP 与一个客户端匹配。

最后，我们研究了基巴纳如何通过综合图形可视化和分析数据来连接所有其他组件。

在下一章中，我们将进入每个组件的需求。

问题

  1. 什么是监控？
  2. 监控如何帮助做出业务决策？
  3. 如何主动检测问题？
  4. 监控如何允许性能基线化？
  5. 监控如何帮助识别不稳定的行为？
  6. 对集中式日志的主要需求是什么？
  7. 什么是 Elasticsearch？
  8. Elasticsearch 以什么格式存储数据？
  9. 什么是 Logstash？
  10. 什么是基巴纳？

进一步阅读