DevOps 监控工具开源指南

在这个新系列中，我们将专注于 DevOps 监控和可观测性工具。 在接下来的几周里，我们将探讨指标聚合和监控、日志聚合、警报和可视化以及分布式追踪。 或者，您可以立即下载完整的 DevOps 监控工具开源指南。

让我们开始吧。

两种不同的视角

曾经，我在一个应用程序中排除了一些令人烦恼的问题，该应用程序需要扩展几个数量级，而且只有几周的时间来重新设计它。 我们没有日志聚合、没有指标聚合、没有分布式追踪，也没有可视化。 我们的大部分工作都必须在实际的生产节点上使用诸如 strace 和 grepping 日志之类的工具来完成。 这些都是很棒的工具，但它们不能轻松地分析跨越数十台主机的分布式系统。 我们完成了这项工作，但它很痛苦，并且涉及比我喜欢的更多的猜测和风险。

在另一份工作中，我帮助排除了生产中一个应用程序的故障，该应用程序遭受了内存不足 (OOM) 问题。 这个问题是不一致的，因为它似乎与运行时间、负载、一天中的时间或任何其他可以提供一些可预测性的方面无关。 显然，要在跨越数百台主机且有许多应用程序调用的系统上诊断这个问题是很困难的。 幸运的是，我们有日志聚合、分布式追踪、指标聚合和大量的可视化。 我们查看了我们的内存图，发现内存使用量明显激增，因此我们使用该激增来提醒我们，以便我们在实时发生时诊断问题。

当我们收到警报时，我们进入我们的日志聚合系统，将日志与内存激增相关联。 我们找到了 OOM 错误以及围绕它的相关调用。 然后我们了解到哪个应用程序正在调用导致激增的服务，并使用该信息找到导致问题的确切事务。 我们确定有人在我们的服务尝试加载的数据库中存储了一个巨大的文件，但是该服务在完全加载和处理记录之前耗尽了内存。 我们一开始就应该防止这种情况，但我们很高兴能如此迅速地找到并修复它，而无需花费太多精力。 一旦我们理解了错误，我们发现很多记录都有这样的大文件，而且我们不需要记录的这部分也能正常运行。

您可能认为第二种情况发生在第一种情况之后很久，并且我们随着时间的推移有所改进。 或者您可能怀疑，当我换工作时，我的新公司拥有更好的工具。 实际上，第二种情况发生在第一种情况之前。 我从一家拥有相当先进的可观测性工具的公司搬到了一家没有可观测性工具的公司。 作为开发人员，在生产中拥有一个应用程序却对此一无所知，这令人感到非常不安。 当我开始重建该基础设施时，我了解了很多关于系统可观测性的重要性以及相关工具。 此外，Mike Julian 的 实用监控 对于那些想更多地了解他们的系统的人来说是必读之书。

可观测性原则

那么，什么是可观测性工具？ 实际上，什么是可观测性？

可观测性不仅仅是一个营销术语； 它是 控制理论 的一个组成部分。 如果您想要快速入门，此 视频 可能会有所帮助。 基本上，可观测性意味着您可以根据输出来估计系统的特定状态。 更一般地，系统的状态应该由其输出确定。 可控性是可观测性的 数学对偶，系统要求系统的状态由系统的输入确定。

这是一个相当简单的概念，但将其付诸实践非常具有挑战性。 在足够复杂的系统中，可能几乎不可能实现完全的可观测性。 但是，您应该努力获得正确的输出，以便您能够确定系统的状态，尤其是在您遇到故障模式时。

可观测性工具类型

在本系列中，我们将深入研究不同类型的可观测性工具。 对于每种类型，我们将介绍它们的用途、有哪些具体的工具可用、一些用例，以及在您搜索新工具时可能出现的任何独特特征。 这些呈现的顺序应该是您实施它们的顺序。 指标聚合是第一位的，因为它通常很容易使用任何现代语言构建的应用程序进行检测。 其次是日志记录，因为它需要更多的应用程序修改，但提供了巨大的价值。 第三是警报和可视化，它们需要前两种类型才能实现完整的功能。 最后是分布式追踪，因为它在简单的单体架构中可能不是必需的，而且更难完全实现。

指标聚合

这种类型的工具通常由时间序列数据组成。 时间序列数据是按时间排序的数据，通常以内部一致的间隔收集。 这种一致性允许对序列应用一些高级计算，并提供使用简单回归或更高级算法的预测分析。

日志聚合

这些工具处理的数据类型与事件的关系比与一系列一致的数据点的关系更密切。 这种输出通常在系统进入某些不需要的状态时发出。 有些系统输出大量不符合此条件的日志。 我们将在以后的文章中介绍更多关于日志记录的注意事项。

警报/可视化

这可能看起来与其他列出的类型不太符合，因为它实际上是其他类型的后续，但它为其他类型提供了可消费的输出，并且可以产生自己的输出。 这些类型的工具通常使系统更容易被人理解。 它们还有助于通过对负面系统状态的主动和被动通知来创建更具交互性的系统。

分布式追踪

与单个应用程序中的追踪非常相似，分布式追踪允许您跟踪单个事务通过整个系统。 这使您可以专注于可能遇到问题的特定事务。 由于性能问题，通常会应用采样算法。

常见的 DevOps 功能

在任何类型的可观测性工具中，您都应该注意几个方面。 我们现在将大致介绍这些内容，并在以后的文章中重新提出它们。

OpenAPI

该规范以前称为 Swagger，但在被 OpenAPI Initiative 在 Linux Foundation 中采用时被重命名。 OpenAPI 规范是一种与语言无关的工具，可以自动生成方法、参数和模型的文档。 这通常用于在 HTTP 中生成 RESTful 接口，但它也是与协议无关的。 如果客户端尚不存在，用户可以用几乎任何语言创建客户端。 每个工具都应该具有这种类型的 API（或者应该很快获得它）。 如果您的工具还没有，您可能需要去别处看看。 尚未实施此规范或未将其列入路线图的工具可能在采用开放、现代的标准和代码方面存在其他缺陷。

开源

在此领域中有很多不错的工具不是开源的，但可能适合您的公司。 如果您选择其中一种工具，请确保其文档和配套工具是开源的。 开源可观测性工具可以提供有价值的见解，了解您的其他可观测性工具如何运行（或者可能无法运行）。 它们还提供任何开源项目的所有其他好处，您可以在 Opensource.com 上阅读更多相关信息。

开放标准

无论工具是否开源，都应尽可能使用开放标准。 我们已经讨论了其中一种，即 OpenAPI，但还有更多。 我们将在适当的章节中讨论这些标准，以确保您知道它们的存在以及它们的使用位置。

广泛传播

可观测性和开放性的一部分是允许每个人查看数据。 您选择的工具应该默认是开放的。 您可能想要限制某些区域，但您希望默认为开放，并且只有在绝对必要时才关闭访问权限。 您永远不知道您公司中的谁可能想要解决您的问题，或者您需要引入谁来帮助解决问题。 您最不希望的就是在排除您的收入来源故障时遇到访问障碍。

联合模型（首选）

这类似于默认设置为开放，但它允许每个人提供输入并在本地更多地控制自己的区域。 许多遗留系统以这样一种方式架构，即需要所有数据流经一个中央系统，而不管需求如何。 这也使围绕该数据的控制集中化。 联合系统允许本地聚合、处理和控制，同时允许中央组织收集相同的数据或汇总的数据。 中央系统可能只想存储本地存储的数据的子集。 这种模式提高了敏捷性、灵活性和可用性。

在本系列中，我们将更详细地探讨每种可观测性工具类型。 我们还将帮助您为您的用例选择合适的工具。 随意按照您想要的任何顺序阅读它们 - 或者您可以 下载整个指南。