日志基础：日志格式、日志级别、日志采集方式
做日志分析这么多年，我见过太多人一上来就查日志，结果格式都看不懂，级别也不分，白费半天劲。今天咱就把这块地基夯实——日志格式、日志级别、采集方式，三个核心点，捋清楚了后面关联查询才不会手忙脚乱。
1. 日志格式：别让数据长成“刺猬”
日志格式说白了就是数据长什么样。我刚开始做安全审计那会儿，碰到过一种自定义格式，时间戳用的是毫秒级Unix时间，字段名全是缩写，看得我头皮发麻。后来我养成了一个习惯：拿到新日志源，先看一条原始日志，再对照格式文档，否则后面做查询会掉坑里。
主流日志格式就那么几种，我列个表，你们感受下差异：
| 格式 | 典型样例（片段） | 适用场景 |
|---|---|---|
| JSON | {"timestamp":"2025-04-04T10:00:00Z","level":"ERROR","msg":"Connection timeout"} | 云服务、微服务、容器 |
| Syslog (RFC 5424) | <34>1 2025-04-04T10:00:00Z myhost app 1234 - - Connection timeout | 网络设备、Linux系统 |
| Apache/Nginx 通用日志 | 192.168.1.1 - - [04/Apr/2025:10:00:00 +0000] "GET /api HTTP/1.1" 200 1234 | Web服务器 |
| CEF (Common Event Format) | CEF:0|Security|ThreatManager|1.0|100|Connection timeout|5|src=192.168.1.1 dst=10.0.0.1 | 安全设备、SIEM |
这里重点说下JSON。我个人最爱JSON格式，为什么？字段清晰，嵌套结构能表达复杂关系。我在项目中遇到过某家云厂商的API网关日志，请求头、响应体全塞在一个JSON里，用jq命令解析比grep爽太多。但坑也明显：字段名不规范的时候，比如同一个key在不同环境里大小写不统一，那查询就抓瞎了。我建议你们在收日志阶段就定好schema，或者用日志采集工具做标准化。
head -n 1看第一行，基本能判断格式。如果是JSON，直接用jq .格式化；如果是Syslog，注意头部优先级（<PRI>）和结构化数据部分。
2. 日志级别：哪些该追，哪些该放
日志级别不是随便写的。我见过有人把所有日志都配成ERROR级别，结果真正出问题的时候，没人看日志——满屏都是红色。合理的级别设计，能让后续的日志关联查询事半功倍。
常用的级别从低到高排序：DEBUG → INFO → WARN → ERROR → FATAL。有些系统还会加TRACE和CRITICAL，但核心逻辑一样——级别越高，意味着越严重，需要人工介入的概率越大。
| 级别 | 含义 | 我的经验 |
|---|---|---|
| DEBUG | 调试信息，开发阶段用 | 生产环境千万别开，否则磁盘直接打满 |
| INFO | 正常流程记录，比如用户登录、接口调用 | 关联查询时常用，但别放敏感数据 |
| WARN | 潜在问题，不直接影响功能 | 比如重试次数超阈值、磁盘使用率>80% |
| ERROR | 功能错误，但系统还能跑 | 大部分安全事件都落在这个级别 |
| FATAL | 致命错误，系统可能直接宕掉 | 我遇到过数据库连接池耗尽，直接FATAL报警 |
说白了，日志级别就是给运维人员和审计人员画的“危险等级图”。你在做关联查询时，先过滤level:ERROR OR level:FATAL，能快速缩小范围。如果查不到，再降级到WARN甚至DEBUG。
3. 日志采集方式：数据怎么来的，决定了你怎么查
日志采集方式常见的有三种：Agent采集、Syslog推送、API拉取。我在项目里三种都玩过，各有优缺点。先看对比：
| 方式 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| Agent采集 | 在服务器上装一个进程（如Filebeat、Fluentd），读取本地日志文件后推送 | 低延迟、支持日志旋转、能加元数据 | 需要管理Agent进程、占用系统资源 |
| Syslog推送 | 网络设备或应用通过Syslog协议直接发到中央收集器 | 标准协议、无需额外Agent | 无确认机制、UDP可能丢包、格式有限 |
| API拉取 | 定期调用云服务或应用的REST API获取日志 | 无需修改目标系统、安全可控 | 依赖API限频、时效性差、可能产生费用 |
我举个实际例子。之前有个客户用Kubernetes部署微服务，日志全部写到stdout，然后用Fluentd以DaemonSet形式采集。这种方式特别适合容器环境——每个Pod不需要额外配置，Fluentd自动收集并加上Pod名称、命名空间等标签。但问题来了：如果Fluentd挂了，日志就丢了。所以我又在采集链路上加了个缓冲队列（Kafka），保证至少一次投递。
另一个场景是审计日志。云厂商的CloudTrail或操作审计日志，通常只能通过API拉取。比如AWS CloudTrail，你每隔5分钟调用一次LookupEvents接口。延迟是硬伤，但数据完整性好。我在做DEK轮换审计的时候，就靠API拉取CloudTrail日志，配合CMK的密钥策略日志，查出来是谁在异常时间做了密钥删除操作。
避坑指南
最后分享几个我踩过的坑，希望对你有用：
- 日志格式不一致。 我曾经处理过一个混合环境，部分服务用JSON，部分用Syslog，还有用原始文本的。做关联查询时，时间戳格式都不一样——有的用ISO 8601，有的用Unix时间戳。我后来统一用Logstash做了格式归一化，才把问题解决。
- 日志级别误用。 某次安全事件，攻击者利用的是一个WARN级别的告警，但运维人员只看了ERROR以上的日志。从那以后，我建议在查询时至少把WARN也纳入关注范围，结合频率做基线。
- 采集链路丢数据。 一个Syslog场景，UDP端口没配限流，结果高峰期日志大量丢失。后来我强制要求所有生产环境采集链路必须支持至少一次投递（比如用TCP Syslog或加缓冲区）。
嗯，日志格式、级别、采集方式这三个基础点，看似简单，但每一个都可能成为后续关联查询的瓶颈。我的原则是：在日志落地那一刻就把它管好，后面的分析才能顺风顺水。