一、前言

1. 初识系统可观测性

在计算机科学领域，可观测性 ( Obervability ) 指的是通过检查系统输出评估系统内部运行状态的一种能力。假设一个系统，能够通过其输出数据推测内部运行状态，则可称之为可观测的系统。

可观测性与功能性 ( Functionality )、可用性 ( Availability ) 、可测性 ( Testability ) 等相类似，是评估系统质量的重要标准之一。

这个术语似乎最近几年才开始流行，实际它源自于几十年前的控制理论 ( Control Theory )。现在被广泛应用于分布式系统设计与实践中，用以追踪问题根因、提升软件多方面表现。

2. 指标，可观测性重要一环

通过上文，我们知道系统可观测性主要通过其输出的数据实现。经业界长期实践总结，该部分数据中日志 ( Log )，追踪 ( Trace ) 和指标 ( Metrics ) 的价值与意义受到广泛重视与认可。

日志与追踪的重要性无需赘述，本文重点关注指标。

指标是量化评估的标准。作为工程师，每天都会与许多指标打交道，无论是产品业务层面的页面访问次数、日活跃用户数、用户全生命周期价值、投资回报比等，还是系统层面 CPU 使用率、接口平均响应时间、P99 等。

这些指标为架构决策、技术选型、系统设计、故障定位提供了重要的量化数据依据，有效推进着系统演进，为产品和业务提供更优越的服务。

3. 行业发展趋势

如何采集、加工、存储、展示指标，在工程实践上方法众多。值得注意的是，伴随分布式和云原生被广泛接受，业界已逐渐沉淀出一些约定俗成的最佳实践。比如 Prometheus 生态，和受 Prometheus 生态启发孵化诞生的 Open Metrics ，这些项目已被 CNCF 采纳，它们定义了大规模云原生分布式系统下指标建设标准并提供相应的解决方案。

二、回到问题

1. 没有银弹，通用方案的“盲区”

出于企业规模、技术风格、资源成本等不同因素考虑，架构师通常会为当前技术团队选择最适合自身的指标解决方案。比如 Google Monarch、美团 CAT 或者开源 Prometheus 生态等等。

我们 B 站游戏平台（下述简称平台）服务端主要采用 JAVA 技术栈，结合自身需要选定了 CAT + Prometheus 生态作为指标解决方案。该套方案为我们提供对 Tomcat、JVM、Container 以及其它标准通用组件的指标采集与监控，满足了我们大部场景下的诉求。但对于业务逻辑模块的指标与监控，没法通过开箱即用方法包办，原因也很简单，业务逻辑模块不同于 Tomcat、JVM 等标准模块，没有 IEEE 或者 JCP 这样的组织来定义标准与规范，每家企业的实现都高度定制化。这部分指标建设必然需要开发团队自行定义与实现。

三、解题思路

1. 确定监控指标

接下来，将以我们实践的一部分向大家分享，如何从无到有解决业务指标监控问题。在开始前，首先要确定需要监控哪些指标。

着眼业务，平台核心产品之一是 SDK , 开发者通过在游戏内集成 SDK 快速让游戏具备账号登录、支付等能力，从而降低开发难度，节省时间专注于游戏内容研发，为玩家提供更丰富游戏体验。抽象关系如下图所示。

可以看出，想要为玩家提供最佳游玩体验，不仅需要游戏开发者提供优质内容，也依赖平台服务稳定性。为此我们需要为核心服务设计唯一关键指标 ( OMTM ) , 用以监控和提升服务质量。

预期目标如下：

我们期望通过监控不同核心服务的流量 ( QPS ) 与成功率指标评估服务质量。

当流量稳定且成功率符合预期 SLA 时，我们有信心相信线上服务是稳定的；当成功率低于预期时，一定是哪些地方出了问题，可能是一次发布引入了 BUG，可能是中间件故障等等。

四、工程实践

现在开始着手实现，我们以登录服务指标建设为例，实现工具为 Prometheus 生态。

1. 指标设计

(1) 登录流量 ( QPS )：   

- 定义：每秒用户登录请求数量   

- 埋点：Prometheus Counter 计数器   

- 算法：PromQL Rate ( 登录请求数量 ) [ 时间窗口 ]

(2) 登录成功率：   

- 定义：每秒用户登录成功数量占比   

- 埋点：在上述埋点基础上，添加用以标示成功或失败的 Label 即可，无需单独埋点   

- 算法：PromQL Rate ( 登录成功数量 / 总数量 ) [ 时间窗口 ]

需要额外注意的是，因为 Prometheus 采集间隔通常是 1 到 2 分钟，同时又因 Rate 函数计算的是时间窗口内复数采集点增长率的平均值，导致最终展示指标会比较平滑。如果对于指标准确度与实时性有更高要求，可以考虑缩短 Prometheus 采集间隔或采用其它如 Kafka + Flink 等实时计算工具采集与计算指标，当然这样成本与复杂度也会随之升高，需要根据团队实际需要作出妥协。

2. 代码埋点

埋点伪代码如下：

测试 /metrics Endpoint 结果：

到此，埋点结束，发布至生产环境后，Prometheus 将通过 B 站内部服务发现机制感知应用启动，并周期拉取 /metrics endpoint 数据存入其时序数据库中。

3. 仪表盘初始化

新建一个新的仪表盘 ( Dashboard )，创建新面板 ( panel )，设置 PromQL 查询语句，并调整排版。

设置 PromQL 查询语句

设置带副坐标系面板

通过 Grafana 图形化工具，将登录流量与登录成功率通过主副坐标系形式复合展示在同一个面板中，相较独立展示信息密度更高，也更美观。

最终效果如下：

4. 报警

报警方案有许多，可以使用 Prometheus 自带报警能力，或其它工具与 Prometheus 配合。工具区别不影响底层逻辑，它们都是以 Prometheus 作为数据源，周期性将 PromQL 计算值与预设 SLA 值做对比 ，当超过或者低于某个阈值时通过触达手段通知工程师。在 B 站内，我们使用基础架构部门提供能力更为强大的 HawkEye 平台统一管理报警策略，最终效果如下。

5. Oncall 机制

完善报警机制后，我们针对不同服务状态：健康、异常、灾难设置了相对应的处理流程。

- 健康状态：服务稳定不影响用户，报警可从容处理，按 SOP 定位、排障、验证，最终关闭流程。

- 异常与灾难状态：服务不稳定已经影响用户，立即按 SOP 操作进行主动失效转移，将故障可用区登录流量引导至另一稳定可用区，再进行定位、排障、验证，回导流量，最终关闭流程。（登录服务作为核心服务，拥有 HA 设计，采用两地三中心部署模式，非本文重点不做细节描述）

至此，我们实现了登录服务中核心登录业务模块指标的监控，并以此为基础，完善更多元指标体系的建设。

五、未来展望

 1. 基于指标的自动化机制建设

实际上，B 站内部已经大量利用量化指标的变化驱动各种自动化机制。如基于不同硬件指标 (CPU/内存/带宽) 的弹性扩缩容机制。大大减少工程师维护工作量，同时也进一步提升了系统弹性与稳定性。

平台也计划通过业务指标的变化去驱动故障转移、根因分析、自动巡检、集成测试等机制，进一步提升整体服务稳定性与质量。

2. 开放指标追求更高服务质量

目前，国际一流互联网企业比如 Google、Apple 等都将其核心服务指标公示在官网上。这是一种对于自身服务的高度自信，同时也反向鞭策其内部工程师不断追求更高的服务质量。相信国内大厂也会逐步跟进，不断驱动行业整体服务质量的提升。

六、参考文档

- https://learning.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch01.html

- https://sre.google/books/

- https://faun.pub/devops-meets-observability-78775c021b0e

- https://www.splunk.com/en_us/data-insider/what-is-observability.html

- https://en.wikipedia.org/wiki/List_of_system_quality_attributes- https://peter.bourgon.org/blog/2017/02/21/metrics-tracing-and-logging.html

- https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md