构建控制面板以获取操作可见性

我们都在笔记本电脑、平板电脑和智能手机上运行应用程序。我们很容易看到设备是否已开机，Wi-Fi 网络连接是否在线。我们知道屏幕会显示关键通知，例如低可用磁盘空间警告。事实上，用户界面 (UI) 的常规速度和响应能力可以很好地指示设备是否有足够的资源（如内存或 CPU）来运行我们的应用程序。

任何为其家庭设备提供远程技术支持的人都可以证明，当无法看到和与设备直接交互时，更难检测和诊断问题。因此，当运行基于云的服务时，我们会面临一个类似的难题：如何监控这些远程服务，如何了解我们的客户是否满意？

要观察单主机服务，我们可以登录该主机，运行各种不同的运行时监控工具，并检查日志以确定主机上所发生情况的根本原因。然而，单主机解决方案仅适用于最简单的非关键性服务。另一个极端是多层分布式微服务，它们运行在数百个或数千个服务器、容器或无服务器环境中。

Amazon 如何了解在全球很多区域的多个可用区运行的所有基于云的服务的实际行为表现？ 自动化监控、自动化修复工作流程（例如，流量转移）和自动化部署系统对于检测和解决这种规模的绝大多数问题至关重要。然而，基于很多原因，我们仍然需要能够随时了解这些服务、工作流程和部署在做什么。

我们将控制面板用作一种机制，来应对掌握云服务中的活动带来的挑战。控制面板是面向人的系统视图，通过显示时间序列指标、日志、轨迹和警报数据提供系统行为方式的简明摘要。

在 Amazon，我们将创建、使用和持续维护这些控制面板称为控制面板化。控制面板化已发展成为一项一流的活动，因为它与设计、编码、构建、测试、部署和扩展服务等其他日常软件交付和运营活动一样，对我们的服务成功至关重要。

当然，我们不希望操作人员一直监控控制面板。大多数时间，没有人监视这些控制面板。事实上，我们已经发现，任何需要手动检查控制面板的操作过程都会因为人为错误而失败，无论查看控制面板的频率有多高。为了解决这个风险，我们创建了自动警报，以持续评估我们的系统发送的最重要的监控数据。通常，这些指标指示系统正在接近某种极限（影响前的主动检测），或者系统已经以某种意想不到的方式受损（影响后的被动检测）。

这些警报可以执行自动修复工作流程，并且可以通知操作人员出现问题。通知将操作人员导向他们需要使用的确切控制面板和 Runbook。当我在值班时收到一条警报通知提醒我出现问题时，我可以快速使用相关的控制面板量化客户影响、验证或对根本原因进行分类，减轻问题和减少恢复时间。即使警报已经开始了自动化修复工作流程，我仍然需要了解自动化工作流程在做什么、对系统会造成什么影响，并且在特殊情况下，通过为安全关键性步骤提供人为确认来向前推动工作流程。

当有事件在进行中时，Amazon 通常会让多个操作人员待命。操作人员在逐步执行一系列任务时，可能会使用不同的控制面板。这些任务通常包括量化对客户的影响、分类、跨多个服务跟踪事件的根本原因、观察自动修复工作流程，以及执行和验证基于 Runbook 的减轻步骤。同时，同行团队和企业利益相关者还使用控制面板来监控事件期间持续发生的影响。这些不同的参与者通过事件管理工具、聊天室（AWS Chatbot 之类的聊天机器人）和电话会议进行交流。每位利益相关者对他们在控制面板中看到的数据都有不同的看法。

每周，Amazon 团队和更广泛的组织还会召开运营审查会议，高级领导、经理和很多工程师都会参加这些会议。在这些会议期间，我们使用幸运轮盘选择高级审计控制面板。利益相关者审查客户经验和关键的服务级目标，如可用性和延迟。这些利益相关者通常使用的审计控制面板显示所有可用区和区域的运营数据。

此外，在进行长期容量规划和预测时，Amazon 使用控制面板来可视化我们的系统在较长时间间隔内发送的最高级的业务、使用率和容量指标。

人们使用控制面板手动监控服务，但一种大小并不适合所有的使用案例。对于大多数系统，我们使用很多控制面板，每个控制面板都提供系统的不同视图。通过这些不同的视图，不同的用户可以从不同的角度在不同的时间间隔了解系统的行为方式。

每个受众想要看到的数据在不同的控制面板之间差异很大。我们已经学会在设计控制面板时重点关注预期受众。我们根据谁将使用控制面板以及他们为什么使用控制面板来决定在每个控制面板中包含哪些数据。您可能听过，在 Amazon，我们从客户的角度出发。创建控制面板就是一个很好的例子。我们根据预期用户的需求及其特定要求构建控制面板。

下图说明了不同的控制面板如何为整个系统提供不同的视图：

在 Amazon，最重要且使用广泛的控制面板是客户体验控制面板。这些控制面板为广泛的用户群而设计，其中包括服务操作人员及很多其他利益相关者。它们高效地提供关于总体服务运行状况和目标遵守情况的指标。它们显示来源于服务本身以及客户端仪器、持续测试程序（如 Amazon CloudWatch Synthetics Canary）和自动修复系统的监控数据。这些控制面板还包含帮助用户回答影响深度和广度等问题的数据。其中一些问题可能是“有多少客户受到了影响？”以及“哪些客户受到的影响最大？”

我们的 Web 服务的入口点通常是 UI 和 API 终端节点，专用的系统级控制面板必须包含足够的数据，以便操作员查看系统及其面向客户的终端节点的行为。这些控制面板主要显示界面级监控数据。这些控制面板为每个 API 显示三种类别的监控数据：

• 与输入相关的监控数据。此类数据可能包括接收到的请求数或从队列/流轮询的工作、请求字节大小百分比以及身份验证/授权失败数。
• 与处理相关的监控数据。此类数据可以包括多模式业务逻辑路径/分支执行计数、后端微服务请求计数/失败/延迟百分比、故障和错误日志输出，以及请求跟踪数据。
• 与输出相关的监控数据。此类数据可以包括响应类型计数（以及按客户划分的错误/故障响应细分）、响应大小，以及写第一个响应字节的时间和写完整响应时间的百分比。

总的来说，我们的目标是尽量将这些客户体验和系统级控制面板保持在高水平。我们刻意避开在这些控制面板中添加太多指标的诱惑，因为信息过载会分散对这些控制面板需要传达的核心信息的注意力。

我们构建了一些控制面板，以帮助在单个服务实例（分区或单元）中快速和全面地评估客户体验。这个窄视图确保在单个服务实例上工作的操作人员不会因来自其他服务实例的无关数据而过载。

我们还构建了客户体验控制面板，以有意显示跨所有可用区和区域的所有服务实例的数据。操作人员使用这些服务审计控制面板审计跨所有服务实例的自动警报。也可以在之前提到的每周运营会议期间审查这些警报。

对于较长期的使用案例，我们还构建了容量规划和预测控制面板，以帮助我们可视化服务的增长。

Amazon API 通常通过编排请求跨后端微服务实施。这些微服务可以归不同团队拥有，每个团队负责处理请求的某个特定方面。例如，有些微服务专门用于请求身份验证和授权、限流/限制实施、使用计量、创建/更新/删除资源、从数据存储中检索资源以及启动异步工作流程。团队通常至少构建一个专用的微服务特定控制面板，以显示每个 API 的指标或服务异步处理数据时的工作单元。

微服务控制面板通常显示特定于实施的监控数据，这些数据需要深入了解服务。这些控制面板主要由拥有服务的团队使用。然而，由于我们的服务装备有很多仪器，我们需要以一种不会压垮操作人员的方式来提供此仪器中的数据。因此，这些控制面板通常以聚合形式显示某些数据。当操作人员在聚合的数据中发现异常情况时，他们通常会使用各种其他工具进行更深入的探究，对底层监控数据执行临时查询，从而分解数据、跟踪请求并显示相关的数据。

我们的服务在通常用于发送指标的 AWS 基础设施上运行，因此，我们还拥有专用的基础设施控制面板。这些控制面板主要专注于我们的系统运行所在的计算资源发送的指标，例如 Amazon Elastic Compute Cloud (EC2) 实例、Amazon Elastic Container Service (ECS)/Amazon Elastic Kubernetes Service (EKS) 容器和 AWS Lambda 函数。这些控制面板通常使用 CPU 利用率、网络流量、磁盘 IO 和空间利用率等指标，以及任何相关的集群、Auto Scaling 以与这些计算资源相关的配额指标。

除了计算资源之外，在很多情况下，微服务取决于其他微服务。即使拥有这些依赖项的团队已经拥有自己的控制面板，每个微服务拥有者通常都会创建专用的依赖项控制面板来提供上游依赖项（例如，代理和负载均衡器）和下游依赖项（例如，数据存储、队列和流）的行为视图，该视图通过其服务来衡量。这些控制面板还可用于跟踪其他关键指标，例如安全证书到期日期和其他的依赖项配额使用。

在 Amazon，我们认为数据表示的一致性对于控制面板的成功创建至关重要。为了使之有效，必须实现每个控制面板以及各个控制面板之间的一致性。多年来，我们已经确定、调整并改善了一组常用的设计习惯和惯例，我们相信这些习惯和惯例可让最广泛的受众访问控制面板，从而最终提高它们对组织的价值。随着时间的推移，我们甚至还发现了衡量和改进这些设计惯例的巧妙方法。例如，如果新操作人员可以快速了解并使用控制面板中提供的数据来了解服务的工作原理，则表明这些控制面板以适当的方式显示了适当的信息。

设计控制面板时，一个非常常见的趋势是高估或低估目标用户的领域知识。构建一个对其创建者完全有意义的控制面板很简单。但这种控制面板可能无法为用户提供价值。我们使用从客户（在本案例中为控制面板用户）反向推动工作的方法来消除这种风险。

我们采用一种设计惯例来标准化控制面板中的数据布局。控制面板从上到下呈现，用户倾向于将最初呈现的图形（在控制面板加载时可见）解释为最重要的图形。因此，我们的设计惯例建议将最重要的数据放置在控制面板的顶部。我们发现，聚合/摘要可用性图形和端到端延迟百分比图形通常是 Web 服务最重要的控制面板。

下面是假设 Foo 服务控制面板顶部的屏幕截图：

如果我们在图形中有很多指标，我们将确保图例不会垂直或水平压缩可见图形数据。如果我们在图形中使用搜索查询，则我们会确保允许一组比正常大的指标结果。

这样可以避免强迫用户水平滚动。凌晨 3 点时，待命操作人员可能不会在笔记本电脑上注意到水平滚动条，因为没有明显的视觉线索指示右边有更多图形。

对于显示日期和时间数据的控制面板，我们确保在控制面板中显示相关时区。对于操作人员在不同时区同时使用的控制面板，我们默认设置为所有用户都可以关联的一个时区 (UTC)。用此方式，用户可以使用一个时区相互通信，从而节省进行过多心理时区转换的时间和精力。

我们默认设置为与最常见的使用案例相关的时间间隔和数据点周期。我们确保控制面板上的所有图形最初显示相同时间范围和分辨率的数据。我们发现，如果控制面板某个部分中的所有图形都具有相同的水平大小，将会非常有益。这使得图形之间很容易进行时间关联。

我们还避免在图形中绘制太多的数据点，因为这会降低控制面板的加载时间。此外，我们还观察到，向用户显示过多的数据点实际上会降低异常的可见性。例如，间隔时间三小时、分辨率一分钟且每个指标有 180 个值的数据点的图形即使在小型控制面板小组件中也能清楚呈现。这一数据点数量还为对持续运营事件进行分类的操作人员提供足够的上下文。

我们的控制面板提供控件来快速调整所有图形的时间间隔和指标周期。我们在控制面板中使用的其他常见的时间间隔 x 分辨率比包括：

• 1 小时 x 1 分钟（60 个时间点）– 可用于放大以观察持续事件
• 12 小时 x 1 分钟（720 个时间点）
• 1 天 x 5 分钟（288 个时间点）– 可用于查看每日趋势
• 3 天 x 5 分钟（864 个时间点）
• 1 周 x 1 分钟（168 个时间点）– 可用于查看每周趋势
• 1 个月 x 1 小时（744 个时间点）
• 3 个月 x 1 天（90 个时间点）– 可用于查看每季度趋势
• 9 个月 x 1 天（270 个时间点）
• 15 个月 x 1 天（450 个时间点）– 可用于长期容量审查
  

当我们为具有相关自动化警报的指标绘制图形时，如果警报阈值是静态的，我们将用横线对图形进行注释。如果警报阈值是动态的，也就是说，它们基于人工智能 (AI) 或机器学习 (ML) 生成的预测，则我们在同一个图形中同时显示实际指标和阈值指标。如果图形显示衡量具有已知限制（例如“最大测试”限制或硬资源限制）的服务的某个方面的指标，我们使用横线来对图形进行注释，以指示已知或测试限制的位置。对于有目标的指标，我们增加了横线，以使用户可以立即看到这些目标。

如果您增加横线到这些图形中，用户可能会发现难以了解横线与哪一条 y 轴相关。为了避免这种模糊性，我们将这样的图形拆分为两个仅使用单个水平轴的图形，并仅增加横线到相应的图形中。

我们避免发生这种情况，因为这可能会减少对一个或多个指标差异的可见性。举例来说，我们在同一个图形上绘制 p0（最小值）和 p100（最大值）延迟，其中 p100 数据点的值可能比 p0 数据点大几个数量级。

如果随意查看 y 轴范围限于数据点值的图形，会使指标看起来比它的实际变化大得多。

我们希望确保单个图形中没有太多的统计数据或不相关的指标。例如，当添加请求处理的图形时，我们通常在控制面板中为以下各项创建单独的相邻图形：

• 可用性 %（故障/请求 * 100）
• p10、平均值、p90 延迟
• p99.9 和最大 (p100) 延迟
  

这尤其适用于特定于实施的指标。我们希望在控制面板文本中提供足够的上下文，例如在每个图形的旁边或下面提供描述文本。操作人员可以阅读此文本以了解指标的含义。然后，操作人员可以解释“正常”是什么样子，以及图形“不正常”时，意味着什么。 在此文本中，我们提供至相关资源的链接，操作人员可以用这些资源来确定根本原因。下面是我们提供的链接类型的几个示例：

• 至 Runbook。对于主题专家，控制面板可以是 Runbook。
• 至相关的“深入探究”控制面板。
• 至其他集群或分区的等效控制面板。
• 至部署管道。
• 至依赖项的联系信息。
  

根据控制面板使用案例的不同，我们发现，显示包含单个数字（例如，指标的最新值）或警报状态的小组件有时候比显示最近所有时间点的复杂时间系列图形更加适当。

稀疏指标指的是仅在存在特定错误条件时发出的指标。虽然只有在必要时才能使用服务发出这些指标，但控制面板用户可能会因空图形或几乎为空的图形而感到困惑。如果我们在设计控制面板时遇到此类指标，我们通常会修改服务，以在没有错误条件的情况下持续为这些指标发出安全（即零）值。然后，操作人员很容易便理解到，缺乏数据意味着服务不能正确发射遥测。

当我们为在系统中聚合多模型行为的指标显示图形时，我们会这样做。我们可能会这样做的一些情况包括：

• 如果服务支持可变大小的请求，我们可能会为请求的总体延迟创建图形。另外，我们还可能会创建图形来显示小型、中型和大型请求的指标。
• 如果某项服务根据输入参数的值（或组合）以不同的方式执行请求，则我们可能会为捕获每种执行模式的指标增加图形。