📚 课程目录第2章日志格式标准

日志格式标准：Syslog、JSON、XML 格式解析与字段定义

聊到产线审计日志，第一个绕不开的问题就是：日志长什么样？

我见过不少团队，一上来就急着写采集脚本、搭平台，结果日志格式五花八门，解析脚本写了一堆 if-else，最后数据对不上，溯源查半天。说白了，格式不标准，后面全是坑。

这一节，我就带你把这三种最常见的日志格式——Syslog、JSON、XML——彻底吃透。你想想看，搞懂了它们，后面做解析、建索引、做分析，才能顺手。

2.1 Syslog 格式：工业界的“老大哥”

Syslog 是日志界的元老。从路由器、交换机到 PLC、CNC 控制器，几乎都支持它。我个人习惯把它叫做“流式文本协议”，因为它就是一行一行的字符串，简单粗暴。

2.1.1 标准格式长什么样？

RFC 5424 定义了现代 Syslog 格式。一个完整的 Syslog 消息包含三个部分：

HEADER：优先级（PRI）、版本、时间戳、主机名、应用名、进程 ID、消息 ID
STRUCTURED-DATA：可选的结构化数据段，用方括号包裹
MSG：实际的日志正文

举个例子，一条产线 PLC 的报警日志：

<134>1 2025-03-21T14:32:10.123Z plc-line-03 APP_CTRL 1234 ALARM001 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] Temperature sensor #3 exceeded threshold: 85.2°C

拆开来看：

<134>：优先级，计算方式是 Facility * 8 + Severity。134 = 16*8 + 6，表示 Local0 设施、Informational 级别。
1：版本号。
2025-03-21T14:32:10.123Z：时间戳，精确到毫秒，带时区。
plc-line-03：主机名，这里我习惯用产线编号。
APP_CTRL：应用名，比如控制程序。
1234：进程 ID。
ALARM001：消息 ID，用于快速分类。
[exampleSDID@32473 ...]：结构化数据，可以塞键值对。
最后是消息正文。

我的经验： 在产线场景中，我建议把 设备ID、工单号、工序号 塞进结构化数据段。这样后续做过滤和关联分析会非常方便。我曾经在一个汽车零部件产线上，就是因为结构化数据里没带工单号，排查一批次不良品时，硬是翻了三天原始日志。

2.1.2 产线常用的 Facility 和 Severity

Facility 值	含义	产线场景举例
16 (Local0)	本地使用 0	PLC 控制器日志
17 (Local1)	本地使用 1	SCADA 系统日志
18 (Local2)	本地使用 2	MES 系统日志
19 (Local3)	本地使用 3	机器人控制器日志

Severity 值	级别	产线含义
0	Emergency	系统不可用，全线停机
1	Alert	需要立即处理，如安全门打开
2	Critical	关键故障，如主轴过载
3	Error	一般错误，如传感器通信失败
4	Warning	警告，如温度接近上限
5	Notice	正常但重要的事件，如换刀完成
6	Informational	常规信息，如启动完成
7	Debug	调试信息，一般不启用

注意： 很多老旧设备只支持 RFC 3164（BSD Syslog）格式，时间戳不带年份，也没有结构化数据。如果你遇到这种设备，解析时一定要做兼容处理。我曾经在一条 2010 年的生产线上吃过这个亏，解析脚本直接崩了。

2.2 JSON 格式：现代系统的“通用语”

JSON 现在几乎是标配了。结构清晰、解析快、天然支持嵌套。我个人非常推荐新上线的产线系统优先使用 JSON 格式输出日志。

2.2.1 产线 JSON 日志的字段定义

我总结了一套产线审计日志的 JSON 字段规范，你可以直接参考：

{
  "timestamp": "2025-03-21T14:32:10.456Z",
  "log_level": "ERROR",
  "source": {
    "device_id": "CNC-003",
    "device_type": "CNC_Machine",
    "ip_address": "192.168.1.103",
    "application": "SpindleControl"
  },
  "event": {
    "event_id": "SPINDLE_OVERLOAD",
    "event_type": "FAULT",
    "description": "Spindle motor current exceeded threshold"
  },
  "context": {
    "work_order": "WO-20250321-0042",
    "product_code": "P-8812-A",
    "station_id": "ST-05",
    "operator_id": "OP-1024"
  },
  "measurements": {
    "motor_current": 45.2,
    "threshold": 40.0,
    "unit": "A"
  },
  "metadata": {
    "log_version": "2.0",
    "data_center": "DC-SH-01",
    "environment": "production"
  }
}

这里有几个关键点：

timestamp：必须用 ISO 8601 格式，带时区。别用时间戳整数，可读性太差。
source：谁产生的日志。设备 ID、类型、IP、应用名，缺一不可。
event：发生了什么。事件 ID 建议用大写+下划线，方便机器处理。
context：业务上下文。工单、产品、工位、操作员，这是审计溯源的关键。
measurements：数值型数据。带上单位，避免歧义。
metadata：元数据。版本号、数据中心等，方便运维。

  核心原则： JSON 日志的字段名统一使用 snake_case（小写+下划线），不要混用 camelCase 或 PascalCase。团队内部一定要有字段字典，否则后期维护就是灾难。

2.2.2 嵌套 vs 扁平：怎么选？

你可能会问：字段是嵌套好还是扁平好？

我的建议是：适度嵌套。完全扁平会导致字段名过长（比如 source_device_id），而嵌套过深又会影响解析性能。一般嵌套 2-3 层就够了。

2.3 XML 格式：老系统的“倔强”

XML 现在用得少了，但在一些老牌 MES 系统、半导体设备（比如 SECS/GEM 协议）里，你依然会碰到它。嗯，这里要注意，XML 的解析开销比 JSON 大，但它的优势是自带 Schema 校验，数据完整性更好。

2.3.1 产线 XML 日志示例

<AuditLog>
  <Header>
    <Timestamp>2025-03-21T14:32:10.789Z</Timestamp>
    <LogLevel>WARNING</LogLevel>
    <Version>1.2</Version>
  </Header>
  <Source>
    <DeviceID>ROBOT-007</DeviceID>
    <DeviceType>ArticulatedRobot</DeviceType>
    <IPAddress>10.0.0.77</IPAddress>
  </Source>
  <Event>
    <EventID>GRIPPER_FORCE_LOW</EventID>
    <EventType>WARNING</EventType>
    <Description>Gripper force below threshold, possible slip</Description>
  </Event>
  <Context>
    <WorkOrder>WO-20250321-0051</WorkOrder>
    <PartID>P-9012-B</PartID>
  </Context>
  <Measurements>
    <Parameter name="gripper_force" unit="N">12.5</Parameter>
    <Parameter name="threshold" unit="N">15.0</Parameter>
  </Measurements>
</AuditLog>

XML 的字段定义思路和 JSON 类似，但更啰嗦。如果你要解析 XML 日志，我建议使用 XPath 或 XSLT，不要手写字符串解析，容易出错。

避坑指南： 我曾经接手过一个项目，上游系统用 XML 输出日志，但字段名大小写不统一（有的用 DeviceID，有的用 deviceId）。解析时 XPath 大小写敏感，导致一堆日志没被解析到。所以，XML 的字段命名规范一定要写进接口文档，并且用 XSD 做强制校验。

2.4 三种格式对比与选型建议

维度	Syslog	JSON	XML
可读性	中等（需解析头部）	高	低（标签多）
解析性能	高（纯文本）	高	低（需 DOM/SAX）
结构化能力	弱（需扩展）	强（原生支持）	强（Schema 校验）
设备兼容性	最广（几乎所有设备）	较广（新设备）	窄（特定行业）
推荐场景	网络设备、PLC、老旧控制器	新产线系统、微服务、边缘网关	MES、半导体设备、合规要求高的场景

我的个人建议是：能上 JSON 就上 JSON。如果设备只支持 Syslog，那就用 Syslog，但一定要在结构化数据段里补充业务字段。XML 嘛，除非上游强制要求，否则尽量别主动选。

2.5 本章知识体系图

下面这张图帮你梳理了三种格式的核心要素和选型逻辑：

2.6 字段定义与规范：统一才是王道

不管你选哪种格式，字段定义必须统一。我见过最离谱的情况是：同一个产线，PLC 用 Syslog，SCADA 用 JSON，MES 用 XML，三个系统的字段名各叫各的，最后做关联分析时，光字段映射就写了 200 行代码。

这里我给出几条硬性规范：

字段命名：统一使用英文小写+下划线（snake_case）。禁止中文、拼音、大小写混用。
时间格式：统一使用 ISO 8601，带时区（如 2025-03-21T14:32:10.123Z）。
设备标识：设备 ID 全局唯一，建议用“产线编号-设备类型-序号”的格式（如 LN03-CNC-007）。
事件 ID：大写+下划线，按“模块_动作_状态”命名（如 SPINDLE_TEMP_OVER_LIMIT）。
日志级别：统一使用 Syslog 的 8 级标准（Emergency ~ Debug），不要自己发明级别。

警告： 字段规范一定要写入《产线日志接入标准文档》，并在设备上线前做格式校验。我曾经因为没做校验，一条 JSON 日志里混进了制表符，导致整个日志采集管道阻塞了 2 小时。这种低级错误，犯一次就够了。

好了，格式标准就讲到这里。你只要记住：选对格式、定好字段、统一规范，后面的解析和分析才能顺风顺水。