混合云和多云最佳实践
简介
我们将多云定义为同时使用多个云服务提供商来运行您自己的工作负载，而混合云则是将您的工作负载扩展到本地和云环境中。混合云和多云环境中的可观测性可能会由于工具多样性、延迟和异构工作负载而增加显著的复杂性。尽管如此，这仍然是开发和业务用户的共同目标。丰富的产品和服务生态系统可以解决这个问题。
然而，可观测性工具对云原生工作负载的实用性可能差异巨大。考虑一下监控容器化批处理工作负载与使用无服务器框架的实时银行应用程序的不同需求：两者都有 logs、metrics 和 traces；但是用于观测它们的工具链会有所不同，有许多云原生、开源和 ISV 产品可供选择。像 Prometheus 这样的开源工具可能非常适合其中一个，而作为托管服务提供的云原生工具可能更好地满足您的需求。
再加上多云和混合云的复杂性，从应用程序中获取洞察变得更加困难。
为了应对这些额外的维度并促进可观测性方法，客户倾向于投资具有统一界面的单一工具链。毕竟，降低信噪比通常是一件好事！然而，单一方法并不适用于所有用例，各种平台的运营模式可能会增加混淆。我们的目标是帮助您做出明智的决策，以补充您的需求并在问题发生时减少平均修复时间。以下是我们通过与各种规模和各个行业的客户合作所总结的最佳实践。
这些最佳实践适用于广泛的角色：企业架构师、开发人员、DevOps 等。我们建议从您组织的业务需求角度来评估它们，以及分布式环境中的可观测性如何提供尽可能多的价值。
不要让工具决定您的决策
您的应用程序、工具和流程的存在是为了帮助实现业务成果，例如增加销售额和客户满意度。明智的技术策略是尽一切可能帮助您实现这些业务目标。但帮助您达成目标的事物只是工具，它们旨在支持您的策略——而不是成为策略本身。打个比方，如果您需要建造一栋房子，您不会问您的工具如何设计和建造它。相反，您的工具是达到目的的手段。
在单一的同构环境中，工具选择的决策更容易。毕竟，如果您在一个环境中运行单个应用程序，那么您的工具可以在所有方面保持一致。但对于混合云和多云环境，情况就不那么明确了，关注您的业务成果——以及跨这些环境观测工作负载所带来的价值——至关重要。每个云服务提供 商 (CSP) 都有自己的原生可观测性解决方案，以及丰富的合作伙伴和独立软件供应商 (ISV) 可供使用。
仅仅因为您在多个环境中运行，并不意味着为每个工作负载使用单一工具是可取的，甚至是推荐的。这可能意味着使用多种服务、框架或提供商来观测您的工作负载。请参阅下面的"单一视图不如工作负载的上下文重要"了解您的运营模型如何需要反映您的需求的详细信息。无论如何，在实施工具时，请记住创建"双向门"，以便您可以在未来发展您的可观测性解决方案。
以下是一些需要避免的"工具优先"结果示例：
- 专注于实施单一工具而没有双向门来升级它，或在未来转向新解决方案，可能会产生本可避免的技术债务。当工具成为解决方案时，有一天它可能成为您需要解决的问题。
- 由于批量折扣而使用单一工具的公司标准可能最终缺少他们可以受益的功能。这可能是"成本高于质量"，无意中创造了单体反模式。这可能会为了保持在批量阈值以下而阻止遥测数据的收集，从而抑制可观测性工具的使用。
- 由于缺乏现有的 trace 收集基础设施（但拥有丰富的 log 和 metric 收集器）而不收集整个类型的遥测数据（通常是 traces），可能导致不完整的可观测性解决方案。
- 为了降低人工和培训成本，支持人员仅接受单一工具链的培训，从而降低了其他可观测性模式的潜在价值。
如果您的工具正在决定您的可观测性策略，那么您需要反转方法。工具旨在赋能和增强可观测性，而不是限制您的选择。
工具泛滥是公司面临的一个非常现实的问题，然而激进地转向单一工具链同样可能降低您可观测性解决方案的实用性。混合云和多云工作负载具有每个平台独有的技术，每个 CSP 的高级服务都很有用——尽管使用单一来源产品的权衡需要基于价值的分析。请参阅"投资 OpenTelemetry"了解缓解其中一些风险的方法。
(可观测性) 数据具有引力
所有数据都具有引力——也就是说，它会吸引工作负载、解决方案、工具、人员、流程和项目围绕它。例如，包含客户交易的数据库将成为吸引计算和分析工作负载的力量。这直接影响您在哪个环境中放置工作负载，以及如何在未来运营它们。可观测性信号也是如此，尽管这些数据产生的引力与您的工作负载和组织上下文相关（请参阅"单一视图不如工作负载的上下文重要"）。
人们无法将可观测性遥测数据的上下文与其相关的底层工作负载和数据完全分离。同样的规则适用于此：您的遥测数据就是数据，它具有引力。这应该影响您放置遥测代理、收集器或聚合和分析信号的系统的位置。
可观测性数据随时间的价值远低于大多数其他数据类型。您可以称之为可观测性数据的"半衰期"。将遥测数据中继到另一个环境的额外延迟视为在其潜在使用之前对该数据的强制贬值，然后将其与您对问题发生时告警的需求进行权衡。
最佳实践是仅在聚合能带来商业价值时才在环境之间发送数据。拥有单一的数据查询源本身并不能解决许多业务需求，并且可能创建比预期更昂贵的解决方案，具有更多的故障点。
单一视图不如工作负载的上下文重要
一个常见的需求是使用"单一视图"来观测您的所有工作负载。这源于一种自然的愿望——尽可能多地查看数据，但要以尽可能简单的方式实现，并减少干扰、挫折和诊断时间。创建这样一个界面来一次性查看整个可观测性解决方案是有用的，但可能会以将遥测数据与其来源上下文分离为代价。
例如，显示一百台服务器 CPU 利用率的 dashboard 可能会显示一些异常的消耗峰值，但这并不能解释为什么会发生这种情况，或者导致这种行为的因素是什么。而且这个 metric 的重要性可能不会立即清楚。
我们曾看到客户有时过于激进地追求单一视图，以至于所有业务上下文都丢失了，试图在一个工具中看到所有内容实际上可能会稀释数据的价值。您的 dashboard 和工具需要讲述一个故事。而这个故事需要包含受工作负载事件影响的业务 metrics 和成果。
此外，您的工具需要与您 的运营模型保持一致。当您的支持团队是全球性的并且可以访问所有环境时，单一视图可以增加价值，但如果他们仅限于访问单个 CSP 或混合环境中的单个工作负载，那么这种方法不会增加任何价值。在这些情况下，允许团队在每个环境中原生创建 dashboard 可能会加快价值实现时间，并且在未来更加灵活。
可观测性数据的价值与其来源应用程序深度集成。您的遥测数据需要来自其环境的上下文感知。在混合云和多云环境中，技术之间的差异使得对上下文的需求更加迫切（尽管 Kubernetes 等系统在不同云提供商和本地环境之间可能是相似的）。
在为分布式系统构建单一视图时，将您的业务 metrics 和服务级别目标 (SLO) 与其他数据（如基础设施 metrics）一起显示在同一视图中，这些数据共同贡献于这些 SLO。这提供了可能缺失的上下文。
单一视图可以帮助快速诊断问题并减少检测时间 (MTTD)，从而减少平均解决时间 (MTTR)，但前提是遥测数据的含义能够被保留。如果没有这一点，单一视图方法可能会增加价值实现时间，或对运营团队产生净负面影响。
如果无法确定单一视图的价值，或者工作负载完全绑定到单个 CSP 或本地环境，请考虑仅将顶级业务 metrics 汇总到单一视图中，将原始 metrics 和其他贡献因素保留在其原始环境中。
投资 OpenTelemetry
在可观测性供应商领域，OpenTelemetry (OTel) 已成为事实上的标准。OTel 可以将您的每种遥测类型编组到一个或多个收集器中， 这些收集器可以包括云原生服务或各种 SaaS 和 ISV 产品。OTel 代理和收集器使用 OpenTelemetry Protocol (OTLP) 进行通信，该协议将信号封装成允许各种部署模式的格式。
要收集最有价值的、包含业务和基础设施上下文的事务 traces，您需要将 trace 收集集成到您的应用程序中。一些自动检测代理几乎无需任何工作即可完成此操作。然而，最复杂的用例确实需要您进行代码更改以支持事务 traces。这会产生一些技术债务并将您的工作负载绑定到特定的技术。
OTel 使用 span 的概念捕获 logs、metrics 和 traces。Span 包含从单个事务中分组在一起的这些信号，将它们打包成一个上下文化的、可搜索的对象。这意味着您可以在一个简单的实体中查看来自单个应用程序事件的信号。例如，用户登录网站以及由此产生的对所有下游服务的请求，可以作为单个 span 呈现。
OTel 不限于应用程序 traces，也广泛用于 logs 和 metrics。许多 ISV 产品今天直接接受 OTLP。
通过使用 OTel 检测您的应用程序，如果您选择从一个可观测性平台迁移到另一个平台，您无需在应用程序层替换此检测。这将您的可观测性解决方案的一部分变成了双向门。
OTel 具有面向未来、可扩展的特点，使得在未来更改收集和分析系统时无需更改应用程序代码变得更加容易，使其成为一种高效的左移。