可观察性道路上的三个监测阶段

现在人们普遍认为，监控只是可观察性的一个子集。监控显示你的IT基础设施和应用出了问题，而可观察性则帮助你了解原因，通常是通过分析日志、指标和跟踪。在今天的环境中，需要各种数据流来确定性能问题的 "根本原因"，可观察性的圣杯，包括可用性数据、性能指标、自定义指标、事件、日志/跟踪和事件。可观察性框架是由这些数据源构建的，它允许运营团队自信地浏览这些数据。

可观察性还可以确定在有或没有人工干预的情况下，采取什么样的规定性行动，以应对甚至防止关键的业务中断场景。要达到可观察性的高级水平，需要监控从反应性到主动性(或预测性)的演变，最后是规范性监控。让我们讨论一下这种演变包括什么。

不是一件简单的事情

首先，看一下联合IT运营的现状，就会发现其中的挑战。基础设施和应用程序分散在暂存、预生产和生产环境中，在企业内部和云中，IT运营团队不断参与，以确保这些环境始终可用，满足业务需求。运营团队必须处理多种工具、团队和流程。对于实施可观察性平台需要多少数据流，以及如何使企业内的业务和IT运营团队遵循一个框架，在一段时间内改善运营优化，人们常常感到困惑。

为了使监控工作成熟起来，超越指标仪表板，进入这种可观察的态势，它通常分三个阶段发展。反应性、主动性(预测性)和规定性。让我们来看看这些是什么。

第一阶段：反应性监测。

这些是监测平台、工具或框架，它们设置性能基线或规范，然后检测这些阈值是否被突破并发出相应的警报。它们有助于确定所需的优化配置，以防止达到性能阈值。随着时间的推移，随着更多的混合基础设施被调用或部署以支持越来越多的业务服务和扩大的企业范围，预先定义的基线可能会发生变化。这可能导致糟糕的性能变得正常化，不触发警报，导致系统完全崩溃。然后，企业期待主动和预测性监测，以提前提醒他们可能表明即将发生事件的性能异常。

第二阶段：主动/预测性监控。

尽管这两个词听起来不同，但预测性监测可以被认为是主动监测的一个子集。主动监测使企业能够查看来自环境的信号，这些信号可能是或可能不是业务服务中断的原因。这使企业能够准备补救方案或标准操作程序(SOP)，以克服零优先级事件。实施主动监控的常见方法之一是为 "管理者的管理者 "提供一个统一的用户界面，运营团队可以访问来自多个监控域的所有警报，以了解其系统的 "正常 "行为和 "性能瓶颈 "行为。当某种行为模式与现有的机器学习模式相匹配，表明存在潜在问题时，监控系统就会触发警报。

预测性监测对市场上较新的技术使用动态阈值，而没有对它们应该如何执行的第一手经验。然后，这些工具了解一段时间内的指标行为，并在注意到标准偏差时发出警报，这可能导致最终用户会注意到的中断或性能下降。可以根据这些警报采取相应的行动，防止发生影响业务的事件。

第三阶段：规范性监测。

这是可观察性框架的最后阶段，监测系统可以从环境中的事件和补救/自动化包中学习，并了解以下情况。

• 哪些警报是最经常发生的，以及针对这些警报从自动化包中执行哪些补救行动?
• 某些被触发的资源是否属于同一个数据中心，或者是在多个数据中心看到的相同问题，这可能导致理解错误的配置基线。
• 如果一个警报是季节性的，可以在以后的阶段忽略，而不执行不必要的自动化。
• 对作为纵向或横向扩展的一部分而引入的新资源执行哪些补救措施。
• IT运营团队需要适当的算法来关联和制定这些方案。这可以是ITOM和ITSM系统对IT运营分析引擎的反馈的组合，以建立规范的模型。

展望未来

监控不是可观察性，而是它的一个关键部分，从反应式监控开始，当预先定义的性能阈值被突破时，它会告诉你。随着你将更多的基础设施和应用服务上线，监控需要转向主动和预测模型，这些模型分析更大的监控数据集，并在服务水平和用户体验受到影响之前检测可能表明潜在问题的异常情况。

然后，可观察性框架需要分析一系列的数据点，以便在检测到异常的最初几分钟内确定性能问题或中断场景的最可能的原因，然后在进入作战室/情况分析电话之前开始努力补救该性能问题。最终的结果是更好的用户体验，一个永远可用的系统，以及改善业务运营。