日志保留

设分层保留（热/温/冷）平衡查询速度、成本和合规需求。

为什么

保 90 天热日志（快 SSD、全索引）比温（便宜盘、少索引）贵 10x 比冷（对象存、无索引）贵 100x。但你需要热供过去 7-30 天（事件诊断、实时仪表盘）、温供 90 天（复盘取证）、冷供 1-7 年（合规、罕调查）。分层策略按龄把每日志放正确层：热 30 天、温 60 多、冷 2+ 年。这砍日志存储成本 70-80% 同时保近事件快查询和长尾合规覆。陷阱是"以防万一"全热 — 10000 服务组织保 90 天热年花 $500k 日志存储，分层则 $100k，近数据同可查询。

何时使用

设日志聚合时。季度随量和合规需求变审查策略。

如何做

1. 定义层及其查询模式
   - 热（0-30d）：快查询（<1s）、实时仪表盘、事件诊断
   - 温（30-90d）：慢查询（<10s）、复盘取证、趋势分析
   - 冷（90d-7y）：慢查询（<60s）或恢复到热、合规、罕调查

2. 设每层保留
   - 热：30 天（或预算紧 7；30 是事件诊断甜点）
   - 温：60 天（从摄入 30-90 总）
   - 冷：2-7 年（合规驱动：GDPR、HIPAA、SOC2）

3. 自动在层间移日志
   - 30d 热 → 温：改存储类、减索引
   - 90d 温 → 冷：移对象存（S3）、弃索引
   - 7y 冷 → 删：合规保留满

4. 按工作查正确层
   - 事件诊断（过去 24h）：查热 → <1s
   - 复盘（过去 30d）：查热 → <1s
   - 趋势分析（过去 90d）：查温 → <10s
   - 合规审计（过去 3y）：冷恢复到热再查 → <60s

5. 跟踪每层成本并调
   - 若热是 60% 成本但 5% 查询 → 缩热到 14d
   - 若冷从不查 → 缩冷到 2y（或合规最小）
   - 策略是盘非常量；按实际用调

示例

# 保留策略（Loki + S3）：
retention:
  hot:
    duration: 30d
    storage: ssd-local          # 快查询，贵
    index: full                 # 全字段索引
  warm:
    duration: 60d               # 从摄入 30-90d
    storage: hdd-shared         # 慢查询，便宜
    index: reduced              # 仅 service、level、trace_id
  cold:
    duration: 2555d             # 7 年（GDPR）
    storage: s3-glacier         # 对象存，无索引
    index: none                 # 恢复到热查

# 成本比较（10k 服务，1TB/天）：
#   全热（90d）：  90 TB × $23/TB/月 = $2,070/月 = $24.8k/年
#   分层：         30 TB 热（$690）+ 60 TB 温（$360）+ 2555 TB 冷（$25）= $1,075/月 = $12.9k/年
#   省：48% 同近数据可查询

# 查询路由（自动）：
#   "过去 24h checkout 错误" → 热 → 0.3s
#   "过去 90d 错误趋势"    → 温 → 8s
#   "过去 3y 合规"         → 冷 → 恢复 2m + 查 60s = 2m60s
#   用户不选层；查询龄定它

常见问题

⚠全热无分层 — 同近数据可查询 10x 成本；"以防万一"非保留策略。
⚠无冷层 — 合规要 7 年保留但你 90d 删，造合规缺口。
⚠手动层移 — 某人每月手移日志到冷，故不发生；按龄自动热→温→冷。
⚠不恢复查冷 — 7 年合规查询冷 60s（无索引）vs. 热 1s；调查先恢复。

最佳实践

✓设分层保留：热 30d（快查询、全索引）、温 60d（慢、减索引）、冷 2-7y（对象存、合规）。
✓按龄自动层转（30d 热→温、90d 温→冷）；手动移不发生。
✓按龄自动路由查询 — 近到热、30-90d 到温、合规到冷带恢复；用户不选层。
✓跟踪每层成本并调；若热 60% 成本但 5% 查询则缩热 — 策略是盘非常量。