第 6 章 监控与遥测
运行系统的遥测数据采集是管理平台的重要功能，从而使运维人员能够监控系统行为、评估性能、做出明智的配置决策、响应故障、识别攻击和诊断问题。本章主要讨论三种类型的遥测数据: 指标(metrics) 、日志(logs) 和跟踪(traces) ，以及用于帮助收集、存储并对每种数据采取行动的开源软件栈。
指标(Metrics)是关于系统的定量数据，包括常见的性能指标，如链路带宽、CPU 利用率和内存使用情况，还包括与上下层对应的二进制结果，以及其他可以用数字编码的状态变量。系统周期性的通过读取计数器或者返回值产生和收集(例如，每隔几秒)这些指标。这些指标可以与物理资源(如服务器和交换机)、虚拟资源(如虚拟机和容器)或高级抽象(如 5.3 节中介绍的 Connectivity Service)相关联。对于可能的数据源，指标监视堆栈的工作是收集、归档、可视化和分析这些数据。
日志(Logs)是定性数据，当发生值得注意的事件时生成，可用于确定有问题的操作条件(例如可能会触发告警的操作)，但更常见的是用于在检测到问题后进行故障排除。各种系统组件(从底层操作系统内核到高级云服务)向日志系统写入遵循良好定义格式的消息。这些消息包含时间戳，使得日志记录堆栈能够解析和关联来自不同组件的消息。
跟踪(Traces)是由用户发起的事务或作业产生的因果关系记录(例如，服务 A 调用服务 B)。它们与日志相关，但提供了关于不同事件发生的上下文的更专门的信息。跟踪在单个程序中很容易理解，其中运行跟踪通常被记录为内存中的调用栈，但跟踪本质上体现的是分布在云上的微服务网络连接图。这使得问题具有挑战性，但也非常重要，因为通常情况下，理解时间依赖现象(例如为什么某个特定资源超载)的唯一方法是理解多个独立工作流彼此如何交互。
退一步看这三种遥测数据，有助于进一步理解设计空间，为此，我们做了四个观察。
首先，遥测数据通常有两个使用场景，大体上可以分为"监控"和"故障排除"。我们以最一般的术语来表示:(a)在一个状态稳定的系统中主动观察问题的告警信号(攻击、错误、故障、过载情况); 与(b)一旦出现潜在问题的告警，仔细观察以确定根本原因并解决问题(修复错误、优化性能、提供更多资源、抵御攻击)。这种区分很重要，因为前者(监控)需要保证最小的开销，最少的人力参与，而后者(故障排除)可能更具侵入性/更昂贵，通常涉及某种程度的人类专业知识。这不是一个完美的区分，大量运维活动发生在中间灰色区域，但了解可用工具的成本/效益权衡是一个重要的起点。
其次，监控和故障排除约自动化越好。首先是自动检测潜在问题的告警，通常包含仪表板，使人们很容易看到模式，并在所有三种数据类型中钻取相关细节。现在越来越多的利用机器学习和统计分析来识别对人类操作者不明显的更深层次的连接，并最终支持闭环控制，其中自动化工具不仅能够检测问题，而且能够发出纠正错误的控制指令。基于本章目的，我们给出了前两个(告警和仪表板)的例子，并声明后两个(分析和闭环控制)超出了本书范围(但可能作为后续章节概述的遥测数据的应用程序运行)。
第三，从生命周期管理的角度来看，监控和故障排除只是测试的延续，区别只在于是工作在生产负载而不是测试负载下。事实上，同一套工具可以用在开发与生产边界的任何一边。例如，任何一个对程序进行过剖析的人都会认识到，在开发过程中，跟踪是一个非常有价值的工具，既可以追踪错误，又可以调优性能。同样，人工端到端测试可以通过触发早期预警警报为生产系统提供价值，在处理有问题的故障模式时，这可能特别有帮助。
最后，由于各个子系统收集的指标、日志和跟踪都有时间戳，因此可以在它们之间建立相关性，这在调试问题或决定是否需要发出告警时很有帮助。在本章的最后两节中，我们将举例说明这种遥测范围的功能在今天的实践中是如何实现的，并讨论产生和使用遥测数据的未来。
6.1 指标和告警
我们从指标开始，流行的开源监控堆栈使用 Prometheus 来收集和存储平台和服务指标，Grafana 用来可视化指标，Alertmanager 用来通知运维团队需要注意的事件。在 Aether 中，Prometheus 和 Alertmanager 被实例化在每个边缘集群上，Grafana 的单一实例在云中集中运行。网上可以找到每个工具的更多信息，所以我们只关注(1)单个 Aether 组件如何适配这一堆栈，以及(2)这个堆栈如何以特定方式对服务进行定制。
延伸阅读:
6.1.1 导出指标
各个组件通过实现 Prometheus 导出器(Prometheus Exporter) 来提供组件指标的当前值。通过 HTTP 查询组件的 Exporter，使用简单的文本格式返回相应的指标。Prometheus 定期抓取 Exporter 的 HTTP 端点，并将指标存储在其时间序列数据库(TSDB, Time Series Database)中，以便进行查询和分析。许多客户端库都可以用于调用代码，以生成 Prometheus 格式的指标。如果组件指标以其他格式输出，那么通常可以使用工具将其转换为 Prometheus 格式并导出。
YAML 配置文件指定了 Prometheus 要从中提取指标的一组 Exporter 端点，以及每个端点的轮询频率。另外，基于 Kubernetes 的微服务可以通过服务监视器(Service Monitor) 自定义资源描述符(Custom Resource Descriptor, CRD)进行扩展，然后 Prometheus 查询该描述符以了解微服务提供的任何 Exporter 端点。
除了基于组件的 Exporter 外，每个边缘集群还定期测试端到端连接(针对各种端到端定义)。一个测试是判断 5G 控制平面是否工作(即边缘站点是否可以连接运行在中心云中的 SD-Core)，另一个测试是判断 5G 用户平面是否工作(即终端是否可以连接互联网)。这是一种常见模式，即单个组件可以导出累加器和其他本地变量，但只有"第三方观察者"才能主动测试外部行为，并报告结果。这些例子对应于第 4 章图 19 中最右边的"端到端测试"。
最后，当一个系统在多个边缘站点上运行时，就像 Aether 的情况一样，有一个设计问题，即监测数据是存储在边缘站点上，只在需要时才慢慢拉到中央位置，还是在产生后立即主动推送到中央位置。Aether 同时采用了这两种方法，取决于所收集数据的数量和紧迫性。默认情况下，由 Prometheus 本地实例收集的指标留在边缘站点上，只有查询结果被返回到中央位置(例如，由 Grafana 显示，如下一小节所述)，适用于高流量和很少查看的指标。一个例外是上面提到的端到端测试，结果被立即推送到中央站点(绕过本地 Prometheus)，因为数量不多，而且可能需要立即关注。
6.1.2 创建仪表板
Prometheus 收集的指标可以用来可视化 Grafana 仪表板。在 Aether 中，意味着在中心云中作为 AMP 的一部分运行 Grafana 实例将查询发送到中心 Prometheus 实例的某个组合以及运行在边缘集群上的 Prometheus 实例的一个子集上。例如，图 25 显示了 Aether 边缘站点集合的摘要仪表板。
图 25. 显示 Aether 边缘部署状态的中央仪表板。
Grafana 为最常见的指标集提供了一套预定义的仪表板，特别是与物理服务器和虚拟资源(如容器)相关的仪表板，但也可以进行定制包含服务级指标和其他特定部署信息的仪表板(例如，Aether 中的每个企业)。例如，图 26 显示了 UPF(用户平面功能)的自定义仪表盘，这是 SD-Core 的数据平面包转发器。该例子显示了站点过去一小时的延迟和抖动指标，底部还有三个折叠的面板(PFCP 会话和消息)。
图 26. 自定义仪表板，显示 SD-Core 组件转发数据平面 UPF 的时延和抖动指标。
简单来说，仪表板由一组面板(panels) 构建而成，其中每个面板都有定义良好的类型(例如，图 graph、表 table、测量 gauge、热图 heatmap)，绑定到某个特定的 Prometheus 查询。使用 Grafana GUI 创建新的仪表板，然后将生成的配置保存在 JSON 文件中。然后，这个配置文件被提交到配置存储库，当它作为生命周期管理的一部分重新启动时，加载到 Grafana 中。例如，下面的代码片段显示了与图 25 中的Uptime面板相对应的 Prometheus 查询。
"expr": "avg(avg_over_time(ace_e2e_ok{endpoint=\"metrics80\",name=\"$edge\"}[$__interval]) * 100)",
注意，这个表达式包括站点($edge)和计算 uptime 的时间间隔($__interval)的变量。
6.1.3 定义告警
当组件指标超过某个阈值时，在 Prometheus 中可以触发告警，通过 Alertmanager 这一工具，可以将告警发送到一个或多个收件人的电子邮件地址或 Slack 频道。
通过定义告警规则(alerting rule) 可以针对特定组件定义告警，该规则调用 Prometheus 查询表达式，每当指定时间段内计算为 true 时，就会触发一条相应的消息，并将其路由到一组接收者。这些规则记录在 YAML 文件中，该文件签入配置存储库中并被加载到 Prometheus(或者独立组件的 Helm Charts 可以通过 Prometheus Rule 自定义资源定义规则)。例如，下面的代码片段显示了两个告警的 Prometheus 规则，其中expr行对应于提交给 Prometheus 的相应查询。
- alert: SingleEdgeTestNotReporting annotations: message: | Cluster {{`{{ .Labels.name }}`}} has not reported for at least 5 minutes. expr: (time() - aetheredge_last_update{endpoint="metrics80"}) > 300 for: 1m labels: severity: critical - alert: SingleEdgeConnectTestFailing annotations: message: | Cluster {{`{{ .Labels.name }}`}} reporting UE connect failure for at least 10 minutes. expr: aetheredge_connect_test_ok{endpoint="metrics80"} < 1 for: 10m labels: severity: critical
在 Aether 中，Alertmanager 被配置为向一组公共接收者发送具有关键(critical) 或警告(warning) 级别的告警。如果需要将特定告警路由到不同的接收端(例如，开发人员为特定组件使用的 Slack 频道)，需要相应改变 Alertmanager 的配置。
6.2 日志
从 Unix 早期开始，操作系统程序员就一直在向 syslog 写入诊断信息。最初收集在本地文件中，如今 syslog 抽象已经通过添加可扩展的服务适应了云环境。今天，典型的开源日志堆栈使用 Fluentd 来收集(聚合、缓冲和路由)由一组组件编写的日志消息，Fluentbit 作为客户端代理运行在每个组件中，帮助开发人员规范日志消息。然后，ElasticSearch 被用来存储、搜索和分析这些消息，Kibana 被用来显示和可视化结果。图 27 显示了一般的数据流，使用 Aether 的主要子系统作为日志消息的说明性来源。
图 27. 日志子系统的日志消息流。
延伸阅读:
