1. 日志记录基础：从“黑匣子”到“上帝视角”

说实话，我刚入行那会儿，对日志这事儿是有点瞧不上的。

当时觉得，代码能跑就行，出问题 debug 不就完了？直到有一次线上事故，某个服务半夜挂了，我连它死前干了什么都不知道。查了一圈，发现日志没开全，关键信息全丢了。那种感觉，就像你开着飞机，黑匣子被人扔了——你只知道它掉下来，却不知道为什么。

从那以后我就明白了：日志不是写给机器看的，是写给自己未来的。

1.1 什么是日志记录？

说白了，日志记录就是给系统装一个“录像机”。

它会把系统里发生的事件按时间顺序记下来。谁、什么时间、从哪来、做了什么、结果如何——这些信息就是日志的核心要素。

我个人习惯把日志理解成“三元组”：时间 + 事件 + 上下文。你想想看，如果一条日志只告诉你“错误发生了”，却没有时间戳、没有请求 ID、没有堆栈信息——它基本等于没写。

1.2 日志的重要性

我经常跟团队里的人说：没有日志的系统，就像没有仪表盘的飞机。你敢飞吗？

日志的重要性体现在几个方面：

• 故障排查：这是最基础的用途。系统挂了，你得知道它为什么挂。我记得有一次排查一个性能问题，就是因为一条日志里记录了 SQL 执行时间，才定位到慢查询的。
• 安全审计：谁在什么时候访问了敏感数据？谁修改了系统配置？这些信息只有日志能告诉你。我曾经参与过一个安全事件复盘，要不是 CloudTrail 日志记录了 API 调用，我们根本不知道攻击者是通过什么漏洞进来的。
• 合规要求：很多行业标准（像 PCI DSS、HIPAA、SOC 2）都明确要求日志保留。你不记，就是违规。
• 性能分析：通过日志里的响应时间、调用链路，你可以找出系统的瓶颈在哪。
• 运营监控：日志能告诉你系统是不是健康的——比如 500 错误突然增多，说明可能出问题了。

1.3 日志的类型

嗯，这里要注意：不同类型的日志，记录的侧重点完全不同。我把它分成三大类，你想想看自己平时是不是也这么分的。

类型	来源	典型内容	关注点
系统日志	操作系统、中间件、硬件	内核消息、设备状态、服务启停、磁盘 IO	系统健康度、资源瓶颈
应用日志	业务代码、Web 服务器、数据库	请求/响应、SQL 执行、业务异常、交易流水	业务连续性、代码质量
安全日志	防火墙、IAM、认证服务	登录尝试、权限变更、API 调用、异常访问	安全事件、合规审计

系统日志

系统日志通常是操作系统或中间件自动生成的。比如 Linux 上的 /var/log/messages、Windows 的事件查看器。我在排查性能问题时，经常盯着系统日志看 CPU 和内存的异常记录。

举个真实的例子：有一次线上机器突然变慢，应用日志看不出问题，但系统日志里反复出现 out of memory: killed process——原来是内存泄漏导致 OOM Killer 不断杀进程。

应用日志

这是开发者最常打交道的。我个人习惯在关键业务路径上打五类日志：入参、出参、耗时、异常、状态变更。少了哪个，排查起来都费劲。

比如一个下单接口，我会这么记：

2024-01-15 10:30:12.345 INFO  [order-service] 用户[user_1234] 发起下单请求，商品ID: prod_5678
2024-01-15 10:30:12.567 INFO  [order-service] 库存扣减成功，剩余: 99
2024-01-15 10:30:12.890 INFO  [order-service] 订单创建成功，订单ID: order_9012，耗时: 545ms
2024-01-15 10:30:12.891 INFO  [order-service] 订单状态变更: PENDING -> PAID

嗯，你注意看：时间戳、请求链路、关键参数、结果、耗时——一个都不能少。

安全日志

安全日志的特殊性在于：大部分时候没人看，但一真出事，它就是你唯一的救命稻草。我记得有一次做 AWS 审计，发现某个 IAM 用户在凌晨三点批量删除了 S3 存储桶。要不是 CloudTrail 记录了每一次 DeleteBucket 的调用，我们根本不知道是密钥泄露了。

知识结构图：日志记录全景

日志记录的原则

我在项目中总结过几条“潜规则”，分享给你：

1. 宁可多记，不能少记。少记一条关键信息，排查成本翻十倍。磁盘便宜，时间贵。
2. 统一格式。团队内所有服务用同一套日志格式（JSON 最推荐），不然你到时候 grep 都抓不到重点。
3. 区分级别。ERROR 别乱打，INFO 别偷懒。我见过有的项目所有日志都是 INFO，线上跟 DEBUG 一样——根本没法看。
4. 不要记敏感信息。密码、身份证、信用卡号——不能进日志。我当年接手过一个项目，日志里明文记录用户密码，吓得我连夜改代码。
5. 保留足够时长。至少 30 天，合规要求更长。用 S3 生命周期策略自动归档，别手删。

这一章的内容就到这儿。记住：日志不是负担，是你对自己的保险。