日志基础与概念
1.1 日志到底有什么用？
很多人觉得日志就是程序跑出来的“废话”，出了事才翻出来看看。我的看法不太一样。
日志是整个系统的“黑匣子”。它记录了系统里发生的一切——谁在什么时间、从哪里、干了什么事、结果怎样。没有日志，你就等于在盲飞。
我总结了几点核心作用：
- 故障排查 —— 系统崩了，第一件事就是查日志。我经历过一次线上服务半夜宕机，全靠日志里的错误栈定位到是数据库连接池耗尽。
- 安全审计 —— 检测入侵、追踪攻击链。你想想看，如果日志被篡改，攻击者就能抹掉痕迹，那安全防护就成了摆设。
- 性能监控 —— 接口响应慢，日志里的耗时字段能帮你找出瓶颈。
- 合规要求 —— 金融、医疗等行业法规强制要求记录操作日志，留存期至少半年。
- 业务分析 —— 用户行为、转化率，从访问日志里都能挖出来。
一句话总结：日志是系统的“眼睛”和“记忆”。没有它，你连系统怎么死的都不知道。
1.2 日志的常见类型
日志不是铁板一块。不同来源、不同用途，日志的格式和内容差异很大。我习惯把它们分成五大类：
| 类型 | 来源 | 典型内容 | 示例 |
|---|---|---|---|
| 系统日志 | 操作系统、内核、服务 | 启动/关闭、硬件错误、驱动加载 | Jan 15 10:22:33 server kernel: [12345] CPU0: Core temperature above threshold |
| 应用日志 | 业务代码、中间件 | 请求处理、错误堆栈、业务数据 | 2025-01-15 10:22:33 ERROR [OrderService] Failed to create order: insufficient balance |
| 安全日志 | 防火墙、IDS/IPS、认证系统 | 登录尝试、违规访问、恶意流量 | Jan 15 10:22:33 auth: Failed password for root from 10.0.0.5 port 22 |
| 审计日志 | 数据库、文件系统、特权操作 | 谁做了什么、变更前后快照 | audit(1736929353.123:456): pid=1234 uid=0 auid=0 ses=1 subj=... msg='op=delete-file' |
| 访问日志 | Web服务器、API网关 | HTTP请求、状态码、耗时 | 192.168.1.1 - - [15/Jan/2025:10:22:33 +0000] "GET /api/users HTTP/1.1" 200 1234 |
在实际项目里，这些日志往往混在一起。我记得有一次排查数据库慢查询，先看的是应用日志，发现没记录SQL，又去翻数据库审计日志，才抓到一条全表扫描。所以，日志分类清楚、集中管理，能省很多时间。
1.3 日志记录标准
日志如果没有统一格式，那就是一堆垃圾。我见过最差的日志，时间戳居然用“今天下午”这种描述——你根本没法排序。
目前业界主流的标准有这几个：
- Syslog（RFC 5424） —— 传统Unix/Linux系统日志格式。包含优先级、时间戳、主机名、进程名、消息体。简单但缺乏结构化。
- Common Log Format（CLF） / Combined Log Format —— Apache/Nginx标准访问日志格式。字段固定，解析速度快。
- JSON 结构化日志 —— 现在最推荐的方式。字段名清晰，机器和人都好读，也方便接入ELK等分析平台。
- CEF（Common Event Format） —— 安全领域常用，ArcSight等SIEM工具原生支持。
来看一个JSON结构化日志的例子：
{
"timestamp": "2025-01-15T10:22:33.456Z",
"level": "ERROR",
"logger": "com.example.order.OrderService",
"thread": "http-nio-8080-exec-3",
"message": "Failed to create order: insufficient balance",
"userId": "u_10086",
"orderId": "ORD-20250115-001",
"stackTrace": "java.lang.IllegalStateException: ...",
"durationMs": 234
}注意：时间戳一定要带时区和毫秒精度。level字段建议用标准等级（DEBUG、INFO、WARN、ERROR、FATAL），别搞“严重”、“轻微”这种自定义。
我个人的习惯：每个日志事件至少包含5个黄金字段——时间戳、日志级别、来源（类名/服务名）、消息内容、上下文ID（请求ID或用户ID）。这样不管出什么问题，都能快速关联。
1.4 日志记录的三大“坑”
这节算是我踩过的坑的总结。你就算记不住前面的，也一定记住这几条。
坑一：时间不同步
分布式系统里，每台机器的时间不一致。我曾经碰到过一个诡异的bug：A服务说请求在10:00发出的，B服务说10:05才收到。查了半天，发现两台机器差了5分钟。解决方案：所有服务器强制使用NTP同步，日志输出统一用UTC。
分布式系统里，每台机器的时间不一致。我曾经碰到过一个诡异的bug：A服务说请求在10:00发出的，B服务说10:05才收到。查了半天，发现两台机器差了5分钟。解决方案：所有服务器强制使用NTP同步，日志输出统一用UTC。
坑二：日志写满了磁盘
全量DEBUG日志一开，半天就能写爆硬盘。系统直接卡死。我的经验：线上环境只开INFO及以上级别，DEBUG日志用动态开关控制（比如通过配置中心热切换）。别忘了配置日志轮转（log rotate），保留最近7天足够了。
全量DEBUG日志一开，半天就能写爆硬盘。系统直接卡死。我的经验：线上环境只开INFO及以上级别，DEBUG日志用动态开关控制（比如通过配置中心热切换）。别忘了配置日志轮转（log rotate），保留最近7天足够了。
坑三：敏感信息泄露
直接在日志里打印密码、身份证号、信用卡号——这是最致命的。一旦日志被第三方看到，合规、赔偿、声誉全完。我写过一篇《Spring Boot日志脱敏最佳实践》，核心就是：永远不要记录明文敏感字段，用掩码（如
直接在日志里打印密码、身份证号、信用卡号——这是最致命的。一旦日志被第三方看到，合规、赔偿、声誉全完。我写过一篇《Spring Boot日志脱敏最佳实践》，核心就是：永远不要记录明文敏感字段，用掩码（如
pass***word）代替。
嗯，基础概念就讲到这里。下面这张图可以帮你把整个知识体系串起来：