📚 课程目录第3章日志源识别

3、日志源识别：哪些东西需要采集？

做日志采集，第一个问题往往不是「怎么采」，而是「采什么」。

我见过不少团队，一上来就铺采集器，恨不得把服务器上所有文件都收走。结果呢？磁盘爆了，ES 集群挂了，真正出故障时却找不到关键日志。说白了，日志源识别是地基——地基没打好，后面全是坑。

  核心原则：不是所有日志都值得采集，但该采的日志一条都不能少。

应用日志是我们排查问题的第一手资料。我个人习惯把应用日志分成三类：

这里有个常见的坑：很多人只采 error.log，觉得业务日志不重要。我在项目中遇到过好几次，线上出了故障，error.log 里只有一行「NullPointerException」，根本看不出上下文。最后还得靠业务日志里的请求参数和调用链路才能定位问题。

我的建议：业务日志和错误日志必须同时采集。业务日志提供上下文，错误日志提供异常点，两者缺一不可。

系统日志反映的是服务器自身的健康状况。你想想看，应用跑得好好的，突然挂了，是应用的问题还是系统的问题？没有系统日志，你根本没法判断。

需要重点关注的系统日志包括：

嗯，这里要注意：系统日志的采集频率不用太高。我一般设置 10-15 秒轮询一次就够了，没必要像应用日志那样实时。系统日志的特点是「平时没啥用，出事时救命」。

我曾经踩过的坑：有一次线上服务频繁重启，查了应用日志啥也没发现。后来翻了 syslog，才发现是 OOM Killer 把进程干掉了。如果当时没采系统日志，这个故障可能得排查好几天。

容器化之后，日志采集的复杂度直接翻倍。为什么？因为容器是动态的——它会创建、销毁、迁移，传统的「tail -f 一个文件」的方式根本行不通。

容器日志主要有三种输出方式：

输出方式	说明	采集方式
stdout/stderr	容器标准输出	Docker 的 json-file driver 或 Fluentd 直接采集
容器内文件	应用写在容器里的日志文件	挂载 volume 或使用 sidecar 采集
Kubernetes 事件	Pod 调度、重启、健康检查等事件	通过 kube-apiserver 的 Event API 采集

我个人习惯的做法是：优先采 stdout/stderr。因为这是容器日志的「标准接口」，不管应用用什么语言写的，只要输出到标准输出，采集器就能统一处理。容器内文件太分散了，维护成本很高。

一个小技巧：在 Kubernetes 环境下，建议给每个 Pod 加一个 sidecar 容器专门做日志采集。这样主容器挂了，日志还能正常采集出去。

网络设备日志——交换机、路由器、防火墙、负载均衡器——这些家伙平时不声不响，一旦出问题就是大面积故障。

网络设备日志的采集方式比较特殊：

我记得有一次，整个机房的网络突然变得很慢。应用日志、系统日志都查了，啥也没发现。最后是防火墙的 syslog 告诉我们——有人在跑 P2P 下载，把带宽占满了。如果没有网络设备日志，这个问题根本无从下手。

注意：网络设备日志的格式五花八门，同一个厂商的不同型号都可能不一样。采集之前一定要先做日志格式解析，不然采回来也是一堆乱码。

说了这么多，我画了一张图帮你梳理一下：

最后，我总结几个自己踩过的坑，希望能帮你少走弯路：

「全量采集」陷阱：我曾经有个项目，把所有日志文件都采了，结果每天产生 2TB 数据，ES 集群直接撑爆。后来只保留关键日志，数据量降到 200GB，排查效率反而更高了。
「只采不解析」陷阱：日志采回来了，但格式没解析，全是原始文本。搜索的时候只能全文检索，慢得要死。记住：采集之前先想好怎么解析。
「忽略元数据」陷阱：日志内容本身很重要，但时间戳、主机名、服务名这些元数据同样关键。没有元数据，你根本不知道这条日志是哪个机器、哪个服务、什么时间产生的。
「静态配置」陷阱：日志源不是一成不变的。应用升级了、容器迁移了、网络设备更换了，采集配置也要跟着变。建议用配置中心或服务发现来管理，别手动改配置文件。

一句话总结：日志源识别不是「采不采」的问题，而是「采什么、怎么采、采了怎么用」的系统工程。想清楚再动手，比盲目铺采集器强一百倍。