📚 课程目录第3章日志生命周期

日志生命周期：从诞生到消亡

日志这东西，说白了就是一条数据流——从应用吐出来，到最终被清理掉。每个环节都藏着成本，稍不留神就烧钱。我见过不少团队只盯着存储砍预算，结果采集端崩了，传输丢数据，归档后查不了……嗯，咱们得把整个生命周期画出来，才知道钱到底花在哪。

核心观点： 成本控制不是只在存储阶段使劲，而是要把每个阶段的“无效日志”和“冗余操作”干掉。

1. 产生阶段：源头减量，最省钱的策略

日志生产的源头在应用代码里。很多人一上来就全打INFO甚至DEBUG，我先泼盆冷水——日志量每涨一个数量级，下游成本至少翻三倍。我在项目里见过一个微服务集群，一天产出5TB日志，排查发现80%是无效的框架日志。最后改了几行log级别配置，直接降到每天800GB。

日志级别控制：生产环境只用WARN和ERROR，DEBUG只在临时调试时开。
采样策略：高吞吐业务（比如API网关）用1:100采样，能保故障定位又不淹存储。
非关键日志降级：心跳、健康检查这类日志直接丢弃，别写文件。

避坑指南： 我曾经接手过一个系统，开发为了“方便排查”把SQL日志全部打到INFO。结果每天产生12TB的SQL日志，光存储成本一个月就多花了20万。后来引入动态日志开关，运行中根据链路ID抽样，成本降到原来的1/10。

2. 采集阶段：别把垃圾搬进来

采集器（Filebeat、Fluentd）不是简单搬运工。你想想看，每条多余的日志从磁盘读到内存、再从网络发出去，每一步都有成本。我习惯在采集端就做两道过滤：丢弃已知的噪点、对长字段截断。

# Filebeat 配置示例 - 仅采集 ERROR 及 WARN 级别，且截断 payload 超过 1024 字符
filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/app/*.log
  multiline:
    pattern: '^\d{4}-\d{2}-\d{2}'
    negate: true
    match: after
  include_lines: ['ERROR', 'WARN']
processors:
  - truncate_fields:
      fields:
        - message
      max_length: 1024
      fail_on_error: false

采集策略	效果	适用场景
全量采集	数据完整，成本最高	审计、安全需求
级别过滤	减少50%-80%日志量	日常监控
采样+静默	减少90%以上	高吞吐、非关键业务

实战经验： 采集端的CPU和内存也是成本。我记得有一次，Filebeat的日志解析正则写得太复杂，导致单机CPU冲到80%，被迫扩容。后来换成简单的grok模板表达式，CPU降到15%。

3. 传输阶段：压不压缩，差好几倍

传输管道（Kafka、网络带宽）是日志成本的黑洞。我用Kafka做过测算：不压缩时，一条2KB的日志占满带宽；开启snappy压缩后变成400字节，吞吐量直接翻倍。但要注意——压缩算法选不对也会增加延迟。

开启端到端压缩：Producer端用lz4或snappy，Consumer端自动解压。
批量发送：batch.size设为64KB～256KB，减少网络请求次数。
限流保护：设置max.request.size防止大日志阻塞管道。

4. 存储阶段：冷热分离，钱要花在刀刃上

存储是成本大头，但也是优化空间最大的地方。我习惯把日志分成三档：热数据（7天以内）放SSD+ES热节点；温数据（7-30天）放普通磁盘；冷数据（30天以上）直接扔对象存储（S3、OSS）。千万别把历史数据全留在ES集群里，那是在烧钱。

注意： ES的索引生命周期管理（ILM）必须配好。我以前见过一个团队没配rollover，一个索引写到了2TB，查询慢得离谱，reindex又花了三天。用ILM自动轮转、自动迁移到冷节点，才是正道。

# ILM 策略示例：7天后迁移到冷存储，30天后删除
PUT _ilm/policy/log_policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": { "max_size": "50GB", "max_age": "1d" }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "allocate": { "number_of_replicas": 1 }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "freeze": {},
          "allocate": { "require": { "box_type": "cold" } }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": { "delete": {} }
      }
    }
  }
}

5. 归档阶段：压缩不是终极方案

归档后的日志一般就没人查了，但合规要求得留着。常用的做法是把ES数据通过snapshot到S3，再用gzip或zstd压缩。我做过对比：zstd能把文本日志压缩到原始大小的5%-8%，而gzip只能到10%-12%。不过zstd需要客户端支持。

定期快照：每天凌晨对前一天的索引做snapshot。
压缩策略：归档文件用zstd level 3，平衡速度与压缩比。
元数据管理：在关系数据库里记录归档文件路径、时间范围，方便检索。

个人经验： 我遇到过归档后查询需求少得可怜，但运维同学坚持保留一年。最后我们做了一个“归档检索服务”：把归档文件的索引元数据放在ClickHouse里，用户要查的时候就通过ClickHouse定位到具体文件，再解压读取。成本比ES存储降低至少80倍。

6. 删除阶段：自动化清理，别留后患

日志不能无限存着。合规要求通常3-6个月，超出部分必须删除。手动删索引早晚会忘，必须用定时任务或ILM的delete phase自动执行。

这里有个坑：有些团队在ES里配了delete操作后，因为磁盘空间不足而失败。我建议在删除前先执行强制合并（force merge）释放段文件，确保空间能被回收。

建议： 将删除操作放在业务低峰期（凌晨3-5点），同时监控磁盘IO。我曾经因为同时删除多个大索引，导致集群IO打满，影响了线上业务。后来改成串行删除，每次只删一个索引，间隔5分钟。

回头看整个生命周期，你会发现——控制成本的核心不是在某一个环节死磕，而是让每个阶段都“恰好”够用，不多浪费一字节。我自己做成本优化时，会先画一条类似上面的流程图，然后逐阶段问三个问题：能不能不产生？能不能少传？能不能存得更便宜？ 这样一轮下来，成本一般能砍50%以上。