如何使用开源 TICK 堆栈为您的应用程序和基础设施启动一个现代化的监控系统

作者：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是一个时间序列数据库。您可以使用它将您的应用程序或服务器生成的所有信息推送到此数据库。这是一个可以下载的二进制文件，它可以在Windows和Mac上运行，设计用于易于安装和启动。InfluxDB使用InfluxQL进行通信。这意味着您可以使用类似于您已经熟悉的SQL的东西来查询此数据库。您不需要学习另一种语言。以下是选择InfluxDB的快速总结。

  • 易于开始
  • 熟悉的查询语法
  • 无外部依赖
  • 开源
  • 水平可扩展
  • Time Series Platform的成员

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

在InfluxData，我们有一套基准测试来展示为什么您需要选择一个合适的时间序列数据库，而不仅仅是您喜欢的数据库类型。InfluxDB与类似数据库之间的写入性能差异相当大。基准测试通常是有点主观的，但我们将它们尽可能地客观化，通过独立测试。请参阅我们与Elasticsearch、MongoDB、Cassandra和OpenTSDB的基准测试。

启动现代监控系统

InfluxData有一套完整的开源项目集，您可以使用它们——Telegraf、InfluxDB、Chronograf和Kapacitor。这些共同被称为TICK堆栈。

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

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

启动 InfluxDB 并开始玩整个 TICK 堆栈非常简单。您只需运行一些二进制文件或运行一些 Docker 容器。您将拥有一个可以使用的监控系统。但监控系统的真正目标是告诉您当您的基础设施或应用程序出现问题时。如果您的监控系统与您的服务器一起关闭，这意味着它不起作用。因此，您需要信任您的监控系统。您需要将它与您的应用程序、基础设施保持足够的距离，以确保在您的应用程序和服务器关闭时，它仍然能够正常运行。这不是一个简单的目标。您需要了解这一点，而不仅仅是 Docker 运行命令的集合。

<figcaption> 管理监控系统并非人人适合 </figcaption>