搞配电主站日志分析的同行，应该都体会过那种“日志天天有，翻的时候想撞墙”的感觉。故障发生的时候，海量正常记录把真正的异常信号淹没在底下：一个控制器反复重启、一条通道几分钟内连续断开又恢复、某一路遥控总是在同一秒报返校超时……单独看每一条都是不起眼的小事，放在一起就是设备劣化或者网络不稳定的早期信号。去年我在整理某套配电主站系统的运行日志时，索性把这些数据系统性地整理成了一份可供算法训练和评测的配电主站日志异常检测数据集。这篇文章就把整个构建过程摊开来讲：日志从哪些环节来、异常类别怎么定义、标注怎么做、异常检测算法怎么在数据集上评测，以及那些只有实际动过手才会遇到的坑。对做电力数据分析、日志异常检测算法研究，或者想给配网自动化系统加一套智能告警能力的人来说，这份实践记录应该有直接的参考价值。
1. 配电主站日志的源头：先搞清楚数据是从哪几个环节冒出来的
1.1 主站日志的六类主要来源
配电主站不是一台机器，而是一套由前置采集、应用服务、数据库、Web发布、安全审计等多个节点组成的系统。日志散布在各个环节，源头不一样，格式和语义差异也很大。我当时梳理下来，大致可以分成六类：
| 日志类别 | 产生位置 | 典型内容 | 对异常检测的价值 |
|---|---|---|---|
| 系统运行日志 | 应用服务器、前置机 | 服务启停、进程崩溃、CPU/内存告警 | 高，直接反映主站自身健康度 |
| 通信报文日志 | 前置采集模块 | 104规约收发、通道状态切换、超时重连 | 高，配网终端通信中断的直观证据 |
| 告警/遥信日志 | 告警服务、SCADA应用 | SOE事件、遥信变位、越限告警、保护动作 | 高，能发现一次设备异常信号 |
| 操作日志 | 调度操作工作站 | 遥控分合、遥调、对点试验、人工置数 | 中高，能发现误操作和异常频率操作 |
| 安全审计日志 | 认证网关、堡垒机 | 登录成功/失败、权限变更、越权访问 | 中，主要支撑安全类异常 |
| 数据库日志 | 数据库服务器 | 慢SQL、死锁、连接数耗尽 | 中，数据库问题往往被忽略 |
很多人做日志异常检测时只盯住告警日志，这是不够的。配网故障往往是“通信先断、遥信后变、操作再失败”这种链条式的表现，单看一类日志根本拼不出完整画面。我在构建数据集时坚持把六类日志都纳入采集范围，交叉关联之后，很多异常的根因才浮出水面。
1.2 一条日志长什么样：格式差异比想象中更大
举两个真实的例子。第一条是典型的告警日志：
2024-06-15 14:23:11.582 | WARNING | ALARM | 101#间隔 | 过流I段动作 | PS_101_L1_O | 动作 | 1 | 0 | 故障遥信第二条是某前置模块的通信日志：
[14:23:12.004] [INFO] CHN: 0002, 主备通道切换, 主: 192.168.10.21:2404 -> 备: 192.168.10.22:2404, 原因: T1超时, 重连次数: 3看到问题了吗？时间戳格式不同、字段分隔符不同、设备标识不规范（一会儿叫“101#间隔”，一会儿在别的地方写“P_101_L1”）、中英文混杂。把这些数据灌给模型之前，必须做字段抽取和格式统一，这一步不做干净，后面所有工作都是白搭。
1.3 为什么配电主站日志异常检测比IT系统日志更难
IT领域的日志异常检测已经很成熟了，但直接搬到配电主站会很不适应，原因有三个：
第一，数据量级虽然不及互联网，但杂度高。一套中型配网主站一天产生几万到几十万条日志，不算大，但六类日志混在一起、模板五花八门，解析成本远高于统一格式的IT系统日志。
第二，正负样本极度失衡。正常日志可能占99%以上，真正算得上异常的不足1%。更麻烦的是，“异常”并不是一个单一类别——通信重连、遥控失败、遥信抖动、数据库慢查询，各自的特征完全不同，硬塞进二分类会让模型学得四不像。
第三，上下文比单条内容更重要。很多异常是“一段时间内反复出现”的模式，而不是“某一条内容明显不对劲”。比如通道在5分钟内重连了20次，单看每一条重连日志都是正常格式，连起来看就是通信链路劣化。所以这个数据集在构建时，我特别强调了会话窗口和事件序列的切分方式，这一点后面细说。
2. 异常分类体系：给日志打标签前，先定义清楚什么叫“异常”
2.1 按根因划分的六类异常
做数据集绕不开标签体系。我一开始也想简单粗暴地标“正常/异常”，但做了一周就发现不可行——不同来源的异常形态差异太大，二分类标签根本训不出有区分度的模型。最后和几位有经验的调度运维人员反复讨论，按根因把异常分成六类：
通信类异常：通道频繁中断、重复重连、规约解析错误、T0/T1/T2超时。特征是周期性或突发性，常见于站所终端与主站之间的链路问题。
设备状态类异常：进程反复重启、CPU/内存持续高位、磁盘空间写满、时钟失步。特征是持续恶化趋势，比如某服务从一天重启1次变成一小时重启3次。
遥信遥测类异常：遥信频繁变位抖动（1秒内多次翻转）、遥测越限、数据跳变、死数据（长时间不变）。这类数据能反映一次设备状态，也能暴露采集回路问题。
遥控操作类异常：遥控返校超时、执行失败、同一间隔短时内重复操作、操作人与间隔不匹配。这类异常极少但影响大，直接关联到操作安全和设备健康。
安全类异常：非授权访问、短时间内多次登录失败、越权执行命令、账号异常锁定。
数据库类异常：慢SQL、死锁、连接池耗尽、备份任务失败。这类往往被忽略，但主站卡顿、遥信刷新延迟的根因经常在这。
每个大类下面，我还细分子类并用代码编号，比如“通信类-通道中断-C1”“通信类-重连风暴-C2”。实际标注时，先标大类再标子类，能大幅降低标注员的认知负担，也方便后续做细粒度评测。
2.2 影响等级：异常检测不能只看类型，还要看严重程度
六类异常之间没有可比性，一次遥控失败比一次通道重连严重得多，所以数据集里每条异常样本还带一个影响等级：
| 等级 | 定义 | 典型实例 |
|---|---|---|
| L1 紧急 | 可能导致遥控失败、数据中断或主站功能不可用 | 通道全部中断、数据库死锁、进程崩溃 |
| L2 重要 | 能明显反映设备劣化，需要尽快处理 | 重连风暴、遥信频繁抖动、慢SQL持续增长 |
| L3 一般 | 单次影响有限，但多次出现需关注 | 单次登录失败、单次超时、偶发优先级告警 |
| L4 提示 | 不直接影响业务，可记录观察 | 时钟偏差小、例行操作记录 |
这个等级在设计评估指标时非常有用。比如我做基线评测时，会把L1和L2的召回率单独拉出来看，比全局F1更有工程意义——毕竟漏掉一个L1的代价，可能顶得上误报几百条L3。
2.3 标签结构设计成什么样
每条日志样本的标签最终设计成这种结构：
label_type：normal或anomalyanomaly_class：上述六类根因之一，正常样本则为空anomaly_subclass：子类编号severity：L1到L4source_type：日志来源（通信、告警、操作、安全等）
这么做有一个额外好处：可以按不同粒度切出子集做实验。比如只挑“通信类异常”训练一个专用检测器，或者只对L1+L2样本评测模型的高危场景效果。
3. 数据集构建的核心流程：从原始日志到一份能训练能评测的语料
3.1 采集窗口设计：别只取“故障那天”的日志
我见过不少团队做数据集时，专门挑故障前后的日志，结果模型在“故障场景”上表现很好，一上生产就垮——因为正常模式的多样性严重不足。我这次采集了整整十二周的日志，覆盖了三个完整自然月。选这个窗口不是拍脑袋，是因为它覆盖了迎峰度夏负荷波动、一次计划检修、两起雷雨天气跳闸、若干次例行遥控操作，既有密集故障段，也有长时间风平浪静的日常段。正常样本的多样性，和异常样本的覆盖率同等重要。
3.2 数据脱敏：第一周就做，别等录入一半才补
配电主站日志里有大量敏感信息：运维账号、工作站IP、网段、设备资产编号、操作人标识，甚至偶尔出现的明文口令片段。我一开始图快没做统一脱敏，等标注了一部分才返工，结果要把对应字段重来一遍，教训挺深刻。后来定下三条规则：
- 操作人姓名/工号替换为匿名编号（U001、U002……），映射表单独加密保存且不随数据集发布。
- IP地址按网段掩码处理，保留段内相对关系，比如保留“192.168.x.x”的第三段，隐藏最后一段。
- 设备资产编号哈希化，同时保留间隔逻辑名（如101#间隔），因为间隔维度对异常分析有意义。
注意：凡是可能定位到具体设备、具体人员、具体地点的信息，发布前一律脱敏。这个红线不能碰，宁可损失一部分分析粒度，也不能带出真实身份信息。
3.3 清洗与标准化：把“八国联军”变成统一格式
清洗这一步我分成四道工序：
去重。同一事件在多个日志文件中重复记录（比如告警库和报文日志同时记录同一次通道中断），按“时间戳±5秒+事件特征”做近似去重，但保留重复计数作为特征字段，因为重复出现的次数本身就是信号。
字段抽取。用正则从原始文本中抽取出结构化字段：时间、来源模块、事件类型、目标设备、动作结果、重连次数、耗时等。抽不出来的部分保留为
raw_text，不强行丢弃。时间戳归一化。统一到毫秒级、统一时区、统一格式为
YYYY-MM-DD HH:mm:ss.SSS。这一步不做，按时间排序和窗口切分都会出错。编码统一。把混杂的GBK和UTF-8文本统一转为UTF-8，乱码记录单独标记并从训练样本中剔除，但保留在原始数据里备查。
清洗完的日志，每条都维护成JSON结构。核心是下面这样的形式：
{ "timestamp": "2024-06-15 14:23:11.582", "source": "alarm_service", "event_type": "protective_trip", "device": "INT_101", "message": "过流I段动作，101#间隔", "session_id": "SES_20240615_1423_001", "raw_text": "2024-06-15 14:23:11.582 | WARNING | ALARM | 101#间隔 | 过流I段动作 | PS_101_L1_O | 动作 | 1 | 0 | 故障遥信", "label": { "label_type": "anomaly", "anomaly_class": "遥信遥测类", "anomaly_subclass": "T2_保护动作", "severity": "L2" } }这里多出来的session_id是会话窗口标识。我按5分钟固定窗口加连接会话两种方式切分，目的就是让模型能看到“上下文片段”，而不是孤零零的一条日志。
3.4 标注规范与一致性控制：多人标完才知道多难对齐
标注是整个流程里最容易被低估的一步。我把标注流程设计成“两轮标注+专家仲裁”：
- 第一轮由三名标注员背靠背独立标注，每人拿到的是同一批样本，但互不知道其他人的结果。
- 标注选项不是简单的“正常/异常”，而是先判断是否异常，再选异常类别和等级，拿不准的标“不确定”。
- 第二轮对比三人的结果，两两计算一致性指标。对一致率低于阈值的样本抽出来重新讨论，统一判断口径。
当时最典型的争议出现在“遥信抖动”和“正常变位”的边界上：有些间隔在检修期间频繁变位属于正常流程，但在运行期间同样频率变位就是异常。后来我们约定，必须结合同期检修计划表做标注，凡是检修窗口内的操作类变位一律视为正常。这种领域知识如果没有沉淀成标注规则，模型学到的一定是脏标签。
3.5 数据切分：按时间切，不按随机切
训练集、验证集、测试集怎么划分，直接决定评测结果可信度。我见过有人直接train_test_split(random_state=42)，这在日志数据上是错误的——相邻时间段的日志高度相似，随机切分会把同一事件的碎片同时塞进训练集和测试集，指标虚高得离谱。最终我按时间顺序切：前8周做训练集，第9到10周做验证集，最后2周做测试集。测试集是模型完全没见过的“未来数据”，这样评测结果才接近线上真实表现。
4. 用自己的数据集跑异常检测：方法路线和评测基线的经验
4.1 日志解析和特征提取：模板抽取这一步绕不开
日志文本不能直接灌进模型。我先把训练集日志做了模板抽取，把类似“通道0002主备切换”这种高频模式归并为事件模板，给每个模板一个ID，然后把原始日志变成事件序列：
事件ID: 104_CHN_SWITCH, 窗口内出现次数: 7, 间隔秒数均值: 32.5 事件ID: 104_RE_ATTACH, 窗口内出现次数: 3, 间隔秒数均值: 120.3特征方面我用了三组：
- 统计特征：窗口内事件种类数、各事件频次、事件序列熵、重连次数均值、超时占比。
- 时序特征：事件间隔的均值/方差/极值、窗口间频次差分。
- 文本特征：对无法模板化的
raw_text做TF-IDF向量化。
这套特征组合对通信类和遥信类异常非常有效。重连风暴的典型特征是104_RE_ATTACH频次突增且间隔均值骤降，在统计特征上非常明显，一个孤立森林就能抓到。
4.2 检测方法：从规则基到深度学习，分层上看
我用自己的数据集跑了三种路线作为基线，供大家参考：
规则基线。把调度值班规则转成正则和阈值条件，比如“5分钟内重连次数>5”“同一间隔10分钟内遥控失败>2次”。可解释性最好，但覆盖率有限，很多“没见过的新异常”漏掉。
传统机器学习。孤立森林和One-Class SVM在“频次突变型”异常上效果不错，训练快、CPU就能跑，适合做第一道粗筛。问题是对“单条内容怪异但频次正常”的异常（比如某条规约报文结构异常）几乎无感。
深度方法。我试过基于Transformer序列建模事件序列，以及日志自编码器重构误差两种做法。前者效果上限高，能在更长的上下文中捕捉异常模式，但对数据量和算力要求更高，训练也更容易过拟合——毕竟配电主站样本量相比互联网级别还是小。
我自己实际部署时采用的是“分层级联”：先用规则过滤掉已知高频异常，再用机器学习模型捕捉未知异常，深度模型做第二道复核。这样既保证精度，又不至于让告警系统变成“黑盒”。
4.3 评测指标：准确率在这个场景里是个陷阱
异常样本占比不到1%时，模型全部判正常也能有99%准确率，所以准确率完全不参考。我建议用这套指标组合：
| 指标 | 关注点 | 用法建议 |
|---|---|---|
| Precision / Recall | 查准与查全的权衡 | 运维场景建议重点看召回率，宁可多误报也不要漏重大异常 |
| F1 / F0.5 | 综合平衡 | F0.5更偏精度，F1更偏召回；个人更推荐F1 |
| PR-AUC | 阈值无关的整体能力 | 如果你想调阈值，这个指标最直观 |
| 高等级样本召回率 | 评估对L1/L2异常抓得全不全 | 这是我最看重的一个指标 |
我跑孤立森林基线时的实测印象是：通信类异常召回率能做到80%以上，但安全类异常召回率不到40%——因为安全异常在正常样本里太稀薄，特征不够突出。这说明单模型打天下不现实，分类别评测、分类别建模的路子更有价值。
5. 构建过程里踩过的坑和后续维护思路
5.1 四个实打实的坑
第一个坑是脱敏做晚了。前面提过，返工成本极高。现在回头看，第一周就该把字段规范、脱敏脚本、样例数据版本一起定好，而不是等清洗完再考虑。
第二个坑是过度标注。标注员面对不确定样本时，倾向于标成“异常”而不是“不确定”，因为人总觉得“标正常可能漏掉问题”。这直接污染标签。后来我强制规定：拿不准的必须标“不确定”，宁可样本少一点，也不能让噪声混进训练集。
第三个坑是随机划分导致的指标虚高。这个前面已经详细说过，时间切分虽然会牺牲一点指标数值，但换来的是可信度，非常值。
第四个坑是一刀切删除设备标识。刚开始做脱敏做的太狠，把所有间隔名、设备名全部替换成统一占位符，结果模型完全丧失设备维度特征。后来改成“哈希化但保持同一设备前后一致性”，模型学到的信息量立刻不一样了。
5.2 数据集版本管理与持续更新
配网设备在改造、终端在增加、主站版本在升级，日志模板和异常模式都会漂移。一次性的数据集用不了太久，我建议按“数据版本”管理：
- 每次新增批次数据，版本号递增（如v1.2、v2.0），并记录数据采集时段、覆盖站点数、新增异常类别。
- 模型评测结果必须标注对应的数据版本，否则不同版本之间对比没有意义。
- 每隔一段时间做一次“异常模式增量分析”，看训练集中未出现过的新日志模板，判断是否需要补充标注。
我自己的习惯是每季度更新一次数据版本，同步重跑基线模型，观测指标变化。虽然麻烦，但这是让异常检测系统不腐烂的唯一办法。
5.3 发布格式的一点建议
数据集发布时，除了原始JSONL样本，我强烈建议额外附带三样东西：
- 事件模板表：把高频日志模板和对应事件ID列出来，方便别人直接做事件序列建模。
- 字段说明和标注规则文档：说明每个字段的含义、取值枚举，以及标注共识（比如检修窗口内变位视为正常）。没有这份文档，别人拿到数据也玩不转。
- 基线脚本和评测脚本：固定评测指标和切分方式，让后来者能在同一把尺子下比较效果。
这些配套材料花的时间不多，但价值不比数据本身小。数据集不是“把文件打包发出去”就完事，能用、能用得起来、能比较，才算一份合格的数据集。
整个过程做下来，我最大的体会是：配电主站日志异常检测的核心难点根本不在算法，而在数据和工程侧。日志源杂乱、标签定义模糊、异常模式依赖领域知识，这些问题的解决程度直接决定模型上限。如果重做一次，我会第一周就把脱敏脚本、字段规范和标注手册三样东西先定稿，再开始大规模清洗和标注。最后再分享一个小技巧：发布数据时把会话窗口的事件序列也同步导出成序列样本，很多人拿到原始日志后卡在“怎么把单条日志组装成事件序列”这一步，你要是在发布时就帮他们解决了，这份数据集的实用价值至少翻一倍。
