Awesome Architecture

简体中文

English

简体中文

English

外观

32 · 可观测性与可靠性技术栈选型 ​

一句话点题:可观测性(Observability)不是装一堆监控大屏,而是在系统出问题时,你能不能用证据回答:谁受影响、哪里变慢、为什么变慢、该不该叫醒人。可靠性技术栈选型,是在给线上系统装神经系统和免疫系统。

🧰 技术栈选型篇第 6 章 · 本章只练一件事

31 章 讲怎么部署。本章讲上线以后怎么知道系统是不是健康,以及不健康时怎么收场。不要从 Prometheus、Grafana、ELK、OpenTelemetry 这些名字开始,要从 SLO(服务等级目标)开始。

开场:监控和可观测性不是一回事 ​

Monitoring(监控)回答的是:

我提前知道要看什么,现在它有没有越线?

例如 CPU 超过 90%、接口错误率超过 5%、队列积压超过 1 万。

Observability(可观测性)回答的是:

我不知道问题会从哪里冒出来,但系统留下的证据够不够我追下去?

例如某个用户下单慢,请求穿过网关、订单、库存、支付、第三方接口,到底卡在哪一跳?是某个租户、某个版本、某个可用区,还是某个数据库索引?

**判断要点:**小系统靠监控也能活;分布式系统只靠监控会瞎。服务越多、调用链越长、版本越频繁,越需要可观测性,而不只是更多仪表盘。

一、从 SLO 倒推,别从工具倒推 ​

可靠性技术栈的第一步是定义三件事:

   SLI(Service Level Indicator,服务等级指标)
      → 你测什么:成功率、P99 延迟、错误率、可用性?

   SLO(Service Level Objective,服务等级目标)
      → 你内部承诺做到多少:99.9% 请求 < 300ms?

   Error Budget(错误预算)
      → 允许失败的额度:预算没烧光,可以继续发版;烧光了,先修稳定性

这套语言的价值,是把「系统稳不稳」从感觉变成可讨论的数字。告警也应该从 SLO 倒推:

用户真的受影响了,才值得叫醒人。

CPU 高、内存高、线程多,都只是原因候选。如果它们没有影响用户旅程,就不该直接变成半夜电话。

二、三类证据:指标、日志、链路 ​

可观测性常说三类信号:

信号适合回答代价
Metrics 指标系统整体趋势:QPS、错误率、P95/P99 延迟、队列深度便宜、适合告警,但细节少
Logs 日志单个事件细节:订单为什么失败、鉴权为什么拒绝细节多,但成本和噪音高
Traces 链路追踪一个请求跨服务的完整路径和每跳耗时对分布式定位很强,但采样和上下文传播要设计

OpenTelemetry / OTel(开放遥测标准与工具集)的价值在这里:它尽量把埋点和后端存储/查询解耦。你先用相对标准的方式生成遥测数据,以后后端从开源换到商业、从 A 厂商换到 B 厂商,迁移成本会小一些。

**判断要点:**工具可以换,埋点习惯很难换。先把 trace id、结构化日志、关键业务指标这些「证据格式」打好,比先纠结大屏配色重要。

三、可靠性不止看见,还要收场 ​

很多团队买了可观测性工具,可靠性却没有变好,原因是:

看见问题不等于能处理问题。

可靠性还需要响应链路:

   告警(Alerting)       → 只叫醒能行动的人
   值班(On-call)        → 明确谁负责响应
   Runbook(处置手册)    → 告警来了第一步做什么
   事故管理(Incident)   → 分级、沟通、升级、复盘
   发布治理             → 灰度、回滚、功能开关、熔断降级

所以第 32 章的选型不能只选「监控后端」,还要选事故流程。严肃系统至少要做到:告警可行动、服务有 owner(负责人)、关键告警有 runbook、事故后有复盘,复盘产出能回写到告警、代码或平台。

四、告警:少而准,别制造噪音 ​

低质量告警长这样:

  • CPU 高了。
  • 内存高了。
  • 磁盘用了 80%。
  • 线程数变多了。

这些都是线索,不一定是事故。更好的告警围绕用户症状:

用户症状可行动告警
登录失败登录成功率低于 SLO
下单慢下单 P99 延迟连续 10 分钟超过目标
消息发不出去队列积压导致通知延迟超过承诺
搜索不可用搜索错误率和空结果率异常

**架构智慧:**别告警「机器不舒服」,要告警「用户正在受伤」。否则你会养出一套噪音系统,最后大家对真正事故也麻木。

五、按成熟度选栈 ​

阶段倾向的栈目标
MVP / 小团队托管日志 + 错误追踪 + uptime 探测 + 少量核心指标出事有人知道,能找到大概原因
标准线上系统指标 + 结构化日志 + 关键链路追踪 + SLO 告警 + runbook用户受影响时能定位、能响应、能回滚
多服务 / 多团队OpenTelemetry + 指标/日志/链路统一关联 + 服务目录 + owner跨团队协作时不靠喊人破案
高可靠关键链路SLO 平台 + 金丝雀分析 + 合成监控 + 事故演练提前发现退化,限制爆炸半径,缩短 MTTR(平均恢复时间)

注意成本:日志全量保留、trace 全量采样、高基数标签(取值种类极多的标签)都会迅速烧钱。可观测性不是采得越多越好,而是为关键问题留下足够证据。

六、选型表 ​

场景信号更倾向的栈选它的理由警惕代价
MVP / 内部工具托管日志 + 错误追踪 + uptime 探测快速闭环,出事能知道不要一开始自建全套平台
标准 Web 应用指标监控 + 结构化日志 + SLO 告警能看错误率、延迟、核心业务是否受影响告警规则要少而准
微服务 / 多团队OTel + Metrics/Logs/Traces 统一关联跨服务定位问题,减少找人时间埋点规范、采样、owner 维护都要治理
支付 / 交易 / 核心链路SLO + 错误预算 + 金丝雀发布 + runbook + 事故管理把可靠性变成可度量、可响应、可复盘成本高,需要值班纪律和组织承诺
数据量巨大 / 成本敏感分层存储 + 采样 + 聚合指标 + 限制高基数标签保留排障能力,控制账单采样过度会丢关键证据

🎯 随堂检验 ​

🤔一个系统半夜经常因为 CPU 90% 告警叫醒值班,但用户请求成功率和延迟都正常。按本章判断,更合理的改法是?
  • A继续叫醒,CPU 高一定是事故
  • B把告警改成围绕用户影响的 SLO,CPU 高作为排查线索或低优先级告警;真正叫醒人的应该是成功率、延迟、错误预算等用户症状
  • C关闭所有监控
🤔一个微服务请求跨 6 个服务,偶发 P99 延迟很高。团队只有每个服务各自的日志,很难定位慢在哪。最该补的是?
  • A再加 20 个业务大屏
  • B补齐链路追踪 traces,统一 trace id 上下文传播,让一次请求跨服务路径可见;同时保留关键指标和结构化日志做关联
  • C把所有日志打印成纯文本,越多越好

本章小结 ​

  • 可观测性不是大屏:它是系统留下足够证据,让你能追问未知问题。
  • 从 SLO 倒推技术栈:先定义用户眼里的好,再决定指标、日志、链路和告警。
  • 三类证据各有用处:Metrics 看趋势和告警,Logs 看细节,Traces 看跨服务路径。
  • 可靠性还需要响应流程:告警、值班、runbook、事故分级、复盘、回滚,缺一块都会断。
  • 按成熟度投入:小团队先闭环,大系统再统一标准和平台化;采集不是越多越好,证据要够用且付得起。

承上启下:通用系统需要看得见和救得回,AI 系统还多了模型、上下文、检索质量、成本和评测这些新变量。下一章 33 · AI 基础设施技术栈选型,我们把技术栈选型推进到 LLM 时代。

相关链接 ​

💬 评论