1. 日志采集概述：为什么需要日志采集？

说实话，我见过太多团队把日志当成「后花园」——想起来就写点，想不起来就拉倒。直到线上出了故障，一群人抓瞎，才意识到日志的重要性。

日志采集，说白了就是把你系统里发生的事，有结构、有顺序、可检索地记录下来。它不是锦上添花，而是基础设施。

一句话总结：没有日志采集的系统，就像没有黑匣子的飞机——飞得再高，出了事也查不出原因。

1.1 为什么非做不可？

我入行头两年，在一家创业公司做后端。有一次凌晨两点，用户量突然暴涨，服务全挂了。我们几个开发对着屏幕干瞪眼——代码里只有零星几个 console.log，连错误栈都没打全。那晚我们花了整整 6 个小时才定位到问题：一个连接池泄漏。

从那以后，我给自己定了个规矩：任何上线的服务，日志必须到位。原因有三点：

  • 系统太复杂，肉眼看不透——微服务、容器、分布式，调用链动不动跨十几个节点。没有日志，你根本不知道数据流在哪断了。
  • 故障恢复需要「回放」——出问题时现场早没了。日志是你唯一能倒带重看的东西。
  • 合规要求越来越严——GDPR、等保、金融审计，哪个不要求留痕？

我的习惯：新项目启动时，第一件事不是写业务代码，而是搭日志采集管道。先把「眼睛」装上，再干活。

1.2 三大核心目标

日志采集不是「记了就完事」。你得想清楚：记这些日志到底为了什么？我个人把它拆成三个维度。

1.2.1 可观测性（Observability）

可观测性这个词最近很火。但别被概念绕晕了——它要解决的就是一个问题：系统现在到底在干嘛？

我习惯把可观测性比作汽车的仪表盘。你开车时不会等发动机冒烟了才知道有问题，而是看转速表、水温表、油量表来实时判断。日志就是系统的「仪表盘数据」。

具体来说，日志在可观测性里扮演三个角色：

  • Metrics 的补充——指标告诉你「CPU 飙到 90% 了」，日志告诉你「是哪个接口导致的」。
  • Tracing 的锚点——链路追踪告诉你请求经过了哪些服务，日志告诉你每个服务里具体发生了什么。
  • 健康状态的晴雨表——错误率、延迟分布、慢查询，都能从日志里聚合出来。

注意：可观测性不是「日志越多越好」。我见过有人把每个循环里的变量都打出来，结果一天产生几十 TB 数据，查询慢得像蜗牛。日志要有目的性，不是流水账。

1.2.2 故障排查（Troubleshooting）

这是日志最原始、也最核心的用途。系统出问题了，你第一反应是什么？我猜是「翻日志」。

但「翻日志」和「高效排查」之间，差着十万八千里。我曾经接手过一个遗留系统，日志全打在一个文件里，没有时间戳、没有级别、没有请求 ID。出问题时，几个开发一起 grep，像大海捞针。

好的故障排查日志，应该满足三个条件：

  1. 可关联——每条日志带上 traceId、requestId，能把一次请求的所有日志串起来。
  2. 有上下文——不光说「出错了」，还要说「谁调了哪个接口、传了什么参数、在哪一步挂的」。
  3. 分级别——ERROR 是真正的问题，WARN 是潜在风险，INFO 是正常流程。别把 INFO 当 DEBUG 用。
// 反面案例
log.info("用户登录失败");

// 正面案例
log.warn("用户登录失败 | userId={} | ip={} | reason={}", 
    userId, clientIp, "密码错误超过5次");

我的经验：每次写日志时，问自己一句——「如果明天线上出问题，我看到这条日志能定位到原因吗？」不能？那就重写。

1.2.3 安全审计（Security Audit）

安全审计这块，很多人觉得「跟我没关系，那是安全团队的事」。但真出了安全事件，第一个被问责的往往是研发——「为什么没记录谁访问了敏感数据？」

我经历过一次内部审计，对方要求提供过去 90 天所有管理员操作记录。幸好我们当时做了操作日志采集，不然真没法交代。

安全审计日志的核心要求：

  • 不可篡改——日志一旦写入，就不能被修改或删除。至少要有 append-only 的保障。
  • 完整记录——谁（Who）、什么时间（When）、从哪（Where）、做了什么（What）、结果如何（Result）。
  • 长期保存——审计日志的保留周期通常以年为单位，不是几天。
审计要素 日志字段示例 说明
Who userId, role, sessionId 谁发起的操作
When timestamp (精确到毫秒) 操作发生的时间点
Where clientIp, serverIp, region 从哪来、到哪去
What action, resource, params 具体做了什么
Result statusCode, errorMsg 成功还是失败

1.3 三大目标的关系

这三个目标不是孤立的。它们像三根柱子，撑起了一个可靠的日志体系。

我画了张图，帮你理清它们之间的关系：

日志采集三大核心目标关系图 日志采集（基础设施） 可观测性 系统实时状态感知 故障排查 问题定位与恢复 安全审计 合规与溯源 系统可靠性 & 业务连续性 三者互相支撑：可观测性帮你提前发现隐患，故障排查帮你快速止血，安全审计帮你事后追责 缺少任何一环，日志体系都是「瘸腿」的

你看，日志采集在最底层，支撑着上面三个目标。而这三个目标最终都指向同一个方向——让系统更可靠，让业务更稳定。

1.4 避坑指南：新手最容易犯的错

讲了这么多理论，来点实际的。我总结了几条新手常踩的坑：

  • 坑一：日志打得太随意——想到哪打到哪，没有统一格式。结果就是没法解析、没法聚合。
  • 坑二：只打 ERROR，不打 INFO——出问题时没有上下文，光看 ERROR 根本不知道前因后果。
  • 坑三：日志不轮转——一个文件写到几十 GB，服务器磁盘直接打满。嗯，我当年就干过这事。
  • 坑四：敏感信息不打码——把用户密码、身份证号直接打出来，审计来了直接凉凉。

我曾经踩过的坑：有一次把 DEBUG 级别的日志直接打到生产环境，结果一天产生了 2TB 数据，ELK 集群直接被打挂。从那以后，我强制要求所有服务必须用日志级别动态调整——线上只开 INFO 以上，需要排查时再临时开 DEBUG。

好了，这一章就聊到这。日志采集不是「写几行代码就完事」的活，它需要你从一开始就想清楚：为什么记、记什么、怎么用。后面我们会一步步深入，把每个环节的坑都给你填平。

← 上一章 📖 返回目录 下一章 →