第1章：日志体系概述——为什么SaaS需要日志监控？
大家好，我是老张。做SaaS运维这些年，我见过太多因为日志没管好而翻车的案例。说实话，日志这东西，平时没人觉得它重要，一出事它就是唯一的救命稻草。
今天咱们聊聊日志体系。别觉得这是基础，基础往往最要命。
1.1 为什么SaaS必须搞日志监控？
先问个问题：你的SaaS系统出过故障吗？肯定出过。那你怎么定位问题的？
我遇到过不少团队，系统崩了第一反应是「重启试试」。重启完问题还在，然后开始翻代码、查数据库，折腾半天才发现是某个接口超时了。嗯，如果日志体系建得好，这种问题三分钟就能定位。
SaaS和传统软件最大的区别是什么？是「多租户」。你想想看，一个系统服务几百个客户，每个客户的数据混在一起。出了问题，你不仅要找到原因，还得说清楚「是哪个客户的问题」、「影响范围多大」。没有日志，你拿什么说？
核心观点：日志监控是SaaS系统的「黑匣子」。飞机出事靠黑匣子，系统出事靠日志。
具体来说，日志监控能帮你解决三个核心问题：
- 故障定位——系统挂了，谁干的？什么时候？为什么？
- 性能分析——哪个接口慢？哪个数据库查询拖后腿？
- 安全审计——谁在什么时候访问了什么数据？有没有异常操作？
我记得有一次，客户投诉说数据丢了。我们查了半天，最后从安全日志里发现是某个运维人员误操作删了表。如果没有日志，这个锅可能就得开发背了。
1.2 日志的分类——别把所有日志放一个篮子里
很多新手喜欢把所有日志打到同一个文件里。我刚开始也这么干过，结果呢？查问题的时候像大海捞针。后来我学乖了，日志必须分类。
一般来说，SaaS系统的日志分三类：
| 日志类型 | 内容 | 典型用途 |
|---|---|---|
| 业务日志 | 用户操作、订单状态、支付记录等 | 业务分析、用户行为追踪、计费审计 |
| 系统日志 | CPU/内存使用率、接口响应时间、数据库慢查询等 | 性能监控、故障排查、容量规划 |
| 安全日志 | 登录记录、权限变更、API调用审计等 | 安全审计、入侵检测、合规检查 |
这三类日志，存储策略和保留时间都不一样。我个人的习惯是：
- 业务日志：保留时间长（至少6个月），因为可能涉及财务审计
- 系统日志：保留时间短（7-30天），滚动覆盖就行
- 安全日志：必须永久保留，出事的时候这就是证据
小技巧：业务日志和安全日志建议单独建索引，方便快速检索。系统日志量大，可以考虑用压缩存储。
1.3 日志的生命周期——从出生到入土
一条日志从产生到最终被删除，其实经历了好几个阶段。我把它总结成「五步走」：
- 产生——应用程序或系统组件输出日志
- 采集——通过Agent或SDK收集日志数据
- 传输——通过网络发送到中央存储
- 存储——写入数据库或文件系统
- 归档/删除——按策略清理过期数据
这里面最容易出问题的是哪一步？我告诉你，是「传输」。我曾经遇到过日志采集Agent把网络带宽打满的情况，导致正常业务请求超时。你说冤不冤？
避坑指南：我曾经因为日志传输没做限流，导致生产环境网络拥堵。后来我学乖了，所有日志采集必须加「背压机制」——当存储端处理不过来时，采集端要主动降速，而不是拼命重试。
再说说存储。很多团队喜欢把所有日志都存到Elasticsearch里。说实话，ES确实好用，但成本也高。我建议分层存储：
- 热数据（最近7天）：放ES，支持实时检索
- 温数据（7-30天）：放对象存储，偶尔查
- 冷数据（30天以上）：压缩归档，基本不查
这样既能保证查询效率，又能控制成本。你想想看，一个SaaS系统每天产生几百GB日志，全放ES里，那得多少钱？
1.4 日志体系建设的「三个不要」
最后，分享几个我踩过的坑：
- 不要等到出事了才建日志——等系统崩了再想加日志，已经晚了
- 不要所有日志一个级别——INFO、WARN、ERROR要区分清楚，不然查问题的时候全是噪音
- 不要忽视日志的「量」——日志太多会拖垮系统，太少又查不到问题。我一般建议控制在每天每节点不超过10GB
嗯，这一章就聊到这儿。日志体系是地基，地基打不好，后面盖什么楼都白搭。下一章咱们聊聊具体的日志采集方案，包括怎么选Agent、怎么配采集规则。
记住一句话：没有日志的系统，就像没有仪表盘的飞机——你敢坐吗？