完整系统

到这里，我们已经把日志监控告警系统拆成了完整链路：

应用日志/埋点
  -> Agent 采集
  -> 日志网关/消息队列
  -> 解析与清洗
  -> 日志存储 + 指标计算 + Trace 存储
  -> 告警引擎
  -> 看板与事故工作台

这套系统的核心不是“存很多日志”，而是让团队在系统异常时能发现、定位、复盘。

数据流设计

日志进入平台后会分成三条流：

1. 明细流：结构化日志写入日志存储，支持搜索和审计。
2. 指标流：从日志或埋点中聚合时间序列，用于看板和告警。
3. 追踪流：span 数据写入 trace 存储，用于还原请求链路。

三条流要通过统一字段关联：service、env、trace_id、timestamp。没有这些字段，平台就会变成三套孤立工具。

存储分层

不同数据有不同保留周期：

数据	保留策略
高频热日志	保留 7 到 14 天，支持快速搜索
冷日志归档	保留数月到数年，服务审计和合规
指标数据	最近数据高精度，历史数据降采样
Trace 数据	采样保留，错误和慢请求优先

如果所有数据都按最高规格保存，成本会失控。存储设计必须从查询场景和保留周期反推。

关键决策

1. 应用直写还是 Agent 采集：直写简单但耦合业务，Agent 能隔离故障和统一策略。
2. 文本日志还是结构化日志：文本迁移成本低，结构化日志更适合查询和聚合。
3. 日志聚合指标还是应用埋点指标：日志聚合易接入，应用埋点语义更准确。
4. 全量 trace 还是采样 trace：全量成本高，采样要保证错误和慢请求优先保留。
5. 告警越敏感越好吗：不是。告警要服务响应效率，过度敏感会制造噪音。

容量估算

设计前要先估算日志量：

日志量 = 服务实例数 × 每实例 QPS × 每请求日志条数 × 单条日志大小

例如 100 个实例，每实例 200 QPS，每请求 2 条日志，每条 1KB，每天日志量约为：

100 × 200 × 2 × 1KB × 86400 ≈ 3.4TB/day

这个数字会直接影响采集带宽、消息队列容量、存储成本和查询方案。没有容量估算的可观测平台，很容易在业务高峰时先把自己压垮。

上线检查清单

• 每个核心服务是否统一输出 service、env、trace_id、level 和时间字段？
• Agent 挂掉、下游不可用、网络抖动时是否有缓冲和重试？
• 日志中是否有敏感字段脱敏规则？
• 核心接口是否有 QPS、错误率、P95/P99 延迟指标？
• 告警是否有聚合、抑制、升级和恢复通知？
• trace 覆盖率是否能支撑核心链路排障？
• 看板是否能从告警直接跳转到对应时间窗口？
• 日志、指标、trace 的保留周期和成本是否可控？

课程总结

日志监控告警系统是一套面向故障处理的工程体系。日志提供细节，指标提供趋势，链路追踪提供路径，告警推动响应，可视化组织上下文。

当你设计下一套系统时，不要等线上事故发生后再补监控。每一个关键链路都应该在上线前回答：

• 如果它变慢了，我们多久能发现？
• 如果它失败了，我们能看到哪一步失败？
• 如果它影响用户，我们能估算影响范围吗？
• 如果问题恢复了，我们能证明它真的恢复了吗？

能回答这些问题，系统才真正具备可运维性。

上一章节可视化设计面向故障排查的可视化工作台，串联日志、指标、链路和告警上下文