能读取 fast.log 与 eve.json 中的告警记录，核对 sid、msg、元数据与触发包字段。
上一课你为规则补齐了 msg、sid、rev、classtype、reference 五块元数据，并在测试模式与 PCAP 回放中确认它们写进了告警日志——这些验证都发生在 fast.log 里。现在把视野拉远一点：一条规则命中后，证据其实落在两个地方，fast.log 与 eve.json。fast.log 你上一课已经读过——人类可读、一行一条告警。eve.json 是你要处理的新对象。
两者并存，用途不同。fast.log 适合值班时人眼快速扫过，几秒钟判断有没有异常。eve.json 按事件逐行记录结构化 JSON，适合脚本解析、统计筛选与长期关联。官方文档把 EVE JSON 作为标准输出格式收录，快速上手章节也用它演示告警查看。
判断规则是否真正生效，只看“有没有告警”不够。你还要核对：告警里的 sid、msg、分类，是否和规则里写的一致——这正是上一课补齐的那几块元数据。字段对得上，规则才算按你的意图工作。
核心概念
eve.json：一行一个事件的结构化日志
类比：值班记录有两种写法。fast.log 像手写的一句话：“13:05 发现异常流量”。eve.json 像一张固定格式的表格，每个格子都有名字：时间、源地址、目的地址、端口、协议、告警签名、分类。表格能筛选、能排序、能汇总；手写一句话只能靠人读。
定义：eve.json 是 Suricata 的事件输出文件，采用 EVE（Extensible Event Format）JSON 格式。每个事件占一行，是一个 JSON 对象。告警事件的 event_type 为 alert，告警对象内包含签名 ID（signature_id）、规则消息（signature）、分类（category）等字段；事件外层还有触发包的源/目的地址、端口与协议字段。官方快速上手文档建议安装 jq 来查看 EVE JSON 输出，因为结构化数据用管道筛选，比肉眼逐行读高效。
官方快速上手文档在安装 Suricata 时一并推荐安装 jq，用它显示 EVE JSON 输出。本课环境是 CentOS/RHEL，请用你的发行版包管理器安装 jq；文档里的 apt 命令针对 Ubuntu PPA，不要照搬。装好后先验证 jq 可用，再继续后面的筛选。
回放之前，先明确要核对的字段。这些元数据你在规则里已经写过：
- msg：告警消息。
- sid：签名编号。
- rev：修订号。
- classtype：分类。
- reference：外部引用。
规则里的是期望值，日志里的是实际值。核对就是逐项对比：msg 是否一致、sid 是否一致、分类是否一致、reference 是否还能对应到规则里的引用。任何一项不一致，都意味着规则可能没有被按原样加载，或输出配置做了改写。官方规则文档列出了完整的元数据关键字，包括 msg、sid、rev、classtype、reference 与 metadata，你可以对照它检查规则写法。
核对顺序建议：先看 fast.log 有没有告警，再进 eve.json 按 sid 精确定位，最后逐字段对比。fast.log 负责回答“有没有”，eve.json 负责回答“是什么”。
核对时用这张对应表：
- 规则 msg → eve.json 的 alert.signature
- 规则 sid → alert.signature_id
- 规则 rev → alert.rev
- 规则 classtype → alert.category
- 规则 reference → 视版本位于 metadata 内，以实际输出为准
fast.log 行里的签名编号形如 [1:sid:rev]，其中的 sid 与 rev 也应与规则一致。
回放 PCAP，核对 fast.log 与 eve.json
- 1
准备一份授权 PCAP 与一条已通过测试模式（-T）的规则。回放前确认 suricata.yaml 中 fast.log 输出已启用——讨论区提醒过：检查 fast.log 前别忘了启用它。
- 2
用离线模式回放 PCAP。官方讨论区给出的用法是 -r 后跟 pcap 路径。
bashsuricata -r /path/to/traffic.pcap - 3
查看 fast.log 尾部的新告警，注意行里的签名编号 [1:sid:rev] 与 msg。发行版安装的日志默认在 /var/log/suricata/ 下。
bashtail -n 20 /var/log/suricata/fast.log - 4
用 jq 从 eve.json 中筛出 alert 事件，先只看告警，忽略其他事件类型。
bashjq 'select(.event_type == "alert")' /var/log/suricata/eve.json | tail -n 20 - 5
按 sid 精确筛选目标告警。把 2100498 换成你自己的 sid。
bashjq 'select(.event_type == "alert" and .alert.signature_id == 2100498)' /var/log/suricata/eve.json - 6
逐项核对字段：alert.signature 对应规则 msg，alert.category 对应 classtype，alert.rev 对应 rev；reference 视版本出现在 metadata 中，以实际输出为准。再检查事件外层的 src_ip、dest_ip、src_port、dest_port、proto 是否与 pcap 中的触发流量相符。
- 7
把核对结果记成一行结论：哪条 sid 命中、字段是否全部一致。不一致时跳到故障排查部分。
你应该看到
你能用 jq 从 eve.json 中筛出目标 sid 的 alert 事件，并核对其中的 msg（alert.signature）、classtype（alert.category）与 reference 和规则定义一致；fast.log 与 eve.json 指向同一条规则。
遇到问题：回放后 fast.log 与 eve.json 都没有目标告警，或只有与规则无关的告警。
可能原因
- PCAP 路径写错，Suricata 没有读到流量。
- 规则没有命中：payload、方向或端口与流量不符。
- fast.log 输出没有在 suricata.yaml 中启用。
- eve.json 里有数据，但 event_type 不是 alert（例如只有 flow 或 stats 事件）。
排查步骤
- 确认 -r 后面的 pcap 路径存在且可读。
- 先用 -T 确认规则语法正确且已被加载。
- 打开 suricata.yaml，确认 fast.log 输出已启用，再重新回放。
- 用 jq 只筛 event_type 为 alert 的行，排除其他事件类型的干扰。
- 用官方测试规则（sid 2100498，匹配内容 uid=0|28|root|29|）验证引擎输出链路本身是否正常。若它能告警而你的规则不能，问题出在规则匹配条件。
离线回放（-r）读取的是现成 PCAP 文件，不会向网络发出任何探测流量，是安全的验证方式。获取攻击场景 PCAP 时，只使用公开靶场或明确授权的样本。不要对真实生产环境抓包回放，也不要对未授权目标做任何扫描或测试。所有实验流量必须来自本地 PCAP 或授权环境。
自检：你写的规则 sid 为 1000001。回放后 fast.log 出现一条告警。你要确认这条告警来自你的规则，并核对 eve.json 里的字段。写出筛选该 sid 的 jq 命令，并列出你要核对的三个字段。
命令：jq 'select(.event_type == "alert" and .alert.signature_id == 1000001)' /var/log/suricata/eve.json。核对三个字段：alert.signature（应等于规则 msg）、alert.category（应等于 classtype）、alert.rev（应等于 rev）。再对照规则定义，确认 msg、classtype、reference 与告警输出一致。