3、统一日志格式标准:JSON vs Syslog vs CEF——如何选择?

日志格式这个话题,说实话,每次我和团队讨论都会有不同意见。有人觉得 Syslog 够用了,有人非 JSON 不可,还有人坚持 CEF 才是 SIEM 的「原配」。我做过好几个对接项目,踩过不少坑。今天就把我的经验摊开来讲。

你想想看,接口日志如果格式不统一,SIEM 解析的时候简直是一场灾难。所以选对格式,是第一步。

3.1 三种格式的「出身」与「性格」

先简单认识一下这三个选手。

格式 出身年代 核心特征 典型应用
Syslog 1980年代 纯文本,无结构化约束 网络设备、Linux 系统
CEF 2000年代 键值对,ArcSight 定义 安全设备、SIEM 对接
JSON 2010年代 结构化,嵌套灵活 云服务、API、微服务
我的习惯:新项目优先考虑 JSON。但如果是对接老牌安全设备,CEF 往往更省心。

3.2 Syslog——老将,但别轻视它

Syslog 是日志界的「活化石」。我在一个金融项目里遇到过,核心防火墙只输出 Syslog,而且格式非常「随意」。嗯,那时候我才意识到,解析 Syslog 有多痛苦。

优点

  • 几乎所有设备都支持
  • 传输协议成熟(UDP/TCP/TLS)
  • 配置简单,开箱即用

缺点

  • 没有固定结构,不同厂商的 Syslog 长得完全不一样
  • 无法表达嵌套关系
  • 时间戳格式不统一,解析容易出问题
避坑指南:我曾经因为 Syslog 的时间戳格式不一致,导致 SIEM 的事件时间线错乱。后来不得不写一大堆正则去适配。如果你必须用 Syslog,一定提前约定好时间格式。

说白了,Syslog 适合那些「能通就行」的场景。但如果你想做精细化分析,它会让你头疼。

3.3 CEF——安全领域的「通用语言」

CEF(Common Event Format)是 ArcSight 推出来的。它本质上是键值对,但比 Syslog 规范很多。我在一个 SOC 项目里,用 CEF 对接了 10 多种安全设备,效果不错。

优点

  • 字段命名统一(如 src、dst、msg)
  • SIEM 解析效率高
  • 支持扩展字段

缺点

  • 格式偏臃肿,可读性一般
  • 不适合复杂嵌套
  • 生态局限在安全领域

你想想看,如果你的 SIEM 是 ArcSight 或 QRadar,CEF 几乎是首选。但如果是 Elastic Stack,JSON 会更顺手。

// 一个典型的 CEF 日志示例
CEF:0|Vendor|Product|1.0|100|Login Failed|5|src=10.0.0.1 dst=10.0.0.2 msg=Invalid password
关键点:CEF 的「0」是版本号,「5」是严重等级。这两个位置不能填错,否则 SIEM 可能无法正确识别。

3.4 JSON——现代日志的「标准答案」

JSON 是我个人最喜欢的格式。它灵活、可读性强,而且几乎所有现代工具都支持。我在一个云原生项目里,所有微服务都输出 JSON 格式,接入 SIEM 几乎零阻力。

优点

  • 结构化强,支持嵌套
  • 解析器成熟(Logstash、Fluentd 都原生支持)
  • 人类可读,调试方便

缺点

  • 体积偏大,带宽和存储成本高
  • 字段命名容易「各自为政」
  • 需要内部约定 schema
// 一个 JSON 日志示例
{
  "timestamp": "2025-03-15T14:23:10Z",
  "event": "login_failed",
  "severity": 5,
  "source_ip": "10.0.0.1",
  "dest_ip": "10.0.0.2",
  "message": "Invalid password"
}
我建议:用 JSON 时,一定要提前写好 schema。我在项目中吃过「字段名不统一」的亏——有人写 src_ip,有人写 sourceAddress,解析起来一团糟。

3.5 到底怎么选?——我的决策框架

说了这么多,你可能会问:我到底该用哪个?别急,我画了一张图,你一看就明白。

日志格式选择决策流程 你的日志从哪来? 老牌网络/安全设备 建议:Syslog 或 CEF 现代云服务 / API / 微服务 建议:JSON(首选) SIEM 是什么平台? ArcSight / QRadar → CEF Elastic / Splunk → JSON 其他 SIEM → 优先 JSON 核心原则:设备生态 + SIEM 平台 + 团队维护能力,三者平衡

决策逻辑其实很简单:

  1. 看设备来源——老牌设备优先考虑 Syslog/CEF,现代服务直接用 JSON。
  2. 看 SIEM 平台——ArcSight/QRadar 对 CEF 有加成,Elastic/Splunk 对 JSON 更友好。
  3. 看团队能力——如果团队对正则不熟,别碰 Syslog;如果 JSON schema 管不好,CEF 更稳。

3.6 我的实战建议

最后,分享几条我自己的「铁律」:

  • 能用 JSON 就用 JSON。 除非设备只支持 Syslog,或者 SIEM 强制要求 CEF。
  • 一定要做 schema 校验。 我曾经因为 JSON 里多了一个字段,导致下游解析直接崩了。加一层校验,能省很多事。
  • Syslog 要「加壳」。 如果只能用 Syslog,我建议在外面包一层 JSON 元数据(比如加个 @timestamp 和 @source),方便 SIEM 统一处理。
  • CEF 注意版本号。 填错版本号,SIEM 可能直接丢弃日志。别问我怎么知道的...
再说一个坑:我曾经在项目里混用了 CEF 和 JSON,结果 SIEM 解析器需要两套规则,维护成本翻倍。尽量统一格式,别搞「混搭」。

好了,三种格式的选型思路就聊到这。记住一句话:没有最好的格式,只有最合适的场景。 你只要把设备生态、SIEM 平台和团队能力三个维度想清楚,答案自然就出来了。