服务状态页：一页看清全部健康度

我们内部有六个系统：门户、订单、库存、报表、消息、文件。每天早上八点四十，运维要挨个登录六个后台看一遍，看完大概十分钟。有一次消息服务的消费队列积压了四个小时，六个后台都显示运行中，因为进程没死，只是消费不动。

那次是财务先发现的，问为什么出库通知没发出去。运维去查，进程在、端口通、CPU 百分之十几，一切看着正常。顺着消费位点看下去，才发现消费线程全卡在一条慢查询上，队列已经堆了八万多条消息。

那之后我做了个状态页，一屏放六个系统，每个系统三层：入口是否可达、核心依赖是否正常、业务指标是否在范围内。用颜色表示状态，点进去看细节。做完之后，早上的巡检从十分钟压到一分钟，积压那类问题能在半小时内被发现。

一、为什么健康度看不全

1.1 指标散在六个地方

每个系统有自己的监控面板，指标命名不一样，阈值也不一样。要看整体，得开六个页面，记六套口径。人在这种切换里很容易漏看，尤其是早上刚上班，注意力不在细节上。

更麻烦的是口径不一致。订单系统的成功率按分钟算，报表系统按五分钟算，两个页面上都写着九十九，实际含义不同。想横向比一下谁更差，比不出来。状态页先要做的是把口径统一。

1.2 监控了机器，没监控业务

CPU、内存、磁盘这些指标反映的是资源，不是业务。进程活着、端口通着、CPU 不高，业务可能已经卡死，比如消费线程全部阻塞在一条慢查询上，或者定时任务卡在锁等待里。

这类故障资源指标完全正常，只有业务指标能看出来。判断业务指标的方法很简单：问一句用户现在能不能完成平时每天都要做的那件事。能完成就是绿的，完不成或者很慢就是黄的或红的。

1.3 告警太多反而没人看

一开始我们把所有指标都接告警，一天两百多条，值班的人看到红色已经麻木。有个真实的例子：某天上午发了三十七条告警，其中三十六条是同一个磁盘使用率的重复通知，真正的那一条被埋在里面，两小时后才被翻出来。

后来做了收敛：只有状态页变红才发告警，黄色只记录。告警数量降到一天十几条，每一条都有人处理。收敛的前提是状态页的判断要准，判断不准，收敛就等于漏报。

二、状态页的信息结构

2.1 三层结构

每个系统分三层。入口层看网关能不能通、页面能不能打开；依赖层看数据库、缓存、消息这些外部依赖；业务层看这个系统自己的核心指标，比如订单的创建成功率、库存的扣减延迟。

三层里任何一层异常，系统整体状态就降级，但降级的程度不同。入口不通是红，依赖挂一个是黄，业务指标越界也是黄。分层的好处是出问题时不用猜，看是哪一层变色，就知道该找网络、找中间件、还是找业务代码。

2.2 三态而不是百分比

健康度用绿、黄、红三态，不用百分比。百分比看着精确，实际问题在阈值难定：九十八和九十九有什么区别，没人说得清，也没人愿意为这个差别定规则。

三态的定义很明确：绿是可用，黄是可用但需要关注，红是不可用或即将不可用。判断标准写在配置里，不靠人现场判断。配置改动要走评审，避免有人为了让页面变绿去调阈值。

2.3 看板配置

下面是状态页的配置片段，定义了系统的三层探针和判定规则。六个系统结构相同，这里只列两个，其余照抄改字段。

page:
  title: 内部系统状态
  refresh_seconds: 30
  stale_after_seconds: 120
  unknown_as: yellow

systems:
  - key: order
    name: 订单系统
    layers:
      entry:   {check: gateway_probe, path: /order/ping, timeout: 3}
      depends: [db_order, cache_order, mq_order]
      business:
        - {metric: order_create_success_rate, op: ">=", value: 0.98, window: 5m}
        - {metric: order_pay_callback_lag_s,  op: "<=", value: 120,  window: 5m}
    rules:
      green:  {entry: up,   depends_failed: 0, business_failed: 0}
      yellow: {entry: up,   depends_failed: 1, business_failed: 1}
      red:    {entry: down}

  - key: message
    name: 消息服务
    layers:
      entry:   {check: tcp_probe, target: mq_broker, timeout: 3}
      depends: [db_message, cache_message]
      business:
        - {metric: consume_lag_s,     op: "<=", value: 300, window: 10m}
        - {metric: dead_letter_count, op: "<=", value: 20,  window: 1h}
    rules:
      green:  {entry: up, depends_failed: 0, business_failed: 0}
      yellow: {entry: up, business_failed: 1}
      red:    {entry: down, business_failed: 2}

配置里两个参数值得单独说。stale_after_seconds 是数据过期时间，超过两分钟没刷新，整页标灰，避免人看着昨天的状态做判断。unknown_as 是未知态的处理方式，默认按黄色，宁可多看两眼，也不要让探针故障变成一个假的绿色。

三、判定规则怎么做

3.1 探活、就绪、业务探针分开

探活只回答进程在不在，就绪回答能不能接流量，业务探针回答核心链路通不通。三者混在一起会导致误判：进程刚启动还没连上数据库，探活通过、就绪失败，状态页应该显示黄色而不是绿色。

分开定义之后，颜色才有意义。探活失败是红，说明进程没了；就绪失败是黄，说明在重启或者依赖没连上；业务探针失败是黄或红，看越界的程度。三种失败对应的处理动作完全不同。

3.2 连续失败才变色

单次探针失败可能是网络抖动，直接变红会造成大量假告警。规则是连续三次失败才降级，恢复要连续五次成功。这两个数字写在配置里，按各系统的稳定性调。

消息服务抖动多一些，用五次和八次；订单系统的探针很快，三次和五次就够。数字不是拍出来的，是从历史告警里回看出来的：把过去一个月的抖动间隔拉出来，取一个能滤掉大部分假告警又不至于太迟钝的值。

3.3 依赖故障的传导

数据库挂了，六个系统都会红，状态页上一片红，反而看不出根因。解决办法是在依赖层标出共同的依赖，同一个依赖导致的红色在上层标注依赖故障，颜色还是红，但文字不同。

这样人一眼能看出是一个原因引起的六个现象，处理的时候直接去修那个依赖，不用逐个系统排查。依赖恢复后，上层的颜色自动跟着变，不需要人工确认。这一条在故障时的价值很高，能省掉半小时的误判。

四、落地与维护

4.1 谁看、多久看

运维每天上班看一次，开发负责人每周看一次趋势。状态页不做成需要盯着的屏幕，挂在内部导航的首页，进系统顺手就看见了。页面上带一个刷新时间，超过两分钟没更新就标灰。

标灰这个细节比想象中重要。探针挂了但页面还在显示上一次的绿色，人会产生错误的安心感。宁可显示未知，也不要显示过期的正常。

页面上还要有一行文字说明判定依据，比如入口探测三秒超时、连续三次失败才降级。写清楚了，别人看到黄色不会以为系统坏了，也知道该不该叫人。这一行字省掉的沟通，比页面配色更有用。

4.2 和告警的分工

状态页负责现在怎么样，告警负责什么时候变了。状态页不推送，告警只推状态变化的边沿，不推持续状态。这样既不会漏，也不会重复。

历史上每次变红的记录都存下来，复盘时能看出一段时间内的稳定性。记录里包含变色时间、恢复时间、当时的指标值。这三样凑齐了，复盘才不用靠回忆。

4.3 数据来源的整合

六个系统的探针输出格式不一致，我们写了一个汇总任务，每分钟拉一次各自的探针结果，归一成统一结构再渲染。这块汇总放在搭贝的定时任务里跑，状态页只读汇总结果，不直接连各系统的数据库。

不让状态页直连业务库，是因为状态页自己不能成为故障源。它一旦对数据库产生压力，就会在系统吃紧的时候添乱。汇总任务失败时，状态页显示未知，不显示上一次的结果。

常见问题

问：状态页的数据多久刷新一次合适？

答：看探针的成本。轻量探针三十秒一次没问题，涉及聚合查询的业务指标一分钟一次更稳。刷新太快会让状态页本身产生压力，太慢会错过短时故障。我们按层设置：入口三十秒，依赖一分钟，业务指标一分钟。

问：业务指标的正常范围怎么定？

答：用历史数据的分位数，不要凭感觉。取过去四周同一时段的成功率，按百分之五和百分之九十五分位定上下界，超出就判黄。新系统没有历史数据时先用宽松阈值，跑两周再收紧。阈值要写进配置，改动留记录。

问：状态页显示绿色，但用户还是报故障，怎么办？

答：说明探针没覆盖到出问题的路径。补探针的原则是按用户实际路径走，不要只测基础的健康检查接口。我们出过一次这样的事：探针只测登录页，登录之后的报表查询挂了，状态页一直绿。之后每个系统都补了一条核心链路探针。

问：多个系统共用一套数据库，状态页怎么避免重复告警？

答：把共用依赖抽成独立项，各系统引用同一个依赖标识，判定时先看依赖状态再看自身。依赖变红时，上层只记录不单独告警，由依赖本身的告警负责通知。页面上仍然全部标红，保证能不能用的判断不缺信息。