3.1 日志的四大类型

3.1 日志的四大类型

本节摘要：日志并不只有"应用打的 text"。按来源和用途，日志至少该分成系统、应用、访问、安全四类，每类的价值、生命周期、给人看和给机器看的角度都不同。本节把这四类日志的边界、代表例子和取舍策略都理清楚，并告诉你为什么"分不清日志类型"会在你凌晨查问题时拖后腿。

一张日志文件混着一百种身份

新团队最常见的问题不是没日志，而是日志全都一股脑堆着、分不清来源。于是查询时你是这样的：搜"error"，弹出来的有内核日志、有业务日志、有 Nginx 访问日志，每一条都号称是 error，但你根本不知道哪个值得半夜爬起来。恰恰是"分不清类型"的混乱，让你在事故里一个多小时翻不对地方。

把四类日志分清楚，本质是一次"按用途打标签"的整理——你的排查就不再是无头苍蝇。

第一类：系统日志

系统日志由操作系统、内核、硬件驱动、系统服务产生。典型来源是 Linux 的 syslog 体系，记录内核报错、硬件告警、服务启停、登录认证这类 OS 层事件。

它的价值在于"机器健康"和"安全痕迹"：内核恐慌、磁盘 IO 错误、网络接口 down、登录失败刷屏。排查方向通常是"这台机器本身有没有问题"，它在应用层故障掩盖下常常被忽视，但往往是根因所在地——比如应用报错满天飞，其实背后是磁盘只读挂载、文件系统满了这类系统级故障。

系统日志的生命周期一般较长，特别是安全日志，需要保留较长时间供审计。它的格式通常是一行结构化：时间戳、主机名、服务/进程、消息。可参考样例：Sep 01 03:12:55 api-01 kernel: EXT4-fs error (device sda1) ...。

第二类：应用日志

应用日志是业务代码自己打的，记录业务处理的脉络：谁在什么时间处理了什么请求、遇到什么异常、处理结果如何。这是排障时最直接的一手证据，也是量最大的那一类。

它的格式最随意——全看你代码里日志打得好不好。结构化日志能做到机器可读（见 3.2），跑出可聚合的字段；乱打的自由文本则只能给人看，检索时靠模糊搜索，很容易漏。

应用日志的生命周期取决于你需不需要回溯：高价值业务日志长留，低价值 debug 日志短留。建议按业务和级别分段保留，而不是一刀切。

第三类：访问日志

访问日志描述"请求流量"，通常由网关/服务器产生，记录每一次 HTTP 请求的入与出：来源 IP、时间、URL、状态码、耗时、User-Agent。典型来源是反向代理（Nginx）或应用服务器自带日志。

访问日志有两个大用途。一个是性能/流量洞察：你可以从它任意切 QPS、按路径分组、算 P95 延迟，相当于从外部视角统计了你的服务真实被怎么访问。另一个是安全审计：异常来源、扫端口、刷接口，都可以从访问日志里看出来。

它的格式高度统一（Nginx 的 log_format 决定），所以很适合机器解析和聚合。生命周期通常较长，尤其对外服务，访问日志是回溯"当时发生了什么流量"的有力证据。

第四类：安全日志

安全日志记录与安全相关的行为和事件。除了上面提到的登录认证、权限变更，还包括防火墙/IDS 的告警、证书失败、异常访问模式等。有些团队把安全日志全塞进 syslog，有些会单独切隔离区。

它的价值在审计与合规：出了安全事故，你要能把"谁在何时做过什么"完整还原出来，这依赖安全日志的完整性和长期保留。安全日志的量通常不大，但合规要求往往严格，保留周期可能按年算——所以通常要单独规划存储，而不是和业务日志一起滚动。

四类日志对照表

分类的价值：一篇事故的教训

讲个切身体会。有次凌晨被叫醒，网上签名服务大量报"网关超时"。值班人先在应用日志里翻了一小时没头绪——因为真实根因是系统日志里的一条"文件系统 read-only"。为什么没先看系统日志？因为他的习惯是"出问题只看应用日志"。这就是分类没入脑的最贵教训：排查路径应当按类型规划，系统层异常先看系统日志，业务异常再看应用日志，流量异常看访问日志，按图索骥，比什么都核对要快得多。

我的建议：日志统一集中化后，第一件事就是给每条日志打上 type 标签（system/application/access/security）。这不只是方便人看，更是给后续自动归类、权限隔离、保留周期管理打基础。一个 type 字段，换来的是排查时少走几百次弯路。

分类之后还要分层级与保留区

光分类型还不够，同一类型里还要按级别和保留策略再切一刀——否则还是会在存储和查询上打架。级层建议就两级：可留长（系统、安全、以及高价值业务日志）和可短期滚动（debug、临时探针、低价值应用日志）。保留策略分别处理：可留长的进独立索引、设更长的生命周期;可短期滚动的进缓存池,满了就扔掉。很多团队去纠结"到底留多久"，其实先把"哪些必须长留"和"哪些可以随时丢"分清,剩下的量自然就明朗了。

另外,权限也要按类型切：运维看系统与应用日志,安全团队看安全日志,业务看本业务访问日志。日志一旦集中化,它就是敏感资产,别把安全日志和业务日志塞进同一个人人能查的桶——这和把审计记录和日常聊天放一个文件柜没什么两样。

本节要点回顾

• 四大类型：系统/应用/访问/安全，各自来源与价值不同。
• 系统日志看机器健康：应用报错满天飞，根因常藏在这里。
• 应用日志是一手证据：量最大，格式决定后续可分析性。
• 访问日志看流量：QPS、路径分组、P95 都能从它算出来。
• 安全日志看审计：量小但要按年留，事故还原靠它。
• 统一打 type 标签：让排查按类型走，别什么都核对。
• 保留策略分开：别一刀切，业务可按级别、安全按合规。

类型分清了，下一个要解决的是"怎么让日志能被机器读懂"——一切查询、聚合、关联的前提都建立在结构化之上，这是下一节的重头戏。