知识点深化 · 可观测性
可观测性：日志(ELK)、指标(Prometheus+Grafana)、链路追踪(Jaeger)
线上出问题，用户先报障，你才发现——这叫"盲人骑瞎马"。可观测性就是让你不登录服务器也能知道系统健康度。它有三大支柱：日志（发生了什么事）、指标（数字趋势）、链路追踪（一个请求跨服务卡在哪）。这一页把三件套讲清楚。
① 小白第一课怎么学（4 步走，约 80 分钟）
先搞懂三大支柱各自回答什么问题，别一上来就搭 ELK。
1分清三支柱（15 分钟）
读②③：日志=事件、指标=数值、链路=请求路径。
2搭指标栈（20 分钟）
读④：Prometheus 拉指标 + Grafana 画图，最常用。
3看一个真实排错（30 分钟）
跟着⑤用指标+日志定位慢请求。
4排错+刷题（15 分钟）
读⑥告警/采样坑，做⑦⑩。
本课小目标学完你要能：① 说清日志/指标/链路各自解决什么；② 读懂 PromQL 基本查询；③ 知道一条告警怎么配；④ 用 trace 找到跨服务慢在哪。
② 一图看懂：可观测性三大支柱
读法：指标告诉你"有问题"（看到 P99 飙高），日志告诉你"具体什么错"（堆栈），链路告诉你"问题出在哪个服务哪一跳"。三层配合排错。
③ 本质直觉：给系统装"神经系统"
一个线上服务由几十个实例、十几个微服务组成。出了问题你不可能一台台 ssh 上去看。可观测性就是把所有信息汇聚到一处，远程就能诊断。
日志回答"发生了什么"：每一条事件带时间、级别（INFO/WARN/ERROR）、trace id。ELK（Elasticsearch+Logstash+Kibana）或 Loki 负责收集、检索。你想知道"刚才那个订单为什么失败"，搜日志。
指标回答"现在怎么样"：是数字随时间的曲线——CPU、内存、QPS、错误率、P99 延迟。Prometheus 定时抓取，Grafana 画看板。你一眼看到"错误率从 0.1% 涨到 5%"。
链路追踪回答"卡在哪"：一个请求经过网关→服务A→服务B→数据库，trace 把每一跳的耗时记下来串成一条。你看到 P99 慢了，点开 trace 发现是"服务B 调数据库花了 1.8 秒"。
排错三步法指标发现"不好了"→ 链路定位"是哪一段"→ 日志看清"具体报错"。别一上来就翻日志——海量日志里捞问题效率极低。
④ 完整体系：ELK、Prometheus+Grafana、Jaeger
三大栈对照
| 支柱 | 主流栈 | 存什么 | 查询方式 |
|---|
| 日志 | ELK / Loki+Grafana | 离散文本事件 | 关键词/级别检索 |
| 指标 | Prometheus + Grafana | 时间序列数字 | PromQL |
| 链路 | Jaeger / Tempo | 请求跨服务调用链 | 按 trace id 查 |
Prometheus 关键概念
| 概念 | 说明 |
|---|
| Counter | 只增计数器（如总请求数），用 rate() 算速率 |
| Gauge | 可增可减的瞬时值（如内存用量、当前排队数） |
| Histogram | 分桶统计延迟，算 P95/P99 |
常用 PromQL
# HTTP 请求 QPS（每秒请求数）
rate(http_requests_total[5m])
# 5xx 错误率
sum(rate(http_requests_total{code=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
# P99 延迟
histogram_quantile(0.99, rate(http_duration_seconds_bucket[5m]))
# CPU 使用率
1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m]))
告警规则（Prometheus Alertmanager）
groups:
- name: api
rules:
- alert: HighErrorRate
expr: sum(rate(http_requests_total{code=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) > 0.02
for: 2m # 持续2分钟才告警，防抖动
labels: {severity: critical}
annotations:
summary: "5xx 错误率超过 2%"
日志规范
生产日志要打 JSON，带 timestamp / level / trace_id / message。级别分层：DEBUG（调试）、INFO（正常流程）、WARN（可疑但没挂）、ERROR（出错了）。别把所有日志都打成 INFO 或 ERROR。
⑤ 用法场景与典型例题
例1（选工具）用户说"下单很慢"，你想知道慢在网关、A 服务还是数据库，该看什么？
跨服务定位耗时用链路追踪。
① 看 Grafana 指标确认 P99 延迟确实涨了。
② 打开 Jaeger，找一个慢请求的 trace。
③ 看到各 span 耗时：网关 10ms、A 服务 15ms、B 服务 1800ms、DB 20ms。
④ 瓶颈在 B 服务。
答案：跨服务耗时定位用 Jaeger 链路追踪，不是翻日志。
例2（PromQL）怎么算过去 5 分钟的 5xx 错误率？
5xx 的速率除以总速率。
① 分子：sum(rate(http_requests_total{code=~"5.."}[5m]))。
② 分母：sum(rate(http_requests_total[5m]))。
③ 相除即错误率。
答案：结果大于 0.02（2%）持续 2 分钟就触发 HighErrorRate 告警。
例3（日志级别）用户登录失败，密码错了一行，该打什么级别？
区分业务预期错误和系统故障。
① 密码错是用户操作，不是系统故障。
② 打 WARN 或 INFO，带用户名。
③ 只有"数据库连不上""空指针崩溃"这种才打 ERROR。
答案：别把密码错打 ERROR，否则告警风暴淹没真正的故障。ERROR 要留给真故障。
采样与成本全量链路追踪开销大，生产一般采样 1%~10%（错误请求全采）。日志也按级别采样，别 DEBUG 全量上生产，否则存储爆了。
⑥ 高频错误诊断（4 条）
错误 1：告警太多，人人视而不见这叫"告警疲劳"。把所有指标都配告警=没有告警。只对真正影响用户的 SLI 配告警，加 for 持续时间防抖动，分级（warning 钉钉、critical 电话）。
错误 2：日志不带 trace_id，没法关联一条请求跨多个服务，日志里没有共同的 trace_id，你就拼不出完整路径。网关入口生成 trace_id，全程透传。
错误 3：只监控服务器，不监控用户体验CPU/内存都正常，但 P99 延迟 3 秒，用户已经在骂了。要加业务指标（错误率、延迟、下单成功率），别只盯主机。
错误 4：日志全打 ERROR 或全打 INFO级别失控，Kibana 里无法区分严重程度。严格按规范：预期内用 WARN/INFO，真故障才 ERROR。
⑦ 考点真题演练（4 题）
考点分布
| 考法 | 出题形式 | 应对 |
|---|
| 三支柱分工 | 场景选工具 | 日志/指标/链路各管一块 |
| PromQL | 算错误率/延迟 | rate + histogram_quantile |
| 告警 | 为什么加 for | 防抖动 |
| 排错顺序 | 慢请求先看啥 | 指标→链路→日志 |
真题基础1. 想知道一个慢请求在网关、A服务、数据库之间到底哪一跳耗时最多，应该用？
真题中档2. Prometheus 里只增不减的总请求数，叫什么类型？
真题中档3. 告警规则里 for: 2m 的作用是？
真题拔高4. 线上报"下单变慢"，正确的排错顺序是？
⑧ 必背命令/知识点卡
三支柱：日志 / 指标 / 链路 发生了什么/现在怎样/卡在哪
日志栈：ELK 或 Loki JSON+trace_id
指标栈：Prometheus 抓 + Grafana 画 PromQL
链路：Jaeger 按 trace id 串起每一跳
算速率：rate(metric[5m]) Counter 必用
算分位：histogram_quantile(0.99, ...) P99
排错：指标发现→链路定位→日志看清 别一上来翻日志
⑨ 应用输出：给一个 Web 服务接好三件套
场景：FastAPI 服务上线，要能看错误率、查日志、追慢请求
① 日志：应用打 JSON 日志（含 trace_id），输出到 stdout，由 Docker/K8s 收集到 Loki。
② 指标：用 prometheus_client 暴露 /metrics，Prometheus 定时抓取；Grafana 看板画 QPS、P99、错误率。
③ 链路：接 OpenTelemetry SDK，上报到 Jaeger；入口生成 trace id 并透传。
④ 告警：配 HighErrorRate（5xx>2% 持续 2 分钟）和 HighLatency（P99>2s）。
⑤ 演练：故意打 503，看 Grafana 错误率变红、告警发钉钉、Jaeger 能搜到这条慢 trace。
口述搭建思路"应用埋点打指标和结构化日志，Prometheus 抓取、Grafana 看板、Jaeger 追链路，告警盯 SLI；出问题按指标→链路→日志三层钻取。"
⑩ 分层练习 15 题（基础 5 + 中档 5 + 拔高 5）
▍基础 5 题
基础1可观测性三大支柱是？
日志、指标、链路追踪。
基础2Grafana 主要用来干嘛？
把 Prometheus 的指标画成看板图表。
基础3Prometheus 用什么语言查询？
PromQL。
基础4日志级别 ERROR 用来记什么？
真正的系统故障，不是用户操作错误。
基础5Jaeger 是哪一类工具？
链路追踪工具。
▍中档 5 题
中档6Counter 和 Gauge 的区别？
Counter 只增（总请求数）；Gauge 可增可减（当前内存）。
中档7怎么算 P99 延迟？
histogram_quantile(0.99, rate(http_duration_bucket[5m]))。
中档8为什么日志要带 trace_id？
把一次请求跨多服务的日志串起来，方便关联排查。
中档9"告警疲劳"是什么？怎么避免？
告警太多导致人人忽略。只对影响用户的 SLI 告警、加 for 防抖动、分级通知。
中档10为什么不能只监控 CPU/内存？
资源正常不代表用户体验好，要加错误率、延迟、业务成功率等用户视角指标。
▍拔高 5 题
拔高11rate() 为什么要加时间窗口？
Counter 是累计值，必须除以时间窗口才得到每秒速率；[5m] 表示过去 5 分钟平均。
拔高12生产链路追踪为什么要采样？
全量 trace 开销和存储巨大。按比例采样，错误请求全采，正常请求采一小部分。
拔高13告警分 warning 和 critical 怎么落地？
warning 发群消息/工单，critical 电话/短信 oncall，避免小事半夜吵醒人。
拔高14日志为什么推荐 JSON 格式？
机器可解析、可按字段检索；纯文本（如"user 123 login fail"）不好结构化过滤。
拔高15指标都正常但用户报错，可能漏了什么？
可能漏了业务指标（如下单成功率、支付成功率），或漏了下游依赖（第三方接口）监控。
⑪ 记忆口诀 + 7 天复习计划
三句口诀
① 日志记事、指标看趋势、链路找卡点。
② Prometheus 抓数 Grafana 画图，PromQL 算率和分位。
③ 排错先指标后链路再日志，告警要精不要多。
| 天 | 任务 | 自检 |
|---|
| 第 1 天 | 读②③，分清三支柱 | 能各举一例 |
| 第 2 天 | 背知识点卡 + 做基础 1-5 | 基础全对 |
| 第 3 天 | 读 PromQL，手写错误率和 P99 | PromQL 写对 |
| 第 4 天 | 做中档 6-10，配一条告警规则 | 会加 for |
| 第 5 天 | 做拔高 11-15 + 真题 4 题 | 会三层排错 |
| 第 6-7 天 | 口述排错三步法，默写三支柱分工 | 不看资料全默对 |
← 返回 FDE 培养总览