这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
指标计算
日志适合回答“某次请求发生了什么”，指标适合回答“系统整体是否正常”。如果线上接口开始变慢，值班人员不可能先读几万行日志，而是需要看到错误率、延迟和吞吐的变化。
指标计算就是把大量事件转成时间序列：
结构化日志 -> 聚合窗口 -> 指标点 -> 时间序列存储 -> 告警与看板指标类型
常见指标可以分成四类：
| 类型 | 示例 | 用途 |
|---|---|---|
| 计数器 | 请求数、错误数 | 计算 QPS、错误率 |
| 直方图 | 请求耗时分桶 | 计算 P95、P99 |
| 仪表盘值 | 队列长度、连接数 | 观察当前状态 |
| 业务指标 | 支付成功率、订单创建量 | 判断业务是否受影响 |
系统监控只看 CPU 和内存是不够的。真正能反映用户体验的是 RED 指标：Rate、Errors、Duration，也就是请求量、错误率和延迟。
聚合窗口
指标需要按时间窗口聚合。例如每 1 分钟计算一次接口错误率：
error_rate = error_count / total_count窗口太短，指标波动大，容易误报；窗口太长，发现问题太慢。常见做法是同时保留多个粒度：
- 10 秒窗口用于快速告警。
- 1 分钟窗口用于常规看板。
- 5 分钟或 1 小时窗口用于趋势分析。
延迟指标不要只算平均值。平均值会掩盖尾部问题，P95、P99 更能反映用户真实体验。
基数控制
指标系统最容易被高基数字段拖垮。例如把 user_id、order_id 放进指标标签，会产生海量时间序列，存储和查询成本迅速失控。
适合做标签的字段是有限集合：
- service
- api
- status_code
- env
- region
不适合做标签的字段是无限或近似无限集合：
- user_id
- request_id
- trace_id
- order_id
这些字段可以留在日志里搜索，但不应该进入指标标签。
计算链路
指标可以来自两条路径：
- 应用直接上报指标，延迟低、语义清晰。
- 从结构化日志中聚合指标，改造成本低、可回溯。
早期可以从日志聚合开始，后续把核心服务改造成直接埋点。两条路径并存时，要定义指标口径，避免同一个错误率在两个看板上不一致。
指标计算完成后，平台已经能判断系统是否异常。下一章要解决的是：异常出现时，如何通知正确的人，并避免无效告警淹没团队。