devops 开源工具链_DevOps监控工具的开源指南

devops 开源工具链

在这个新系列中，我们将重点介绍DevOps监视和可观察性工具。 在接下来的几周中，我们将探讨指标聚合和监视，日志聚合，警报和可视化以及分布式跟踪。 或者，您现在可以将整个开源指南下载到DevOps监视工具 。

让我们开始吧。

两种观点的故事

曾几何时，我正在对应用程序中一些棘手的问题进行故障排除，这些问题需要扩展几个数量级，而仅需几个星期即可对其进行重新架构。 我们没有日志聚合，没有度量标准聚合，没有分布式跟踪，也没有可视化。 我们的大部分工作必须使用strace和grepping日志之类的工具在实际的生产节点上完成。 这些都是很棒的工具，但是它们使分析跨数十个主机的分布式系统变得不容易。 我们完成了工作，但是这很痛苦，涉及的猜测和风险比我所希望的要多得多。

在另一项工作中，我帮助解决了生产中遇到内存不足（OOM）问题的应用程序。 该问题不一致，因为它似乎与运行时间，负载，一天中的时间或任何其他可提供一定可预测性的方面没有关联。 在跨越数百个主机且有许多应用程序调用它的系统上，这显然将是很难诊断的问题。 幸运的是，我们进行了日志聚合，分布式跟踪，指标聚合以及大量可视化。 我们查看了内存图，发现内存使用率出现明显的峰值，因此我们使用该峰值来提醒我们，以便我们可以在发生问题时实时诊断问题。

收到警报后，我们进入了日志聚合系统，将日志与内存峰值关联起来。 我们发现了OOM错误及其相关的调用。 然后，我们了解了导致该峰值的应用程序正在调用该服务，并使用该信息来查找导致该问题的确切事务。 我们确定有人在我们的服务试图加载的数据库中存储了一个巨大的文件，但是该服务在完全加载和处理记录之前就耗尽了内存。 我们本来应该对此进行防御，但是我们很高兴能如此快地找到它，并且只需很少的努力就可以解决它。 理解了错误之后，我们发现很多记录都具有类似这样的大文件，并且我们不需要记录的那部分来正常运行。

您可能会认为第二种情况比第一种情况发生了很长时间，并且随着时间的推移我们已经有所改善。 也许您怀疑当我换工作时，我的新公司拥有更好的工具。 实际上，第二种情况发生在第一种情况之前。 我从一家拥有相当先进的可观察性工具的公司发展为一家没有可观察性工具的公司。 开发人员在生产中拥有应用程序却一无所知，这实在令人不安。 当我开始重建该基础架构时，我了解了很多有关系统可观察性和相关工具的重要性。 另外，迈克·朱利安（Mike Julian）的《 实用监视》对于那些想进一步了解其系统的人来说是必读的。

可观察性原则

那么，什么是可观察性工具？ 其实，可观察性是什么？

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

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

可观察性工具类型

在本系列中，我们将深入探讨不同类型的可观察性工具。 对于每种类型，我们将介绍它们的用途，可用的特定工具，一些用例以及在搜索新工具期间可能出现的任何独特特征。 这些内容以应实施它们的顺序显示。 首先是指标聚合，因为使用任何现代语言构建的应用程序通常都很容易检测。 其次是日志记录，因为它将需要更多的应用程序修改，但具有巨大的价值。 第三是警报和可视化，这需要前两种类型才能发挥全部功能。 最后是分布式跟踪，因为它在简单的整体中可能不是必需的，并且很难完全实现。

指标汇总

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

日志汇总

这些工具处理的数据类型更多地与事件相关，而不是与一系列一致的数据点相关。 当系统进入一些不希望的状态时，通常会发出此输出。 一些系统输出很多不符合此条件的日志。 在以后的文章中，我们将介绍更多有关日志记录的注意事项。

警报/可视化

这似乎不适合所列出的其他类型，因为它确实排在其他类型之后，但是它为其他类型提供了消耗品输出，并且可以产生自己的输出。 这些类型的工具通常会使系统对人类更易理解。 它们还通过有关否定系统状态的主动通知和被动通知来帮助创建一个更具交互性的系统。

分布式跟踪

就像在单个应用程序中进行跟踪一样，分布式跟踪使您可以在整个系统中跟踪单个事务。 这样，您就可以处理可能遇到问题的特定事务。 由于性能问题，通常采用采样算法。

DevOps的常见功能

在任何类型的可观察性工具中，您都应该寻找几个方面。 我们现在将全面介绍这些内容，并将在以后的文章中重新介绍它们。

OpenAPI的

该规范以前称为Swagger，但在Linux基金会内部的OpenAPI Initiative采纳后重新命名。 OpenAPI规范是与语言无关的工具，可以自动生成方法，参数和模型的文档。 这通常用于在HTTP中生成RESTful接口，但也与协议无关。 如果尚不存在，则用户可以使用几乎任何一种语言创建客户端。 每个工具都应具有此类API（或应尽快获得）。 如果您的工具尚无此工具，则可能需要在其他地方查找。 尚未实施此规范或未在其路线图上使用的工具可能在采用开放的现代标准和代码方面存在其他缺陷。

开源的

这个领域有很多好的工具，这些工具不是开源的，但可能适合您的公司。 如果选择其中一种工具，请确保其文档和附件工具是开源的。 开源可观察性工具可以为您其他可观察性工具的运行方式（或可能无法运行）提供有价值的见解。 它们还提供了任何开源项目的所有其他优点，您可以在Opensource.com上了解更多信息。

开放标准

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

广泛传播

可观察性和开放性的一部分是允许所有人查看数据。 默认情况下，您选择的工具应处于打开状态。 您可能需要限制某些区域，但是只有在绝对必要时，您才需要默认打开和关闭访问权限。 您永远不会知道公司中的谁可能想解决您的问题，或者您需要谁来帮助解决问题。 您需要做的最后一件事是对收入来源进行故障排除时的访问障碍。

联合模型（首选）

这类似于默认打开，但它允许每个人提供输入并在本地控制自己的区域。 许多遗留系统的架构均要求所有数据无论需要都流经中央系统。 这也集中了对该数据的控制。 联邦系统允许本地聚合，处理和控制，同时允许中央组织收集相同的数据或汇总的数据。 中央系统可能只需要存储在本地级别的数据子集。 该模型提高了敏捷性，灵活性和可用性。

在本系列中，我们将更详细地探讨每种可观察性工具类型。 我们还将帮助您为用例选择正确的工具。 可以按任意顺序随意阅读它们，也可以下载整个指南 。

接下来要读什么

翻译自: https://opensource.com/article/18/8/now-available-open-source-guide-devops-monitoring-tools

devops 开源工具链