📚 课程目录第1章日志体系概述

1. 日志体系概述：为什么需要企业级日志

聊到日志，很多人第一反应就是「出问题了才去看」。说实话，这种想法在个人项目或小团队里还能凑合，一旦到了企业级规模，就完全行不通了。

我经历过一个典型的场景：某次线上支付接口超时，业务方说是网络问题，网络组说是应用层问题，运维说是中间件问题。三方各执一词，最后花了整整两天翻日志才定位到——是某个老版本 SDK 的线程池耗尽。如果当时有统一的企业级日志体系，这个问题半小时内就能解决。

企业级日志的核心价值：不是「记录」，而是「可观测」与「可追溯」。它让系统行为变得透明，让故障排查从「猜」变成「看」。

说白了，企业级日志要解决三个核心问题：

我记得有一次给某银行做咨询，他们的日志散落在 200 多台服务器上，每台机器各自为政。审计来了，光收集日志就花了一周。嗯，这就是典型的「有日志，没体系」。

我的建议：不要等到出事故了才想起建日志体系。从系统设计的第一天，就把日志当作一等公民对待。

日志不是一锅粥。我个人习惯把日志分成三大类，每一类的关注点完全不同。

业务日志是离用户最近的日志。它记录的是「谁在什么时间做了什么」。比如用户下单、支付成功、退款申请，这些都是业务日志。

我曾经遇到过一个坑：某团队把所有业务逻辑都写在日志里，一个请求能打 50 行日志。结果日志量暴增，磁盘写满，反而把真正的问题淹没了。所以，业务日志要「精」不要「多」。

避坑指南：我曾经见过有人把用户密码明文打在业务日志里。这是严重的安全事故。记住：永远不要在日志中记录敏感信息（密码、身份证、银行卡号等）。

系统日志是运维的「眼睛」。它告诉你服务器是不是快挂了、数据库连接池是不是满了、磁盘是不是要爆了。

我个人习惯把系统日志分为三个层级：

你想想看，如果系统日志没有统一格式，每个中间件各写各的，那排查问题时就像在拼拼图。所以，我建议所有系统日志都遵循相同的 schema，至少包含时间戳、级别、来源、消息体这四个字段。

安全日志平时可能没人看，但一旦出事，它就是「救命稻草」。安全日志的核心是「不可篡改」和「完整记录」。

我记得有一次做安全审计，发现某台服务器凌晨 3 点有异常登录。顺着安全日志一查，发现是某个离职员工的账号还在用。这就是安全日志的价值——它能在事后帮你还原整个攻击链路。

关键原则：安全日志必须使用 WARN 或 ERROR 级别记录，并且要实时同步到独立的日志存储系统，不能和应用日志混在一起。

日志不是「写进去就完事了」。它有自己的生命周期，从产生到销毁，每个阶段都有讲究。

日志的产生不是随意的。我建议每个团队都制定一份「日志规范文档」，明确以下几点：

小技巧：我习惯在日志中加入 traceId，这样一次请求经过的所有服务都能串联起来。排查问题时，直接搜 traceId 就能看到完整链路。

日志采集最怕两件事：丢日志和重复采集。我见过最惨的情况是，日志采集 Agent 挂了三天没人发现，结果那三天的数据全丢了。

所以，我建议：

日志存储是个「无底洞」。每天几十 TB 的日志量，全存下来成本太高。所以要有分级存储策略：

注意：归档不等于「扔到冷存储就不管了」。归档后的日志仍然要能检索，只是查询速度慢一些。我见过有人把日志归档到 S3 后就不建索引了，结果审计来了根本查不到。

日志不是永久保存的。根据合规要求，不同类型的日志有不同的保留期限。到期后，必须彻底销毁，不能只是「删除文件」——要确保数据无法恢复。

我曾经帮一家金融公司做日志治理，发现他们三年前的日志还躺在磁盘上。这不仅浪费存储，还增加了数据泄露的风险。所以，我建议建立自动化的日志生命周期管理策略，到期自动清理。

总结一句话：企业级日志不是「写日志」，而是「管日志」。从产生到销毁，每个环节都要有规范、有工具、有监控。