关键决策
这一页整理可观测平台设计过程中遇到的关键决策点，每个决策都说明了问题、对比过的方案和最终选择理由。
决策 1：应用直写还是 Agent 采集
问题
日志如何进入平台？
方案对比
- 应用直写：实现简单，但把业务请求和日志系统强耦合，日志服务挂了业务可能被拖垮。
- Agent 采集：应用只写本地文件，Agent 负责读取、缓冲和批量发送，隔离故障。
决策
Agent 采集。应用只写本地文件，性能可控；Agent 批量发送减少网络开销；下游不可用时本地缓冲重试；采集策略统一管理，不频繁改业务代码。
决策 2：文本日志还是结构化日志
问题
日志如何组织，才能被稳定地查询和聚合？
方案对比
- 文本日志 + 正则解析：迁移成本低，但容易受格式变化影响。
- 结构化 JSON 日志：查询和聚合准确，但需要业务改造。
决策
组合使用，核心服务尽量结构化输出 JSON，历史服务先用解析规则兼容。统一字段（time、service、instance、env、level、trace_id、message）是平台能聚合的前提，否则每个团队各写各的，平台无法统一处理。
决策 3：日志聚合指标还是应用埋点指标
问题
指标从哪里来？
方案对比
- 从结构化日志聚合：接入成本低、可回溯，但语义依赖日志质量。
- 应用直接埋点上报：延迟低、语义清晰，但需要业务改造。
决策
早期从日志聚合开始，后续把核心服务改造成直接埋点。两条路径并存时要定义指标口径，避免同一个错误率在两个看板上不一致。
决策 4：全量 trace 还是采样 trace
问题
链路追踪数据量大，如何控制存储成本？
决策
采样，但保护核心信号。固定比例采样 + 错误请求全量采样 + 慢请求提高采样率 + 重要租户定向采样。关键是入口采样后下游必须遵循同一个采样决策，否则 trace 残缺。错误和慢请求是排障价值最高的数据，不能因为采样丢失。
决策 5：告警越敏感越好吗
问题
告警阈值设得越低越灵敏越好？
决策
不是。告警要服务响应效率，过度敏感会制造噪音。 瞬时抖动不一定需要告警，持续异常才更可能需要人工介入。规则要有持续时间；按服务、根因、时间聚合；抑制派生告警；有升级和恢复通知。告警上线后要统计触发次数、确认率、恢复率，清理误报和漏报。
决策 6：日志解析放在哪一层
问题
文本日志在哪里转成结构化字段？
方案对比
- 应用内结构化输出：最准确，需业务改造。
- Agent 侧解析：灵活，但易受格式变化影响。
- 服务端解析：集中处理，便于统一升级，增加后端压力。
决策
组合使用：核心服务尽量输出结构化 JSON，历史服务用解析规则兼容，解析规则由服务端统一管理以便升级。解析阶段同时完成脱敏、过滤和大小限制。
决策 7：高基数字段放哪
问题
user_id、order_id 这类字段能否放进指标标签？
决策
不能。把它们放进指标标签会产生海量时间序列，存储和查询成本失控。适合做标签的是 service、api、status_code、env、region 这类有限集合。高基数字段留在日志里搜索，不进入指标标签。
决策 8：告警内容如何组织
问题
一条可用的告警应该包含什么？
决策
尽量接近排障入口。至少包含：哪个服务/接口/业务指标异常、当前值/阈值/持续时间、影响范围（错误请求数或受影响租户）、最近变更链接（发布单/配置变更）、关联看板/日志查询/trace 示例。告警内容越接近排障入口，平均恢复时间越短。从告警跳转看板时要自动带上时间范围、服务名和环境。