可观察性会让你陷入循环吗？

们管理和维护应用程序和环境的健康和功能的新准则是可观察性。可观察性是软件、服务、平台或产品的质量，它使我们能够了解系统的行为方式。如果没有新的数据源为我们提供洞察力，我们的现代云原生应用程序将很难监控。可观察性，即深度数据，是我们的开发人员和 DevOps 工程师的新动力。可观察性的二重性是可控性。可观察性是从外部暴露的信号推断“机器”内部状态的能力。可控性是控制输入以将内部状态引导至所需结果的能力。在驾驶时，观察红色红灯意味着通过按下刹车来控制我们的车辆（或者在一些现代车辆中，为我们自动应用刹车）。
我们经常发现可观察性被呈现为所需的最终状态。然而，在现代计算环境中，事实并非如此。毕竟，有多少次应用程序停止工作（或提供不正确的结果）而回应是耸耸肩走开？我们需要从线性模型移动到循环模型，从 ‘看到一些东西。说些什么。’ 到 '看到的东西。做点什么。所以，可观察性是一个循环。我们需要停止将其视为向用户和客户提供高性能、高质量体验的挑战的最终状态。对技术感兴趣朋友可以加这个扣扣2779571288交流。

观察和控制

可观察性是软件、服务、平台或产品的质量，它使我们能够了解系统的行为方式。它超越了传统数据，帮助我们寻找我们已经期望发生的事情，为我们没有意识到可能发生的事情提供数据。它是了解我们的应用程序和系统运行状态的窗口。可观察性是一个数据问题。数据仅与聚合、分析、可视化和响应数据的能力一样有用。这允许可观察性扩展我们的监控范式，利用 AI/ML 扩展我们的分析和可视化。

伴随可观察性而来的是警报。毕竟，当出现问题时，我们需要能够尽快意识到并做出反应。事实上，这种警报功能实际上可以区分监控和可观察性——检测和警报我们知道可能出错的地方（监控）与检测我们没有预见到的错误（可观察性）。我们可以认为可观察性让我们看到活动（监控）并通过向我们显示系统中已知和未知的活动来减少检测的时间。

在某些方面，可观察性可以在 Chuck Norris 级别进行监控，即使我们没有预料到最初的动作，警报也会导致响应。可控性就是这种反应。在粗略的层面上，可控性包括两个部分。一个经常被遗忘或混为一个概念。但实际上有两个要点，平均响应时间和平均解决时间。您的直接反应是让事情重新工作，这可能有与解决路径不同的路径，即确定根本原因并解决它们以允许持续开发和持续性能改进。所以让我们看一个相当简单的例子。

猫和金丝雀

您经营一个社交平台，允许人们上传他们的猫午睡的照片：CatNapFriends。该应用程序具有许多微服务，并且您已经开始为图像处理引入无服务器元素。该应用程序运行良好，符合规模并且响应迅速，让用户感到高兴。

您发现您的函数在较低的流量下执行速度有点慢，因此您稍微更改函数以使其更快。您的测试表明它在您的测试中运行速度提高了 50%，因此您已准备好进行部署。作为一个聪明、安全和理智的人，你会采用金丝雀模型。当它向外扩展时出现问题，您的无服务器函数开始将持续时间缩短到几秒钟或返回错误。您的用户不再那么高兴了。您的 Twitter 提要炸了，而您的 Facebook 则是您不愿看到的内容。对技术感兴趣朋友可以加这个扣扣2779571288交流。

那么问题来了：

您发现问题的速度有多快？
你让别人知道的速度有多快？
您恢复到高性能系统的速度有多快？
你是如何找出根本原因的？
这些问题中的每一个都可以有多个答案，但有些答案可能更适合您的业务，老实说，您的理智。

从监控开始

我们怎么知道出了什么问题？好吧，如果你看不到它，它就从来没有发生过。当然，直到您接到 CIO 打来的电话，询问为什么国家新闻会询问您的网站为何关闭。从Twitter 上的用户那里了解问题可能会限制职业生涯。

所以我们从监控开始。虽然监控有时会被归为看到我们已经知道的事物的类别，但在可观察性方面的监控也可以标记我们还不知道的事物… 有时，您会听到可观察性是回答未知未知数的能力，同时专注于根本原因分析。可观测性的恒星使用意味着在我们进入解决阶段之前很久就检测到未知数。

粒度和保真度在您的监控和检测中发挥着重要作用。因此，让我们想象一下无服务器场景是正在进行的问题。您每 5 秒抓取一个数据点。没问题。但是等等，无服务器冷启动在 200-700 毫秒之间；热启动是 8-50 毫秒。你只是错过了。在 5 秒的窗口中，您可能会错过很多无服务器启动。你刚刚又错过了。当我们进行分布式跟踪时，情况可能会更糟。您需要查看轨迹上的每一点、每一点数据。它在此监视和检测阶段很有用，但在解决阶段将变得越来越重要。现在我们有了数据，我们需要进入循环中的下一个阶段，检测。

检测和警报

检测显然是意识到出了问题（或带外）。在传统监控中，它最常关注静态阈值。但是还有很多其他选择，例如心跳检查、资源耗尽、异常值检测、突然更改、历史异常和自定义阈值。

如您所知，该列表涵盖了我们已经知道的两件事（静态、心跳），但也开始接近未知数（异常值、突然变化）。随着我们进入 AI/ML 类别，我们开始看到更多可观察到的事件导致未知检测器（已经由历史异常表示）。真正的价值在于能够定义自定义检测器；请记住，在我们的可观察性世界中，我们（尚）不知道这些问题，因此当我们确实学习了一个新问题时，我们应该能够对其进行跟踪。

检测导致警报。检测和警报将我们带到第一个开环/闭环分叉处。开环是将人作为触发元素的环。在检测中，开环是指操作员（或系统）在监控仪表板上发现问题（例如指标超出范围）并提醒负责人（例如）。闭环将是仪表板突出显示更改/触发（如闪烁的红色）和/或启动自动警报。闭环响应是其中自动化元素是对触发元素的响应。可能会发生多种组合，但通过可观察性，您想弄清楚如何最好地尽可能长时间地保持闭环过程。您仍然需要在某些地方使用开环，但特别是在检测和警报方面，

闭环可控

很高兴知道某事已经发生或即将发生。然而，如果你不能采取行动，那么虽然崩溃可能令人兴奋，但它不会便宜。行动可以意味着很多事情，但通常分为两个步骤。

响应是控制（和恢复）的第一步。您可能需要从分类的角度考虑这一点：它可以在没有立即关注的情况下存活，无论如何它会死，或者它是否会在立即关注下存活。对我们来说幸运的是，应用程序“死亡”是可以复活的。

所以这样想吧。“我的服务运行速度比正常或预期慢，但工作仍在进行。让我找出问题所在，然后修复它。或者，您最终可能会得到“我的服务已死或无法正常工作，让我回到稳定状态，然后找到并修复它”。该响应非常适合自动化技术。根据警报和周围事件的性质，很可能会启动自动响应（通过运行手册或触发不同的操作脚本）。

在上面的示例 CatNapFriends 中，我们推送了该功能的新版本。我们的监控发现了一个有害的变化，我们发出了警报。现在，假设这些警报之一也连接到触发器/脚本，该触发器/脚本立即将我们的更新回滚到最后一个已知的良好发行版。它还会提醒我们的相关人员检查问题并开始调查根本原因。在每种情况下，都应发送适当的警报，将问题、响应通知正确的群体，并且基本上让人们了解情况。

这引导我们解决问题

关闭循环——并保持开放
分辨率几乎总是一个开环。当我们需要继续修复它时，我们将深入研究代码、基础设施和/或配置。这不仅会深入了解需要解决的直接问题，还会深入了解可能影响该解决方案或受该解决方案影响的其他项目。对于 CatNapFriends 及其突然的缓慢行为，可能是编码错误无法返回图像处理的完成。可能是您的无服务器配置设置为最小内存并且图像淹没了容器。可能是您与新服务和其他元素发生了无法预料的交互。幸运的是，可观察性考虑了这种可见性需求，并将其与数据联系起来。

这些是可观察性的三个主要数据类别：指标、跟踪、日志。

可观察性的数据类：指标、跟踪和日志

它继续讨论可控性概念：响应、解决、重新部署。

可控性概念：响应、解决、重新部署

我们需要可观察性来关闭循环，我们需要工具和技术来使我们能够在规模上以速度和精度做到这一点。这是一个循环，通过每个阶段并返回到下一个阶段。我们努力确保我们经常处于监控方面，但需要注意所有其他步骤都可以随时使用。

因此，虽然可观察性从控制理论中获取线索，但实用方法从计算机过程控制和 SCADA（监督控制和数据采集）实现中获取。系统的可见性很好，但不足以通过这种可见性管理当今日益复杂的容器和 Kubernetes、微服务和无服务器功能。然而，随着强大的可观察性，需要很好的控制，无论是开环还是闭环。对技术感兴趣朋友可以加这个扣扣2779571288交流。