你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

云监视和响应

项目
09/23/2023

本文是云监视指南系列教程的一部分。

响应是基于数据驱动的监视决策定义一个或多个操作的结果，这些决策支持服务使用者：

使其可操作：使用经过优化的监视配置来创建可操作的信号。
持续监视：在整个事件中应用监视和故障排除活动，以进一步帮助诊断问题。
自动执行：根据识别的信号配置自动调查、诊断、解决、恢复和修正。

意义原则在此处适用。这有助于处理流程或策略，以便优化和优化警报、通知和报表摘要的操作。云监视不仅仅是通知人类错误。它还要向系统和服务提供信号以做出反应。

监视在各种方案中起着关键作用：

启用动态服务行为：动态控制系统和服务根据监视数据做出响应，并自动消除事件。
持续评估信号：不断通知并提供动态进程、合规性、自动缩放和可视化效果的遥测数据。
组织操作：帮助 IT 组织处理和管理更改。

警报

自动化取代了现代云环境中更昂贵的服务管理流程，消除了更多事件。警报在意识中起着关键作用，但必须可操作，以避免警报疲劳或噪音。

定义警报有助于主动确保服务和系统保持正常运行、响应迅速、可靠且安全。保证性能、维护服务级别目标（SLO）、可用性和隐私需要适当的警报策略。不断升级的警报对可观测性并不重要，今天不应将其视为第一道防线。相反，自动化应该在这里扮演关键角色。

传统上，监视意味着引发一个警报，即有人可以采取行动，这意味着一个完全反应的过程。遵循新式服务管理或云操作做法，必须修改此方法。此方法紧随传统的 ITIL 事件管理路径，这与通过敏捷性、最低成本和优化实现云效率的目标不匹配。

一种新式方法可能具有检测到的条件，这些条件信息量更大且自动化，例如：

检测到的条件	原始操作	新式操作
性能指标 - 高内存使用率。安全威胁 - 检测到可疑网络活动。可用性故障 - Azure blob 存储请求失败。	警报和通知，webhook，推送通知，playbook，自动缩放	查询日志以识别有问题的组件，并触发自动化以纠正有问题的组件的问题。

下面是 Azure 中警报和自动化功能的相关资源列表：

新式云监视

与过去提供的监视平台和相关工具相比，云计算提供：

设计响应选项的更大灵活性。
开发和启用自动响应的更简单方式。
云协议或 API 方法可以更轻松地与工作管理系统（包括 DevOps）集成。

对于自动化操作范围，请考虑以下模式，无论是调查、扩充、路由、分配、修正、恢复还是解决方法：

业务流程方法	说明
全自动	操作自动执行。完全自动化应被证明是可靠、高效且持久的，使其有用性不短且安全。完全自动化可解放你的资源，使其能够更侧重于策略计划。
半自动化	任何修正操作都需要审批。
手动	操作员从特选库中选择自动化示例或 playbook。

警报取决于基于安全事件、性能指标、可用性信息和日志的检测数据。数据驱动操作通过聚合和处理不同的收集的数据类型来确定影响以及要采取的响应性操作，从而分析每个受监视资源的整体、端到端视角。

使用这些资源展开阅读，详细了解基于指标警报和安全事件的自动化：

开始使用 Azure Monitor 在 Azure 中自动缩放。

成本效益

与其他可观测性规则一样，团队需要了解并实现成本影响，以及为支持新式事件管理定义的响应类型如何帮助控制成本。尽管总体目标是通过快速响应和解决问题来减少平均恢复时间（MTTR），但必须不断评估对 IT 或业务收入流的潜在成本和影响。

每个报告的事件都有成本。假设组织投资业务流程来自动执行响应。在这种情况下，应通过增加云服务的消耗来利用那些启用自动化的服务或功能来评估成本的成本效益和影响。

自动化

云自动化在安全和运行状况监视方面具有巨大优势。速度、灵活性和精准率是云自动化为响应操作带来的三个原型。这通常称为业务流程，Microsoft 云提供多个服务。

例如：

从一个或多个日志中检测到标识驱动的威胁，并引发警报。
将立即触发自动化以收集更多信息并关联更多日志以扩充警报。
操作员通过从库中选择正确的自动化（例如禁用用户帐户）来采取措施。

示例或用例可以完全自动化。

自动化的角色然后提供一种可降低成本并节省时间的 playbook：

无需执行长时间的调查、诊断、解决和恢复的安全事件。
“检测到修正”周期可能以秒或分钟为单位，而不是小时。

接下来，你的团队需要构建一个列表或自动化示例库，这些示例可以灵活使用-无论是从公共网站上的原材料，还是内部策展并存储在源代码管理存储库中。

下面是基于标识或安全事件进行更多自动化的建议读取列表：

成功的警报策略

无法修复未知的损坏问题。

对重要事项发出警报。它以收集和测量正确的指标和日志为基础。你还需要一个能够在满足条件时存储、聚合、可视化、分析和启动自动响应的监视工具。仅当完全了解服务和应用程序的构成时，才能提高服务和应用程序的可观测性。将该组成映射到要由监视平台应用的详细监视配置。此配置包括可预测且值得发出警报的故障状态（症状，而不是故障原因）。

信息性警报

在某些情况下，某些警报可能是 信息性的。我们可以使用它来了解系统的行为方式。例如，你可能想要获取以下信息警报：

VM 已关闭：VM 自动关闭，以 根据检测到的计划或低利用率来最大程度地减少浪费和控制成本 。

在此示例中，业务流程基于本机计划功能以及检测利用率条件的监视平台使用。它会通知你执行的操作和原因，而不是将警报通知或上报作为唯一操作。
空闲资源：IaaS 或 PaaS 资源在较长时间内处于空闲状态，或者未根据 Azure 顾问建议进行预配。

在此示例中，业务流程可用于根据业务逻辑或 ITSM 流程工作流管理这些与基础结构相关的活动。现在需要更快的响应和操作。使用云时，警报对于人类来说比作为自动化价值流的一部分的自动响应或正在进行的业务流程要少。

警报策略注意事项

请记住，学习是关键，设计正确时，信息性警报可以让你深入了解云生态系统和运行状况。

在确定某一症状是否适合发出警报时，请考虑以下原则：

可操作： 问题是否重要？它是否反映了应用程序运行状况中的实际问题？例如，当资源持续期间 CPU 使用率过高或 SQL 查询持续导致性能问题时，可能需要发送警报，但你可能不希望在短时间内 CPU 峰值时发送警报。使事情可操作以减少误报并避免警报疲劳。
紧迫性： 这个问题是否需要紧急关注？如果这些问题的答案是肯定的，应立即通知负责团队。
客户影响： 服务或应用程序的用户是否受问题影响？
对依赖系统的影响： 是否有相关依赖项的警报可以关联，以避免通知不同的团队都处理同一问题？

通过这些初始注意事项，可以开始开发监视配置。可以跨环境测试和验证假设。例如，在非生产环境和生产环境中持续评估这些注意事项和问题。持续改进是成功响应监视信号的关键。

在持续评估工作内容时，请考虑问自己这些问题，以帮助提高监视响应有效性的意识：

警报量： 是否收到大量警报量？是否可以避免许多不可操作的警报？
被忽视的问题： 你是否从遇到监视配置未捕获的问题的用户那里获得报告或票证？
误报： 是否收到错误标记的警报或信号？
警报或事件： 是否确实需要发送警报，或者某些引发的警报是否只是系统中标记的事件？如果在查询信号时显示，而不是发送警报，那么这是否足以避免警报疲劳和不可操作的通知？

有关 Microsoft 监视解决方案中功能的详细信息，请参阅本文系列中的监视平台概述。