日志标准与格式：Syslog、JSON、CEF
日志格式这东西，说小很小，说大能让你排查问题到崩溃。我见过太多团队因为格式不统一，告警解析出错，甚至把正常流量当成攻击。今天咱们就聊聊三种最常见的格式：Syslog、JSON、CEF。掌握了它们，你基本能应对90%以上的日志场景。
Syslog：最老牌的日志协议
Syslog 诞生于 80 年代，最初是 UNIX 系统的日志标准。你别看它老，现在网络设备、Linux 服务器、防火墙全在用。它的核心思想很简单：设施 + 严重级别 + 消息体。
- 设施（Facility）：标记日志来自哪个子系统，比如 kern、auth、mail、local0~7。
- 严重级别（Severity）：0~7，0 最高（Emergency），7 最低（Debug）。
- 消息体：时间戳、主机名、进程名、进程ID、实际日志内容。
以前我在维护一个 Cisco 路由器集群时，遇到过大量冗余的 Debug 日志淹没了消息队列。排查了半小时才发现是某个接口的 debug 没关。后来我强制规定：生产环境只允许 local0~local3 出站，且 severity ≤ 4（Warning）。
Syslog 原始格式示例：
<14>Feb 3 12:34:56 myserver sshd[12345]: Failed password for root from 192.168.1.100 port 22 ssh2数字 14 是 PRI（计算方式： Facility*8 + Severity），这里 Facility=1（user），Severity=6（Info）。解析时优先剥离这个数字，后续按空格分割即可。
JSON：结构化日志之王
JSON 在 Web 后端、微服务、云原生里几乎是默认选择。你想想看，直接 JSON.stringify() 一下，键值对、嵌套结构、数组都保留，解析成本极低。我用过最爽的一次是在 Kubernetes 集群里，直接把 Pod 日志格式化为 JSON，配合 Loki 做标签索引，检索效率比纯文本高出十几倍。
JSON 格式的问题在于——缺乏标准字段规范。同一个“用户ID”，有人叫 user_id，有人叫 uid，有人叫 userId。我建议你团队内部一定要定义一份 必选字段清单，比如：
| 字段名 | 含义 | 示例值 |
|---|---|---|
| timestamp | ISO8601 时间戳 | 2025-02-03T12:34:56Z |
| level | 日志级别（小写） | error |
| logger | 记录器名称 | com.example.UserService |
| message | 人类可读描述 | Failed login attempt |
| context | 业务上下文对象 | {"ip":"192.168.1.100","user":"root"} |
千万不要把敏感信息塞进 JSON，我见过有人直接把用户密码明文写在日志里，审计时被罚惨了。
避坑指南：JSON 嵌套过深会导致解析性能下降，尤其在高吞吐场景下。我曾经遇到一个 Java 服务每秒输出 5000 条日志，每条 JSON 嵌套 7 层，Logstash 直接被打垮。后来限制嵌套 ≤ 3 层，问题解决。
CEF：安全设备的事实标准
CEF（Common Event Format）是由 ArcSight 定义的，专门用于安全设备日志。说白了，它用键值对格式，但字段名是预定义的。比如源IP叫 src，目标IP叫 dst，动作叫 act。这样 SIEM 系统拿到就能直接关联，不需要额外映射。
CEF 格式的头部固定为：
CEF:0|厂商|设备名|版本|签名ID|名称|严重级别|key=value 键值对举个例子：
CEF:0|Check Point|FireWall-1|R81|100001|Access Deny|5|src=10.0.0.1 dst=192.168.1.100 proto=tcp sport=12345 dport=80我在帮某银行做 SOC 改造时，他们原本用自定义格式，后来统一改成 CEF。改造后报警关联速度提升了 3 倍，因为解析器不再需要写自定义正则了。
个人建议：如果你的安全设备支持 CEF 输出，优先开启。它能直接兼容大多数 SIEM（Splunk、QRadar、ArcSight）。但要注意 CEF 的字段长度限制，某些 SIEM 只解析前 1024 个字符，长字段会被截断。
三种格式核心对比
为了让你一目了然，我画了张对比表：
| 维度 | Syslog | JSON | CEF |
|---|---|---|---|
| 可读性 | 中（依赖正则） | 高（键值对直观） | 高（字段预定义） |
| 结构化程度 | 弱（只有头部分类） | 强（完全结构） | 强（固定+扩展） |
| 解析性能 | 快（无嵌套） | 中（嵌套影响） | 快（扁平KV） |
| 适用场景 | 网络设备/系统日志 | 应用/微服务日志 | 安全设备/ SIEM数据源 |
| 扩展性 | 差（依赖header） | 好（自由KV） | 好（扩展KV） |
| 行业标准 | RFC 5424 | 无强制，团队指定 | ArcSight/CEF specs |
一次性说清楚：什么时候该选哪个？
- 如果你在管服务器、路由器、交换机：Syslog 是标配。别强行改成 JSON，设备不支持。你只需要规划好设施和级别，加上日志聚合器（如 rsyslog、syslog-ng）做转发。
- 如果你的应用是自己开发的：请用 JSON。没有比 JSON 更灵活的现代格式了。配合 ELK / Loki 做索引，查询体验翻倍。
- 如果日志需要进入 SIEM（安全信息与事件管理）：优先 CEF。它能让安全分析师直接拿到关键字段，省去大量字段映射工作。
我曾经在一个项目里同时收到三种格式的日志，统一用 Logstash 做解析。Syslog 和 CEF 都顺滑，唯独 JSON 因为有些字段名不统一，反复提 PR 改应用代码。后来我在 CI 阶段加了一个日志格式校验，不符合定义的直接报错，才彻底解决。
一个实战技巧：如果你的日志量巨大（日均 TB 级），尽量用 Syslog 或者 CEF 这类扁平的 KV 格式。JSON 的序列化和反序列化会额外消耗 20%~40% 的 CPU。我帮某大厂做过压测，同样的流量，Syslog 解析速度是 JSON 的 2.3 倍。
格式切换的避坑清单
嗯，这里再列几个我踩过的坑：
- 时区问题：Syslog 默认不包含时区，统一使用本地时间。如果你多个机房跨时区，必须强制用 UTC。
- JSON 中换行符：如果日志本身含换行符，JSON 会被破坏。我遇到过 Java 堆栈日志打印出来直接断行，导致 ELK 解析失败。处理方式：用
\\n转义。 - CEF 中的特殊字符：管道符
|是分隔符，字段里出现必须转义成\|。等号=在 KV 里是保留字符，也要转义。 - 字符编码：全用 UTF-8。我见过某设备输出 GBK，集成后中文乱码查了三天。
我曾经在一次安全事件排查中，发现防火墙日志因为用了非标准 CEF 格式（厂商自己改了字段名），导致 SIEM 无法关联，错过了入侵告警。后来我要求所有新接入设备必须通过格式检查脚本，否则拒绝接入。
看到这张图了吧？三种格式各有明确的地盘。你不需要纠结于「哪个最好」，而是要问「我的场景最适合哪个」。把这三种格式吃透，我保证你在审计日志采集这条路上能少踩一半的坑。