设计原则
设计日志监控告警系统时踩过的坑，让我总结出几条可以复用到其他系统的原则。
1. 发现、定位、复盘三件事
原则
可观测性不是收集数据，而是让团队具备三种能力。实践
发现：系统异常时能主动提醒，而不是等用户反馈。定位：能从告警跳到相关日志、指标和调用链。复盘：能保留足够上下文分析影响范围和根因。判断一个监控组件是否有价值，就看它服务于这三件事中的哪一件。
2. 三类数据联动
原则
日志、指标、链路追踪要串起来，而不是三套孤立工具。实践
只有日志会陷入海量文本搜索；只有指标知道异常不知道细节；只有链路追踪缺少整体趋势。三类数据通过统一字段（service、env、trace_id、timestamp）关联，排障路径是”告警 → 指标 → 慢 trace → 相关日志 → 根因”。
3. Agent 隔离故障
原则
不要让业务请求和日志系统强耦合。实践
应用直写数据库或远程日志服务，会把业务和日志平台绑在一起：日志服务慢，业务也慢；日志服务挂了，业务可能被拖垮。让应用只写本地文件，采集 Agent 负责读取、缓冲和发送，把故障隔离在业务之外。
4. 事件时间优先
原则
排障和指标计算使用事件时间，而不是采集时间。实践
日志必须区分事件时间和采集时间。网络延迟或 Agent 积压会让采集时间错乱，导致时间线混乱。指标计算应该用事件时间，同时记录采集时间用于判断延迟和异常。
5. 控制基数
原则
指标标签只用有限集合字段。实践
把 user_id、order_id、trace_id 放进指标标签，会产生海量时间序列，存储和查询成本迅速失控。适合做标签的是 service、api、status_code、env、region 这类有限集合。高基数字段留在日志里搜索，不进入指标标签。
6. 告警服务响应效率
原则
告警的目标不是"有异常就发消息"，而是"需要人处理时通知正确的人"。实践
糟糕的告警会在凌晨发出几百条无效通知，最后所有人都学会忽略它。告警规则要有数据源、条件、持续时间和通知策略；要按服务、根因、时间聚合；要抑制派生告警；要有升级和恢复通知。告警噪音是系统性的，需要持续治理。
7. 采样要保护核心信号
原则
trace 不可能全量采集，但错误和慢请求必须优先保留。实践
高流量服务 100% 采集 trace 成本过高，用固定比例采样、错误全量采样、慢请求提高采样率。关键是入口采样后，下游要遵循同一个采样决策，否则 trace 残缺。错误和慢请求是排障价值最高的数据，永远不能因为采样而丢失。
8. 从查询场景反推存储
原则
所有数据按最高规格保存，成本会失控。实践
高频热日志保留 7-14 天，冷日志归档数月到数年，指标最近高精度历史降采样，trace 采样保留。存储设计必须从查询场景和保留周期反推，而不是”先存着再说”。
可观测平台设计 checklist
采集与解析：
✓ 核心服务统一输出 service / env / trace_id / level / 时间字段
✓ Agent 挂掉、下游不可用时有缓冲和重试
✓ 敏感字段有脱敏规则
指标与告警：
✓ 核心接口有 QPS、错误率、P95/P99 延迟指标
✓ 告警有聚合、抑制、升级和恢复通知
✓ 告警内容可直达排障入口
追踪与可视化：
✓ trace 覆盖率支撑核心链路排障
✓ 看板能从告警跳转到对应时间窗口
✓ 日志、指标、trace 保留周期和成本可控记住：
- 不要等线上事故发生后再补监控
- 日志提供细节，指标提供趋势，追踪提供路径
- 告警的价值在响应效率，不在通知数量