操作意识
在开始了解监视以提升可靠性之前，需要完成一个先导步骤。 首先，需要确保具有合理的操作意识水平。
简单来说，为了实现生产中系统的可靠性，首先得较好地了解这些系统及其在生产中的运行方式。
收集有关当前配置的信息
尽管这听起来有点怪，但在许多环境中，我们需要回答的第一个问题是“生产中究竟运行的是什么？”。如今生产环境及其部署路径都非常复杂，因此通常首先需要做一些了解。 比如有个应用程序，其组成部分有哪些呢？ 哪些部分与其他部分通信？ 此应用程序明显（和不那么明显）的依赖关系是什么？
收集有关正常性能和过去性能的信息
获取此信息后，可以尝试获得性能和系统“正常”行为的基线。 我们可能需要这些信息的原因有很多，而不仅仅是在诊断应用程序问题时可以帮到我们。 故障期间难以找出在 CPU 为 80% 的情况下运行数据库服务器是好事还是坏事。
获取该基线的过程中，需要进一步了解过去的性能。 的确，过去的性能不能保证将来的结果，但有时也可以帮助我们调整期望。 同样，如果可以访问服务过去的中断或故障信息，这些至少让我们多多少少了解潜在故障模式，可将其纳入可靠性的考虑范围中。
收集上下文信息
最后，能够获得系统的一些上下文信息会非常有用。 上下文可纳入各种不同的存储桶中，其中很多是社会-技术性的。 例如：在社会方面，想要收集有关服务或应用程序利益干系人的有用信息。
你可能会认为：“哦，谁拥有或关心特定的应用程序/服务是明摆着的”，但在企业环境或其他复杂的组织中，这比听起来要困难得多。
令人担心的是，如果不清楚谁是利益干系人，就难以在系统可靠性方面取得很大进展，稍后将在讨论 SLI 和 SLO 时讲述原因。
在上下文问题的技术方面，关注技术问题将非常有用，比如应用程序如何进入生产？是在大型部署过程中手动部署的吗？还是通过自动 CI/CD 管道使用一组出色的单元测试进行部署的？
此信息可能会产生很多影响，包括如果进行可靠性改进更新时迭代变得非常容易。 它还可能是一个非常有用的指标，指出我们可以开展哪些工作来产生重大影响。
用于获得操作意识的 Azure 工具
获得操作意识通常不容易，我们来看几个可帮到我们的 Azure 工具。 这些介绍非常浅显；如果想要更深入地探索，此模块结束时有其他 Microsoft Learn 模块和文档的资源，可供你选取和阅读。
Application Insights
我们将看到的第一个工具可以帮助我们了解“实际运行的是什么？”这个问题。 作为操作人员，被要求处理已在生产中运行的应用程序并不罕见。 虽然理想情况下，我们是整个软件生命周期的一部分（从设计阶段开始），但事实并不总是如此。 发生这种情况时，尤其是对于更复杂的多层应用程序或基于微服务的应用程序而言，只是了解所有移动部件的行为已属不易。
而 Application Insights 这种工具可以减少困难，并提供生产中的应用程序行为相关信息。 这样开发人员耗费最少的工作量，就可以检测应用程序，使其自动将遥测信息发送到在 Azure 中运行的收集器。 利用此信息，Application Insights 能够创建应用程序组件的可视化映射以及这些组件之间的通信。
下面是一个示例：
在上图中，不仅可以看到应用程序的组件，还可以看到这些组件之间的通信。 如果细看组件之间的某一连接，可以看到组件之间进行的调用数及这些调用的平均延迟。 还可以看到成功和失败调用次数的表示形式。 如果选择这些映射元素中的任何一个，Application Insights 将让你深入了解相关信息，查看这些调用的性能和成功/失败指标的详细统计信息。 这提供一种很好的方法，助我们很好地了解应用程序组件及它们如何作为基线运行。 请注意，在发生故障前，务必了解应用程序映射，及 Application Insights 提供的所有功能。
Azure Resource Graph
Application Insights 是获得一些应用程序操作意识的好方法，但如果想要站在更高的角度，了解订阅中 Azure 上正在运行的所有资源，要怎么办呢？ 过去，你会下载报表或编写 PowerShell 来收集此信息，但现在还有更简单的方法。
Azure Resource Graph 资源管理器从 Azure 门户中为所需数据提供交互式查询环境。 它允许运行任意查询，这些查询将基于当前正在使用的资源返回实时答案。 例如，如果想要查看当前正在运行的所有 VM，可以运行以下查询：
将返回订阅中正在使用的 VM 的完整详细列表：
此环境中使用的查询语言为 Kusto 查询语言 (KQL)。 稍后此模块中谈及 Azure Monitor Log Analytics 时，将详细介绍它。
仪表板
操作意识的最传统的操作工具是“古老”的仪表板。 通常，当我们想到操作人员时，会浮现这样一个画面：他们坐在大型显示器前面，专注地盯着充满图形、图表和计数器的仪表板。 此模块不会探讨如何构建、编辑和使用仪表板。 这在很大程度上是通过固定门户中其他位置的内容，然后根据需要移动它们来完成的。
我们将了解不常使用的两项仪表板功能，它们非常有用。 可以在每个仪表板顶部找到这些功能。
通过这两个突出显示的箭头，可以上传和导出仪表板的 JSON 表示形式。
我们从导出功能开始。 如果选择“导出”，然后选择“下载”，则表示当前仪表板的 JSON 文件会下载到计算机。 如果需要，可立马尝试：登录到门户，从产品菜单中选择“仪表板”，然后选择“导出”>“下载”。
对于此文件，至少可以做两件事，而且非常方便：
可将此文件签入源代码管理系统。 这样一来，就可以跟踪不同版本的仪表板，还可以允许想要使用仪表板的其他人访问它们。 一些人将其称之为“仪表板即代码”。
可将此文件用作新仪表板的基础。 下面是一个具体例子（稍后在此学习路径中还会看到）：假设你需要向同事展示特定仪表板在上周发生的故障期间一小时内的情况。 你可以发布仪表板，并让他们选择准确的时间和时间段。 但为了简单和出错更少，可以下载按需设置的仪表板并共享该 JSON 文件。 如果想要另外突出显示同一仪表板的某一时间段情况（比如未来一小时），可以轻松地编辑 JSON。
这就是导出功能。 现在我们来关注上传功能的使用。 除了能够加载上一节中版本控制过或编辑过的文件之外，还可以使用“上传”功能，在构造仪表板时使用其他人的细心的劳动成果。
我们来看看本节最后一个示例，将本单元中的两个观点很好地结合。 将此 JSON 文件：
下载到计算机，然后将其上传到仪表板时，应看到如下所示的内容：
现在有了一个实时仪表板，其中显示了订阅中正在使用的资源的易于理解的清单。 此仪表板的数据来自与我们先前学习的 Azure Resource Graph 资源管理器中数据相同的源。 事实上，如果选择其中一个磁贴，则可以查看并编辑（根据需要）正运行的那个查询，生成方块中显示的信息。 很棒，不是吗？
利用操作意识，我们将开始探索为了帮助提高可靠性而需要监视的内容。