你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
已启用 Azure Arc 的 Kubernetes 的服务可观测性
可观测性是一种应用程序特征，它指从系统外部输出了解系统内部状态的方便程度。 我们通过观测 CPU 时间、内存、磁盘空间、延迟、错误和其他指标来衡量计算机系统。 系统的可观测性越高，我们就越容易通过观测它来了解它的状况。
系统的可观测性对其运行成本有显著影响。 可观测的系统为其操作员提供有意义的可操作数据，使他们能够获取有利的结果并减少停机时间。 信息越多并不一定意味着系统的可观测性越好。 事实上，有时系统生成的信息量会使从应用程序生成的干扰信息中识别有价值的运行状况信号变得更困难。
服务可观测性非常重要，因为它可以帮助你了解基于动态体系结构的分布式和云系统中的性能和问题。
实施一种解决方案来实现服务可观测性可能有助于：
- 确保最终用户可以使用你的应用程序并满足业务预期。
- 了解整个系统以及它如何使用单一管理视图协同工作。
- 为系统建立基线并了解不同的情况如何影响系统性能。
- 在发生意外的情况和行为后生成操作项。
已启用 Azure Arc 的 Kubernetes 提供两个集成扩展选项来帮助你实现服务可观测性：Open Service Mesh 和自承载 API 管理网关。 下面的设计注意事项部分将详细讨论这些选项。
体系结构
下图演示了影响数据量的服务可观测性的三大支柱。
下图显示了在已启用 Arc 的 Kubernetes 群集中运行的各种 Open Service Mesh 组件。 它还显示了在服务网格中启用的示例应用程序，为该应用程序自动配置了 Envoy 挎斗容器。
设计注意事项
可观测性的三大支柱是指标、日志和跟踪。 将它们整合到可观测性策略中将有助于使系统可观测。
- 指标是描述系统在特定时间点的某个方面的数值。指标始终会定期收集。
以下屏幕截图显示了服务的示例 HTTP 请求指标的可视化效果。 此示例中的指标显示为指定时间段内每分钟的 HTTP 请求速率。
日志可以存储具有自身结构的各种数据类型。 日志包含有关事务的详细信息，让你可以获取给定事件的更完整经历。 应用程序日志通常包括时间戳、日志级别以及用于了解事件上下文的任何信息。 收集日志并将其发送到日志服务以进行存储和分析。
分布式跟踪是一种诊断技术，可帮助用户找出应用程序中的故障和性能问题，尤其是可能跨多个计算机或进程分布的任何问题。 此技术通过应用程序跟踪请求，将不同应用程序组件完成的工作相关联，并将其与应用程序可能为并发请求所做的其他工作分开。
以下屏幕截图显示了使用 Application Insights 的端到端事务的可视化效果。 这种可视化效果便于了解响应时间、响应代码以及事务链中请求之间发生的任何异常。
指标、日志和分布式跟踪这三大支柱是相互关联的。 指标以数值形式存储在时序数据库中。 它们也比日志小得多，因此它们更容易评估并且对准实时警报很有用。 日志捕获和传达的信息比指标多得多，因此它们对于更深入的调试很有用。 跟踪是请求范围的，对于在遍历分布式系统的各个组件时获取请求可见性很有用。
下表显示了三大支柱对收集的影响。
| 收集特征 | 指标 | 日志 | 布式跟踪 |
|---|---|---|---|
| 考虑每个事务 | 是 | 是 | 否（采样） |
| 对基数问题免疫 | 否 | 是 | 是 |
| 成本 | 低 | 高 | 低 |
可通过不同的方式实现服务可观测性。 可以使用服务网格在平台层实现此目的，应用程序感知不到此层并且此层不会更改。 还可以使用库来检测应用程序，为此通常会使用 Application Insights 等应用程序性能监视 (APM) 工具。 API 网关提供南北流量的可观测性，但缺乏 pod 间通信的可观测性和大规模配置的便利性。
以下部分介绍如何使用服务网格和适用于 Azure Arc 的自承载 API 网关来实现服务可观测性。
服务网格
服务网格为工作负载提供流量管理、复原能力、策略实施、传输安全性、标识安全性和可观测性等功能。 应用程序与这些操作功能相分离；服务网格将这些功能移出应用层并移到基础结构层。 这是通过一个高性能代理来完成的，该代理会调解服务的所有入站和出站流量。
- 已启用 Azure Arc 的 Kubernetes 支持 Open Service Mesh (OSM)，这是一个作为扩展部署的云原生计算基金会 (CNCF) 项目。 Open Service Mesh 是一种轻型、可扩展的云原生服务网格，可让用户统一地管理、保护和获取高度动态微服务环境现成的可观测性功能。
- 其他需要供应商支持的流行服务网格包括 Istio、Consul Connect 和 Linkerd。
- 根据在实施服务网格时使用的功能，应用程序操作员可能需要承担额外的责任来定义每个服务的配置（例如访问规则和加入服务）。 此外，群集操作员必须了解并管理服务网格控制器。 由于服务网格使用挎斗模式的方式，调试传出和传入流量时需要来自服务网格控制平面和挎斗的访问日志。
服务网格可观测性
可观测性是服务网格提供的众多功能中的一项重要功能。 选择满足最低可观测性要求的服务网格，以便减少服务网格可能附带的复杂性和需要配置的组件数量。 评估服务网格提供的以下常见可观测性功能和用例：
- 指标生成，包括四个黄金信号：延迟、流量、错误和饱和度。
- RED 方法（调用速率/秒、错误数、调用持续时间内的延迟），它是四个黄金信号的子集，用于衡量服务。 服务网格应提供一种标准化方式来收集 RED 指标、跟踪等。
- 可观测性将提高，从提高覆盖范围到作为服务网格一部分的所有服务。
- 通过自动检测所有服务来提高可观测性采用的功能。
- 与服务可观测性支柱的强大集成。 服务网格应该能够抓取指标并收集监视解决方案中出现的日志。 确保服务网格的遥测收集支持你的业务需求并与现有的监视解决方案正常集成。
下图显示了服务网格代理的数据收集和转发功能的示例。
API 管理自承载网关
通过 Azure API 管理与 Kubernetes 上的 Azure Arc 之间的集成，可以将 API 管理网关组件部署为已启用 Azure Arc 的 Kubernetes 群集中的扩展。 这样就可以在群集中运行 API 管理网关的容器化版本。 所有自承载网关都是通过与它们联合的 API 管理服务进行管理的，在所有内部和外部 API 中为你提供直观统一的管理体验。
需要创建策略才能将自承载网关配置为接受传入流量以定向到服务。 随着服务规模的扩大，其管理可能会变得更复杂。
有关详细信息，请参阅自承载网关概述
API 管理自承载网关可观测性
自承载网关发出指标、stdout 日志和 stderr 日志。 它发出的指标可以通过群集中的 ConfigMap 进行配置。 有关使用 API 管理进行高级监视的信息，请参阅高级监视。
自承载网关可观测性考虑到了进入群集的外部流量（南北向），但不为群集中的 pod 间流量（东西向）提供任何可观测性。
云指标和日志：指标默认发出到 Azure Monitor。 Log Analytics 允许使用用于容器的 Azure Monitor 收集和查看自承载网关容器日志。 有关详细信息，请参阅为 Azure API 管理自承载网关配置本地指标和日志。
本地指标和日志：来自自承载网关的指标和日志可与本地监视工具集成或者由 Config Map 发出。 可以配置指标以发布到指标服务器。 网关日志默认发出到 stdout 和 stderr。 有关详细信息，请参阅为 Azure API 管理自承载网关配置本地指标和日志。
技术对照表
下表显示了实现选项之间的差异，以帮助你选择用于实现服务可观测性的方法。
| 功能 | 服务网格 | 应用程序性能监视 | 自承载 API 网关 |
|---|---|---|---|
| 支持东西向流量 | 是 | 是 | 否 |
| 指标功能 | 是 | 是 | 是 |
| 日志记录功能 | 是 | 是 | 自定义实现 |
| 分布式跟踪功能 | 是 | 是 | 是 |
| 实现层 | 网络 | 应用程序 | 网络 |
| 支持的协议 | HTTP（S）、TCP、gRPC | 空值 | HTTP（S）、websocket |
| 配置责任 | 群集操作员 | 应用程序开发人员 | 应用程序操作员和群集运算符 |
| 可观测性的配置复杂性 | 低 | 高 | 中 |
设计建议
实现 Open Service Mesh 以获取服务的运行状况和性能可观测性。 Open Service Mesh 使用挎斗代理作为单独的容器注入到与工作负载相同的 pod 中，以获取遥测数据。 这些代理拦截发往工作负载的所有入站和出站 HTTP 流量，并将数据报告给 Open Service Mesh。 有了此系统，服务开发人员无需检测其代码即可收集遥测数据。
使用已启用 Azure Arc 的 Kubernetes 群集扩展功能来启用 Open Service Mesh，以允许 Microsoft 为你管理控制平面。 有关详细信息，请参阅部署已启用 Azure Arc 的 Open Service Mesh（预览版）。
若要最大程度地提高应用程序和服务的可用性和性能，请启用 Azure Monitor 容器见解。 它提供一个全面的解决方案，用于从云和本地环境收集、分析和处理遥测数据。 已启用 Azure Arc 的 Open Service Mesh 与 Azure Monitor 深度集成，让你无缝查看和响应 OSM 指标与应用程序容器日志提供的关键 KPI。 可以按照这些步骤启用 OSM 指标。 对于分布式跟踪，我们建议使用可与 OSM 控制平面集成的 Jaeger。
Open Service Mesh 还通过 Prometheus 和 Grafana 为指标提供记录的可观测性集成，通过 Jaeger 提供跟踪功能，并通过 Fluent Bit 提供日志转发功能。 如果你不使用 Azure 监视解决方案，则这些集成提供了替代选项。 可以根据需要使用这些集成扩展到其他内部监视工具。
至少应该定义以下三个 RED 指标并为所有服务衡量这些指标：
- 请求速率：服务每秒接收的请求数。
- 错误数：失败的请求数或每秒失败的请求率。
- 持续时间：服务处理请求所花费的时间。
Open Service Mesh 在 Azure Monitor 中提供了几个预配置的服务工作簿，因此你不必要手动设置仪表板和图表。 此详细遥测数据让你可以观测服务行为，以及对应用程序进行故障排除、维护和优化。 在 Azure Monitor 中使用 OSM 监视工作簿可以：
- 获取网格中所有服务的概述，并获取四个黄金监视信号中三个信号的关键服务级别指标：延迟、请求和错误。
- 针对服务水平目标 (SLO) 定义、查看和设置警报，这些目标汇总了服务的用户可见性能。
- 查看各个服务的指标图表，以便可以使用筛选和细分来深入分析它们，并可按响应代码、协议、目标 pod、流量源等筛选数据。
使用 Jaeger UI 中的可视化效果可以：
- 查看拓扑图可视化效果，其中显示了哪些微服务相互通信、请求发送到何处以及需要多长时间。
- 检查特定的请求和响应，以了解它们是如何以及何时发生，这样就可以对分布式系统进行监视和故障排除。
服务可观测性只是云监视策略的一条规程。 有关管理规程的详细信息，请查看管理规程关键设计领域。
后续步骤
有关混合云和多云旅程的详细信息，请参阅以下文章：
- 查看已启用 Azure Arc 的 Kubernetes 的先决条件。
- 查看启用 Azure Arc 的 Kubernetes 的经过验证的 Kubernetes 发行版。
- 了解如何管理混合和多云环境。
- 若要详细了解已启用 Azure Arc 的 Open Service Mesh，请参阅：
- 了解如何为 Azure Kubernetes 服务 (AKS) 上的 Open Service Mesh 配置监视和可观测性
- 了解已启用 Azure Arc 的 Kubernetes 的管理和监视。
- 了解服务网格。
- 使用 Azure Arc Jumpstart 中的 Open Service Mesh 扩展来体验已启用 Azure Arc 的 Kubernetes。
- 通过 Azure Arc 学习路径了解有关 Azure Arc 的详细信息。
- 查看常见问题解答 - 已启用 Azure Arc，以获取最常见问题的解答。