PDFDevOps 世界中的监控
完美不应成为追求更好的绊脚石。
Theo Schlossnagle，Circonus
本文的标题可能暗示它是关于在正在转型或已经转型为 DevOps 的组织中，您应该如何监控系统。实际上，本文旨在让您思考计算技术发生了怎样的变化，以及您对监控的概念或许需要在应用于勇敢的 DevOps 新世界之前重新调整中心。
更令人警醒的事实是，这不仅是一个勇敢的新世界，也是一个快速的新世界。采用 DevOps 的主要驱动因素之一是速度——特别是以速度降低风险。组织必须做出许多改变来适应这一点。DevOps 社区经常谈论自动化和文化。这很有道理，因为自动化是速度的来源，并且每个问题都可以重新表述为人员（或沟通）问题；自动化和文化是关键。
话虽如此，监控行业的基础已经发生了转变。这种剧烈的变化导致现有工具发生改变，并且监控领域涌现出新的工具，但仅凭这些还不足以将我们带入低风险的 DevOps 世界——除非有新的和更新的思维方式。为什么？因为变化。
监控，其核心是观察和确定系统的行为，通常带有确定“正确性”的潜在动机。它的目的是回答始终存在的问题：我的系统是否在按预期运行？还值得一提的是，“系统”是一个非常通用的术语，在健康的组织中，系统的范围比仅仅是计算机和计算服务要广泛得多；它们包括销售、营销和财务，以及其他“业务部门”，因此企业被视为真正复杂的相互依赖的系统。也就是说，良好的监控可以帮助人们真正系统地看待不仅是系统，还有组织。
像陈年佳酿一样历久弥新的系统早已过时。今天的系统诞生于敏捷世界，并保持流动性，以适应供应商和消费者格局的变化。“适应或死亡”的合理回应是“我要做 DevOps！”这种高度动态的系统势必会挑战传统的监控范式。
旧世界
在发布周期“缓慢”（通常在 6 到 18 个月之间）的世界中，使软件可操作是一项有趣的挑战。在一个发布周期开始时部署的系统看起来很像几个月后的同一个系统。并不是说它停滞不前，而更像是它分支进入了仅维护的思维模式。伴随维护而来的是错误修复，甚至性能增强，但不是新功能、新系统组件、旧系统组件的移除以及从根本上改变架构压力的新特性或功能。简而言之，它不是很流畅。
对于监控而言，这种缺乏流动性是极好的。如果今天的系统就是明天的系统，并且该系统今天所做的练习与明天大致相同，那么围绕系统应该如何表现制定一套期望就变得非常自然。从更务实的角度来看，通过观察系统组件的行为而制定的基线很可能具有长期而有用的生命周期。
本文不会深入探讨不频繁地发布大量代码更改所涉及的风险，因为有无数的故事（轶事或其他）说明了它们的严重性和概率确定性。只需说：那条路上有恶龙。这是敏捷、看板和其他更具响应性的工作流程被广泛采用的众多原因之一。DevOps 是使转型成为可能的组织结构。
新世界
因此，我们都赞同快速和流畅的业务和开发流程，并且我们拥有持续的“一切”来让我们管理风险。世界是美好的，对吧？嗯，“持续监控”（在这种新的持续意义上）并不存在，而且，此外，这个名称会很愚蠢；难道不应该所有的监控都一直是持续的吗？
这里最大的问题是，为监控提供动力的基本原则，即判断您的机器是否表现良好的方法，需要了解良好行为是什么样的。无论您是构建统计基线、使用形式模型，还是只是凭感觉，为了理解系统是否行为不端，您都需要知道它们表现良好时是什么样子的。
在这个新世界中，您不仅拥有可以持续引入更改的流畅开发流程，而且还采用了微服务系统架构模式。微服务只是规定，特定技术问题的解决方案应隔离为具有明确定义接口的网络可访问服务，以便该服务具有自由度。许多开发人员喜欢这种模式，因为他们在服务设计方面获得了更多的自主权，扩展到语言、数据库技术等的选择。这种自由非常强大，但其真正的价值在于解耦发布计划和维护，并允许围绕安全性、弹性合规性进行独立的更高层次的决策。
这看起来可能是一个奇怪的题外话，但这两个变化的结合导致了监控领域意想不到的事情：今天的系统既不像明天的系统，也不应该像明天的系统那样运行。
关于 ML 和 AI 的题外话
许多监控公司一直在努力跟上短暂架构的步伐。节点来来去去，架构从一分钟到下一分钟动态调整大小，以满足不断增长和缩小的需求。随着节点的启动和随后的消失，监控解决方案必须适应。虽然一些旧的监控系统难以应对这个概念，但大多数现代系统都能轻松应对这种类型的动态系统调整大小。
第二个，也是很大程度上尚未满足的挑战，不是架构规模的动态性，而是其设计的动态性。借助基于微服务的架构和多个敏捷团队不断发布软件和服务，现代架构的设计不断变化。
监控领域的一个热门话题是如何将 ML（机器学习）和 AI（人工智能）应用于手头的问题，但当前的方法似乎是在尝试解决昨天的问题，而不是明天的问题。AI 和 ML 提供了一套非常丰富的新技术来解决问题，并且无疑将在监控领域发挥重要作用，但它们必须解决的问题不是建模架构并学习指导其操作。它今天学习的架构到明天就会发生变化，任何指导都将过时。相反，为了产生重大影响，AI 和 ML 方法需要退后一步，帮助指导流程和设计。
成功监控的特征
如果不提供一些战术建议就对监控的现状投下悲观的阴影，那将是残酷的。幸运的是，很多人都非常出色地监控着他们的系统。以下是他们的共同点
什么比如何更重要
首先要记住的是，如果您关注的是错误的事情，那么世界上所有的工具都无法帮助您检测到不良行为。警惕那些为复杂的组装系统提供预定监控的工具；科技行业的系统很少在两个不同的组织中以相同的方式组装和使用。可能的情况是，监控看起来毫无用处，但在某些情况下，它可能会提供系统运行良好的虚假信心。
当谈到监控“正确的事情”时，始终从上到下审视您的业务。组织运营的技术系统仅仅是为了满足某些既定的业务目标而配置和运营的。首先监控该目标是否正在实现。一个半开玩笑的例子：始终监控工资系统，因为如果您没有拿到工资，那还有什么意义呢？
数学：这是必要的
其次，拥抱数学。在现代，功能是基本要求；系统工作是不够的，它必须运行良好。很少有一天您会有一个重要的监视器消耗布尔值“好”或“坏”。最常见的情况是，系统正在围绕交付的性能进行监控，因此消耗的值（或指标）是数字，通常是延迟（表示特定操作花费的时间）。您现在正在处理数字，所以无论您是否喜欢，都需要数学。基本的统计学是提出和解释有关系统行为问题的答案的基本要求。
随着系统的增长以及对系统行为的关注越来越多，数据量也会增加。在七年中，Circonus 经历了数据量几乎增加了七个数量级。有些人仍然通过每分钟左右从系统中获取一次测量值来监控系统，但越来越多的人实际上在观察他们的系统在做什么。这导致标准服务器上每秒产生数百万甚至数千万个测量值。人们倾向于不解决难题，除非答案有价值。当您可能有数千台服务器时，处理来自单台服务器的每秒 1000 万次测量值可能听起来像是过度杀伤，但人们正在这样做，因为存在使寻找答案的成本低于这些答案的价值的技术。人们这样做是因为他们能够运行更好、更快的系统并击败竞争对手。要处理如此大的数据量，您还必须使用一套强大的工具。要围绕如此大的数据量提出明智的问题，您必须拥抱数学。
您可以想象，如果没有一套工具来帮助您对观察到的数据执行快速、准确和适当的数学分析，您将处于相当不利的地位；幸运的是，从 Python 和 R 到帮助您从现代监控供应商处找到更全面解决方案的工具，有无数的选择。
数据保留
成功监控系统的第三个重要特征是数据保留。监控数据通常被认为是低价值和高成本的，并且经常被轻率地删除。时代已经改变，与所有计算事物一样，存储数据的成本已大幅下降。更重要的是，DevOps 改变了长期保留此数据的价值。DevOps 是一种学习文化。当事情出错时（而且总是会出错），至关重要的是要有一个健全的流程来询问系统和组织，以了解故障是如何发生的。这允许更改流程以降低未来的风险。没错，学习可以降低风险。
按照我们前进的步伐，不可否认的是，您的组织将对过去失败后立即错过的故障开发出明智的问题。这些新问题对于您组织的发展至关重要，但如果您可以及时回溯并询问有关过去事件的这些问题，它们将变得非常宝贵。这就是监控中的数据保留为您带来的好处。您在今年网络星期四购物流量之前的验尸分析中学到的新流程和询问方法现在可以应用于去年的网络星期四购物流量。这通常会导致引人入胜且有价值的学习，您猜对了，它可以降低未来的风险。
清楚地表达成功的样子
对于成功的监控系统，最后一条建议是具体说明成功的样子。使用一种语言来表达成功的样子可以让人们获得成功。认为自己做得很好并达到了期望，然后得知目标已经改变或者您无法表达自己为什么成功，这完全令人沮丧。SLI（服务级别指标）、SLO（服务级别目标）和 SLA（服务级别协议）的艺术在这里占据主导地位。几乎每个低级、临时的监视器和每个高级执行 KPI（关键绩效指标）都可以用“服务级别”来表达。了解您的业务提供的服务以及您旨在交付该服务的级别是监控的核心。
SLI 是您已确定为与服务交付直接相关的事物。SLO 是您为负责给定 SLI 的团队设定的目标。SLA 是具有后果的 SLO，通常是财务后果。虽然有点过于简化，但可以这样想：什么是重要的？它应该是什么样的？我应该承诺什么？为此，对直方图的良好理解会有所帮助。
从 RUM 到 RSM
Web 世界中的监控很久以前就从网站的缓慢、合成的 ping 转移到记录和分析与每个用户的每次交互；在世纪之交，Web 的合成监控让位于 RUM（真实用户监控），并且没有人回头。随着我们构建更多更小、解耦的服务，我们进入了负责为其他小型系统提供服务的领域——这些通常是工程 SLO 构建的基础。
API 请求或数据库交互或磁盘操作（甚至 syscall！）的平均延迟的日子正在消失。RSM（真实系统监控）即将到来，就像 RUM 一样，我们将记录和分析系统级交互——每一个交互。在过去的十年中，系统可观察性的提高（例如广泛采用的 DTrace 和 Linux 的 eBPF）以及时间序列数据库的改进（例如 Circonus 的 IRONdb 中的一流直方图存储）使得交付 RSM 成为可能。（要详细了解直方图数据存储的不同之处以及更重要的相关性，请参阅 Baron Schwartz 的评论，“为什么百分位数的工作方式与您想象的不同。”）
RSM 允许您全面地查看实际的系统行为，考虑到观察到的性能的整个分布，而不是始终错误地表示系统使用体验的合成诱导测量。
从合成 Web 监控到 RUM 的转变是巨大的；期待即将到来的向 RSM 的转变也同样如此。
不要拖延
今天，随着架构每分钟或每小时动态地变化大小，并且每天或每周变化设计，我们需要退后一步，记住监控是关于理解系统的行为，并且系统不一定仅限于计算机和软件。企业本身就是一个复杂的系统，包括销售、营销、工程、财务等解耦但相互连接的子系统。监控可以应用于所有这些系统，以衡量重要指标并检测整体系统行为的变化。
监控可能看起来非常令人难以承受。最重要的是要记住，完美永远不应成为更好的绊脚石。DevOps 使组织内部能够进行高度迭代的改进。如果您没有监控，请获取一些；获取任何东西。有总比没有好，如果您已经接受了 DevOps，那么您就已经注册了随着时间的推移使其变得更好。
Theo Schlossnagle 是一位软件工程师和连续创业者。他目前领导 Circonus，在那里他专注于构建分布式系统和规模，以帮助人们随着时间的推移分析其分布式系统的规模行为。
相关文章
黑盒调试
James A. Whittaker，Herbert H. Thompson
一切都与应用程序边界发生的事情有关。
https://queue.org.cn/detail.cfm?id=966807
工程师统计学
Heinrich Hartmann
将统计技术应用于运营数据
https://queue.org.cn/detail.cfm?id=2903468
时间，但更快
Theo Schlossnagle
一场关于透过镜子看时间的计算冒险
https://queue.org.cn/detail.cfm?id=3036398
版权所有 © 2017 归所有者/作者所有。出版权已许可给 。
最初发表于 Queue 第 15 卷，第 6 期—
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 你根本不懂应用程序性能
您无需在每次遇到性能或容量规划问题时都进行全面基准测试。一个简单的测量将提供系统的瓶颈点：这个示例程序在每 CPU 每秒 8 个请求后会明显变慢。这通常足以告诉您最重要的事情：您是否会失败。
Peter Ward, Paul Wankadia, Kavita Guliani - 在 Google 重新发明后端子集划分
后端子集划分对于降低成本非常有用，甚至对于在系统限制内运行可能是必要的。十多年来，Google 使用确定性子集划分作为其默认后端子集划分算法，但尽管此算法平衡了每个后端任务的连接数，但确定性子集划分具有高连接抖动级别。我们在 Google 的目标是设计一种连接抖动减少的算法，该算法可以替代确定性子集划分作为默认后端子集划分算法。
Noor Mubeen - 工作负载频率缩放定律 - 推导与验证
本文介绍了与每个 DVFS 子系统级别的工作负载利用率缩放相关的方程。建立了频率、利用率和比例因子（其自身随频率变化）之间的关系。这些方程的验证被证明是棘手的，因为工作负载固有的，利用率也在治理样本的粒度上以看似未指定的方式变化。因此，应用了一种称为直方图脊线追踪的新颖方法。在将 DVFS 视为构建块时，量化缩放影响至关重要。典型应用包括 DVFS 调控器和或影响系统利用率、功率和性能的其他层。
Ulan Degenbaev, Jochen Eisinger, Manfred Ernst, Ross McIlroy, Hannes Payer - 空闲时间垃圾回收调度
谷歌的 Chrome 浏览器致力于提供流畅的用户体验。动画将以 60 FPS（每秒帧数）更新屏幕，从而使 Chrome 大约有 16.6 毫秒的时间来执行更新。在这 16.6 毫秒内，必须处理所有输入事件，必须执行所有动画，最后必须渲染帧。错过的截止日期将导致丢帧。这些对用户是可见的，并且会降低用户体验。此处将此类零星的动画伪影称为卡顿。本文介绍了一种在 Chrome 使用的 JavaScript 引擎 V8 中实现的方法，用于在 Chrome 空闲时调度垃圾回收暂停。
© 保留所有权利。