这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
完整架构
完整的日志监控告警系统拆成完整链路：
应用日志/埋点
-> Agent 采集
-> 日志网关/消息队列
-> 解析与清洗
-> 日志存储 + 指标计算 + Trace 存储
-> 告警引擎
-> 看板与事故工作台这套系统的核心不是”存很多日志”，而是让团队在系统异常时能发现、定位、复盘。
数据流设计
日志进入平台后分成三条流：
| 数据流 | 存储 | 用途 |
|---|---|---|
| 明细流 | 日志存储 | 搜索和审计 |
| 指标流 | 时间序列库 | 看板和告警 |
| 追踪流 | Trace 存储 | 还原请求链路 |
三条流通过统一字段关联：service、env、trace_id、timestamp。
分层架构
┌─────────────────────────────────────────────────────────────────┐
│ 采集层 │
│ 应用日志（结构化输出） -> Agent（读文件/缓冲/批量/重试） │
└──────────────────────────────┬───────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ 管道层 │
│ 消息队列（削峰） -> 解析清洗（脱敏/统一字段/索引） │
└──────────────────────────────┬───────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ 存储层 │
│ 日志存储 · 时间序列库 · Trace 存储（按保留周期分层） │
└──────────────────────────────┬───────────────────────────────────┘
▼
┌─────────────────────────────────────────────────────────────────┐
│ 使用层 │
│ 告警引擎（规则/聚合/抑制/升级） -> 看板 -> 事故工作台 │
└─────────────────────────────────────────────────────────────────┘存储分层
| 数据 | 保留策略 |
|---|---|
| 高频热日志 | 保留 7-14 天，支持快速搜索 |
| 冷日志归档 | 保留数月到数年，服务审计和合规 |
| 指标数据 | 最近高精度，历史降采样 |
| Trace 数据 | 采样保留，错误和慢请求优先 |
排障路径
告警 -> 指标看板 -> 慢 trace -> 相关日志 -> 根因例如：告警显示支付回调 P95 超过 2 秒，点击看板看到延迟集中在 Payment Service，打开慢 trace 发现 MySQL 查询耗时异常，最后通过 trace_id 搜到 SQL 参数和错误日志。
容量估算
日志量 = 服务实例数 × 每实例 QPS × 每请求日志条数 × 单条日志大小例如 100 个实例，每实例 200 QPS，每请求 2 条日志，每条 1KB，每天日志量约为：
100 × 200 × 2 × 1KB × 86400 ≈ 3.4TB/day这个数字直接影响采集带宽、消息队列容量、存储成本和查询方案。没有容量估算的可观测平台，容易在业务高峰时先把自己压垮。
关键指标
- 采集延迟、丢失率、查询延迟、告警准确率、噪音率。
- 核心服务黄金指标：请求量、错误率、延迟（P50/P95/P99）、饱和度。
- 告警确认率、恢复率、平均发现时间和平均恢复时间。
这套架构的关键在于：日志提供细节，指标提供趋势，链路追踪提供路径，告警推动响应，可视化组织上下文。