二、日志体系基础：日志分类、日志级别与存储格式
好，咱们进入正题。日志体系，说白了就是PIS系统的“黑匣子”。你想想看，列车跑在线路上，屏幕突然黑了，广播突然哑了，你远程怎么查？靠的就是日志。
我个人习惯，把日志体系拆成三块来理解：分什么类、定什么级、存成什么样。这三块搞明白了，后面做日志分析、远程维护，才有根基。
2.1 日志分类：系统日志、应用日志、安全日志
PIS系统的日志，我一般分成三大类。这不是我瞎编的，是实际运维中，你排查问题时的三条路径。
- 系统日志：记录操作系统、硬件驱动、网络接口的状态。比如“网卡down了”、“磁盘空间不足”、“CPU温度过高”。
- 应用日志：记录PIS软件自身的运行轨迹。比如“播控软件启动”、“视频流切换”、“到站触发成功”。这是咱们最常看的。
- 安全日志：记录登录、权限变更、异常访问。比如“用户admin远程登录”、“配置文件被修改”、“非法IP尝试连接”。
我记得有一次，某条线路的PIS频繁黑屏。应用日志里啥也没报，干干净净。我差点怀疑是硬件问题。后来翻了系统日志，才发现是系统时间被NTP同步跳变，导致播控进程崩溃。你看，只看一类日志，容易掉坑里。
2.2 日志级别：DEBUG / INFO / WARN / ERROR / FATAL
级别这东西，说白了就是给日志贴个“严重程度”的标签。我见过不少项目，日志级别设得乱七八糟，要么全是INFO，要么全是ERROR，分析起来头大。
咱们PIS系统，一般用这五个级别，从低到高：
| 级别 | 含义 | 典型场景 |
|---|---|---|
| DEBUG | 调试信息 | 变量值、函数入口出口、循环次数 |
| INFO | 正常信息 | 服务启动、播控切换、到站触发 |
| WARN | 警告 | 磁盘使用率超80%、网络延迟偏高 |
| ERROR | 错误 | 播控进程崩溃、数据库连接失败 |
| FATAL | 致命错误 | 系统宕机、主控板完全失联 |
嗯，这里要注意：生产环境千万别开DEBUG。为什么？我经历过一次，某条线路的PIS控制器，DEBUG一开，一天能刷几个GB的日志，直接把存储写爆了，系统卡死。后来我定了个规矩：生产环境只保留INFO及以上，DEBUG只在测试环境用。
2.3 日志存储格式：结构化与非结构化
日志存成什么样，直接影响你后续能不能快速分析。我见过最原始的，就是纯文本，一行一行地写，看着像天书。现在咱们PIS系统，主流做法是结构化日志。
什么叫结构化？说白了，就是每条日志都按固定的模板来写，比如JSON格式。举个例子：
{
"timestamp": "2025-03-21 14:30:00.123",
"level": "ERROR",
"module": "PlayerService",
"thread": "main-12",
"message": "视频流播放失败",
"details": {
"url": "rtsp://10.1.1.100:554/stream1",
"error_code": 1003,
"retry_count": 3
}
}你看，时间、级别、模块、线程、消息、详情，一目了然。用工具（比如ELK、Graylog）一搜，就能快速定位问题。
我个人建议，PIS系统的日志存储格式，至少包含以下字段：
- 时间戳：精确到毫秒，带时区。别问我为什么，跨时区线路调试时你就知道了。
- 日志级别：DEBUG/INFO/WARN/ERROR/FATAL
- 模块名称：比如播控模块、广播模块、通信模块
- 线程/进程ID：方便追踪并发问题
- 消息体：描述发生了什么
- 上下文：比如设备ID、线路ID、车厢号
你想想看，如果日志格式不统一，有的写“播放失败”，有的写“视频流异常”，你拿什么去聚合分析？所以，我每次做PIS系统设计，第一件事就是定日志规范，格式写进开发文档里，谁不按规范来，代码review直接打回。
好了，日志体系的基础就这些。分类让你知道去哪找，级别让你知道有多严重，格式让你知道怎么查。下一节，咱们聊聊日志采集和传输，那又是另一番天地了。