可观测性体系建设五步心法：明业务、立规范、采数据、显特征、获洞见

笔者做监控 11 年，在可观测性领域创业 4 年，与各类客户沟通较多，发现很多企业想要建设可观测性体系，但是不得章法，我把整个建设过程做了一个简单总结，梳理一下其中的脉络，希望对你有所启发。

整个可观测性体系建设，我总结为五个步骤：明业务、立规范、采数据、显特征、获洞见。

核心要点

• 可观测性建设不要从工具开始，要先从业务目标、北极星指标和关键用户路径开始。
• 规范越早建立，后面批量采集、展示、告警、复盘和知识复用越省事。
• 采数据不是“能采多少采多少”，而是围绕未来排障价值、成本和统一规范采集指标、日志、链路、事件、Profiling。
• 显特征的目标，是把海量观测数据组织成趋势、聚合、关系和异常模式。
• 获洞见的目标，是形成止损依据，帮助团队知道故障方向、影响范围和下一步动作。

下面挨个说明。可观测性体系涉及的内容太过驳杂庞大，本文更多是说明思路，不涉及实操。

明业务

首先，要把您的业务梳理明白。理清楚您的最终业务目标和指标，通常称为北极星指标，举例：

• 电商系统：订单量、订单金额等
• 游戏：在线人数、交易金额等
• 视频播放：点击 Play 的次数等

简单而言，就是把老板层面（全公司层面）关注的指标理清楚，如果这些指标出现异常（比如下跌），可能就是重大业务故障，SRE、DEV 都要及时介入处理。

北极星指标通常是一些结果性质的指标，如果要做的更精细化，还应该拆解出过程指标，比如电商系统的订单量，我们就要分析，哪些关键环节影响订单量，哪些过程指标可以衡量客户主流程（下订单）健康与否，比如：

• 客户登录次数、登录失败次数
• 浏览商品的次数、浏览商品的响应速度
• 添加购物车的次数、成功率、延迟
• 结算次数、结算失败次数、结算延迟
• 等等

理清楚这些关键的结果指标和过程指标之后，进而从技术角度，就要梳理看哪些系统、模块影响了这些指标，这些系统就应该定义为 P1 级别的系统，重点保障。这些 P1 级别的系统的 SLI、SLO 数据就要重点管理起来。

这一步的本质，是先定义“什么叫业务真的出问题”，再讨论监控哪些技术对象。如果业务指标没有定义清楚，后面再多 CPU、内存、接口、日志和 Trace，也很难判断事故优先级。

立规范

如果公司较小，微服务数量 20 个以下，机器只有几十台，规范与否大家感受不深。如果微服务上千、机器过万，那感受就深了。如果规范做得好，就可以批量干很多事情，很多知识也都是复用的。

从可观测性角度，可能需要立规范的一些点：

• 统一使用哪个指标、日志、链路追踪的系统
• 日志打印方式
• 各类观测数据的标签
• 微服务自身暴露哪些可观测性数据，以及如何暴露
• 变更事件如何统一收集呈现
• SLI、SLO 数据统一梳理、呈现、告警
• 告警规则的制定原则、分派规则
• 数据协议规范格式
• 等等

立规范这个事情，做得越靠前，后面越省事，高阶架构师做过很多横向的体系设计，通常会把可观测性这摊事做得比较靠前，因为系统的可观测性和系统的可用性、鲁棒性类似，都是系统必须要关注的特性之一。

规范不是为了写文档好看，而是为了让系统变多、团队变多、数据变多以后，仍然可以批量治理。没有统一标签、数据协议和告警原则，后面做大盘、订阅、聚合、SLO 和故障复盘都会变成手工活。

采数据

各类观测数据（指标、日志、链路、事件、Profiling）的采集，要按照前面制定的规范走，要考虑成本、考虑数据未来的价值。对于各类中间件、数据库，因为都是通用产品，采集哪些指标、日志，重点关注哪些数据，在业内通常可以找到最佳实践，而对于公司自研的那些微服务，就稍微麻烦一些了。需要：

• 梳理自身业务，确定暴露哪些数据才能方便未来排查问题
• 从上到下推动埋点，否则难以落地

采数据最容易走偏的地方，是只看“能不能采到”，不看“以后能不能用上”。真正要优先采的，是能帮助判断业务影响、定位系统对象、还原变化过程、解释用户体验的数据。

显特征

这里的特征，指的是数据特征。海量的零散的观测数据，人类是没法一条一条查看的，要想从数据中获取有价值的信息，很难。需要我们有效组织数据，从中发现一些特征规律。举一些例子：

• 把指标数据放到折线图里，可以看到趋势特征，可以看到最大最小值，可以看到哪个时间有突变，就是典型的从数据中提取特征
• 把较大量的日志，通过聚类算法计算日志 pattern，比如 10000 条日志，最终提取出 20 条 pattern，这样用户更容易理解分析
• 把告警事件按照标签做聚合，通常是按照告警规则标题做聚合，或者按照 region、severity、env、service 等做聚合
• 把近期的变更事件和关键告警放在一个图上，可以从时间维度较为容易分析告警和变更的关系
• 把微服务按照层级聚合为子系统，然后聚合为系统，发生故障之后，就可以方便知道哪些系统受到影响，确认影响范围
• 等等

从具体工具上来看，比如 Grafana、Flashcat 等，都是有力工具，帮助用户快速发现数据特征。

显特征不是简单把数据画出来，而是把数据组织成可决策的信息。趋势图、聚合结果、拓扑关系、变更叠加、异常卡片，都应该服务同一个目标：让值班人少翻数据，多看到方向。

获洞见

可观测性体系要解决的最大的场景需求，就是故障定位，进而执行止损动作。通过数据特征，我们最终要得到的洞见，就是“止损依据”！用户通常需要建立各种视图，通过视图分析数据特征，进而综合分析，得到“止损依据”。

比如用户访问电商 App 延迟较高，我们可能要分析：

• 容量水位数据
• 变更数据
• 依赖的服务的健康状况
• 基础网络
• 等等

通过特征分析，来确认对应的方向是否有问题，综合多个方向的分析结论，最终得到故障的原因，知道原因了也就知道如何止损了。

这里的洞见不是玄学，也不是 AI 自动给一个结论。它来自已经组织好的数据特征：哪些指标异常、哪些服务受影响、近期发生过什么变更、依赖对象是否健康、影响面是否扩大。洞见最终要落到止损动作上。

FAQ

可观测性体系建设应该先买工具还是先梳理业务？

先梳理业务。工具只能承载数据和流程，不能替团队定义哪些业务指标异常才算真故障。业务目标、北极星指标和 P1 系统不清楚，工具接入越多，噪音越多。

指标、日志、链路、事件和 Profiling 是否都要一次性建设？

不建议一开始追求全量。可以围绕核心业务链路优先建设最能支撑故障发现和定位的数据，再逐步补齐。采集动作要考虑成本和未来排障价值。

SLI/SLO 应该放在哪一步？

SLI/SLO 的目标来自“明业务”，口径依赖“立规范”，数据来自“采数据”，展示和告警依赖“显特征”，最终服务“获洞见”和稳定性治理。因此它不是单独一步，而是贯穿五步。

总结

本文提纲挈领梳理了可观测性体系建设的五步法：明业务、立规范、采数据、显特征、获洞见。

第一性原理很简单：可观测性不是为了采更多数据，而是为了在业务异常时更快判断影响、更快定位方向、更快形成止损依据。只能算是一个梗概，希望对你有所帮助。我们创业这些年，一直聚焦在监控、可观测性领域，深知这个领域的驳杂，如果你需要乙方协助构建整套体系，欢迎联系我们。

本文作者秦晓辉，监控领域从业 11 年，Open-Falcon、Nightingale 开源项目创始人，极客时间专栏《运维监控系统实战笔记》作者，现为 Flashcat 联合创始人，创业中。