如何使用开源 TICK Stack 快速搭建现代化的应用程序和基础设施监控系统

作者：Gianluca Arbezzano254 / 产品, 开发者
2018 年 8 月 23 日

导航至

我们的应用程序会说话，而时间序列是它们的语言之一。DevOps、云计算和容器改变了我们编写和运行应用程序的方式。这篇文章展示了 InfluxData 和社区正在构建什么，以提供基于开源项目集的现代且灵活的监控工具包。

在过去的十年里，一切都发生了变化：容器、虚拟机、云计算。此外，一切都变得更快，我们需要一个能够支持这种速度的环境。我们的应用程序需要增长，以帮助我们长期维护它们。为此，我们需要了解应用程序的行为，并准备好失败和改进。我们拥有实现这一目标的工具和技术，只需要将它们整合在一起，以了解应用程序的行为方式、基础设施的增长方式，并最终了解系统故障或错误，从而提高性能。

监控日志

长期以来，我们一直在阅读日志，并使用一些工具来帮助我们理解应用程序的行为。我们这样做是因为

  1. 我们需要信任某人。 我们仅仅通过看屏幕是无法知道应用程序的行为的。我们需要了解用户如何使用我们的应用程序以及有多少错误。有很多指标需要跟踪。所有这些指标共同构建了对我们系统的信任。
  2. 我们想要预测未来。 我们希望将这些预测建立在我们识别的指标和行为之上，以了解我们是否在增长、增长了多少以及未来可以增长多快。有了所有这些信息，我们可以设计一个计划，也许可以预测一些糟糕的事件（也因为我们不是约翰·兰博，他肯定知道在任何情况下该怎么做！）。

<figcaption> 日志示例</figcaption>

系统监控团队使用一个非常强大的命令，称为“tail”来读取日志。这就是我们的应用程序通常说话的方式。当涉及到日志时，存在一个基本或正常状态。如果我们的日志以这种正常状态流式传输，那么一切都很好。如果它们流式传输得太快或太慢，那么就说明有问题，需要采取纠正措施。

这不是理解应用程序如何说话的最聪明的方式，但它是每个人都在使用的最常见的监控应用程序的方式。我们现在肯定可以做得更好，这与日志的性质有关。

日志是描述性的，包含大量信息。但是将它们存储在数据库中非常昂贵。它们不容易索引，因为它们通常是纯文本格式。这意味着您的引擎需要努力工作才能理解与其他日志的连接，或者让您搜索您正在寻找的内容。如果您有大量日志或正在使用日志来处理应用程序中的任何事情，那么您需要有一个良好的系统在您背后。这很困难，但绝对不是不可能的。

有很多工具和服务可以帮助将日志放在一起并弄清楚发生了什么，例如 Logstash、Kibana、Elasticsearch、NewRelic、CloudWatch、Graphite 等。其中一些以服务形式提供，一些是开源项目，一些两者都是。关键是，有很多选择。

选择日志监控工具

选择合适的工具始终取决于您正在做什么。在某些用例中，您需要日志用于取证或存档。由于日志包含有关正在发生的事情的详细信息，因此您将能够将它们用于这些用例。当您遇到错误时，您将能够确定它是什么类型的错误。日志通常用于获取此类信息。

但是，在其他情况下，您只需要知道应用程序的行为方式——它是增长还是缩小，或者错误在时间上是如何分布的。您真的不需要知道根本原因或发生了什么——您只需要知道存在行为变化。另一方面，时间序列也用于您的日常工作中，以帮助您了解系统的性能。它们不像日志那样详细——因为它们说的是另一种语言。例如，CPU、内存使用率是时间序列。

您不能只使用时间序列而不使用日志，因为有些问题您需要使用适当的日志来解决。我不是来争论日志优于时间序列还是反之亦然的好处，因为您很可能两者都需要，并且您将从两者中提取价值。您不仅会同时使用两者，而且实际上，日志是时间序列数据的一种形式。如果您将日志通过时间序列和值进行缩减，那么我们可以在其上进行一些数学运算，并且日志变得更容易索引。

实际上，您正在将日志转换为时间序列。如果您考虑应用程序中的登录次数、您遇到的错误数量或如果您是一家金融公司，您正在进行的交易数量，这些都是时间序列，因为它是一个值，一次登录，在某个时间点。它是在时间上的分布。这就是时间序列的含义。这就是日志可以被翻译的方式。这不是整数或值。这只是从不同角度来看的适当日志。

为了简化，您可以将日志简化为一个值，并且您有一个时间点可以聚合、比较等等。如果您考虑您的应用程序大约 10 分钟，您可以获得大量时间序列。

额外加分项：您可以从服务器获得的所有资源使用情况都是时间序列。您可以使用应用程序统计信息来可视化它们，以了解错误率的峰值如何加剧您的内存使用。

以下引言是正确的：做复杂的事情非常容易。

作为开发人员，我们知道我们五年前所做的一切现在看起来都如此复杂。我们现在的目标是使事情变得简单。当您拥有简单的东西时，更容易向其他人解释和维护。这就是我尝试用时间序列做的事情：只有一个简单的值和时间，其中值是一个数字。使用这种模型，您可以进行一些数学运算，聚合它们，创建图表，并且您有一种成本较低的方式来从应用程序中提取信息。但是，与 Cassandra、MySQL、MongoDB 等传统通用工具相比，InfluxDB 更适合处理此类数据，因为它提供了专门用于解决此特定用例的功能，例如连续查询、保留策略，以及优化的功能集，例如序列和压缩。

使用 InfluxDB 进行日志存储

InfluxDB 是一个时间序列数据库。您可以使用它来获取应用程序或服务器生成的所有信息，并将它们推送到此数据库。它是一个 Go 二进制文件，您可以下载它，它可以在 Windows 和 Mac 中运行，旨在非常容易安装和启动。InfluxDB 使用 InfluxQL 进行通信。这意味着您可以使用类似于您已经熟悉的 SQL 的东西来查询此数据库。您不需要学习另一种语言。以下是选择 InfluxDB 的原因的快速摘要。

  • 易于上手
  • 熟悉的查询语法
  • 没有外部依赖项
  • 开源
  • 水平可扩展
  • 有凝聚力的时间序列平台成员

InfluxDB 拥有庞大的用户群和庞大的社区。与下面讨论的其他 InfluxData 平台组件结合使用，它可以创建一个全栈监控系统。InfluxDB 支持不规则时间序列（事件以不规则的时间间隔发生）和规则时间序列（指标以规则的时间间隔发生），如下所示。

在 InfluxData，我们有一组基准测试来展示为什么您需要选择合适的时间序列数据库，而不是简单地选择您最喜欢的数据库类型。InfluxDB 与同类数据库之间的写入性能差异非常大。基准测试通常带有某种主观性，但我们尝试通过独立测试使它们尽可能客观。请参阅我们的基准测试，将 InfluxDB 与 Elasticsearch、MongoDB、Cassandra 和 OpenTSDB 进行比较。

快速搭建现代监控系统

InfluxData 拥有一整套开源项目，您可以使用它们——Telegraf、InfluxDB、Chronograf 和 Kapacitor。这些统称为 TICK Stack。

<figcaption> 构建监控或事件系统的完整堆栈</figcaption>

  1. Telegraf 是一个指标收集代理。它也是一个 Go 二进制文件，您可以下载并启动它。它非常容易。您可以在每台服务器上安装一个 Telegraf，并将其配置为从每台服务器获取信息。Telegraf 是基于插件的，具有输入和输出插件。如果您已经部署了监控系统，并且正在寻找一个强大的收集器，则可以使用 Telegraf。
  2. InfluxDB 是我们的存储引擎。来自 Telegraf 的所有指标都发送到 InfluxDB。
  3. Chronograf 是一个用于管理和查看所有数据的仪表板。从 Chronograf，您还可以管理 InfluxDB 和 Kapacitor。如果您选择不使用 Chronograf，还有其他项目实现了 InfluxDB 输出，包括 Grafana。
  4. Kapacitor，TICK Stack 的原生数据处理引擎，可以配置为侦听指标并对正在发生的事情采取积极主动的措施。它可以处理来自 InfluxDB 的流数据和批量数据。您可以将 Kapacitor 警报发送到兼容的事件管理集成。例如，Kapacitor 可以向 PagerDuty 发送消息，如果出现问题，您可能会在晚上接到电话，或者它可以在 Slack 上发送消息。

启动 InfluxDB 并开始使用整个 TICK Stack 非常简单。您只需运行一些二进制文件或运行一些 Docker 容器。您就拥有了一个可以使用的监控系统。但是，监控系统的真正目标是告诉您何时基础设施或应用程序宕机。如果您的监控系统与服务器一起宕机，则意味着它不起作用。因此，您需要信任您的监控系统。您需要将其与您的应用程序和基础设施远远隔开，以 100% 确保当您的应用程序和服务器宕机时它仍然存活。这不是一个简单的目标。您需要知道这一点，它不仅仅是一组 Docker-run 命令。

<figcaption> 管理监控系统并非易事</figcaption>