最佳实践概述

可观测性是一个广泛的主题，拥有成熟的工具生态。但并非每种工具都适合每个解决方案！为了帮助您梳理可观测性需求、配置和最终部署，我们总结了五个关键最佳实践，指导您在可观测性策略上的决策过程。

监控重要的事项

可观测性最重要的考虑因素不是您的服务器、网络、应用程序或客户。而是对您、您的业务、您的项目或您的用户最重要的事项。

首先确定您的成功标准。例如，如果您运行电子商务应用程序，您的成功衡量标准可能是过去一小时的购买次数。如果您运行非营利组织，可能是捐赠额与当月目标的对比。支付处理商可能关注交易处理时间，而大学则希望衡量学生出勤率。

提示

成功指标因人而异！我们可能在这里以电子商务应用程序为例，但您的项目可能有截然不同的衡量方式。无论如何，建议是相同的：了解好的状态是什么样子，并为之进行衡量。

无论您的应用程序是什么，您都必须从识别关键 metrics 开始。然后从这些 metrics 逆向推导¹，看看从应用程序或基础设施角度什么会影响它们。例如，如果 Web 服务器的高 CPU 使用率会危及客户满意度，进而影响您的销售，那么监控 CPU 利用率就很重要！

了解您的目标，并对其进行衡量！

在确定了重要的顶层 KPI 后，您的下一项工作是拥有自动化的方式来跟踪和衡量它们。关键成功因素是在监视工作负载运营的同一系统中进行此操作。对于我们的电子商务工作负载示例，这可能意味着：

• 将销售数据发布到时间序列中
• 在同一系统中跟踪用户注册
• 衡量客户在网页上停留的时间，并（同样）将此数据推送到时间序列中

大多数客户已经拥有这些数据，但从可观测性角度来看，这些数据不一定在正确的位置。销售数据通常可以在关系数据库或商业智能报告系统中找到，用户注册数据也是如此。而访问持续时间数据可以从日志或 Real User Monitoring 中提取。

无论您的 metric 数据的原始位置或格式如何，它都必须作为时间序列进行维护。每个对您最重要的关键 metric，无论是业务、个人、学术还是任何其他目的，都必须以时间序列格式存在，以便您将其与其他可观测性数据（有时称为信号或遥测）进行关联。

图 1：时间序列示例

上下文传播和工具选择

工具选择很重要，对您如何运营和修复问题有深远影响。但比选择次优工具更糟糕的是缺少所有基本信号类型的工具。例如，从工作负载收集基本日志但缺少事务追踪，会给您留下一个空白。结果是对整个应用程序体验的视图不连贯。所有现代可观测性方法都依赖于通过应用程序追踪来"连接各个点"。

对您健康状况和运营的完整了解需要收集日志、metrics 和 traces 的工具，然后执行关联、分析、异常检测、仪表板展示、告警等。

信息

某些可观测性解决方案可能不包含上述所有功能，但旨在增强、扩展或为现有系统提供附加价值。在所有情况下，在开始可观测性项目时，工具的互操作性和可扩展性是重要考虑因素。

每个工作负载都不同，但通用工具可以加快结果

在每个工作负载中使用通用的工具集有额外好处，例如减少运维摩擦和培训，通常您应该努力减少工具或供应商的数量。这样做可以让您快速将现有的可观测性解决方案部署到新环境或工作负载，并在出现问题时更快地解决。

您的工具应该足够广泛，能够观察工作负载的每一层：基础设施、应用程序、网站以及两者之间的一切。在无法使用单一工具的地方，最佳实践是使用具有开放标准、开源的工具，因此具有最广泛的跨平台集成可能性。

与现有工具和流程集成

不要重新发明轮子！"圆形"已经是很好的形状了，我们应该始终构建协作和开放的系统，而不是数据孤岛。

• 与现有的身份提供者集成（例如 Active Directory、基于 SAML 的 IdPs）。
• 如果您已有 IT 故障跟踪系统（例如 JIRA、ServiceNow），请与之集成以在问题出现时快速管理。
• 如果您已有现有的工作负载管理和升级工具（例如 PagerDuty、OpsGenie），请使用它们！
• 基础设施即代码工具，如 Ansible、SaltStack、CloudFormation、TerraForm 和 CDK，都是很好的工具。使用它们来管理您的可观测性以及其他一切，并使用您今天已经使用的相同基础设施即代码工具构建您的可观测性解决方案（参见从第一天开始纳入可观测性）。

使用自动化和机器学习

计算机擅长发现模式，也擅长发现数据不遵循模式的情况！如果您有数百、数千甚至数百万个数据点需要监控，那么不可能了解每一个的健康阈值。但许多可观测性解决方案具有异常检测和机器学习功能，可以管理数据基线化的无差别繁重工作。

我们将此称为"知道好的状态是什么样子"。如果您已经对工作负载进行了彻底的负载测试，您可能已经知道这些健康性能 metrics，但对于复杂的分布式应用程序，为每个 metric 创建基线可能很困难。这就是异常检测、自动化和机器学习不可或缺的地方。

利用代表您管理应用程序健康基线和警报的工具，从而让您专注于目标，监控重要的事项。

从工作负载的所有层收集遥测数据

您的应用程序不是孤立存在的，与网络基础设施、云提供商、互联网服务提供商、SaaS 合作伙伴以及您控制范围内外的其他组件的交互都可能影响您的结果。拥有整个工作负载的全面视图非常重要。

关注集成

如果您必须选择一个领域进行插桩，那无疑是组件之间的集成。这是可观测性最强大的体现。作为规则，每当一个组件或服务调用另一个时，该调用必须至少衡量以下数据点：

1. 请求和响应的持续时间
2. 响应的状态

为了创建可观测性所需的连贯、全面的视图，收集的信号中必须包含整个请求链的单一唯一标识符。

不要忘记终端用户体验

拥有工作负载的完整视图意味着在所有层理解它，包括终端用户如何体验它。衡量、量化和了解何时您的目标因糟糕的用户体验而面临风险，与监视可用磁盘空间或 CPU 利用率同样重要——如果不是更重要的话！

如果您的工作负载是直接与终端用户交互的（例如作为网站或移动应用程序提供的任何应用程序），那么 Real User Monitoring 不仅监控向用户交付的"最后一公里"，还监控他们实际如何体验您的应用程序。最终，如果您的用户无法实际使用您的服务，那么所有的可观测性之旅都没有意义。

数据就是力量，但不要纠结于小事

根据应用程序的规模，您可能有大量组件需要从中收集信号。虽然这样做很重要且有价值，但您的努力可能会有递减回报。这就是为什么最佳实践是从监控重要的事项开始，以此来映射您的重要集成和关键组件，并专注于正确的细节。

从第一天开始纳入可观测性

与安全性一样，可观测性不应该是开发或运营的事后想法。最佳实践是将可观测性提前纳入您的规划，就像安全性一样，这为人们创建了一个工作模型并减少了应用程序的不透明角落。在主要开发工作完成后添加事务追踪需要时间，即使使用自动插桩也是如此。这项努力会带来远大于投入的回报！但在开发周期后期进行可能会导致一些返工。

与其在后期将可观测性加入您的工作负载，不如利用它来帮助加速您的工作。适当的日志记录、metric 和 trace 收集可以加速应用程序开发，促进良好实践，并为未来的快速问题解决奠定基础。

Footnotes

1. Amazon 广泛使用逆向工作流程来关注客户及其成果，我们强烈建议任何从事可观测性解决方案的人以同样的方式从自己的目标逆向工作。您可以在 Werner Vogels 的博客上阅读更多关于逆向工作的内容。 ↩