好分期云原生转型下的北极星监控体系

1、北极星监控体系建设背景

在互联网业务场景下，系统稳定性和可用性是至关重要的，任何故障都可能对业务产生严重影响。然而，在这样的环境中，由于业务规模庞大、系统复杂度高，当出现故障时，往往会面临排查问题效率慢的挑战。 传统的监控体系可能无法满足对复杂系统的全面监测和快速问题定位的需求，导致故障持续时间延长，影响业务运营。

主要影响故障排查与恢复效率的因素如下：

• 分布式系统的复杂性： 互联网业务通常采用分布式架构，涉及多个服务、多个节点，各个组件之间相互依赖。当出现故障时，需要跨足多个组件和服务，传统的排查方式往往需要逐个检查，增加了排查的复杂性和耗时。

• 数据量庞大： 互联网业务产生的监控数据、日志数据庞大且复杂，传统方式下人工分析和筛查这些数据非常耗时。人工排查往往需要大量的时间和人力，容易遗漏关键信息，延长了故障解决的时间。

• 实时性要求高： 互联网业务对系统的实时性要求极高，任何故障都可能导致用户感知到的服务不可用。传统的手段往往需要较长的时间来定位问题，无法满足实时性要求，从而影响业务的连续性。

• 缺乏自动化支持： 传统方式下，排查问题主要依赖人工经验和手动分析，缺乏自动化工具的支持。随着业务规模的扩大，手动排查的效率显著降低，同时也容易受到人为因素的影响。

• 缺乏历史数据分析： 传统方式下对历史数据的分析能力有限，难以识别潜在的系统趋势和周期性问题。这使得排查过程缺乏对系统整体性能演变的深刻理解，导致故障定位不够全面。

• 不足的可视化支持： 传统的排查方式通常缺乏直观的可视化工具，使运维人员难以全面了解系统运行状态。可视化是快速定位问题的重要手段，而传统方式的缺乏可能导致问题被忽略或定位不准确。

随着好分期业务的快速发展，我们的服务架构也持续迭代升级，由传统的软件单体应用架构，升级到微服务架构，从单一单元拆分成相对小的、独立的服务，使我们的服务可以更快速的交付，同时降低了单点故障的风险，运维团队也相应的转为 Devops 模式来加速交付效率，提高交付质量。

随着服务规模的增长，架构也更加复杂，生产场景也会遇到前文所述问题的困扰，已有的监控工具缺失严重，功能薄弱，不能有效的快速发现问题或定位问题范围，排查解决问题为“自下而上”的方式，各环节分散排查是否出问题，而缺少精确定位故障发生原因的手段和工具。

与此同时好分期服务正在进行云原生、混合云架构的升级，通过多机房、混合云部署模式，进一步提升架构的容灾能力，同时借助云计算平台弹性伸缩能力，更好的平衡负载能力、安全性和成本。

随着公司业务和技术的发展，系统的复杂性提高，传统的监控方式已无法满足对系统全面、实时监控的需求。所以我们需要建设北极星指标监控体系，通过全面检监测、智能分析、实时响应等功能，为复杂的混合云微服务环境提供更高效的故障排查和性能优化手段。

2、北极星指标体系

2.1 北极星指标定义

北极星指标(North Star Metric), 也叫做第一关键指标 (One Metric That Matters), 是指在产品的当前阶段与业务/战略相关的绝对核心指标。可以帮助团队评估产品的成熟度及平台化用户规模，验证产品是否达到 PMF 阶段，在团队内拉齐当前产品迭代的核心目标认知。

2.2 北极星指标的作用

• 指引未来： 能够清晰地表明产品要传达的功能点与产品未来阶段需要优化的方向。
团队协同： 能够让其他产品组的同事知道当前产品组内的实时进展，便于跨组的资源协同。

• 结果导向： 能够使我们对结果负责，即以业务效果/结果而不是业务数量来衡量团队的工作质量。

2.3 北极星指标的特性

• 能够反映用户从产品获得核心价值

• 能否为产品达到长期商业目标奠定基础

• 能否反应用户活跃程度

• 指标变好，能否预示公司在往好的方向发展

• 是否简单，直观，容易获得，可拆解

• 是否是先导指标，而非滞后指标

一些北极星指标示例：

2.4 北极星指标的异常才是真的“故障”

尽可能建立业务北极星指标实时采集，围绕这些指标建设更实时、更多维度的监控策略，当业务受损时第一时间感知，能够最大限度提升故障发现速度。当底层系统异常而业务并未受损时，控制告警范围和优先级，仅从解决隐患的层面去避免升级成为故障，也可以减少无用告警的噪音，避免真正的故障事件被噪声淹没。

2.5 从影响到根因，从局部到全局，自上而下，层层下钻

当故障发生时，通过北极星指标的异常，能够第一时间明确故障影响，对损失做出有效的评估，但进一步定位引发故障的根因，需要对该业务指标进行逐级拆分和下钻，这需要我们建立自上而下的体系。

在明确北极星指标的同时，需要明确影响该指标的业务、服务，并且需要将该关联关系通过系统管理，能够系统里显性展现，同时也可以借助于 CMDB 资源管理系统，将服务所依赖的其他组件、用到的各类资源，也维护到上述关联关系中。这样，在北极星指标异常构成故障时，可以通过该关联关系，去排查影响该指标的服务状态，明确故障范围，也可以进一步检查异常范围所依赖的服务和组件，逐级下钻，最终定位到引发异常的真正原因。

3、Zeus 运维平台监控系统

3.1 Zeus 监控系统架构

基于北极星指标体系的思想，我们以夜莺监控系统作为基础进行二次开发，结合已经建成的服务树、CMDB 系统，建设了适合微财产品技术的 Zeus 平台监控系统。经过对比选型，我们选定 Victoria Metrics 作为时序性数据库，并对数据存储做了多副本冗余以解决数据安全和持久化需求，并支持更大的指标写入与读取的并发。

Zeus 运维平台使用 go 语言自研了统一的 Agent，用于作业批量下发执行、服务器初始化与服务器信息上报，监控系统系统级别指标仍然使用该统一 Agent，我们对 Agent 做了资源 限制和自动恢复等机制，整合了所有运维的批处理操作，仅有一个 Agent 即可一站式解决，降低了维护复杂度也提升了稳定性。同时引入了夜莺系统 Categraf 方式，All in one 的解决了业内常见的各类中间件指标采集，代替了维护多套 Prometheus Exporter 的方案。

我们为业务提供了标准化、规范化的 SDK，方便业务快速接入自己的项目，自主上报各类指标。也开放了 Http 接口，方便公司已有的各类监控组件将自己的数据汇总到 Zeus。系统的架构如下：

3.2 接入指标类型

当前已完成资源层（IaaS 层），平台层（或称组建层，PaaS 层），应用层（SaaS 层）指标采集接入，各级别监控指标包含：

IaaS 层：物理机、虚拟机的 CPU、内存、磁盘利用率，读写 IO、网卡流量等基础系统层指标。 由 Zeus 统一 Agent 采集。PaaS 层：容器节点状态、资源利用率，通过 Prometheus 主动拉取。Mysql、Redis、Kafka、RabbitMQ、ES、Mango 等集群各类指标。由 Zeus 统一 Agent 通过 Categraf 方式一站式采集。SaaS 层：各种由业务埋点上报指标，也可以包含技术指标，由业务通过统一 Prometheus-Client SDK 上报。也可以接入各类监控指标采集系统通过 Http 接口上报的自定义指标。

3.3 指标与服务关联

围绕服务树和 CMDB 资源归属，可以建立起所有指标与服务或者业务的关系，我们需要明确以下规范：

我们已经在服务树中定义了任何业务或服务节点的唯一标识 nid，所有采集或主动上报的指标，需要符合数据格式规范的同时，必须声明该指标所属服务树节点唯一标识 nid， 服务节点唯一标识查找方式如下：

通过 nid 去查询该节点所关联的指标，就可以快速确定不同层级指标的关联关系，如：

直接可以在服务树监控信息，看到已经关联到该节点的各层指标监控图，业务服务状态一目了然。

3.4 故障的定位

通过上述关联，已经可以快速定位任何一个节点的异常状况，是由哪一层哪一个指标异常引起，而更高层级节点，会逐步收敛指标明细程度，直到最高公司层级，仅需要专注公司业务最重要的“北极星指标”即可，如下图（当前未完成全部指标采集，仅展示已接入业务）

任何上层指标的异常，会导致该节点状态异常，会在服务树节点上由绿色的健康状况，变化成为橙色的 Warning 或红色的 Alarm 状态，方便技术与业务同学快速感知异常信息，只需要逐级展开服务树节点，就可以层层下钻，逐步确定故障范围，排查故障原因。示例如下：

可以看到，上层节点服务异常，通过下钻，可以快速的定位到该业务某些接口流量突增导致接口响应时间上升，问题定位快速直接。仍然可以继续展开，精确定位到异常的具体 APP，和该 APP 所依赖的底层数据库等组件的负载水位信息。

3.5 监控策略与告警

在 Zeus 运维平台， 可以直接打开监控平台独立的页面，根据登陆人的角色，可以看到自己拥有权限的服务树节点对应的监控页面，即可去修改监控阈值，或增加自定义监控项：

我们会逐步完善监控的标准化模板，力求做到新服务上线，即可自动配置个层级的基础监控，基本完成一个服务所需要的各类基础监控，包含但不限于：资源利用率、水位线、重要接口的状态码与响应时间、所依赖的数据库、Redis、消息队列等组件状态等等。通过规范化自动化最大化降低研发在监控层面的投入，仅需要去特殊定制额外需要关心的自定义监控项即可。

同样，在监控平台页面可以去查看任何节点的异常告警信息。不同级别的告警，就会在服务树上表现为不同颜色的节点健康状态。并且我们已经在服务树上将组织架构的人员信息和角色做了规范化管理，不同级别的告警，也会根据其重要程度，发送给应该通知的人。后续会上线告警回调机制，也就是告警需要值班人认领，超时无人认领的高级别告警，会逐级升级通报给服务树上层和更高权限的角色，直到告警被响应或恢复，做到重要遗产不漏报。

4、监控系统的规划

目前 Zeus 监控系统仅完成一期上线，在已有的功能完善、新功能开发、稳定性优化等方面，仍然需要大力投入，持续建设和运营，在接下来主要会围绕以下几个方面推进。

4.1 进一步完善资源归属

当前各类中间件的归属信息，梳理的不够精细，大部分数据库集群是使用信息，仅能精确到实例所归属的业务这一层级，在服务树上表现为关联到第三层级，而问题的精确定位和告警，需要业务配合，将各自服务所使用到的各类组件信息补充完整，我们会提供方便汇总上述信息的工具，也会通过 Agent 主动探测资源归属的信息，将更加精确的关联关系信息，管理到 CMDB 系统中，全面打通监控体系。

在深度信息补充的同时，也需要进一步推动完善广度的拓宽，也就是需要建立更多“北极星指标”的实时采集，和配套的复杂的监控机制。当前仅仅在部分业务进行了试点应用，后续需要推广到整个技术体系，这需要所有产研同学的配合和各业务负责人的支持。

4.2 赋能 SRE 稳定性优化

接下来运维同学会逐步转型 SRE 方向，去接收和负责部分业务的稳定性指标与稳定性优化工作，围绕稳定性提升，可以分为故障前、故障中、故障后三个阶段。监控系统在故障前的感知，故障中预案有效执行，以及故障后数据分析都有着非常重要的作用，所以监控系统要持续建设以下几个重要功能，赋能 SRE，助力业务稳定性优化。

4.2.1 监控策略继承

规范化监控，需要更快速方便的管理，借助服务树的继承结构，可以通过调整上层节点的监控项，让全局或自定义范围的监控策略统一调整，更加便于告警策略的统一规范化管理。

4.2.2 告警回调与逐级通报

重要告警需要值班人或负责人快速认领，我们需要将这个流程产品化，而形成机制，避免因人员失误导致重要故障无感知或遗漏。借助于服务树层级和人员角色信息，监控系统可以做到重要告警信息无响应时，逐级升级通报，直到被认领或问题恢复。

4.2.3 告警历史数据分析

告警信息内，包含了一个故障事件的发生、止损、恢复等关键信息，而这些信息的组合就是稳定性优化最重要的切入点：MTTR（平均恢复时常）。所以监控系统可以讲告警信息提取，将故障信息的管理更加完整和高效。

4.2.4 变更可观测 – 事件墙

在稳定性优化方面，也存在着 80%的故障是由于变更引起的“二八原则”，所有对生产环境进行变更的事件对服务造成的影响快速体现，是变更可观测方向持续提升和优化的能力，Zeus 监控系统会提供统一的事件上报规范，接入各类生产环境变更事件的关键信息，在监控图中打标显性提示。当一个指标异常与一个变更事件事件重合，即可快速执行回滚操作，这在稳定性优化方面是非常有用的帮助。

4.2.5 预案自动策略触发

类似于事件墙对于回滚预案的触发，监控告警可以作为预案执行的触发条件，Zeus 运维平台后续也要在预案管理和自动化执行方面，与监控系统结合，来建设自动化预案的能力。

4.3 为成本运营系统提供数据

任何业务都需要持续的做有效的成本控制运营工作，技术侧也需要不断的优化资源使用率，精简业务架构来达成技术成本的有效控制。未来 Zeus 平台会建设一套成本运营系统，来达到成本精确分摊归属，以成本云营为抓手，推动成本控制和预算预估的工作。

当前指标体系划分三个层级，即资源层（IaaS 层）、平台层（PaaS 层）、应用层（SaaS 层），这在全新设计规划的成本运营系统是相匹配的，这三个层级在成本运营的方向上是上游与下游的关系，也是供给方与需求方的关系，各层级的成本分开计算，分别计算其上游的成本输入和下游的成本输出，最终得到各层级的入账减去出账的剩余利润。在做成本优化时各层级“自负盈亏”才能做到有效的优化工作。 而计算每个成本单元的出入账目时，最重要的就是资源的用量，这些用量信息，是需要借助监控系统来实时采集上报的。

5、总结

为了解决在线业务发生故障时无法快速感知、快速定位以及恢复的问题，我们围绕“北极星指标”体系，设计了一套自上而下，层层下钻的监控体系，该系统与已经建设的服务树、CMDB 系统为基础，基于开源夜莺监控系统，进行了大量二次开发将系统进行结合，并完成一期的功能测试和上线，已经接入到 Zeus 统一运维平台。

新的监控系统已经可以支持业务指标与服务、服务依赖的其他服务和在线组件关联，也可以通过服务树对上层业务指标进行下钻，逐步定位问题根因，基本实现了“北极星指标”体系的设计。

后续还需要进一步拓展接入的业务数、北极星指标数，以及进一步精细各类资源的归属信息，来提升系统在稳定性优化方向上贡献的价值。同时后续也会持续建设更多新的功能，在成本运营方向提供数据支持。

作者介绍

单连斌，微财数科 运维开发资深工程师

王学森，微财数科 运维负责人

吴迪，微财数科 副总裁