Changelog

All notable changes to this project will be documented in this file.

[Unreleased]

Added

• confvars_case 示例项目: 新增完整的配置变量使用案例
  • 添加配置文件 conf/wparse.toml 和 conf/wpgen.toml
  • 添加安全密钥配置 .warp_parse/sec_key.toml
  • 添加知识库模型:
    • address 表 (create.sql, data.csv, insert.sql)
    • example 表 (create.sql, data.csv, insert.sql)
    • 知识库配置 knowdb.toml
  • 添加 OML 模型:
    • benchmark1/adm.oml
    • benchmark2/adm.oml
  • 添加 WPL 规则:
    • benchmark/parse.wpl - 解析规则
    • benchmark/gen_rule.wpl - 生成规则
    • benchmark/sample.dat - 示例数据
  • 添加拓扑配置:
    • Sources: wpsrc.toml
    • Sinks:
      • Business sinks: benchmark1.toml, benchmark2.toml
      • Infra sinks: default.toml, error.toml, miss.toml, monitor.toml, residue.toml
      • 默认配置: defaults.toml
  • 添加运行脚本 run.sh
  • 添加项目说明文档 README.md

Changed

• MySQL 连接器安全性增强: 更新 connectors/sink.d/50-mysql.toml
  • 将硬编码的用户名和密码改为使用环境变量
  • username: 使用 ${SEC_MYSQL_USER}
  • password: 使用 ${SEC_MYSQL_PWD}

Previous Changes

详见 git commit 历史:

• 10eb55a - Merge branch ‘main’
• d40c3fc - fix:demo-parseql
• eb5e699 - demo
• b9cfdb7 - 普通日志异常解决

Beginner Guide

我们来开启 WarpParse 的使用学习。

准备工作

安装

curl  -sSf https://raw.githubusercontent.com/wp-labs/warp-parse/refs/heads/main/setup.sh | sh

最新发布页

MacOS 提示：

• 打开安装限制

下载学习示例

git clone https://github.com/wp-labs/wp-examples.git

目标1: 让WarpParse 运行起来

初始化项目

wproj init

mkdir ${HOME}/wp-space ;
cd  ${HOME}/wp-space;

wproj init -m full

• 项目的结构

tree -L 2
.
├── conf
│   ├── wparse.toml
│   └── wpgen.toml
├── connectors
│   ├── sink.d
│   └── source.d
├── data
│   ├── in_dat
│   ├── logs
│   ├── out_dat
│   └── rescue
├── models
│   ├── knowledge
│   ├── oml
│   └── wpl
└── topology
    ├── sinks
    └── sources

生成测试数据

第一个例子，是最为简单的从文件解析到文件

wpgen sample -n 3000 

引擎解析数据

wparse batch --stat 2 -p 

运行结果：

============================ total stat ==============================

+-------+------------+-----------------+---------+-------+---------+----------+--------+
| stage | name       | target          | collect | total | success | suc-rate | speed  |
+======================================================================================+
| Parse | parse_stat | /nginx//example |         | 3000  | 3000    | 100.0%   | 3.12   |
|-------+------------+-----------------+---------+-------+---------+----------+--------|
| Pick  | pick_stat  | file_1          |         | 3000  | 3000    | 100.0%   | 150.00 |
|-------+------------+-----------------+---------+-------+---------+----------+--------|
| Sink  | sink_stat  | demo/json       |         | 1280  | 1280    | 100.0%   | 3.56   |
+-------+------------+-----------------+---------+-------+---------+----------+--------+

数据统计

wproj data stat

• 输出

== Sources ==
| Key    | Enabled | Lines | Path                    | Error |
|--------|---------|-------|-------------------------|-------|
| file_1 |    Y    |  3000 | .../data/in_dat/gen.dat | -     |
Total enabled lines: 3000

== Sinks ==
| Scope    | Sink        | Path                         | Lines |
|----------|-------------|------------------------------|-------|
| business | demo/json   | .../data/out_dat/demo.json   |  3000 |
| infra    | default/[0] | .../data/out_dat/default.dat |     0 |
| infra    | error/[0]   | .../data/out_dat/error.dat   |     0 |
| infra    | miss/[0]    | .../data/out_dat/miss.dat    |     0 |
| infra    | monitor/[0] | .../data/out_dat/monitor.dat |     0 |
| infra    | residue/[0] | .../data/out_dat/residue.dat |     0 |

只能基于文件才可以通过wproj统计

目标2: 解析自己的日志

学习 WPL 解析日志

样本： linux 系统日志

Oct 10 08:30:15 server systemd[1]: Started Apache HTTP Server.

• 打开 editor工具
• 看看 editor的几个例子
• 学习下WPL

纳入WP工程

mkdir ./models/wpl/my_sys

样本放置:

./models/wpl/my_sys/sample.dat

WPL放置：

./models/wpl/my_sys/parse.wpl

生成数据

使用 wpgen

批量解析

使用 wparse

Docker

TODO:

Benchmark 用例指南

benchmark 目录收录了基于 benchmark/benchmark_common.sh 的性能测试用例。测试用例按数据源类型组织为多个 case 目录，每个 case 下包含不同的处理场景。本文档说明整体结构、通用参数与各测试场景的用途。

前置准备

1. 所有脚本默认在 release profile 下运行，并依赖 wparse/wpgen/wproj，确保它们位于 PATH 中。
2. 从 benchmark 目录或具体测试目录运行脚本。

目录结构

benchmark/
├── benchmark_common.sh      # 公共函数库（参数解析、环境初始化等）
├── check_run.sh            # 批量测试脚本（使用 -m 参数运行所有测试）
├── models/                 # 共享的模型文件
│   ├── wpl/               # WPL 规则集（nginx、sysmon、apt、aws 等）
│   └── oml/               # OML 转换模型
├── sinks/                 # 共享的 sink 配置
│   ├── parse_to_blackhole/
│   ├── parse_to_file/
│   ├── trans_to_blackhole/
│   └── trans_to_file/
├── case_tcp/              # TCP 数据源测试场景
│   ├── sources/           # TCP 源配置
│   ├── parse_to_blackhole/
│   ├── parse_to_file/
│   ├── trans_to_blackhole/
│   └── trans_to_file/
├── case_file/             # File 数据源测试场景
│   ├── sources/           # File 源配置
│   ├── parse_to_blackhole/
│   ├── parse_to_file/
│   ├── trans_to_blackhole/
│   └── trans_to_file/
├── case_syslog/           # Syslog 数据源测试场景
│   ├── sources/           # Syslog 源配置
│   ├── parse_to_blackhole/
│   └── trans_to_blackhole/
└── wpgen_test/            # wpgen 性能测试

测试场景说明

处理模式：

• parse: 解析模式 - 使用 WPL 规则对日志进行解析和转换
• trans: 透传模式 - 不进行解析，直接转发原始数据

输出目标：

• blackhole: 黑洞输出 - 丢弃数据，用于测试纯解析/转发性能
• file: 文件输出 - 输出到文件，测试完整的处理链路

示例：

• parse_to_blackhole: 解析后丢弃，测试解析性能
• parse_to_file: 解析后写入文件，测试完整解析链路
• trans_to_blackhole: 透传后丢弃，测试转发性能
• trans_to_file: 透传后写入文件，测试完整转发链路

通用选项

所有测试脚本共享以下参数（由 benchmark_common.sh 中的 benchmark_parse_args 解析）：

• -m: 使用中等规模数据集（LINE_CNT=200,000 行）；默认使用大规模数据集（20,000,000 行）
• -f: 强制重新生成输入数据，即使 ./data/in_dat/*.dat 已存在（部分脚本支持）
• -c <cnt>: 指定数据条数，与 -m 互斥，优先级更高
• -w <cnt>: 指定 wparse worker 数量
  • daemon 模式默认 6 worker
  • batch/blackhole 模式默认 10 worker
• wpl_dir: 指定 WPL 规则集目录（位置参数）
  • 可选值：nginx、sysmon、apt、aws 等
  • 默认值：nginx
  • 路径相对于 benchmark/models/wpl/
• speed: 样本生成限速（行/秒），0 表示不限速（位置参数，默认 0）

执行 ./run.sh -h 可查看某个测试脚本支持的选项组合。

快速开始

1. 运行单个测试

cd benchmark

# 使用默认配置（nginx 规则，大规模数据集）
./case_tcp/parse_to_blackhole/run.sh

# 使用中等规模数据集
./case_tcp/parse_to_blackhole/run.sh -m

# 使用 sysmon 规则，12 个 worker，限速 1M 行/秒
./case_tcp/parse_to_blackhole/run.sh -w 12 sysmon 1000000

# 自定义数据量和 worker 数
./case_file/parse_to_file/run.sh -c 500000 -w 8

2. 批量测试所有场景

使用 check_run.sh 脚本自动运行所有测试用例（使用 -m 参数进行小数据测试）：

cd benchmark
./check_run.sh

输出示例：

========================================
Benchmark Check - Small Data Test
========================================

检查 case_tcp ...
  → 运行 case_tcp/parse_to_blackhole ...
    ✓ case_tcp/parse_to_blackhole 通过

  → 运行 case_tcp/parse_to_file ...
    ✓ case_tcp/parse_to_file 通过
  ...

========================================
测试总结
========================================
总测试数: 10
通过: 10
失败: 0

所有测试通过！

测试场景清单

TCP 数据源测试（case_tcp）

数据源： wpgen 通过 TCP 连接（默认端口 19001）发送样本数据

File 数据源测试（case_file）

数据源： wpgen 预先生成数据文件到 ./data/in_dat/

Syslog 数据源测试（case_syslog）

数据源： wpgen 通过 Syslog UDP 协议发送样本数据

wpgen 性能测试（wpgen_test）

专门测试 wpgen 的样本数据生成能力，不启动 wparse。

配置文件说明

每个测试场景目录下通常包含：

<test_scenario>/
├── conf/
│   ├── wparse.toml    # wparse 引擎配置
│   └── wpgen.toml     # wpgen 数据生成配置
├── data/              # 运行时数据目录（自动创建）
│   ├── in_dat/        # 输入数据
│   ├── out_dat/       # 输出数据
│   ├── logs/          # 日志文件
│   └── rescue/        # 异常数据
├── .run/              # 运行时文件（PID 等）
└── run.sh             # 测试脚本

wparse.toml 配置要点

[models]
wpl = "../../models/wpl"    # WPL 规则路径（相对于测试目录）
oml = "../../models/oml"    # OML 模型路径

[topology]
sources = "../sources"      # 数据源配置路径
sinks = "../../sinks/xxx"   # Sink 配置路径

[performance]
parse_workers = 6           # 解析 worker 数量
rate_limit_rps = 0          # 速率限制（0 表示不限制）

wpgen.toml 配置要点

[generator]
mode = "sample"             # 生成模式
count = 1000                # 每批次数量
speed = 0                   # 生成速度限制
parallel = 4                # 并行度

[output]
connect = "tcp_sink"        # 连接器类型（tcp_sink/file_raw_sink 等）
params = { port = 19001 }   # 连接器参数

性能调优建议

确定最佳 Worker 数

1. 从 CPU 核心数开始测试
2. 使用不同 worker 数运行同一测试：

   ./case_tcp/parse_to_blackhole/run.sh -m -w 2
   ./case_tcp/parse_to_blackhole/run.sh -m -w 4
   ./case_tcp/parse_to_blackhole/run.sh -m -w 6
   ./case_tcp/parse_to_blackhole/run.sh -m -w 8
   

3. 对比吞吐量，找到性价比最优点

数据规模选择

• 开发/调试：使用 -m 参数（20 万行），快速验证
• 性能测试：使用默认规模（2000 万行）或自定义 -c 参数
• 压力测试：使用 -c 指定更大数据量

避免 I/O 瓶颈

• blackhole 测试：测试纯计算性能，无 I/O 影响
• file 测试：注意磁盘 I/O 可能成为瓶颈
• 使用 SSD 或 RAM disk 可提升 I/O 性能

输出与校验

每个脚本会自动调用以下命令显示结果：

• wproj data stat: 打印数据统计信息（输入/输出条数、耗时等）
• wproj validate sink-file: 校验输出文件（仅限 file 输出场景）

若遇到数据残留导致统计不准，可手动执行：

wproj data clean   # 清理 wparse 数据
wpgen data clean   # 清理 wpgen 数据

或使用 -f 参数强制重新生成数据（部分脚本支持）。

常见问题

WPL 模型加载失败

检查 wparse.toml 中的 wpl 路径是否正确，应相对于测试目录：

[models]
wpl = "../../models/wpl"  # 正确
# wpl = "../../../models/wpl"  # 错误（旧配置）

数据生成失败

• 检查磁盘空间是否充足
• 确认 wpgen.toml 配置正确
• 查看 ./data/logs/ 下的日志文件

测试运行缓慢

• 使用 -m 参数减小数据规模
• 调整 -w 参数优化 worker 数
• 检查系统资源使用情况（CPU、内存、磁盘 I/O）

apt_file_to_blackhole

本测试用于验证 apt_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：APT 3K 威胁日志，File 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 APT 3K 威胁日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（APT 3K 威胁日志，File 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 314,200 EPS，约是 Vector (33,614 EPS) 的 9.35 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（700.03 % vs 563.18 %）。
   • 内存: WarpParse 的内存占用更低（175.63 MB vs 261.19 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 9.35 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

aws_file_to_blackhole

本测试用于验证 aws_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：AWS ELB 日志，File 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 AWS ELB 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（AWS ELB 日志，File 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 1,012,400 EPS，约是 Vector (158,730 EPS) 的 6.38 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（826.53 % vs 633.77 %）。
   • 内存: WarpParse 的内存占用更低（237.05 MB vs 296.87 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 6.38 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

mixed_file_to_blackhole

本测试用于验证 mixed_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景覆盖两类混合日志：

• Mixed-1295B：四类日志 1:1:1:1 混合，平均 1295B。
• Mixed-867B：四类日志 3:2:1:1 混合，平均 867B。

链路为 File 输入到 BlackHole 输出，仅做日志解析。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Mixed 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Parse Only，Mac M4 Mini）

结论

在本测试场景（Mixed 日志，File 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 在两种混合配比下均明显领先。

   • 1:1:1:1 配比：452,300 EPS（MPS 558.59），约为 Vector 的 4.4x。
   • 3:2:1:1 配比：672,500 EPS（MPS 556.05），约为 Vector 的 4.7x。

2. 系统资源开销: 资源对比见报告主表，WarpParse 在吞吐提升的同时保持更优的内存占用。

总结: 两种混合配比下，WarpParse 均在吞吐上大幅领先并维持较优的资源效率，适合高吞吐混合日志的 file→blackhole 场景。

nginx_file_to_blackhole

本测试用于验证 nginx_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：Nginx 访问日志，File 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Nginx 访问日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（Nginx 访问日志，File 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 2,456,100 EPS，约是 Vector (540,540 EPS) 的 4.54 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（684.40 % vs 341.51 %）。
   • 内存: WarpParse 的内存占用更低（107.36 MB vs 230.67 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 4.54 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

sysmon_file_to_blackhole

本测试用于验证 sysmon_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：Sysmon 1K JSON 日志，File 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Sysmon 1K JSON 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（Sysmon 1K JSON 日志，File 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 440,000 EPS，约是 Vector (76,717 EPS) 的 5.74 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（852.01 % vs 462.81 %）。
   • 内存: WarpParse 的内存占用更低（223.52 MB vs 294.87 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 5.74 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

apt_file_to_blackhole

本测试用于验证 apt_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：APT 3K 威胁日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 APT 3K 威胁日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（APT 3K 威胁日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 280,000 EPS，约是 Vector (30,612 EPS) 的 9.15 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（768.50 % vs 560.94 %）。
   • 内存: WarpParse 的内存占用更低（172.72 MB vs 248.00 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 9.15 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

aws_file_to_blackhole

本测试用于验证 aws_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：AWS ELB 日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 AWS ELB 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（AWS ELB 日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 710,400 EPS，约是 Vector (129,743 EPS) 的 5.48 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（837.44 % vs 593.45 %）。
   • 内存: WarpParse 的内存占用更低（230.00 MB vs 283.67 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 5.48 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

mixed_file_to_blackhole

本测试用于验证 mixed_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景覆盖两类混合日志：

• Mixed-1295B：四类日志 1:1:1:1 混合，平均 1295B。
• Mixed-867B：四类日志 3:2:1:1 混合，平均 867B。

链路为 File 输入到 BlackHole 输出，执行日志解析 + 转换。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Mixed 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证管线解析+转换能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确，转换链路正确执行。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Parse + Transform，Mac M4 Mini）

结论

在本测试场景（Mixed 日志，File 输入到 BlackHole 输出，执行 日志解析 + 转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 在两种混合配比下均显著领先。

   • 1:1:1:1 配比：396,300 EPS（MPS 489.43），约为 Vector 的 4.0x。
   • 3:2:1:1 配比：560,600 EPS（MPS 463.52），约为 Vector 的 4.1x。

2. 系统资源开销: 资源详情见报告主表，WarpParse 在吞吐提升的同时保持资源优势。

总结: 两种混合配比下，WarpParse 在解析+转换场景依旧显著领先，适合高吞吐的 file→blackhole 混合日志处理。

nginx_file_to_blackhole

本测试用于验证 nginx_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：Nginx 访问日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Nginx 访问日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（Nginx 访问日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 1,749,200 EPS，约是 Vector (470,312 EPS) 的 3.72 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（762.65 % vs 372.09 %）。
   • 内存: WarpParse 的内存占用更低（143.16 MB vs 254.05 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 3.72 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

sysmon_file_to_blackhole

本测试用于验证 sysmon_file_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：Sysmon 1K JSON 日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Sysmon 1K JSON 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: File 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（Sysmon 1K JSON 日志，File 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 354,800 EPS，约是 Vector (58,200 EPS) 的 6.10 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（880.24 % vs 431.45 %）。
   • 内存: WarpParse 的内存占用更低（157.88 MB vs 296.28 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 6.10 倍），同时保持了更低的内存占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

file_blackhole 说明

本用例演示“文件源 → Blackhole 汇“的批处理性能基准测试场景：使用 wpgen 生成测试数据文件，wparse 通过批处理模式读取并解析，输出到 blackhole 以测试纯解析吞吐性能。

目录结构

benchmark/file_blackhole/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   ├── wpgen.toml              # 第一路文件生成器配置
│   └── wpgen1.toml             # 第二路文件生成器配置
├── data/                        # 运行数据目录
│   ├── in_dat/                 # 输入数据目录
│   │   ├── gen.dat            # 第一路生成数据
│   │   └── gen1.dat           # 第二路生成数据
│   ├── out_dat/                # 输出数据目录
│   │   ├── error.dat          # 错误数据输出
│   │   ├── miss.dat           # 缺失数据输出
│   │   ├── monitor.dat        # 监控数据输出
│   │   └── residue.dat        # 残留数据输出
│   ├── logs/                   # 日志文件目录
│   └── rescue/                 # 救援数据目录
└── .run/                        # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark/file_blackhole

# 默认大规模性能测试（2000 万行数据）
./run.sh

# 中等规模测试（20 万行数据）
./run.sh -m

# 强制重新生成数据（即使已存在）
./run.sh -f

# 指定 worker 数量
./run.sh -w 8

# 使用特定 WPL 规则
./run.sh nginx

# 组合使用
./run.sh -m -w 8 -f nginx

运行参数

性能测试选项

• 默认测试：2000 万行数据，双路文件源，6 个 worker
• 中等测试：20 万行数据，适合快速验证
• 强制生成：-f 参数强制重新生成测试数据
• 自定义 WPL：支持 nginx、apache、sysmon 等规则

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 数据生成检查

   • 检查 data/in_dat/gen.dat 和 data/in_dat/gen1.dat 是否存在
   • 如果不存在或使用 -f 参数，则生成新数据

3. 数据生成（如需要）

   • 启动 wpgen 生成第一路数据到 gen.dat
   • 启动 wpgen 生成第二路数据到 gen1.dat
   • 支持并发生成提高效率

4. 批处理执行

   • 使用 wparse batch 读取文件数据
   • 应用 WPL 规则进行解析
   • 数据输出到 blackhole（丢弃）

5. 性能统计

   • 实时显示处理进度
   • 记录吞吐量、处理时间等指标
   • 输出最终性能报告

数据流向

wpgen 生成器 1        wpgen 生成器 2
       ↓                    ↓
   gen.dat              gen1.dat
       ↓                    ↓
┌────────────────────────────────┐
│      wparse batch             │
│   - 读取文件数据               │
│   - 应用 WPL 规则解析          │
│   - 分发到 sinks              │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│  blackhole  │   monitor   │
│    sink     │    sink     │
│ (丢弃数据)  │ (收集统计)  │
└─────────────┴─────────────┘

验证与故障排除

运行成功验证

1. 检查性能输出

   • 查看 terminal 输出的实时统计信息
   • 关注 “Throughput”（吞吐量）指标
   • 确认无错误或异常

2. 验证输出文件

   # 检查监控数据
   ls -la data/out_dat/monitor.dat
   
   # 确认其他文件为空（无错误）
   ls -la data/out_dat/{error,miss,residue}.dat
   

性能

优化

1. 系统级优化

   Linux 系统：

   # CPU 亲和性设置
   taskset -c 0-5 ./run.sh -w 6
   
   # I/O 调度器优化（SSD）
   echo noop | sudo tee /sys/block/sdX/queue/scheduler
   
   # 增大文件描述符限制
   ulimit -n 65536
   

   macOS 系统：

   # 调整文件描述符限制
   ulimit -n 65536
   
   # 调整系统参数（需要管理员权限）
   sudo sysctl -w kern.maxfiles=65536
   sudo sysctl -w kern.maxfilesperproc=65536
   

2. 应用级优化

   • 增加 worker 数量：-w 12（不超过 CPU 核心数）
   • 使用更快的 WPL 规则（如 nginx）
   • 启用数据预生成并缓存

3. 存储优化

   • 使用 SSD 存储
   • 使用 RAID 0 提高读写性能
   • 考虑使用内存文件系统

影响因素

1. WPL 规则复杂度

   • nginx：简单正则，性能最佳
   • apache：中等复杂度
   • sysmon：复杂规则，性能较低

2. 数据特征

   • 日志行长度
   • 正则匹配复杂度
   • 字段提取数量

3. 系统配置

   • CPU 核心数和频率
   • 内存大小和速度
   • 磁盘 I/O 性能（关键因素）

使用建议

• 选择 file_blackhole：

  • 需要测试纯解析性能
  • 批量数据处理场景
  • 追求最高吞吐量

• 选择 tcp_blackhole：

  • 需要可靠的网络传输
  • 实时数据处理
  • 模拟 TCP 数据源

• 选择 syslog_blackhole：

  • 传统 syslog 集成
  • 极限性能测试
  • 日志收集场景

本文档最后更新时间：2025-12-16

file_file 说明

本用例演示“文件源 → 文件汇“的性能基准测试场景：使用 wpgen 生成测试数据文件，wparse 通过批处理模式读取并解析，输出到文件以测试完整的数据处理管道性能。

目录结构

benchmark/file_file/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── record.md                    # 运行记录文档
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   └── wpgen.toml              # 文件生成器配置
├── models/                      # 模型配置目录
│   ├── sinks/                  # 数据汇配置
│   │   ├── defaults.toml       # 默认配置
│   │   ├── business.d/         # 业务组配置
│   │   │   └── all.toml        # 文件汇组配置
│   │   └── infra.d/            # 基础设施组配置
│   │       ├── default.toml    # 默认数据汇
│   │       ├── error.toml      # 错误数据处理
│   │       ├── miss.toml       # 缺失数据处理
│   │       ├── monitor.toml    # 监控数据处理
│   │       └── residue.toml    # 残留数据处理
│   ├── sources/                # 数据源配置
│   │   └── wpsrc.toml          # 文件源配置
│   ├── wpl/                    # WPL 解析规则目录
│   │   ├── nginx/              # Nginx 日志规则
│   │   ├── apache/             # Apache 日志规则
│   │   └── sysmon/             # 系统监控规则
│   ├── oml/                    # OML 转换规则目录（空）
│   └── knowledge/              # 知识库目录（空）
├── data/                        # 运行数据目录
│   ├── in_dat/                 # 输入数据目录
│   │   └── gen.dat            # 生成数据文件
│   ├── out_dat/                # 输出数据目录
│   │   ├── all.dat            # 主输出文件
│   │   ├── error.dat          # 错误数据输出
│   │   ├── miss.dat           # 缺失数据输出
│   │   ├── monitor.dat        # 监控数据输出
│   │   └── residue.dat        # 残留数据输出
│   ├── logs/                   # 日志文件目录
│   └── rescue/                 # 救援数据目录
└── .run/                       # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark/file_file

# 默认大规模性能测试（2000 万行数据）
./run.sh

# 中等规模测试（20 万行数据）
./run.sh -m

# 强制重新生成数据（即使已存在）
./run.sh -f

# 指定 worker 数量
./run.sh -w 8

# 使用特定 WPL 规则
./run.sh nginx

# 组合使用
./run.sh -m -w 8 -f nginx

运行参数

性能测试选项

• 默认测试：2000 万行数据，单路文件源，2 个 worker
• 中等测试：20 万行数据，适合快速验证
• 强制生成：-f 参数强制重新生成测试数据
• 自定义 WPL：支持 nginx、apache、sysmon 等规则

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 初始化环境

   • 初始化 release 模式环境
   • 验证指定的 WPL 规则路径
   • 清理历史数据和日志

3. 数据生成检查

   • 检查 data/in_dat/gen.dat 是否存在
   • 如果不存在或使用 -f 参数，则生成新数据

4. 数据生成（如需要）

   • 启动 wpgen 生成数据到 gen.dat
   • 支持并发和批量生成

5. 批处理执行

   • 使用 wparse batch 读取文件数据
   • 应用 WPL 规则进行解析
   • 数据输出到文件（all.dat）

6. 性能统计

   • 实时显示处理进度
   • 记录吞吐量、处理时间等指标
   • 输出最终性能报告

数据流向

wpgen 生成器
       ↓
   gen.dat (输入文件)
       ↓
┌────────────────────────────────┐
│      wparse batch             │
│   - 读取文件数据               │
│   - 应用 WPL 规则解析          │
│   - 分发到 sinks              │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│    all.dat  │   monitor   │
│  (主输出)   │    sink     │
│             │ (收集统计)  │
└─────────────┴─────────────┘

使用建议

• 选择 file_file：

  • 需要测试完整的数据处理管道
  • 验证输出格式和内容
  • 文件到文件转换场景

• 选择 file_blackhole：

  • 只关心解析性能
  • 批量数据处理
  • 追求最高吞吐量

• 选择 tcp_blackhole：

  • 网络数据源
  • 实时处理需求
  • 可靠传输要求

• 选择 syslog_blackhole：

  • 日志集成
  • 高频数据接收
  • 传统 syslog 场景

贡献与反馈

如发现问题或有性能优化建议，请：

1. 提交详细的测试环境信息（CPU、内存、存储配置）
2. 包含完整的性能报告和 I/O 统计
3. 分享存储优化经验和最佳实践
4. 提供不同文件格式下的性能对比

本文档最后更新时间：2025-12-16

file_blackhole

本用例演示“文件源 → Blackhole 汇“的批处理性能基准测试场景：使用 wpgen 生成测试数据文件，wparse 通过批处理模式读取并解析，输出到 blackhole 以测试纯解析吞吐性能。

目录结构

benchmark/file_blackhole/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   ├── wpgen.toml              # 第一路文件生成器配置
│   └── wpgen1.toml             # 第二路文件生成器配置
├── models/                      # 模型配置目录
│   ├── sinks/                  # 数据汇配置
│   │   ├── defaults.toml       # 默认配置
│   │   ├── business.d/         # 业务组配置
│   │   │   └── all.toml        # Blackhole 汇组配置
│   │   └── infra.d/            # 基础设施组配置
│   │       ├── default.toml    # 默认数据汇
│   │       ├── error.toml      # 错误数据处理
│   │       ├── miss.toml       # 缺失数据处理
│   │       ├── monitor.toml    # 监控数据处理
│   │       └── residue.toml    # 残留数据处理
│   ├── sources/                # 数据源配置
│   │   └── wpsrc.toml          # 文件源配置
│   ├── wpl/                    # WPL 解析规则目录
│   │   ├── nginx/              # Nginx 日志规则
│   │   ├── apache/             # Apache 日志规则
│   │   └── sysmon/             # 系统监控规则
│   ├── oml/                    # OML 转换规则目录（空）
│   └── knowledge/              # 知识库目录（空）
├── data/                        # 运行数据目录
│   ├── in_dat/                 # 输入数据目录
│   │   ├── gen.dat            # 第一路生成数据
│   │   └── gen1.dat           # 第二路生成数据
│   ├── out_dat/                # 输出数据目录
│   │   ├── error.dat          # 错误数据输出
│   │   ├── miss.dat           # 缺失数据输出
│   │   ├── monitor.dat        # 监控数据输出
│   │   └── residue.dat        # 残留数据输出
│   ├── logs/                   # 日志文件目录
│   └── rescue/                 # 救援数据目录
├── out/                         # 输出目录
└── .run/                        # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark/file_blackhole

# 默认大规模性能测试（2000 万行数据）
./run.sh

# 中等规模测试（20 万行数据）
./run.sh -m

# 强制重新生成数据（即使已存在）
./run.sh -f

# 指定 worker 数量
./run.sh -w 8

# 使用特定 WPL 规则
./run.sh nginx

# 组合使用
./run.sh -m -w 8 -f nginx

运行参数

性能测试选项

• 默认测试：2000 万行数据，双路文件源，6 个 worker
• 中等测试：20 万行数据，适合快速验证
• 强制生成：-f 参数强制重新生成测试数据
• 自定义 WPL：支持 nginx、apache、sysmon 等规则

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 数据生成检查

   • 检查 data/in_dat/gen.dat 和 data/in_dat/gen1.dat 是否存在
   • 如果不存在或使用 -f 参数，则生成新数据

3. 数据生成（如需要）

   • 启动 wpgen 生成第一路数据到 gen.dat
   • 启动 wpgen 生成第二路数据到 gen1.dat
   • 支持并发生成提高效率

4. 批处理执行

   • 使用 wparse batch 读取文件数据
   • 应用 WPL 规则进行解析
   • 数据输出到 blackhole（丢弃）

5. 性能统计

   • 实时显示处理进度
   • 记录吞吐量、处理时间等指标
   • 输出最终性能报告

数据流向

wpgen 生成器 1        wpgen 生成器 2
       ↓                    ↓
   gen.dat              gen1.dat
       ↓                    ↓
┌────────────────────────────────┐
│      wparse batch             │
│   - 读取文件数据               │
│   - 应用 WPL 规则解析          │
│   - 分发到 sinks              │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│  blackhole  │   monitor   │
│    sink     │    sink     │
│ (丢弃数据)  │ (收集统计)  │
└─────────────┴─────────────┘

验证与故障排除

运行成功验证

1. 检查性能输出

   • 查看 terminal 输出的实时统计信息
   • 关注 “Throughput”（吞吐量）指标
   • 确认无错误或异常

2. 验证输出文件

   # 检查监控数据
   ls -la data/out_dat/monitor.dat
   
   # 确认其他文件为空（无错误）
   ls -la data/out_dat/{error,miss,residue}.dat
   

性能

优化

1. 系统级优化

   Linux 系统：

   # CPU 亲和性设置
   taskset -c 0-5 ./run.sh -w 6
   
   # I/O 调度器优化（SSD）
   echo noop | sudo tee /sys/block/sdX/queue/scheduler
   
   # 增大文件描述符限制
   ulimit -n 65536
   

   macOS 系统：

   # 调整文件描述符限制
   ulimit -n 65536
   
   # 调整系统参数（需要管理员权限）
   sudo sysctl -w kern.maxfiles=65536
   sudo sysctl -w kern.maxfilesperproc=65536
   

2. 应用级优化

   • 增加 worker 数量：-w 12（不超过 CPU 核心数）
   • 使用更快的 WPL 规则（如 nginx）
   • 启用数据预生成并缓存

3. 存储优化

   • 使用 SSD 存储
   • 使用 RAID 0 提高读写性能
   • 考虑使用内存文件系统

影响因素

1. WPL 规则复杂度

   • nginx：简单正则，性能最佳
   • apache：中等复杂度
   • sysmon：复杂规则，性能较低

2. 数据特征

   • 日志行长度
   • 正则匹配复杂度
   • 字段提取数量

3. 系统配置

   • CPU 核心数和频率
   • 内存大小和速度
   • 磁盘 I/O 性能（关键因素）

使用建议

• 选择 file_blackhole：

  • 需要测试纯解析性能
  • 批量数据处理场景
  • 追求最高吞吐量

• 选择 tcp_blackhole：

  • 需要可靠的网络传输
  • 实时数据处理
  • 模拟 TCP 数据源

• 选择 syslog_blackhole：

  • 传统 syslog 集成
  • 极限性能测试
  • 日志收集场景

本文档最后更新时间：2025-12-16

file_file 说明

本用例演示“文件源 → 文件汇“的性能基准测试场景：使用 wpgen 生成测试数据文件，wparse 通过批处理模式读取并解析，输出到文件以测试完整的数据处理管道性能。

目录结构

benchmark/file_file/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── record.md                    # 运行记录文档
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   └── wpgen.toml              # 文件生成器配置
├── data/                        # 运行数据目录
│   ├── in_dat/                 # 输入数据目录
│   │   └── gen.dat            # 生成数据文件
│   ├── out_dat/                # 输出数据目录
│   │   ├── all.dat            # 主输出文件
│   │   ├── error.dat          # 错误数据输出
│   │   ├── miss.dat           # 缺失数据输出
│   │   ├── monitor.dat        # 监控数据输出
│   │   └── residue.dat        # 残留数据输出
│   ├── logs/                   # 日志文件目录
│   └── rescue/                 # 救援数据目录
└── .run/                       # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark/file_file

# 默认大规模性能测试（2000 万行数据）
./run.sh

# 中等规模测试（20 万行数据）
./run.sh -m

# 强制重新生成数据（即使已存在）
./run.sh -f

# 指定 worker 数量
./run.sh -w 8

# 使用特定 WPL 规则
./run.sh nginx

# 组合使用
./run.sh -m -w 8 -f nginx

运行参数

性能测试选项

• 默认测试：2000 万行数据，单路文件源，2 个 worker
• 中等测试：20 万行数据，适合快速验证
• 强制生成：-f 参数强制重新生成测试数据
• 自定义 WPL：支持 nginx、apache、sysmon 等规则

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 初始化环境

   • 初始化 release 模式环境
   • 验证指定的 WPL 规则路径
   • 清理历史数据和日志

3. 数据生成检查

   • 检查 data/in_dat/gen.dat 是否存在
   • 如果不存在或使用 -f 参数，则生成新数据

4. 数据生成（如需要）

   • 启动 wpgen 生成数据到 gen.dat
   • 支持并发和批量生成

5. 批处理执行

   • 使用 wparse batch 读取文件数据
   • 应用 WPL 规则进行解析
   • 数据输出到文件（all.dat）

6. 性能统计

   • 实时显示处理进度
   • 记录吞吐量、处理时间等指标
   • 输出最终性能报告

数据流向

wpgen 生成器
       ↓
   gen.dat (输入文件)
       ↓
┌────────────────────────────────┐
│      wparse batch             │
│   - 读取文件数据               │
│   - 应用 WPL 规则解析          │
│   - 分发到 sinks              │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│    all.dat  │   monitor   │
│  (主输出)   │    sink     │
│             │ (收集统计)  │
└─────────────┴─────────────┘

使用建议

• 选择 file_file：

  • 需要测试完整的数据处理管道
  • 验证输出格式和内容
  • 文件到文件转换场景

• 选择 file_blackhole：

  • 只关心解析性能
  • 批量数据处理
  • 追求最高吞吐量

• 选择 tcp_blackhole：

  • 网络数据源
  • 实时处理需求
  • 可靠传输要求

• 选择 syslog_blackhole：

  • 日志集成
  • 高频数据接收
  • 传统 syslog 场景

贡献与反馈

如发现问题或有性能优化建议，请：

1. 提交详细的测试环境信息（CPU、内存、存储配置）
2. 包含完整的性能报告和 I/O 统计
3. 分享存储优化经验和最佳实践
4. 提供不同文件格式下的性能对比

本文档最后更新时间：2025-12-16

syslog_blackhole 说明

本用例演示“Syslog 源 → Blackhole 汇“的性能基准测试场景：使用 wpgen 通过 Syslog 协议发送数据，wparse 以 daemon 模式接收并处理，输出到 blackhole 以测试网络接收与解析的综合性能。

目录结构

benchmark/syslog_blackhole/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── record.md                    # 运行记录文档
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   ├── wpgen.toml              # Syslog UDP 生成器配置
│   └── wpgen1.toml             # Syslog TCP 生成器配置（可选）
├── data/                        # 运行数据目录
│   ├── out_dat/                # 输出数据目录
│   │   ├── error.dat          # 错误数据输出
│   │   ├── miss.dat           # 缺失数据输出
│   │   ├── monitor.dat        # 监控数据输出
│   │   └── residue.dat        # 残留数据输出
│   ├── logs/                   # 日志文件目录
│   └── rescue/                 # 救援数据目录
├── logs/                       # 额外的日志目录
└── .run/                       # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 支持 UDP/TCP 网络连接的系统环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark

# 默认大规模性能测试（2000 万行数据）
./syslog_blackhole/run.sh

# 中等规模测试（20 万行数据）
./syslog_blackhole/run.sh -m

# 指定 worker 数量
./syslog_blackhole/run.sh -w 8

# 使用特定 WPL 规则
./syslog_blackhole/run.sh nginx

# 使用 sysmon 规则并限速 50 万行/秒
./syslog_blackhole/run.sh sysmon 500000

# 组合使用
./syslog_blackhole/run.sh -m -w 4 nginx 300000

运行参数

性能测试选项

• 默认测试：2000 万行数据，Syslog UDP，2 个 worker
• 中等测试：20 万行数据，适合快速验证
• 自定义 WPL：支持 nginx、apache、sysmon 等规则
• 速率限制：可指定生成速率，测试流控性能
• 双协议支持：可切换 UDP/TCP 模式

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 初始化环境

   • 初始化 release 模式环境
   • 验证指定的 WPL 规则路径
   • 清理历史数据和日志

3. 启动 Daemon 模式

   • 启动 wparse daemon 监听 Syslog 端口
   • 加载指定的 WPL 规则
   • 等待 Syslog 连接

4. 数据生成与发送

   • 启动 wpgen 生成测试数据
   • 通过 Syslog 协议发送到 wparse daemon
   • 支持高并发发送

5. 性能监控

   • 实时监控处理速度
   • 记录吞吐量、延迟等指标
   • 收集错误和异常统计

6. 结果统计

   • 停止 daemon 进程
   • 输出性能报告
   • 验证数据完整性

数据流向

wpgen 生成器
    ↓ Syslog 协议 (UDP/TCP, 端口 1514/1515)
┌────────────────────────────────┐
│        wparse daemon           │
│    - 接收 Syslog 数据          │
│    - 应用 WPL 规则解析         │
│    - 分发到 sinks             │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│  blackhole  │   monitor   │
│    sink     │    sink     │
│ (丢弃数据)  │ (收集统计)  │
└─────────────┴─────────────┘

syslog_blackhole 说明

本用例演示“Syslog 源 → Blackhole 汇“的性能基准测试场景：使用 wpgen 通过 Syslog 协议发送数据，wparse 以 daemon 模式接收并处理，输出到 blackhole 以测试网络接收与解析的综合性能。

目录结构

benchmark/syslog_blackhole/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── record.md                    # 运行记录文档
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   ├── wpgen.toml              # Syslog UDP 生成器配置
│   └── wpgen1.toml             # Syslog TCP 生成器配置（可选）
├── data/                        # 运行数据目录
│   ├── out_dat/                # 输出数据目录
│   │   ├── error.dat          # 错误数据输出
│   │   ├── miss.dat           # 缺失数据输出
│   │   ├── monitor.dat        # 监控数据输出
│   │   └── residue.dat        # 残留数据输出
│   ├── logs/                   # 日志文件目录
│   └── rescue/                 # 救援数据目录
├── logs/                       # 额外的日志目录
└── .run/                       # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 支持 UDP/TCP 网络连接的系统环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark

# 默认大规模性能测试（2000 万行数据）
./syslog_blackhole/run.sh

# 中等规模测试（20 万行数据）
./syslog_blackhole/run.sh -m

# 指定 worker 数量
./syslog_blackhole/run.sh -w 8

# 使用特定 WPL 规则
./syslog_blackhole/run.sh nginx

# 使用 sysmon 规则并限速 50 万行/秒
./syslog_blackhole/run.sh sysmon 500000

# 组合使用
./syslog_blackhole/run.sh -m -w 4 nginx 300000

运行参数

性能测试选项

• 默认测试：2000 万行数据，Syslog UDP，2 个 worker
• 中等测试：20 万行数据，适合快速验证
• 自定义 WPL：支持 nginx、apache、sysmon 等规则
• 速率限制：可指定生成速率，测试流控性能
• 双协议支持：可切换 UDP/TCP 模式

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 初始化环境

   • 初始化 release 模式环境
   • 验证指定的 WPL 规则路径
   • 清理历史数据和日志

3. 启动 Daemon 模式

   • 启动 wparse daemon 监听 Syslog 端口
   • 加载指定的 WPL 规则
   • 等待 Syslog 连接

4. 数据生成与发送

   • 启动 wpgen 生成测试数据
   • 通过 Syslog 协议发送到 wparse daemon
   • 支持高并发发送

5. 性能监控

   • 实时监控处理速度
   • 记录吞吐量、延迟等指标
   • 收集错误和异常统计

6. 结果统计

   • 停止 daemon 进程
   • 输出性能报告
   • 验证数据完整性

数据流向

wpgen 生成器
    ↓ Syslog 协议 (UDP/TCP, 端口 1514/1515)
┌────────────────────────────────┐
│        wparse daemon           │
│    - 接收 Syslog 数据          │
│    - 应用 WPL 规则解析         │
│    - 分发到 sinks             │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│  blackhole  │   monitor   │
│    sink     │    sink     │
│ (丢弃数据)  │ (收集统计)  │
└─────────────┴─────────────┘

apt_tcp_to_blackhole

本测试用于验证 apt_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：APT 3K 威胁日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 APT 3K 威胁日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（APT 3K 威胁日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 298,200 EPS，约是 Vector (46,100 EPS) 的 6.47 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更低（693.55 % vs 849.30 %）。
   • 内存: WarpParse 的内存占用基本持平（408.87 MB vs 421.18 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 6.47 倍），同时保持了更低的 CPU 占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

apt_tcp_to_file

本测试用于验证 apt_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：APT 3K 威胁日志，TCP 输入到 File 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 APT 3K 威胁日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（APT 3K 威胁日志，TCP 输入到 File 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 179,600 EPS，约是 Vector (36,200 EPS) 的 4.96 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更低（605.69 % vs 688.47 %）。
   • 内存: WarpParse 的内存占用更高（1016.06 MB vs 368.91 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 4.96 倍），同时保持了更低的 CPU 占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

aws_tcp_to_blackhole

本测试用于验证 aws_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：AWS ELB 日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 AWS ELB 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（AWS ELB 日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 884,700 EPS，约是 Vector (163,600 EPS) 的 5.41 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率基本持平（612.28 % vs 628.67 %）。
   • 内存: WarpParse 的内存占用更高（709.96 MB vs 264.21 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 5.41 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

aws_tcp_to_file

本测试用于验证 aws_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：AWS ELB 日志，TCP 输入到 File 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 AWS ELB 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（AWS ELB 日志，TCP 输入到 File 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 347,800 EPS，约是 Vector (74,700 EPS) 的 4.66 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（495.90 % vs 374.47 %）。
   • 内存: WarpParse 的内存占用更高（481.30 MB vs 264.70 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 4.66 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

mixed_tcp_to_blackhole

本测试用于验证 mixed_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景覆盖两类混合日志：

• Mixed-1295B：四类日志 1:1:1:1 混合，平均 1295B。
• Mixed-867B：四类日志 3:2:1:1 混合，平均 867B。

链路为 TCP 输入到 BlackHole 输出，仅做日志解析。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Mixed 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Parse Only，Mac M4 Mini）

结论

在本测试场景（Mixed 日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 在两种混合配比下均显著领先。

   • 1:1:1:1 配比：446,300 EPS（MPS 551.18），约为 Vector 的 4.0x。
   • 3:2:1:1 配比：613,000 EPS（MPS 506.85），约为 Vector 的 3.8x。

2. 系统资源开销: 资源详情见报告主表。

总结: 两种混合配比下，WarpParse 在 TCP→BlackHole 解析场景都保持明显吞吐优势。

mixed_tcp_to_file

本测试用于验证 mixed_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景覆盖两类混合日志：

• Mixed-1295B：四类日志 1:1:1:1 混合，平均 1295B。
• Mixed-867B：四类日志 3:2:1:1 混合，平均 867B。

链路为 TCP 输入到 File 输出，仅做日志解析。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Mixed 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路落盘吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Parse Only，Mac M4 Mini）

结论

在本测试场景（Mixed 日志，TCP 输入到 File 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 在两种混合配比下均领先。

   • 1:1:1:1 配比：229,100 EPS（MPS 282.94），约为 Vector 的 3.8x。
   • 3:2:1:1 配比：308,400 EPS（MPS 255.00），约为 Vector 的 4.4x。

2. 系统资源开销: 资源详情见报告主表；落盘链路的内存峰值受缓冲策略影响。

总结: 两种混合配比下，WarpParse 在 TCP→File 解析场景保持明显吞吐优势。

nginx_tcp_to_blackhole

本测试用于验证 nginx_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：Nginx 访问日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Nginx 访问日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（Nginx 访问日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 1,737,200 EPS，约是 Vector (974,100 EPS) 的 1.78 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率基本持平（506.85 % vs 530.76 %）。
   • 内存: WarpParse 的内存占用更高（426.09 MB vs 233.23 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 1.78 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

nginx_tcp_to_file

本测试用于验证 nginx_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：Nginx 访问日志，TCP 输入到 File 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Nginx 访问日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（Nginx 访问日志，TCP 输入到 File 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 1,084,600 EPS，约是 Vector (91,200 EPS) 的 11.89 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（541.19 % vs 186.35 %）。
   • 内存: WarpParse 的内存占用更高（696.63 MB vs 230.62 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 11.89 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

sysmon_tcp_to_blackhole

本测试用于验证 sysmon_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：Sysmon 1K JSON 日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Sysmon 1K JSON 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（Sysmon 1K JSON 日志，TCP 输入到 BlackHole 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 418,900 EPS，约是 Vector (111,900 EPS) 的 3.74 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率基本持平（720.42 % vs 720.04 %）。
   • 内存: WarpParse 的内存占用更高（455.91 MB vs 362.95 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 3.74 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

sysmon_tcp_to_file

本测试用于验证 sysmon_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析）。

场景描述

本场景可概括为：Sysmon 1K JSON 日志，TCP 输入到 File 输出，执行 日志解析 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Sysmon 1K JSON 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Mac M4 Mini）

结论

在本测试场景（Sysmon 1K JSON 日志，TCP 输入到 File 输出，执行 日志解析 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 279,700 EPS，约是 Vector (62,100 EPS) 的 4.50 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（713.18 % vs 471.40 %）。
   • 内存: WarpParse 的内存占用更高（441.34 MB vs 343.65 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 4.50 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

apt_tcp_to_blackhole

本测试用于验证 apt_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：APT 3K 威胁日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 APT 3K 威胁日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（APT 3K 威胁日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 238,900 EPS，约是 Vector (34,000 EPS) 的 7.03 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更低（657.14 % vs 693.47 %）。
   • 内存: WarpParse 的内存占用更低（364.73 MB vs 408.92 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 7.03 倍），同时系统资源开销（CPU & 内存）均显著降低。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

apt_tcp_to_file

本测试用于验证 apt_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：APT 3K 威胁日志，TCP 输入到 File 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 APT 3K 威胁日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（APT 3K 威胁日志，TCP 输入到 File 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 169,800 EPS，约是 Vector (24,900 EPS) 的 6.82 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（663.90 % vs 538.78 %）。
   • 内存: WarpParse 的内存占用更高（871.77 MB vs 393.26 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 6.82 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

aws_tcp_to_blackhole

本测试用于验证 aws_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：AWS ELB 日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 AWS ELB 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（AWS ELB 日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 611,800 EPS，约是 Vector (152,900 EPS) 的 4.00 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率基本持平（624.17 % vs 611.53 %）。
   • 内存: WarpParse 的内存占用更高（478.25 MB vs 288.53 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 4.00 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

aws_tcp_to_file

本测试用于验证 aws_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：AWS ELB 日志，TCP 输入到 File 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 AWS ELB 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（AWS ELB 日志，TCP 输入到 File 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 318,200 EPS，约是 Vector (58,200 EPS) 的 5.47 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（593.16 % vs 331.78 %）。
   • 内存: WarpParse 的内存占用更高（409.21 MB vs 276.99 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 5.47 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

mixed_tcp_to_blackhole

本测试用于验证 mixed_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景覆盖两类混合日志：

• Mixed-1295B：四类日志 1:1:1:1 混合，平均 1295B。
• Mixed-867B：四类日志 3:2:1:1 混合，平均 867B。

链路为 TCP 输入到 BlackHole 输出，执行日志解析 + 转换。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Mixed 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证管线解析+转换能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确，转换链路正确执行。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Parse + Transform，Mac M4 Mini）

结论

在本测试场景（Mixed 日志，TCP 输入到 BlackHole 输出，执行 日志解析 + 转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 在两种混合配比下均显著领先。

   • 1:1:1:1 配比：387,400 EPS（MPS 478.44），约为 Vector 的 3.6x。
   • 3:2:1:1 配比：515,300 EPS（MPS 426.07），约为 Vector 的 3.3x。

2. 系统资源开销: 资源详情见报告主表。

总结: 两种混合配比下，WarpParse 在 TCP→BlackHole 的解析+转换场景均保持明显吞吐优势。

mixed_tcp_to_file

本测试用于验证 mixed_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景覆盖两类混合日志：

• Mixed-1295B：四类日志 1:1:1:1 混合，平均 1295B。
• Mixed-867B：四类日志 3:2:1:1 混合，平均 867B。

链路为 TCP 输入到 File 输出，执行日志解析 + 转换。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Mixed 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证端到端落盘链路的解析+转换能力。
4. 预期行为:

• 高频日志稳定消费，不丢失、不乱序，字段提取正确，转换链路正确执行。
• 在对应输入/输出链路下持续跑满数据源，不出现明显 backpressure。
• 监控指标可正常采集，用于后续性能对比。

Results（Parse + Transform，Mac M4 Mini）

结论

在本测试场景（Mixed 日志，TCP 输入到 File 输出，执行 日志解析 + 转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 在两种混合配比下均显著领先。

   • 1:1:1:1 配比：199,300 EPS（MPS 246.14），约为 Vector 的 3.3x。
   • 3:2:1:1 配比：299,600 EPS（MPS 247.72），约为 Vector 的 4.3x。

2. 系统资源开销: 资源详情见报告主表；落盘链路的内存峰值受缓冲策略影响。

总结: 两种混合配比下，WarpParse 在 TCP→File 解析+转换场景保持明显吞吐优势。

nginx_tcp_to_blackhole

本测试用于验证 nginx_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：Nginx 访问日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Nginx 访问日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（Nginx 访问日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 1,219,100 EPS，约是 Vector (870,500 EPS) 的 1.40 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更低（485.37 % vs 514.06 %）。
   • 内存: WarpParse 的内存占用更高（415.22 MB vs 238.50 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 1.40 倍），同时保持了更低的 CPU 占用。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

nginx_tcp_to_file

本测试用于验证 nginx_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：Nginx 访问日志，TCP 输入到 File 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Nginx 访问日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（Nginx 访问日志，TCP 输入到 File 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 797,700 EPS，约是 Vector (70,800 EPS) 的 11.27 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（492.15 % vs 160.79 %）。
   • 内存: WarpParse 的内存占用更高（523.97 MB vs 226.58 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 11.27 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

sysmon_tcp_to_blackhole

本测试用于验证 sysmon_tcp_to_blackhole 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：Sysmon 1K JSON 日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Sysmon 1K JSON 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: BlackHole 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（Sysmon 1K JSON 日志，TCP 输入到 BlackHole 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 299,500 EPS，约是 Vector (97,200 EPS) 的 3.08 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更低（664.56 % vs 710.83 %）。
   • 内存: WarpParse 的内存占用更低（367.47 MB vs 399.64 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 3.08 倍），同时系统资源开销（CPU & 内存）均显著降低。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

sysmon_tcp_to_file

本测试用于验证 sysmon_tcp_to_file 场景下的引擎性能（Mac M4 Mini，日志解析+转换）。

场景描述

本场景可概括为：Sysmon 1K JSON 日志，TCP 输入到 File 输出，执行 日志解析+转换 能力。

本测试旨在评估 WarpParse 与 Vector 两款引擎在 Sysmon 1K JSON 日志 处理场景下的表现。

设计

1. 测试目标: 对比两引擎在该日志场景下的吞吐、延迟、CPU/内存使用。
2. 输入配置: TCP 输入，覆盖高并发/大吞吐压测场景。
3. 输出配置: File 输出，用于验证链路吞吐能力。
4. 预期行为:

• 解析与转换链路正确执行，字段映射/增强结果与规则期望一致。
• 高负载下转换不成为瓶颈，整体吞吐稳定，延迟可控。
• 性能与资源指标可正常采集，用于后续对比与回归。

Results（Mac M4 Mini）

结论

在本测试场景（Sysmon 1K JSON 日志，TCP 输入到 File 输出，执行 日志解析+转换 能力）中，对比 WarpParse 与 Vector 的性能表现，得出以下结论：

1. 吞吐性能: WarpParse 表现出显著优势。

   • 消费速率达到 219,900 EPS，约是 Vector (40,300 EPS) 的 5.46 倍。
   • 这意味着在相同硬件资源下，WarpParse 能够处理更大规模的数据流量。

2. 系统资源开销:

   • CPU: WarpParse 的 CPU 使用率更高（719.29 % vs 391.09 %）。
   • 内存: WarpParse 的内存占用更高（431.93 MB vs 394.67 MB）。

总结: WarpParse 在该场景下展现了卓越的吞吐性能（领先约 5.46 倍），虽然在资源消耗上略有增加，但考虑到数倍的性能提升，整体能效比极高。对于追求高吞吐量的日志处理场景，WarpParse 是更优的选择。

tcp_blackhole 说明

本用例演示“TCP 源 → Blackhole 汇“的性能基准测试场景：使用 wpgen 通过 TCP 协议发送数据，wparse 以 daemon 模式接收并处理，输出到 blackhole 以测试可靠传输与解析的综合性能。

目录结构

benchmark/tcp_blackhole/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   ├── wpgen.toml              # 第一路 TCP 生成器配置
│   └── wpgen2.toml             # 第二路 TCP 生成器配置（可选）
├── models/                      # 模型配置目录
│   ├── sinks/                  # 数据汇配置
│   │   ├── defaults.toml       # 默认配置
│   │   ├── business.d/         # 业务组配置
│   │   │   └── sink.toml       # 业务汇组配置
│   │   └── infra.d/            # 基础设施组配置
│   │       ├── default.toml    # 默认数据汇
│   │       ├── error.toml      # 错误数据处理
│   │       ├── miss.toml       # 缺失数据处理
│   │       ├── monitor.toml    # 监控数据处理
│   │       └── residue.toml    # 残留数据处理
│   ├── sources/                # 数据源配置
│   │   └── wpsrc.toml          # TCP 源配置
│   ├── wpl/                    # WPL 解析规则目录
│   │   ├── nginx/              # Nginx 日志规则
│   │   ├── apache/             # Apache 日志规则
│   │   └── sysmon/             # 系统监控规则
│   ├── oml/                    # OML 转换规则目录（空）
│   └── knowledge/              # 知识库目录（空）
├── data/                        # 运行数据目录
│   ├── out_dat/                 # 输出数据目录
│   │   ├── error.dat           # 错误数据输出
│   │   ├── miss.dat            # 缺失数据输出
│   │   ├── monitor.dat         # 监控数据输出
│   │   └── residue.dat         # 残留数据输出
│   └── logs/                    # 日志文件目录
└── .run/                        # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 支持 TCP 网络连接的系统环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark

# 默认大规模性能测试（2000 万行数据）
./tcp_blackhole/run.sh

# 中等规模测试（20 万行数据）
./tcp_blackhole/run.sh -m

# 使用 sysmon 规则并限速 100 万行/秒
./tcp_blackhole/run.sh sysmon 1000000 

# 自定义测试参数
./tcp_blackhole/run.sh  -w 8 nginx 500000

./tcp_blackhole/run.sh  -w 8 sysmon 500000

运行参数

性能测试选项

• 默认测试：2000 万行 Nginx 日志，不限速，6 个 worker
• 中等测试：20 万行数据，适合快速验证
• 自定义 WPL：支持 nginx、apache、sysmon 等规则
• 速率限制：可指定生成速率，测试流控性能

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 初始化环境

   • 初始化 release 模式环境
   • 验证指定的 WPL 规则路径
   • 清理历史数据和日志

3. 启动 Daemon 模式

   • 启动 wparse daemon 监听 TCP 端口
   • 加载指定的 WPL 规则
   • 等待 TCP 连接

4. 数据生成与发送

   • 启动 wpgen 生成测试数据
   • 通过 TCP 协议发送到 wparse daemon
   • 支持单路或双路并发发送

5. 性能监控

   • 实时监控处理速度
   • 记录吞吐量、延迟等指标
   • 收集错误和异常统计

6. 结果统计

   • 停止 daemon 进程
   • 输出性能报告
   • 验证数据完整性

数据流向

wpgen 生成器
    ↓ TCP 连接 (端口 19001)
┌────────────────────────────────┐
│        wparse daemon           │
│    - 接收 TCP 数据              │
│    - 应用 WPL 规则解析           │
│    - 分发到 sinks               │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│  blackhole  │   monitor   │
│    sink     │    sink     │
│ (丢弃数据)  │ (收集统计)     │
└─────────────┴─────────────┘

验证与故障排除

运行成功验证

1. 检查性能输出

   • 查看 terminal 输出的实时统计信息
   • 关注 “Throughput”（吞吐量）指标
   • 确认无错误或异常

2. 验证输出文件

   # 检查监控数据
   ls -la data/out_dat/monitor.dat
   
   # 确认其他文件为空（无错误）
   ls -la data/out_dat/{error,miss,residue}.dat
   

常见问题与解决方案

1. TCP 连接被拒绝

错误信息：Connection refused

解决方案：

• 确认 wparse daemon 已成功启动
• 检查端口 19001 是否被占用
• 验证防火墙设置

# 检查端口占用
netstat -tlnp | grep 19001

# 或使用 ss 命令
ss -tlnp | grep 19001

2. daemon 进程未正常退出

解决方案：

# 查找并终止 wparse 进程
ps aux | grep wparse
kill -9 <PID>

# 清理可能残留的端口占用
sudo lsof -i :19001

性能

优化

1. 系统级优化

   Linux 系统：

   # CPU 亲和性设置
   taskset -c 0-5 ./run.sh -w 6
   
   # 实时优先级（需要 root）
   sudo chrt -f 99 ./run.sh
   
   # 调整 TCP 缓冲区（需要 root）
   sudo sysctl -w net.core.wmem_max=26214400
   sudo sysctl -w net.core.rmem_max=26214400
   

影响因素

1. WPL 规则复杂度

   • nginx：简单正则，性能最佳
   • apache：中等复杂度
   • sysmon：复杂规则，性能较低

2. 数据特征

   • 日志行长度
   • 正则匹配复杂度
   • 字段提取数量

3. 系统配置

   • CPU 核心数和频率
   • 内存大小和速度
   • 磁盘 I/O（日志写入）

本文档最后更新时间：2025-12-16

tcp_blackhole 说明

本用例演示“TCP 源 → Blackhole 汇“的性能基准测试场景：使用 wpgen 通过 TCP 协议发送数据，wparse 以 daemon 模式接收并处理，输出到 blackhole 以测试可靠传输与解析的综合性能。

目录结构

benchmark/tcp_blackhole/
├── README.md                    # 本说明文档
├── run.sh                       # 性能测试运行脚本
├── conf/                        # 配置文件目录
│   ├── wparse.toml             # WarpParse 主配置
│   ├── wpgen.toml              # 第一路 TCP 生成器配置
│   └── wpgen2.toml             # 第二路 TCP 生成器配置（可选）
├── models/                      # 模型配置目录
│   ├── sinks/                  # 数据汇配置
│   │   ├── defaults.toml       # 默认配置
│   │   ├── business.d/         # 业务组配置
│   │   │   └── sink.toml       # 业务汇组配置
│   │   └── infra.d/            # 基础设施组配置
│   │       ├── default.toml    # 默认数据汇
│   │       ├── error.toml      # 错误数据处理
│   │       ├── miss.toml       # 缺失数据处理
│   │       ├── monitor.toml    # 监控数据处理
│   │       └── residue.toml    # 残留数据处理
│   ├── sources/                # 数据源配置
│   │   └── wpsrc.toml          # TCP 源配置
│   ├── wpl/                    # WPL 解析规则目录
│   │   ├── nginx/              # Nginx 日志规则
│   │   ├── apache/             # Apache 日志规则
│   │   └── sysmon/             # 系统监控规则
│   ├── oml/                    # OML 转换规则目录（空）
│   └── knowledge/              # 知识库目录（空）
├── data/                        # 运行数据目录
│   ├── out_dat/                 # 输出数据目录
│   │   ├── error.dat           # 错误数据输出
│   │   ├── miss.dat            # 缺失数据输出
│   │   ├── monitor.dat         # 监控数据输出
│   │   └── residue.dat         # 残留数据输出
│   └── logs/                    # 日志文件目录
└── .run/                        # 运行时数据目录
    └── rule_mapping.dat        # 规则映射数据

快速开始

运行环境要求

• WarpParse 引擎（需在系统 PATH 中）
• Bash shell 环境
• 支持 TCP 网络连接的系统环境
• 推荐系统：
  • Linux：最佳性能，支持所有优化功能
  • macOS：良好性能，部分优化功能受限

运行命令

# 进入 benchmark 目录
cd benchmark

# 默认大规模性能测试（2000 万行数据）
./tcp_blackhole/run.sh

# 中等规模测试（20 万行数据）
./tcp_blackhole/run.sh -m

# 使用 sysmon 规则并限速 100 万行/秒
./tcp_blackhole/run.sh sysmon 1000000 

# 自定义测试参数
./tcp_blackhole/run.sh  -w 8 nginx 500000

./tcp_blackhole/run.sh  -w 8 sysmon 500000

运行参数

性能测试选项

• 默认测试：2000 万行 Nginx 日志，不限速，6 个 worker
• 中等测试：20 万行数据，适合快速验证
• 自定义 WPL：支持 nginx、apache、sysmon 等规则
• 速率限制：可指定生成速率，测试流控性能

执行逻辑

流程概览

run.sh 脚本执行以下主要步骤：

1. 环境准备

   • 加载 benchmark 公共函数库
   • 解析命令行参数
   • 设置默认值（大规模：2000万行，中等：20万行）

2. 初始化环境

   • 初始化 release 模式环境
   • 验证指定的 WPL 规则路径
   • 清理历史数据和日志

3. 启动 Daemon 模式

   • 启动 wparse daemon 监听 TCP 端口
   • 加载指定的 WPL 规则
   • 等待 TCP 连接

4. 数据生成与发送

   • 启动 wpgen 生成测试数据
   • 通过 TCP 协议发送到 wparse daemon
   • 支持单路或双路并发发送

5. 性能监控

   • 实时监控处理速度
   • 记录吞吐量、延迟等指标
   • 收集错误和异常统计

6. 结果统计

   • 停止 daemon 进程
   • 输出性能报告
   • 验证数据完整性

数据流向

wpgen 生成器
    ↓ TCP 连接 (端口 19001)
┌────────────────────────────────┐
│        wparse daemon           │
│    - 接收 TCP 数据              │
│    - 应用 WPL 规则解析           │
│    - 分发到 sinks               │
└────────────────────────────────┘
    ↓
┌─────────────┬─────────────┐
│  blackhole  │   monitor   │
│    sink     │    sink     │
│ (丢弃数据)  │ (收集统计)     │
└─────────────┴─────────────┘

验证与故障排除

运行成功验证

1. 检查性能输出

   • 查看 terminal 输出的实时统计信息
   • 关注 “Throughput”（吞吐量）指标
   • 确认无错误或异常

2. 验证输出文件

   # 检查监控数据
   ls -la data/out_dat/monitor.dat
   
   # 确认其他文件为空（无错误）
   ls -la data/out_dat/{error,miss,residue}.dat
   

常见问题与解决方案

1. TCP 连接被拒绝

错误信息：Connection refused

解决方案：

• 确认 wparse daemon 已成功启动
• 检查端口 19001 是否被占用
• 验证防火墙设置

# 检查端口占用
netstat -tlnp | grep 19001

# 或使用 ss 命令
ss -tlnp | grep 19001

2. daemon 进程未正常退出

解决方案：

# 查找并终止 wparse 进程
ps aux | grep wparse
kill -9 <PID>

# 清理可能残留的端口占用
sudo lsof -i :19001

性能

优化

1. 系统级优化

   Linux 系统：

   # CPU 亲和性设置
   taskset -c 0-5 ./run.sh -w 6
   
   # 实时优先级（需要 root）
   sudo chrt -f 99 ./run.sh
   
   # 调整 TCP 缓冲区（需要 root）
   sudo sysctl -w net.core.wmem_max=26214400
   sudo sysctl -w net.core.rmem_max=26214400
   

影响因素

1. WPL 规则复杂度

   • nginx：简单正则，性能最佳
   • apache：中等复杂度
   • sysmon：复杂规则，性能较低

2. 数据特征

   • 日志行长度
   • 正则匹配复杂度
   • 字段提取数量

3. 系统配置

   • CPU 核心数和频率
   • 内存大小和速度
   • 磁盘 I/O（日志写入）

本文档最后更新时间：2025-12-16

Linux性能测试报告

1. 技术概述与测试背景

1.1 测试背景

本报告旨在深度对比 WarpParse 与 Vector 在高性能日志处理场景下的能力差异。基于 Linux 平台测试数据，覆盖从轻量级 Web 日志到复杂的安全威胁日志，重点评估两者在单机环境下的解析（Parse）与转换（Transform）性能、资源消耗及规则维护成本。

1.2 被测对象

• WarpParse: 大禹安全公司研发的高性能 ETL 核心引擎，采用 Rust 构建，专为极致吞吐和复杂安全日志分析设计。
• Vector: 开源领域标杆级可观测性数据管道工具，同样采用 Rust 构建，以高性能和广泛的生态兼容性著称。

2. 测试环境与方法

2.1 测试环境（Test Environment）

平台信息（Platform）

• 平台类型：AWS EC2
• 操作系统：Ubuntu 24.04 LTS
• 系统架构：x86_64

计算资源（Compute）

• CPU：8 vCPU
• 内存：16 GiB

存储配置（Storage）

• 存储类型：Amazon EBS
• 卷类型：通用型 SSD（gp3）
• 卷大小：128 GiB
• IOPS：30,000
• 吞吐量：200 MiB/s

说明（Notes）

• gp3 卷支持 IOPS 与吞吐量独立配置，用于避免容量与性能强绑定
• 当前配置提供较高的随机 I/O 能力（IOPS），并具备中等顺序 I/O 吞吐能力

2.2 测试范畴 (Scope)

• 日志类型:
  • Nginx Access Log (239B): 典型 Web 访问日志，高吞吐场景。
  • AWS ELB Log (411B): 云设施负载均衡日志，中等复杂度。
  • Sysmon JSON (1K): 终端安全监控日志，JSON 结构，字段较多。
  • APT Threat Log (3K): 模拟的高级持续性威胁日志，大体积、长文本。
  • Mixed Log: 上述四类日志混合形成的日志类型。
• 数据拓扑:
  • File -> BlackHole: 测算引擎极限 I/O 读取与处理能力 (基准)。
  • TCP -> BlackHole: 测算网络接收与处理能力。
  • TCP -> File: 测算端到端完整落地能力。
• 测试能力:
  • 解析 (Parse): 仅进行正则提取/JSON解析与字段标准化。
  • 解析+转换 (Parse+Transform): 在解析基础上增加字段映射、富化、类型转换等逻辑。

2.3 评估指标

• EPS (Events Per Second): 每秒处理事件数（核心吞吐指标）。
• MPS (MiB/s): 每秒处理数据量。
• CPU/Memory: 进程平均与峰值资源占用。
• Rule Size: 规则配置文件体积，评估分发与维护成本。

3. 详细性能对比分析

3.1 日志解析能力 (Parse Only)

3.1.1 Nginx Access Log (239B)

解析规则大小：

• WarpParse：174B
• Vector：416B

3.1.2 AWS ELB Log (411B)

解析规则大小：

• WarpParse：1153B
• Vector：2289B

3.1.3 Sysmon JSON Log (1K)

解析规则大小：

• WarpParse：1552B
• Vector：3259B

3.1.4 APT Threat Log (3K)

解析规则大小：

• WarpParse：985B
• Vector：1759B

3.1.5 Mixed Log (平均日志大小：867B)

解析规则大小：

• WarpParse：6102B
• Vector：9373B

混合日志规则：

• 4类日志按照3:2:1:1混合

3.2 解析 + 转换能力 (Parse + Transform)

3.2.1 Nginx Access Log（239B）

解析+转换规则大小：

• WarpParse：521B
• Vector：682B

3.2.2 AWS ELB Log（411B）

解析+转换规则大小：

• WarpParse：1694B
• Vector：2650B

3.2.3 Sysmon JSON Log (1K)

解析+转换规则大小：

• WarpParse：2249B
• Vector：3782B

3.2.4 APT Threat Log (3K)

解析+转换规则大小：

• WarpParse：1638B
• Vector：2259B

3.2.5 Mixed Log (平均日志大小：867B)

解析+转换规则大小：

• WarpParse：6102B
• Vector：9373B

混合日志规则：

• 4类日志按照3:2:1:1混合

4. 核心发现与架构优势分析

4.1 性能与资源效率

核心发现:

1. 吞吐量领先: Linux 平台各测试场景下，WarpParse 在解析场景领先 2.0x - 21.5x，解析+转换场景领先 1.8x - 16.9x。
2. 算力利用率: WarpParse 依然采用“以算力换吞吐”的策略，CPU 占用高于 Vector，但换取数倍吞吐回报。
3. 大日志处理: 在 APT (3K) 场景下，WarpParse 维持高吞吐与高 MPS，Vector 吞吐下降明显。

4.2 规则与维护成本

优势分析:

• 规则体积更小: 同等语义下，WarpParse 的规则体积显著小于 Vector 的 VRL 脚本。
  • Nginx: 174B (WarpParse) vs 416B (Vector)
  • APT: 985B (WarpParse) vs 1759B (Vector)
• 维护性: 规则体积更小意味着更快的分发与更短的冷启动时间，适合大规模 Agent 或边缘场景。

4.3 稳定性

• 压力测试过程中，WarpParse 保持稳定吞吐，未观察到明显背压导致的处理崩塌。
• 注意点: 在 TCP -> File 场景下，WarpParse 的内存占用在大包场景会有上升（如 APT 场景 1GB+），与其缓冲策略相关。

5. 总结与建议

结论: Linux 平台测试显示，WarpParse 在吞吐、规则体积与端到端能力上均优于 Vector，特别适用于 SIEM/SOC 等实时高吞吐日志处理场景。

Mac 性能测试报告

1. 技术概述与测试背景

1.1 测试背景

本报告旨在深度对比 WarpParse 与 Vector 在高性能日志处理场景下的能力差异。基于最新基线数据，测试覆盖了从轻量级 Web 日志到复杂的安全威胁日志，重点评估两者在单机环境下的解析（Parse）与转换（Transform）性能、资源消耗及规则维护成本。

1.2 被测对象

• WarpParse: 大禹安全公司研发的高性能 ETL 核心引擎，采用 Rust 构建，专为极致吞吐和复杂安全日志分析设计。
• Vector: 开源领域标杆级可观测性数据管道工具，同样采用 Rust 构建，以高性能和广泛的生态兼容性著称。

2. 测试环境与方法

2.1 测试环境

• 平台: Mac M4 Mini
• 操作系统: MacOS
• 硬件规格: 10C16G

2.2 测试范畴 (Scope)

• 日志类型:
  • Nginx Access Log (239B): 典型 Web 访问日志，高吞吐场景。
  • AWS ELB Log (411B): 云设施负载均衡日志，中等复杂度。
  • Sysmon JSON (1K): 终端安全监控日志，JSON 结构，字段较多。
  • APT Threat Log (3K): 模拟的高级持续性威胁日志，大体积、长文本。
  • Mixed Log (): 上述四类日志混合起来形成的日志类型。
• 数据拓扑:
  • File -> BlackHole: 测算引擎极限 I/O 读取与处理能力 (基准)。
  • TCP -> BlackHole: 测算网络接收与处理能力。
  • TCP -> File: 测算端到端完整落地能力。
• 测试能力:
  • 解析 (Parse): 仅进行正则提取/JSON解析与字段标准化。
  • 解析+转换 (Parse+Transform): 在解析基础上增加字段映射、富化、类型转换等逻辑。

2.3 评估指标

• EPS (Events Per Second): 每秒处理事件数（核心吞吐指标）。
• MPS (MiB/s): 每秒处理数据量。
• CPU/Memory: 进程平均与峰值资源占用。
• Rule Size: 规则配置文件体积，评估分发与维护成本。

3. 详细性能对比分析

3.1 日志解析能力 (Parse Only)

在纯解析场景下，WarpParse 展现出压倒性的性能优势，尤其在小包高并发场景下。

3.1.1 Nginx Access Log (239B)

解析规则大小：

• WarpParse：174B
• Vector：416B

3.1.2 AWS ELB Log (411B)

解析规则大小：

• WarpParse：1153B
• Vector：2289B

3.1.3 Sysmon JSON Log (1K)

解析规则大小：

• WarpParse：1552B
• Vector：3259B

3.1.4 APT Threat Log (3K)

解析规则大小：

• WarpParse：985B
• Vector：1759B

3.1.5 Mixed log (平均日志大小：867B)

解析规则大小：

• WarpParse：3864B
• Vector：7723B

混合日志规则：

• 4类日志按照3:2:1:1混合

3.2 解析 + 转换能力 (Parse + Transform)

引入转换逻辑后，WarpParse 依然保持显著领先，表明其数据处理管线极其高效，转换操作未成为瓶颈。

3.2.1 Nginx Access Log（239B）

解析+转换规则大小：

• WarpParse：521B
• Vector：682B

3.2.2 AWS ELB Log（411B）

解析+转换规则大小：

• WarpParse：1694B
• Vector：2650B

3.2.3 Sysmon JSON Log (1K)

解析+转换规则大小：

• WarpParse：2249B
• Vector：3782B

3.2.4 APT Threat Log (3K)

解析+转换规则大小：

• WarpParse：1638B
• Vector：2259B

3.2.5 Mixed Log (平均日志大小：1295B)

解析+转换规则大小：

• WarpParse：6102B
• Vector：9373B

混合日志规则：

• 4类日志按照1:1:1:1混合

3.2.6 Mixed Log (平均日志大小：867B)

解析+转换规则大小：

• WarpParse：6102B
• Vector：9373B

混合日志规则：

• 4类日志按照3:2:1:1混合

3.3 linux测试数据

3.3.1 Nginx Access Log (239B)

解析规则大小：

• WarpParse：174B
• Vector：416B

3.3.2 AWS ELB Log (411B)

解析规则大小：

• WarpParse：1153B
• Vector：2289B

3.3.3 Sysmon JSON Log (1K)

解析规则大小：

• WarpParse：1552B
• Vector：3259B

3.3.4 APT Threat Log (3K)

解析规则大小：

• WarpParse：985B
• Vector：1759B

3.3.5 Mixed Log (平均日志大小：867B)

解析+转换规则大小：

• WarpParse：6102B
• Vector：9373B

混合日志规则：

• 4类日志按照3:2:1:1混合

3.4.1 Nginx Access Log（239B）

解析+转换规则大小：

• WarpParse：521B
• Vector：682B

3.4.2 AWS ELB Log（411B）

解析+转换规则大小：

• WarpParse：1694B
• Vector：2650B

3.4.3 Sysmon JSON Log (1K)

解析+转换规则大小：

• WarpParse：2249B
• Vector：3782B

3.4.4 APT Threat Log (3K)

解析+转换规则大小：

• WarpParse：1638B
• Vector：2259B

3.4.5 Mixed Log (平均日志大小：867B)

• 解析+转换规则大小：

  • WarpParse：6102B
  • Vector：9373B

  混合日志规则：

  • 4类日志按照3:2:1:1混合

4. 核心发现与架构优势分析

4.1 性能与资源效率

核心发现:

1. 吞吐量碾压: 在所有 24 组对比测试中，WarpParse 均取得领先。解析场景下平均领先 3.7x - 11.9x，解析+转换场景下领先 1.4x - 11.3x。
2. 算力利用率: WarpParse 倾向于“以算力换吞吐“，CPU 占用率普遍高于 Vector，但换来了数倍的处理能力。例如在 Sysmon 解析中，WarpParse 用 1.8 倍的 CPU 换取了 Vector 5.7 倍的吞吐。
3. 大日志处理: 在 APT (3K) 这种大体积日志场景下，WarpParse 展现出极强的稳定性，MPS 达到 1062 MiB/s，接近千兆处理能力，而 Vector 在该场景下吞吐下降明显。

4.2 规则与维护成本

优势分析:

• 规则体积更小: 同等语义下，WarpParse 的 WPL/OML 规则体积显著小于 Vector 的 VRL 脚本。
  • Nginx: 174B (WarpParse) vs 416B (Vector)
  • APT: 985B (WarpParse) vs 1759B (Vector)
• 维护性: 更小的规则体积意味着更快的网络分发速度、更短的冷启动时间，这在边缘计算或大规模 Agent 下发场景中至关重要。

4.3 稳定性

• 在整个高压测试过程中，WarpParse 保持了极高的吞吐稳定性，未观察到显著的 Backpressure（背压）导致的处理崩塌。
• 注意点: 在 TCP -> File 的端到端场景中，WarpParse 的内存占用在部分大包场景下会有所上升（如 APT 场景达到 1GB+），这与其为了维持高吞吐而使用的缓冲策略有关。

5. 总结与建议

结论: 对于专注于日志分析、安全事件处理（SIEM/SOC）、以及对实时性有苛刻要求的 ETL 场景，WarpParse 是优于 Vector 的选择。它通过更高效的 Rust 实现和专用的 WPL/OML 语言，成功打破了通用 ETL 工具的性能天花板。

Rule Definitions

本文档汇总了测试中使用的解析与解析+转换规则，按日志类型与引擎归档，并用 Markdown 对“解析配置 / 解析+转换配置”作清晰标注。

1. Nginx Access Log (239B)

WarpParse

• 解析配置（WPL）

package /nginx/ {
   rule nginx {
        (ip:sip,_^2,chars:timestamp<[,]>,http/request:http_request",chars:status,chars:size,chars:referer",http/agent:http_agent",_")
   }
}

• 解析+转换配置（WPL + OML）

package /nginx/ {
   rule nginx {
        (ip:sip,_^2,chars:timestamp<[,]>,http/request:http_request",chars:status,chars:size,chars:referer",http/agent:http_agent",_")
   }
}

name : nginx
rule : /nginx/*
---
size : digit = take(size);
status : digit = take(status);
str_status = match read(option:[status]) {
    digit(500) => chars(Internal Server Error);
    digit(404) => chars(Not Found); 
};
match_chars = match read(option:[wp_src_ip]) {
    ip(127.0.0.1) => chars(localhost); 
    !ip(127.0.0.1) => chars(attack_ip); 
};
* : auto = read();

Vector

• 解析配置（VRL）

source = '''
  parsed = parse_regex!(.message, r'^(?P<client>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] "(?P<request>[^"]*)" (?P<status>\d{3}) (?P<size>\d+) "(?P<referer>[^"]*)" "(?P<agent>[^"]*)" "(?P<extra>[^"]*)"')
  .sip = parsed.client
  .http_request = parsed.request
  .status = parsed.status
  .size = parsed.size
  .referer = parsed.referer
  .http_agent = parsed.agent
  .timestamp = parsed.time
  del(.message)
'''

• 解析+转换配置（VRL）

source = '''
  parsed = parse_regex!(.message, r'^(?P<client>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] "(?P<request>[^"]*)" (?P<status>\d{3}) (?P<size>\d+) "(?P<referer>[^"]*)" "(?P<agent>[^"]*)" "(?P<extra>[^"]*)"')
  .sip = parsed.client
  .http_request = parsed.request
  .referer = parsed.referer
  .http_agent = parsed.agent
  .timestamp = parsed.time
  del(.message)
  .status = to_int!(parsed.status)
  .size = to_int!(parsed.size)
if .host == "127.0.0.1" {
    .match_chars = "localhost"
} else if .host != "127.0.0.1" {
    .match_chars = "attack_ip"
}  
if .status == 500 {
    .str_status = "Internal Server Error"
} else if .status == 404 {
    .str_status = "Not Found"
}  
'''

2. AWS ELB Log (411B)

WarpParse

• 解析配置（WPL）

package /aws/ {
   rule aws {
        (
            symbol(http),
            chars:timestamp,
            chars:elb,
            chars:client_host,
            chars:target_host,
            chars:request_processing_time,
            chars:target_processing_time,
            chars:response_processing_time,
            chars:elb_status_code,
            chars:target_status_code,
            chars:received_bytes,
            chars:sent_bytes,
            chars:request | (chars:request_method, chars:request_url, chars:request_protocol),
            chars:user_agent,
            chars:ssl_cipher,
            chars:ssl_protocol,
            chars:target_group_arn,
            chars:trace_id,
            chars:domain_name,
            chars:chosen_cert_arn,
            chars:matched_rule_priority,
            chars:request_creation_time,
            chars:actions_executed,
            chars:redirect_url,
            chars:error_reason,
            chars:target_port_list,
            chars:target_status_code_list,
            chars:classification,
            chars:classification_reason,
            chars:traceability_id,
        )
   }
   }

• 解析+转换配置（WPL + OML）

package /aws/ {
   rule aws {
        (
            symbol(http),
            chars:timestamp,
            chars:elb,
            chars:client_host,
            chars:target_host,
            chars:request_processing_time,
            chars:target_processing_time,
            chars:response_processing_time,
            chars:elb_status_code,
            chars:target_status_code,
            chars:received_bytes,
            chars:sent_bytes,
            chars:request | (chars:request_method, chars:request_url, chars:request_protocol),
            chars:user_agent,
            chars:ssl_cipher,
            chars:ssl_protocol,
            chars:target_group_arn,
            chars:trace_id,
            chars:domain_name,
            chars:chosen_cert_arn,
            chars:matched_rule_priority,
            chars:request_creation_time,
            chars:actions_executed,
            chars:redirect_url,
            chars:error_reason,
            chars:target_port_list,
            chars:target_status_code_list,
            chars:classification,
            chars:classification_reason,
            chars:traceability_id,
        )
   }
   }

name : aws
rule : /aws/*
---
sent_bytes:digit = take(sent_bytes) ;
target_status_code:digit = take(target_status_code) ;
elb_status_code:digit = take(elb_status_code) ;
extends : obj = object {
    ssl_cipher = read(ssl_cipher);
    ssl_protocol = read(ssl_protocol);
};
match_chars = match read(option:[wp_src_ip]) {
    ip(127.0.0.1) => chars(localhost); 
    !ip(127.0.0.1) => chars(attack_ip); 
};
str_elb_status = match read(option:[elb_status_code]) {
    digit(200) => chars(ok);
    digit(404) => chars(error); 
};
* : auto = read();

Vector

• 解析配置（VRL）

source = '''
  parsed = parse_regex!(.message, r'^(?P<type>\S+) (?P<timestamp>\S+) (?P<elb>\S+) (?P<client_host>\S+) (?P<target_host>\S+) (?P<request_processing_time>[-\d\.]+) (?P<target_processing_time>[-\d\.]+) (?P<response_processing_time>[-\d\.]+) (?P<elb_status_code>\S+) (?P<target_status_code>\S+) (?P<received_bytes>\d+) (?P<sent_bytes>\d+) "(?P<request_method>\S+) (?P<request_url>[^ ]+) (?P<request_protocol>[^"]+)" "(?P<user_agent>[^"]*)" "(?P<ssl_cipher>[^"]*)" "(?P<ssl_protocol>[^"]*)" (?P<target_group_arn>\S+) "(?P<trace_id>[^"]*)" "(?P<domain_name>[^"]*)" "(?P<chosen_cert_arn>[^"]*)" (?P<matched_rule_priority>\S+) (?P<request_creation_time>\S+) "(?P<actions_executed>[^"]*)" "(?P<redirect_url>[^"]*)" "(?P<error_reason>[^"]*)" "(?P<target_port_list>[^"]*)" "(?P<target_status_code_list>[^"]*)" "(?P<classification>[^"]*)" "(?P<classification_reason>[^"]*)" (?P<traceability_id>\S+)$')
  .timestamp = parsed.timestamp
  .symbol = parsed.type
  .elb = parsed.elb
  .client_host = parsed.client_host
  .target_host = parsed.target_host
  .request_processing_time = parsed.request_processing_time
  .target_processing_time = parsed.target_processing_time
  .response_processing_time = parsed.response_processing_time
  .elb_status_code = parsed.elb_status_code
  .target_status_code = parsed.target_status_code
  .received_bytes = parsed.received_bytes
  .sent_bytes = parsed.sent_bytes
  .request_method = parsed.request_method
  .request_url = parsed.request_url
  .request_protocol = parsed.request_protocol
  .user_agent = parsed.user_agent
  .ssl_cipher = parsed.ssl_cipher
  .ssl_protocol = parsed.ssl_protocol
  .target_group_arn = parsed.target_group_arn
  .trace_id = parsed.trace_id
  .domain_name = parsed.domain_name
  .chosen_cert_arn = parsed.chosen_cert_arn
  .matched_rule_priority = parsed.matched_rule_priority
  .request_creation_time = parsed.request_creation_time
  .actions_executed = parsed.actions_executed
  .redirect_url = parsed.redirect_url
  .error_reason = parsed.error_reason
  .target_port_list = parsed.target_port_list
  .target_status_code_list = parsed.target_status_code_list
  .classification = parsed.classification
  .classification_reason = parsed.classification_reason
  .traceability_id = parsed.traceability_id
  del(.message)
'''

• 解析+转换配置（VRL）

source = '''
  parsed = parse_regex!(.message, r'^(?P<type>\S+) (?P<timestamp>\S+) (?P<elb>\S+) (?P<client_host>\S+) (?P<target_host>\S+) (?P<request_processing_time>[-\d\.]+) (?P<target_processing_time>[-\d\.]+) (?P<response_processing_time>[-\d\.]+) (?P<elb_status_code>\S+) (?P<target_status_code>\S+) (?P<received_bytes>\d+) (?P<sent_bytes>\d+) "(?P<request_method>\S+) (?P<request_url>[^ ]+) (?P<request_protocol>[^"]+)" "(?P<user_agent>[^"]*)" "(?P<ssl_cipher>[^"]*)" "(?P<ssl_protocol>[^"]*)" (?P<target_group_arn>\S+) "(?P<trace_id>[^"]*)" "(?P<domain_name>[^"]*)" "(?P<chosen_cert_arn>[^"]*)" (?P<matched_rule_priority>\S+) (?P<request_creation_time>\S+) "(?P<actions_executed>[^"]*)" "(?P<redirect_url>[^"]*)" "(?P<error_reason>[^"]*)" "(?P<target_port_list>[^"]*)" "(?P<target_status_code_list>[^"]*)" "(?P<classification>[^"]*)" "(?P<classification_reason>[^"]*)" (?P<traceability_id>\S+)$')
  .timestamp = parsed.timestamp
  .symbol = parsed.type
  .elb = parsed.elb
  .client_host = parsed.client_host
  .target_host = parsed.target_host
  .request_processing_time = parsed.request_processing_time
  .target_processing_time = parsed.target_processing_time
  .response_processing_time = parsed.response_processing_time
  .received_bytes = parsed.received_bytes
  .request_method = parsed.request_method
  .request_url = parsed.request_url
  .request_protocol = parsed.request_protocol
  .user_agent = parsed.user_agent
  .ssl_cipher = parsed.ssl_cipher
  .ssl_protocol = parsed.ssl_protocol
  .target_group_arn = parsed.target_group_arn
  .trace_id = parsed.trace_id
  .domain_name = parsed.domain_name
  .chosen_cert_arn = parsed.chosen_cert_arn
  .matched_rule_priority = parsed.matched_rule_priority
  .request_creation_time = parsed.request_creation_time
  .actions_executed = parsed.actions_executed
  .redirect_url = parsed.redirect_url
  .error_reason = parsed.error_reason
  .target_port_list = parsed.target_port_list
  .target_status_code_list = parsed.target_status_code_list
  .classification = parsed.classification
  .classification_reason = parsed.classification_reason
  .traceability_id = parsed.traceability_id
  del(.message)
  .elb_status_code = to_int!(parsed.elb_status_code)
  .target_status_code = to_int!(parsed.target_status_code)
  .sent_bytes = to_int!(parsed.sent_bytes)
if .host == "127.0.0.1" {
    .match_chars = "localhost"
} else if .host != "127.0.0.1" {
    .match_chars = "attack_ip"
}   
if .elb_status_code == 200 {
    .str_elb_status = "ok"
} else if .elb_status_code == 404 {
    .str__elb_status = "error"
}
  .extends = {
    "ssl_cipher": .ssl_cipher,
    "ssl_protocol": .ssl_protocol,
}
'''

3. Sysmon Log (1K, JSON)

WarpParse

• 解析配置（WPL）

package /sysmon/ {
   rule sysmon {
        (_:pri<<,>>,3*_,_),(_\S\y\s\m\o\n\:,
        json(
            @Id:id,
            @Description/ProcessId:process_id,
            @Level:severity,
            @Opcode:Opcode,
            @ProcessId:ProcessId,
            @Task:Task,
            @ThreadId:ThreadId
            @Version:Version,
            @Description/CommandLine:cmd_line,
            @Description/ParentCommandLine:parent_cmd_line,
            @Description/LogonGuid:logon_guid,
            @Description/LogonId:logon_id,
            @Description/Image:process_path,
            @Description/ParentImage:parent_process_path,
            @Description/ParentProcessGuid:parent_process_guid,
            @Description/ParentProcessId:parent_process_id,
            @Description/ParentUser:parent_process_user,
            @Description/ProcessGuid:process_guid,
            @Description/Company:product_company,
            @Description/Description:process_desc,
            @Description/FileVersion:file_version,
            chars@Description/Hashes:Hashes
            @Description/IntegrityLevel:integrity_level,
            @Description/OriginalFileName:origin_file_name,
            @Description/Product:product_name,
            @Description/RuleName:rule_name,
            @Description/User:user_name,
            chars@Description/UtcTime:occur_time,
            @Description/TerminalSessionId:terminal_session_id,
            @Description/CurrentDirectory:current_dir,
            @Keywords:keywords
            )
        )
    }
   }

• 解析+转换配置（WPL + OML）

package /sysmon/ {
   rule sysmon {
        (_:pri<<,>>,3*_,_),(_\S\y\s\m\o\n\:,
        json(
            @Id:id,
            @Description/ProcessId:process_id,
            @Level:severity,
            @Opcode:Opcode,
            @ProcessId:ProcessId,
            @Task:Task,
            @ThreadId:ThreadId
            @Version:Version,
            @Description/CommandLine:cmd_line,
            @Description/ParentCommandLine:parent_cmd_line,
            @Description/LogonGuid:logon_guid,
            @Description/LogonId:logon_id,
            @Description/Image:process_path,
            @Description/ParentImage:parent_process_path,
            @Description/ParentProcessGuid:parent_process_guid,
            @Description/ParentProcessId:parent_process_id,
            @Description/ParentUser:parent_process_user,
            @Description/ProcessGuid:process_guid,
            @Description/Company:product_company,
            @Description/Description:process_desc,
            @Description/FileVersion:file_version,
            chars@Description/Hashes:Hashes
            @Description/IntegrityLevel:integrity_level,
            @Description/OriginalFileName:origin_file_name,
            @Description/Product:product_name,
            @Description/RuleName:rule_name,
            @Description/User:user_name,
            chars@Description/UtcTime:occur_time,
            @Description/TerminalSessionId:terminal_session_id,
            @Description/CurrentDirectory:current_dir,
            @Keywords:keywords
            )
        )
    }
   }

name : sysmon
rule : /sysmon/*
---
Id:digit = take(id) ;
LogonId:digit = take(logon_id) ;
enrich_level = match read(option:[severity]) {
    chars(4) => chars(severity);
    chars(3) => chars(normal);
};
extends : obj = object {
    OriginalFileName = read(origin_file_name);
    ParentCommandLine = read(parent_cmd_line);
};
extends_dir = object {
    ParentProcessPath = read(parent_process_path);
    Process_path = read(process_path);
};
match_chars = match read(option:[wp_src_ip]) {
    ip(127.0.0.1) => chars(localhost); 
    !ip(127.0.0.1) => chars(attack_ip); 
};
num_range = match read(option:[Id]) {
    in ( digit(0), digit(1000) ) => read(Id) ;
    _ => digit(0) ;
};
* : auto = read();

Vector

• 解析配置（VRL）

source = '''
  parsed_msg = parse_regex!(.message, r'^[^{]*(?P<body>\{.*)$')
  parsed = parse_regex!(parsed_msg.body, r'(?s)\{"Id":(?P<Id>[^,]+),"Version":(?P<Version>[^,]+),"Level":(?P<Level>[^,]+),"Task":(?P<Task>[^,]+),"Opcode":(?P<Opcode>[^,]+),"Keywords":(?P<Keywords>[^,]+),"RecordId":(?P<RecordId>[^,]+),"ProviderName":"(?P<ProviderName>[^"]*)","ProviderId":"(?P<ProviderId>[^"]*)","LogName":"(?P<LogName>[^"]*)","ProcessId":(?P<ProcessId>[^,]+),"ThreadId":(?P<ThreadId>[^,]+),"MachineName":"(?P<MachineName>[^"]*)","TimeCreated":"(?P<TimeCreated>[^"]*)","ActivityId":(?P<ActivityId>[^,]+),"RelatedActivityId":(?P<RelatedActivityId>[^,]+),"Qualifiers":(?P<Qualifiers>[^,]+),"LevelDisplayName":"(?P<LevelDisplayName>[^"]*)","OpcodeDisplayName":"(?P<OpcodeDisplayName>[^"]*)","TaskDisplayName":"(?P<TaskDisplayName>[^"]*)","Description":\{"RuleName":"(?P<RuleName>[^"]*)","UtcTime":"(?P<UtcTime>[^"]*)","ProcessGuid":"(?P<ProcessGuid>[^"]*)","ProcessId":"(?P<DescProcessId>[^"]*)","Image":"(?P<Image>[^"]*)","FileVersion":"(?P<FileVersion>[^"]*)","Description":"(?P<Description>[^"]*)","Product":"(?P<Product>[^"]*)","Company":"(?P<Company>[^"]*)","OriginalFileName":"(?P<OriginalFileName>[^"]*)","CommandLine":"(?P<CommandLine>[^"]*)","CurrentDirectory":"(?P<CurrentDirectory>[^"]*)","User":"(?P<User>[^"]*)","LogonGuid":"(?P<LogonGuid>[^"]*)","LogonId":"(?P<LogonId>[^"]*)","TerminalSessionId":"(?P<TerminalSessionId>[^"]*)","IntegrityLevel":"(?P<IntegrityLevel>[^"]*)","Hashes":"(?P<Hashes>[^"]*)","ParentProcessGuid":"(?P<ParentProcessGuid>[^"]*)","ParentProcessId":"(?P<ParentProcessId>[^"]*)","ParentImage":"(?P<ParentImage>[^"]*)","ParentCommandLine":"(?P<ParentCommandLine>[^"]*)","ParentUser":"(?P<ParentUser>[^"]*)"\},"DescriptionRawMessage":"(?P<DescriptionRawMessage>[^"]*)"\}$')
  .cmd_line = parsed.CommandLine
  .product_company = parsed.Company
  .process_id = parsed.ProcessId
  .Opcode = parsed.Opcode
  .ProcessId = parsed.ProcessId 
  .Task = parsed.Task
  .ThreadId = parsed.ThreadId
  .Version = parsed.Version
  .current_dir = parsed.CurrentDirectory
  .process_desc = parsed.Description
  .file_version = parsed.FileVersion
  .Hashes = parsed.Hashes
  .process_path = parsed.Image
  .integrity_level = parsed.IntegrityLevel
  .logon_guid = parsed.LogonGuid
  .logon_id = parsed.LogonId
  .origin_file_name = parsed.OriginalFileName
  .parent_cmd_line = parsed.ParentCommandLine
  .parent_process_path = parsed.ParentImage
  .parent_process_guid = parsed.ParentProcessGuid
  .parent_process_id = parsed.ParentProcessId
  .parent_process_user = parsed.ParentUser
  .process_guid = parsed.ProcessGuid
  .product_name = parsed.Product
  .rule_name = parsed.RuleName
  .terminal_session_id = parsed.TerminalSessionId
  .user_name = parsed.User
  .occur_time = parsed.UtcTime
  .DescriptionRawMessage = parsed.DescriptionRawMessage
  .id = parsed.Id
  .keywords = parsed.Keywords
  .severity = parsed.Level
  .LevelDisplayName = parsed.LevelDisplayName
  .LogName = parsed.LogName
  .MachineName = parsed.MachineName
  .OpcodeDisplayName = parsed.OpcodeDisplayName
  .ProviderId = parsed.ProviderId
  .ProviderName = parsed.ProviderName
  .TaskDisplayName = parsed.TaskDisplayName
  .TimeCreated = parsed.TimeCreated
  del(.message)

• 解析+转换配置（VRL）

source = '''
  parsed_msg = parse_regex!(.message, r'^[^{]*(?P<body>\{.*)$')
  parsed = parse_regex!(parsed_msg.body, r'(?s)\{"Id":(?P<Id>[^,]+),"Version":(?P<Version>[^,]+),"Level":(?P<Level>[^,]+),"Task":(?P<Task>[^,]+),"Opcode":(?P<Opcode>[^,]+),"Keywords":(?P<Keywords>[^,]+),"RecordId":(?P<RecordId>[^,]+),"ProviderName":"(?P<ProviderName>[^"]*)","ProviderId":"(?P<ProviderId>[^"]*)","LogName":"(?P<LogName>[^"]*)","ProcessId":(?P<ProcessId>[^,]+),"ThreadId":(?P<ThreadId>[^,]+),"MachineName":"(?P<MachineName>[^"]*)","TimeCreated":"(?P<TimeCreated>[^"]*)","ActivityId":(?P<ActivityId>[^,]+),"RelatedActivityId":(?P<RelatedActivityId>[^,]+),"Qualifiers":(?P<Qualifiers>[^,]+),"LevelDisplayName":"(?P<LevelDisplayName>[^"]*)","OpcodeDisplayName":"(?P<OpcodeDisplayName>[^"]*)","TaskDisplayName":"(?P<TaskDisplayName>[^"]*)","Description":\{"RuleName":"(?P<RuleName>[^"]*)","UtcTime":"(?P<UtcTime>[^"]*)","ProcessGuid":"(?P<ProcessGuid>[^"]*)","ProcessId":"(?P<DescProcessId>[^"]*)","Image":"(?P<Image>[^"]*)","FileVersion":"(?P<FileVersion>[^"]*)","Description":"(?P<Description>[^"]*)","Product":"(?P<Product>[^"]*)","Company":"(?P<Company>[^"]*)","OriginalFileName":"(?P<OriginalFileName>[^"]*)","CommandLine":"(?P<CommandLine>[^"]*)","CurrentDirectory":"(?P<CurrentDirectory>[^"]*)","User":"(?P<User>[^"]*)","LogonGuid":"(?P<LogonGuid>[^"]*)","LogonId":"(?P<LogonId>[^"]*)","TerminalSessionId":"(?P<TerminalSessionId>[^"]*)","IntegrityLevel":"(?P<IntegrityLevel>[^"]*)","Hashes":"(?P<Hashes>[^"]*)","ParentProcessGuid":"(?P<ParentProcessGuid>[^"]*)","ParentProcessId":"(?P<ParentProcessId>[^"]*)","ParentImage":"(?P<ParentImage>[^"]*)","ParentCommandLine":"(?P<ParentCommandLine>[^"]*)","ParentUser":"(?P<ParentUser>[^"]*)"\},"DescriptionRawMessage":"(?P<DescriptionRawMessage>[^"]*)"\}$')
  .cmd_line = parsed.CommandLine
  .product_company= parsed.Company
  .Opcode = parsed.Opcode
  .process_id = parsed.ProcessId 
  .ProcessId = parsed.ProcessId 
  .Task = parsed.Task
  .ThreadId = parsed.ThreadId
  .Version = parsed.Version
  .current_dir = parsed.CurrentDirectory
  .process_desc = parsed.Description
  .file_version = parsed.FileVersion
  .Hashes = parsed.Hashes
  .process_path = parsed.Image
  .integrity_level = parsed.IntegrityLevel
  .logon_guid = parsed.LogonGuid
  .origin_file_name = parsed.OriginalFileName
  .parent_cmd_line = parsed.ParentCommandLine
  .parent_process_path = parsed.ParentImage
  .parent_process_guid = parsed.ParentProcessGuid
  .parent_process_id = parsed.ParentProcessId
  .parent_process_user = parsed.ParentUser
  .process_guid = parsed.ProcessGuid
  .product_name = parsed.Product
  .rule_name = parsed.RuleName
  .terminal_session_id = parsed.TerminalSessionId
  .user_name = parsed.User
  .occur_time = parsed.UtcTime
  .DescriptionRawMessage = parsed.DescriptionRawMessage
  .keywords = parsed.Keywords
  .severity = parsed.Level
  .LevelDisplayName = parsed.LevelDisplayName
  .LogName = parsed.LogName
  .MachineName = parsed.MachineName
  .OpcodeDisplayName = parsed.OpcodeDisplayName
  .ProviderId = parsed.ProviderId
  .ProviderName = parsed.ProviderName
  .TaskDisplayName = parsed.TaskDisplayName
  .TimeCreated = parsed.TimeCreated
  del(.message)
  .LogonId = to_int!(parsed.LogonId)
  .Id = to_int!(parsed.Id)
if .host == "127.0.0.1" {
    .match_chars = "localhost"
} else if .host != "127.0.0.1" {
    .match_chars = "attack_ip"
}   
if .severity == "4" {
    .enrich_level = "severity"
} else if .Level == "3" {
    .enrich_level = "normal"
} 
.extends = {
    "OriginalFileName": .origin_file_name,
    "ParentCommandLine": .parent_cmd_line,
}
.extends_dir = {
    "ParentProcessPath": .parent_process_path,
    "Process_path": .process_path,
}
.num_range = if .Id >= 0 && .Id <= 1000 {
    .Id
} else {
    0
}
'''

4. APT Threat Log (3K)

WarpParse

• 解析配置（WPL）

package /apt/ {
   rule apt {
        (
            _\#,
            time:timestamp,
            _,
            chars:Hostname,
            _\%\%, 
            chars:ModuleName\/,
            chars:SeverityHeader\/,
            symbol(ANTI-APT)\(,
            chars:type\),
            chars:Count<[,]>,
            _\:,
            chars:Content\(,
        ),
        (
            kv(chars@SyslogId),
            kv(chars@VSys),
            kv(chars@Policy),
            kv(chars@SrcIp),
            kv(chars@DstIp),
            kv(chars@SrcPort),
            kv(chars@DstPort),
            kv(chars@SrcZone),
            kv(chars@DstZone),
            kv(chars@User),
            kv(chars@Protocol),
            kv(chars@Application),
            kv(chars@Profile),
            kv(chars@Direction),
            kv(chars@ThreatType),
            kv(chars@ThreatName),
            kv(chars@Action),
            kv(chars@FileType),
            kv(chars@Hash)\),
        )\,
    }
   }

• 解析+转换配置（WPL + OML）

package /apt/ {
   rule apt {
        (
            _\#,
            time:timestamp,
            _,
            chars:Hostname,
            _\%\%, 
            chars:ModuleName\/,
            chars:SeverityHeader\/,
            symbol(ANTI-APT)\(,
            chars:type\),
            chars:Count<[,]>,
            _\:,
            chars:Content\(,
        ),
        (
            kv(chars@SyslogId),
            kv(chars@VSys),
            kv(chars@Policy),
            kv(chars@SrcIp),
            kv(chars@DstIp),
            kv(chars@SrcPort),
            kv(chars@DstPort),
            kv(chars@SrcZone),
            kv(chars@DstZone),
            kv(chars@User),
            kv(chars@Protocol),
            kv(chars@Application),
            kv(chars@Profile),
            kv(chars@Direction),
            kv(chars@ThreatType),
            kv(chars@ThreatName),
            kv(chars@Action),
            kv(chars@FileType),
            kv(chars@Hash)\),
        )\,
    }
   }

name : apt
rule : /apt/*
---
count:digit = take(Count) ;
severity:digit = take(SeverityHeader) ;
match_chars = match read(option:[wp_src_ip]) {
    ip(127.0.0.1) => chars(localhost); 
    !ip(127.0.0.1) => chars(attack_ip); 
};
num_range = match read(option:[count]) {
    in ( digit(0), digit(1000) ) => read(count) ;
    _ => digit(0) ;
};
src_system_log_type = match read(option:[type]) {
    chars(l) => chars(日志信息);
    chars(s) => chars(安全日志信息);
};
extends_ip : obj = object {
    DstIp = read(DstIp);
    SrcIp = read(SrcIp);
};
extends_info : obj = object {
    hostname = read(Hostname);
    source_type = read(wp_src_key)
};
* : auto = read();

Vector

• 解析配置（VRL）

source = '''
  parsed_log = parse_regex!(.message, r'(?s)^#(?P<timestamp>\w+\s+\d+\s+\d{4}\s+\d{2}:\d{2}:\d{2}[+-]\d{2}:\d{2})\s+(?P<hostname>\S+)\s+%%(?P<ModuleName>\d+[^/]+)/(?P<SeverityHeader>\d+)/(?P<symbol>[^(]+)\((?P<type>[^)]+)\)\[(?P<count>\d+)\]:\s*(?P<content>[^()]+?)\s*\(SyslogId=(?P<SyslogId>[^,]+),\s+VSys="(?P<VSys>[^"]+)",\s+Policy="(?P<Policy>[^"]+),\s+SrcIp=(?P<SrcIp>[^,]+),\s+DstIp=(?P<DstIp>[^,]+),\s+SrcPort=(?P<SrcPort>[^,]+),\s+DstPort=(?P<DstPort>[^,]+),\s+SrcZone=(?P<SrcZone>[^,]+),\s+DstZone=(?P<DstZone>[^,]+),\s+User="(?P<User>[^"]+)",\s+Protocol=(?P<Protocol>[^,]+),\s+Application="(?P<Application>[^"]+)",\s+Profile="(?P<Profile>[^"]+)",\s+Direction=(?P<Direction>[^,]+),\s+ThreatType=(?P<ThreatType>[^,]+),\s+ThreatName=(?P<ThreatName>[^,]+),\s+Action=(?P<Action>[^,]+),\s+FileType=(?P<FileType>[^,]+),\s+Hash=(?P<Hash>.*)\)$')
  .Hostname = parsed_log.hostname
  .SrcPort = parsed_log.SrcPort
  .SeverityHeader = parsed_log.SeverityHeader
  .type = parsed_log.type
  .Count = parsed_log.count
  .Content = parsed_log.content
  .VSys = parsed_log.VSys
  .DstPort = parsed_log.DstPort
  .Policy = parsed_log.Policy
  .SrcIp = parsed_log.SrcIp
  .DstIp = parsed_log.DstIp
  .SrcZone = parsed_log.SrcZone
  .DstZone = parsed_log.DstZone
  .User = parsed_log.User
  .Protocol = parsed_log.Protocol
  .ModuleName = parsed_log.ModuleName
  .symbol = parsed_log.symbol
  .timestamp = parsed_log.timestamp
  .SyslogId = parsed_log.SyslogId
  .Application = parsed_log.Application
  .Profile = parsed_log.Profile
  .Direction = parsed_log.Direction
  .ThreatType = parsed_log.ThreatType
  .ThreatName = parsed_log.ThreatName
  .Action = parsed_log.Action
  .FileType = parsed_log.FileType
  .Hash = parsed_log.Hash
  del(.message)
'''

• 解析+转换配置（VRL）

source = '''
parsed_log = parse_regex!(.message, r'(?s)^#(?P<timestamp>\w+\s+\d+\s+\d{4}\s+\d{2}:\d{2}:\d{2}[+-]\d{2}:\d{2})\s+(?P<hostname>\S+)\s+%%(?P<ModuleName>\d+[^/]+)/(?P<SeverityHeader>\d+)/(?P<symbol>[^(]+)\((?P<type>[^)]+)\)\[(?P<count>\d+)\]:\s*(?P<content>[^()]+?)\s*\(SyslogId=(?P<SyslogId>[^,]+),\s+VSys="(?P<VSys>[^"]+)",\s+Policy="(?P<Policy>[^"]+)",\s+SrcIp=(?P<SrcIp>[^,]+),\s+DstIp=(?P<DstIp>[^,]+),\s+SrcPort=(?P<SrcPort>[^,]+),\s+DstPort=(?P<DstPort>[^,]+),\s+SrcZone=(?P<SrcZone>[^,]+),\s+DstZone=(?P<DstZone>[^,]+),\s+User="(?P<User>[^"]+)",\s+Protocol=(?P<Protocol>[^,]+),\s+Application="(?P<Application>[^"]+)",\s+Profile="(?P<Profile>[^"]+)",\s+Direction=(?P<Direction>[^,]+),\s+ThreatType=(?P<ThreatType>[^,]+),\s+ThreatName=(?P<ThreatName>[^,]+),\s+Action=(?P<Action>[^,]+),\s+FileType=(?P<FileType>[^,]+),\s+Hash=(?P<Hash>.*)\)$')
  .Hostname = parsed_log.hostname
  .SrcPort = parsed_log.SrcPort
  .SeverityHeader = parsed_log.SeverityHeader
  .type = parsed_log.type
  .Content = parsed_log.content
  .VSys = parsed_log.VSys
  .DstPort = parsed_log.DstPort
  .Policy = parsed_log.Policy
  .SrcIp = parsed_log.SrcIp
  .DstIp = parsed_log.DstIp
  .SrcZone = parsed_log.SrcZone
  .DstZone = parsed_log.DstZone
  .User = parsed_log.User
  .Protocol = parsed_log.Protocol
  .ModuleName = parsed_log.ModuleName
  .symbol = parsed_log.symbol
  .timestamp = parsed_log.timestamp
  .SyslogId = parsed_log.SyslogId
  .Application = parsed_log.Application
  .Profile = parsed_log.Profile
  .Direction = parsed_log.Direction
  .ThreatType = parsed_log.ThreatType
  .ThreatName = parsed_log.ThreatName
  .Action = parsed_log.Action
  .FileType = parsed_log.FileType
  .Hash = parsed_log.Hash
  del(.message)
.severity = to_int!(parsed_log.SeverityHeader)
.count = to_int!(parsed_log.count)
if .host == "127.0.0.1" {
    .match_chars = "localhost"
} else if .host != "127.0.0.1" {
    .match_chars = "attack_ip"
}  
if .type == "l" {
.src_system_log_type = "日志信息"
} else if .type == "s" {
.src_system_log_type = "安全日志信息"
}
.extends_ip = {
    "DstIp": .DstIp,
    "SrcIp": .SrcIp,
}
.extends_info = {
    "hostname": .Hostname,
    "source_type": .source_type,
}
.num_range = if .count >= 0 && .count <= 1000 {
    .count
} else {
    0
}
'''

Test Data Samples

本文档展示了四类日志在经过解析与转换后的输出数据样本 (Output Samples)。

1. Nginx Access Log Samples

样本数据

180.57.30.148 - - [21/Jan/2025:01:40:02 +0800] "GET /nginx-logo.png HTTP/1.1" 500 368 "http://207.131.38.110/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36" "-"

解析结果 (Parsed):

• WarpParse:

{
	"wp_event_id": 1764645169882925000,
	"sip": "180.57.30.148",
	"timestamp": "21/Jan/2025:01:40:02 +0800",
	"http_request": "GET /nginx-logo.png HTTP/1.1",
	"status": "500",
	"size": "368",
	"referer": "http://207.131.38.110/",
	"http_agent": "Mozilla/5.0(Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 ",
	"wp_src_key": "socket",
	"wp_src_ip": "127.0.0.1"
}

• Vector:

{
	"host": "127.0.0.1",
	"http_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36",
	"http_request": "GET /nginx-logo.png HTTP/1.1",
	"port": 58102,
	"referer": "http://207.131.38.110/",
	"sip": "180.57.30.148",
	"size": "368",
	"source_type": "socket",
	"status": "500",
	"timestamp": "21/Jan/2025:01:40:02 +0800"
}

解析+转换结果 (Transformed):

• WarpParse:

{
	"host": "127.0.0.1",
	"http_agent": "Mozilla/5.0(Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36 ",
	"http_request": "GET /nginx-logo.png HTTP/1.1",
	"match_chars": "localhost",
	"referer": "http://207.131.38.110/",
	"sip": "180.57.30.148",
	"size": 368,
	"source_type": "socket",
	"status": 500,
	"str_status": "Internal Server Error",
	"timestamp": "21/Jan/2025:01:40:02 +0800"
}

• Vector:

{
	"host": "127.0.0.1",
	"http_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36",
	"http_request": "GET /nginx-logo.png HTTP/1.1",
	"match_chars": "localhost",
	"port": 53894,
	"referer": "http://207.131.38.110/",
	"sip": "180.57.30.148",
	"size": 368,
	"source_type": "socket",
	"status": 500,
	"str_status": "Internal Server Error",
	"timestamp": "21/Jan/2025:01:40:02 +0800"
}

2. AWS ELB Log Samples

样本数据

http 2018-11-30T22:23:00.186641Z app/my-lb 192.168.1.10:2000 10.0.0.15:8080 0.01 0.02 0.01 200 200 100 200 "POST https://api.example.com/u?p=1&sid=2&t=3 HTTP/1.1" "Mozilla/5.0 (Win) Chrome/90" "ECDHE" "TLSv1.3" arn:aws:elb:us:123:tg "Root=1-test" "api.example.com" "arn:aws:acm:us:123:cert/short" 1 2018-11-30T22:22:48.364000Z "forward" "https://auth.example.com/r" "err" "10.0.0.1:80" "200" "cls" "rsn" TID_x1

解析结果 (Parsed):

• WarpParse:

{
	"wp_event_id": 1764646097464011000,
	"symbol": "http",
	"timestamp": "2018-11-30T22:23:00.186641Z",
	"elb": "app/my-lb",
	"client_host": "192.168.1.10:2000",
	"target_host": "10.0.0.15:8080",
	"request_processing_time": "0.01",
	"target_processing_time": "0.02",
	"response_processing_time": "0.01",
	"elb_status_code": "200",
	"target_status_code": "200",
	"received_bytes": "100",
	"sent_bytes": "200",
	"request_method": "POST",
	"request_url": "https://api.example.com/u?p=1&sid=2&t=3",
	"request_protocol": "HTTP/1.1",
	"user_agent": "Mozilla/5.0 (Win) Chrome/90",
	"ssl_cipher": "ECDHE",
	"ssl_protocol": "TLSv1.3",
	"target_group_arn": "arn:aws:elb:us:123:tg",
	"trace_id": "Root=1-test",
	"domain_name": "api.example.com",
	"chosen_cert_arn": "arn:aws:acm:us:123:cert/short",
	"matched_rule_priority": "1",
	"request_creation_time": "2018-11-30T22:22:48.364000Z",
	"actions_executed": "forward",
	"redirect_url": "https://auth.example.com/r",
	"error_reason": "err",
	"target_port_list": "10.0.0.1:80",
	"target_status_code_list": "200",
	"classification": "cls",
	"classification_reason": "rsn",
	"traceability_id": "TID_x1",
	"wp_src_key": "socket",
	"wp_src_ip": "127.0.0.1"
}

• Vector:

{
	"actions_executed": "forward",
	"chosen_cert_arn": "arn:aws:acm:us:123:cert/short",
	"classification": "cls",
	"classification_reason": "rsn",
	"client_host": "192.168.1.10:2000",
	"domain_name": "api.example.com",
	"elb": "app/my-lb",
	"elb_status_code": "200",
	"error_reason": "err",
	"host": "127.0.0.1",
	"matched_rule_priority": "1",
	"port": 58786,
	"received_bytes": "100",
	"redirect_url": "https://auth.example.com/r",
	"request_creation_time": "2018-11-30T22:22:48.364000Z",
	"request_method": "POST",
	"request_processing_time": "0.01",
	"request_protocol": "HTTP/1.1",
	"request_url": "https://api.example.com/u?p=1&sid=2&t=3",
	"response_processing_time": "0.01",
	"sent_bytes": "200",
	"source_type": "socket",
	"ssl_cipher": "ECDHE",
	"ssl_protocol": "TLSv1.3",
	"symbol": "http",
	"target_group_arn": "arn:aws:elb:us:123:tg",
	"target_host": "10.0.0.15:8080",
	"target_port_list": "10.0.0.1:80",
	"target_processing_time": "0.02",
	"target_status_code": "200",
	"target_status_code_list": "200",
	"timestamp": "2018-11-30T22:23:00.186641Z",
	"trace_id": "Root=1-test",
	"traceability_id": "TID_x1",
	"user_agent": "Mozilla/5.0 (Win) Chrome/90"
}

解析+转换结果 (Transformed):

• WarpParse:

{
	"timestamp": "2018-11-30T22:23:00.186641Z",
	"actions_executed": "forward",
	"chosen_cert_arn": "arn:aws:acm:us:123:cert/short",
	"classification": "cls",
	"classification_reason": "rsn",
	"client_host": "192.168.1.10:2000",
	"domain_name": "api.example.com",
	"elb": "app/my-lb",
	"elb_status_code": 200,
	"error_reason": "err",
	"extends": {
		"ssl_cipher": "ECDHE",
		"ssl_protocol": "TLSv1.3"
	},
	"host": "127.0.0.1",
	"match_chars": "localhost",
	"matched_rule_priority": "1",
	"received_bytes": "100",
	"redirect_url": "https://auth.example.com/r",
	"request_creation_time": "2018-11-30T22:22:48.364000Z",
	"request_method": "POST",
	"request_processing_time": "0.01",
	"request_protocol": "HTTP/1.1",
	"request_url": "https://api.example.com/u?p=1&sid=2&t=3",
	"response_processing_time": "0.01",
	"sent_bytes": 200,
	"source_type": "socket",
	"ssl_cipher": "ECDHE",
	"ssl_protocol": "TLSv1.3",
	"str_elb_status": "ok",
	"target_group_arn": "arn:aws:elb:us:123:tg",
	"target_host": "10.0.0.15:8080",
	"target_port_list": "10.0.0.1:80",
	"target_processing_time": "0.02",
	"target_status_code": 200,
	"target_status_code_list": "200",
	"trace_id": "Root=1-test",
	"traceability_id": "TID_x1",
	"user_agent": "Mozilla/5.0 (Win) Chrome/90"
}

• Vector:

{
	"actions_executed": "forward",
	"chosen_cert_arn": "arn:aws:acm:us:123:cert/short",
	"classification": "cls",
	"classification_reason": "rsn",
	"client_host": "192.168.1.10:2000",
	"domain_name": "api.example.com",
	"elb": "app/my-lb",
	"elb_status_code": 200,
	"error_reason": "err",
	"extends": {
		"ssl_cipher": "ECDHE",
		"ssl_protocol": "TLSv1.3"
	},
	"host": "127.0.0.1",
	"match_chars": "localhost",
	"matched_rule_priority": "1",
	"port": 53995,
	"received_bytes": "100",
	"redirect_url": "https://auth.example.com/r",
	"request_creation_time": "2018-11-30T22:22:48.364000Z",
	"request_method": "POST",
	"request_processing_time": "0.01",
	"request_protocol": "HTTP/1.1",
	"request_url": "https://api.example.com/u?p=1&sid=2&t=3",
	"response_processing_time": "0.01",
	"sent_bytes": 200,
	"source_type": "socket",
	"ssl_cipher": "ECDHE",
	"ssl_protocol": "TLSv1.3",
	"str_elb_status": "ok",
	"symbol": "http",
	"target_group_arn": "arn:aws:elb:us:123:tg",
	"target_host": "10.0.0.15:8080",
	"target_port_list": "10.0.0.1:80",
	"target_processing_time": "0.02",
	"target_status_code": 200,
	"target_status_code_list": "200",
	"timestamp": "2018-11-30T22:23:00.186641Z",
	"trace_id": "Root=1-test",
	"traceability_id": "TID_x1",
	"user_agent": "Mozilla/5.0 (Win) Chrome/90"
}

3. Sysmon Log Samples

样本数据

<14>Apr 09 18:37:27 10.77.32.19 Microsoft-Windows-Sysmon:{"Id":1,"Version":1,"Level":4,"Task":1,"Opcode":0,"Keywords":0,"RecordId":null,"ProviderName":"P","ProviderId":"PID","LogName":"L","ProcessId":1,"ThreadId":1,"MachineName":"A","TimeCreated":"2025-04-10T14:17:28.693228+08:00","ActivityId":null,"RelatedActivityId":null,"Qualifiers":null,"LevelDisplayName":"信息","OpcodeDisplayName":"信息","TaskDisplayName":"Process Create","Description":{"RuleName":"R","UtcTime":"2025-04-10 06:17:28.503","ProcessGuid":"{G}","ProcessId":"1","Image":"C:\\Windows\\a.exe","FileVersion":"1","Description":"D","Product":"P","Company":"C","OriginalFileName":"a.exe","CommandLine":"a.exe","CurrentDirectory":"C:\\","User":"U","LogonGuid":"{LG}","LogonId":"1","TerminalSessionId":"1","IntegrityLevel":"M","Hashes":"H","ParentProcessGuid":"{PG}","ParentProcessId":"1","ParentImage":"C:\\Windows\\b.exe","ParentCommandLine":"b.exe","ParentUser":"U"},"DescriptionRawMessage":"Process Create\r\nRuleName: R"}

解析结果 (Parsed):

• WarpParse:

{
	"wp_event_id": 1764657738662604000,
	"cmd_line": "a.exe",
	"product_company": "C",
	"current_dir": "C:\\\\",
	"process_desc": "D",
	"file_version": "1",
	"Hashes": "H",
	"process_path": "C:\\\\Windows\\\\a.exe",
	"integrity_level": "M",
	"logon_guid": "{LG}",
	"logon_id": "1",
	"origin_file_name": "a.exe",
	"parent_cmd_line": "b.exe",
	"parent_process_path": "C:\\\\Windows\\\\b.exe",
	"parent_process_guid": "{PG}",
	"parent_process_id": "1",
	"parent_process_user": "U",
	"process_guid": "{G}",
	"process_id": "1",
	"product_name": "P",
	"rule_name": "R",
	"terminal_session_id": "1",
	"user_name": "U",
	"occur_time": "2025-04-10 06:17:28.503",
	"DescriptionRawMessage": "Process Create\\r\\nRuleName: R",
	"id": "1",
	"keywords": "0",
	"severity": "4",
	"LevelDisplayName": "信息",
	"LogName": "L",
	"MachineName": "A",
	"Opcode": "0",
	"OpcodeDisplayName": "信息",
	"ProcessId": "1",
	"ProviderId": "PID",
	"ProviderName": "P",
	"Task": "1",
	"TaskDisplayName": "Process Create",
	"ThreadId": "1",
	"TimeCreated": "2025-04-10T14:17:28.693228+08:00",
	"Version": "1",
	"wp_src_key": "socket",
	"wp_src_ip": "127.0.0.1"
}

• Vector:

{
	"DescriptionRawMessage": "Process Create\\r\\nRuleName: R",
	"Hashes": "H",
	"LevelDisplayName": "信息",
	"LogName": "L",
	"MachineName": "A",
	"Opcode": "0",
	"OpcodeDisplayName": "信息",
	"ProcessId": "1",
	"ProviderId": "PID",
	"ProviderName": "P",
	"Task": "1",
	"TaskDisplayName": "Process Create",
	"ThreadId": "1",
	"TimeCreated": "2025-04-10T14:17:28.693228+08:00",
	"Version": "1",
	"cmd_line": "a.exe",
	"current_dir": "C:\\\\",
	"file_version": "1",
	"host": "127.0.0.1",
	"id": "1",
	"integrity_level": "M",
	"keywords": "0",
	"logon_guid": "{LG}",
	"logon_id": "1",
	"occur_time": "2025-04-10 06:17:28.503",
	"origin_file_name": "a.exe",
	"parent_cmd_line": "b.exe",
	"parent_process_guid": "{PG}",
	"parent_process_id": "1",
	"parent_process_path": "C:\\\\Windows\\\\b.exe",
	"parent_process_user": "U",
	"port": 50558,
	"process_desc": "D",
	"process_guid": "{G}",
	"process_id": "1",
	"process_path": "C:\\\\Windows\\\\a.exe",
	"product_company": "C",
	"product_name": "P",
	"rule_name": "R",
	"severity": "4",
	"source_type": "socket",
	"terminal_session_id": "1",
	"timestamp": "2025-12-02T06:33:53.716258Z",
	"user_name": "U"
}

解析+转换结果 (Transformed):

• WarpParse:

{
	"Id": 1,
	"LogonId": 1,
	"enrich_level": "severity",
	"extends": {
		"OriginalFileName": "a.exe",
		"ParentCommandLine": "b.exe"
	},
	"extends_dir": {
		"ParentProcessPath": "C:\\\\Windows\\\\b.exe",
		"Process_path": "C:\\\\Windows\\\\a.exe"
	},
	"match_chars": "localhost",
	"num_range": 1,
	"wp_event_id": 1764813339134818000,
	"cmd_line": "a.exe",
	"product_company": "C",
	"current_dir": "C:\\\\",
	"process_desc": "D",
	"file_version": "1",
	"Hashes": "H",
	"process_path": "C:\\\\Windows\\\\a.exe",
	"integrity_level": "M",
	"logon_guid": "{LG}",
	"origin_file_name": "a.exe",
	"parent_cmd_line": "b.exe",
	"parent_process_path": "C:\\\\Windows\\\\b.exe",
	"parent_process_guid": "{PG}",
	"parent_process_id": "1",
	"parent_process_user": "U",
	"process_guid": "{G}",
	"process_id": "1",
	"product_name": "P",
	"rule_name": "R",
	"terminal_session_id": "1",
	"user_name": "U",
	"occur_time": "2025-04-10 06:17:28.503",
	"DescriptionRawMessage": "Process Create\\\\r\\\\nRuleName: R",
	"keywords": "0",
	"severity": "4",
	"LevelDisplayName": "信息",
	"LogName": "L",
	"MachineName": "A",
	"Opcode": "0",
	"OpcodeDisplayName": "信息",
	"ProcessId": "1",
	"ProviderId": "PID",
	"ProviderName": "P",
	"Task": "1",
	"TaskDisplayName": "Process Create",
	"ThreadId": "1",
	"TimeCreated": "2025-04-10T14:17:28.693228+08:00",
	"Version": "1",
	"wp_src_key": "socket",
	"wp_src_ip": "127.0.0.1"
}

• Vector:

{
	"DescriptionRawMessage": "Process Create\\\\r\\\\nRuleName: R",
	"Hashes": "H",
	"Id": 1,
	"LevelDisplayName": "信息",
	"LogName": "L",
	"LogonId": 1,
	"MachineName": "A",
	"Opcode": "0",
	"OpcodeDisplayName": "信息",
	"ProcessId": "1",
	"ProviderId": "PID",
	"ProviderName": "P",
	"Task": "1",
	"TaskDisplayName": "Process Create",
	"ThreadId": "1",
	"TimeCreated": "2025-04-10T14:17:28.693228+08:00",
	"Version": "1",
	"cmd_line": "a.exe",
	"current_dir": "C:\\\\",
	"enrich_level": "severity",
	"extends": {
		"OriginalFileName": "a.exe",
		"ParentCommandLine": "b.exe"
	},
	"extends_dir": {
		"ParentProcessPath": "C:\\\\Windows\\\\b.exe",
		"Process_path": "C:\\\\Windows\\\\a.exe"
	},
	"file_version": "1",
	"host": "127.0.0.1",
	"integrity_level": "M",
	"keywords": "0",
	"logon_guid": "{LG}",
	"match_chars": "localhost",
	"num_range": 1,
	"occur_time": "2025-04-10 06:17:28.503",
	"origin_file_name": "a.exe",
	"parent_cmd_line": "b.exe",
	"parent_process_guid": "{PG}",
	"parent_process_id": "1",
	"parent_process_path": "C:\\\\Windows\\\\b.exe",
	"parent_process_user": "U",
	"port": 49838,
	"process_desc": "D",
	"process_guid": "{G}",
	"process_id": "1",
	"process_path": "C:\\\\Windows\\\\a.exe",
	"product_company": "C",
	"product_name": "P",
	"rule_name": "R",
	"severity": "4",
	"source_type": "socket",
	"terminal_session_id": "1",
	"timestamp": "2025-12-04T02:04:24.686378Z",
	"user_name": "U"
}

4. APT Threat Log Samples

样本数据

#Feb  7 2025 15:07:18+08:00 USG1000E %%01ANTI-APT/4/ANTI-APT(l)[29]: An advanced persistent threat was detected. (SyslogId=1, VSys="public-long-virtual-system-name-for-testing-extra-large-value-to-simulate-enterprise-scenario", Policy="trust-untrust-high-risk-policy-with-deep-inspection-and-layer7-protection-enabled-for-advanced-threat-detection", SrcIp=192.168.1.123, DstIp=182.150.63.102, SrcPort=51784, DstPort=10781, SrcZone=trust-zone-with-multiple-segments-for-internal-security-domains-and-access-control, DstZone=untrust-wide-area-network-zone-with-external-facing-interfaces-and-honeynet-integration, User="unknown-long-user-field-used-for-simulation-purpose-with-extra-description-and-tags-[tag1][tag2][tag3]-to-reach-required-size", Protocol=TCP, Application="HTTP-long-application-signature-identification-with-multiple-behavior-patterns-and-deep-packet-inspection-enabled", Profile="IPS_default_advanced_extended_profile_with_ml_detection-long", Direction=aaa-long-direction-field-used-to-extend-size-with-additional-info-about-traffic-orientation-from-client-to-server, ThreatType=File Reputation with additional descriptive context of multi-layer analysis engine including sandbox-behavioral-signature-ml-static-analysis-and-network-correlation-modules-working-together, ThreatName=bbb-advanced-threat-campaign-with-code-name-operation-shadow-storm-and-related-IOCs-collected-over-multiple-incidents-in-the-wild-attached-metadata-[phase1][phase2][phase3], Action=ccc-block-and-alert-with-deep-scan-followed-by-quarantine-and-forensic-dump-generation-for-further-investigation, FileType=ddd-executable-binary-with-multiple-packed-layers-suspicious-import-table-behavior-and-evasion-techniques, Hash=eee1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef-long-hash-value-used-for-testing-purpose-extended-with-multiple-hash-representations-[MD5:aaa111bbb222ccc333]-[SHA1:bbb222ccc333ddd444]-[SHA256:ccc333ddd444eee555]-[SSDEEP:ddd444eee555fff666]-end-of-hash-section, Extr... [truncated]

解析结果 (Parsed):

• WarpParse:

{
	"wp_event_id": 1764661811871722000,
	"timestamp": "2025-02-07 15:07:18",
	"Hostname": "USG1000E",
	"ModuleName": "01ANTI-APT",
	"SeverityHeader": "4",
	"symbol": "ANTI-APT",
	"type": "l",
	"Count": "29",
	"Content": "An advanced persistent threat was detected.",
	"SyslogId": "1",
	"VSys": "public-long-virtual-system-name-for-testing-extra-large-value-to-simulate-enterprise-scenario",
	"Policy": "trust-untrust-high-risk-policy-with-deep-inspection-and-layer7-protection-enabled-for-advanced-threat-detection",
	"SrcIp": "192.168.1.123",
	"DstIp": "182.150.63.102",
	"SrcPort": "51784",
	"DstPort": "10781",
	"SrcZone": "trust-zone-with-multiple-segments-for-internal-security-domains-and-access-control",
	"DstZone": "untrust-wide-area-network-zone-with-external-facing-interfaces-and-honeynet-integration",
	"User": "unknown-long-user-field-used-for-simulation-purpose-with-extra-description-and-tags-[tag1][tag2][tag3]-to-reach-required-size",
	"Protocol": "TCP",
	"Application": "HTTP-long-application-signature-identification-with-multiple-behavior-patterns-and-deep-packet-inspection-enabled",
	"Profile": "IPS_default_advanced_extended_profile_with_ml_detection-long",
	"Direction": "aaa-long-direction-field-used-to-extend-size-with-additional-info-about-traffic-orientation-from-client-to-server",
	"ThreatType": "File Reputation with additional descriptive context of multi-layer analysis engine including sandbox-behavioral-signature-ml-static-analysis-and-network-correlation-modules-working-together",
	"ThreatName": "bbb-advanced-threat-campaign-with-code-name-operation-shadow-storm-and-related-IOCs-collected-over-multiple-incidents-in-the-wild-attached-metadata-[phase1][phase2][phase3]",
	"Action": "ccc-block-and-alert-with-deep-scan-followed-by-quarantine-and-forensic-dump-generation-for-further-investigation",
	"FileType": "ddd-executable-binary-with-multiple-packed-layers-suspicious-import-table-behavior-and-evasion-techniques",
	"Hash": "eee1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef-long-hash-value-used-for-testing-purpose-extended-with-multiple-hash-representations-[MD5:aaa111bbb222ccc333]-[SHA1:bbb222ccc333ddd444]-[SHA256:ccc333ddd444eee555]-[SSDEEP:ddd444eee555fff666]-end-of-hash-section, ExtraInfo=\"This is additional extended information purposely added to inflate the total log size for stress testing of log ingestion engines such as Vector, Fluent Bit, self-developed ETL pipelines, and any high-throughput log processing systems. It contains repeated segments to simulate realistic verbose threat intelligence attachment blocks. [SEG-A-BEGIN] The threat was part of a coordinated multi-vector campaign observed across various geographic regions targeting enterprise networks with spear-phishing, watering-hole attacks, and supply-chain compromise vectors. Enriched indicators include C2 domains, malware families, behavioral clusters, sandbox detonation traces, and network telemetry correlation. [SEG-A-END] [SEG-B-BEGIN] Further analysis revealed that the payload exhibited persistence techniques including registry autoruns, scheduled tasks, masquerading, process injection, and lateral movement attempts leveraging remote service creation and stolen credentials. The binary contains multiple obfuscation layers, anti-debugging, anti-VM checks, and unusual API call sequences. [SEG-B-END] [SEG-C-BEGIN] IOC Bundle: Domains=malicious-domain-example-01.com,malicious-domain-example-02.net,malicious-update-service.info; IPs=103.21.244.0,198.51.100.55,203.0.113.77; FileNames=update_service.exe,winlog_service.dll,mscore_update.bin; RegistryKeys=HKCU\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run,HKLM\\\\System\\\\Services\\\\FakeService; Mutex=Global\\\\A1B2C3D4E5F6G7H8; YARA Matches=[rule1,rule2,rule3]. [SEG-C-END] EndOfExtraInfo\",
	"wp_src_key": "socket",
	"wp_src_ip": "127.0.0.1"
}

• Vector:

{
	"Action": "ccc-block-and-alert-with-deep-scan-followed-by-quarantine-and-forensic-dump-generation-for-further-investigation",
	"Application": "HTTP-long-application-signature-identification-with-multiple-behavior-patterns-and-deep-packet-inspection-enabled",
	"Content": "An advanced persistent threat was detected.",
	"Count": "29",
	"Direction": "aaa-long-direction-field-used-to-extend-size-with-additional-info-about-traffic-orientation-from-client-to-server",
	"DstIp": "182.150.63.102",
	"DstPort": "10781",
	"DstZone": "untrust-wide-area-network-zone-with-external-facing-interfaces-and-honeynet-integration",
	"FileType": "ddd-executable-binary-with-multiple-packed-layers-suspicious-import-table-behavior-and-evasion-techniques",
	"Hash": "eee1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef-long-hash-value-used-for-testing-purpose-extended-with-multiple-hash-representations-[MD5:aaa111bbb222ccc333]-[SHA1:bbb222ccc333ddd444]-[SHA256:ccc333ddd444eee555]-[SSDEEP:ddd444eee555fff666]-end-of-hash-section, ExtraInfo=\"This is additional extended information purposely added to inflate the total log size for stress testing of log ingestion engines such as Vector, Fluent Bit, self-developed ETL pipelines, and any high-throughput log processing systems. It contains repeated segments to simulate realistic verbose threat intelligence attachment blocks. [SEG-A-BEGIN] The threat was part of a coordinated multi-vector campaign observed across various geographic regions targeting enterprise networks with spear-phishing, watering-hole attacks, and supply-chain compromise vectors. Enriched indicators include C2 domains, malware families, behavioral clusters, sandbox detonation traces, and network telemetry correlation. [SEG-A-END] [SEG-B-BEGIN] Further analysis revealed that the payload exhibited persistence techniques including registry autoruns, scheduled tasks, masquerading, process injection, and lateral movement attempts leveraging remote service creation and stolen credentials. The binary contains multiple obfuscation layers, anti-debugging, anti-VM checks, and unusual API call sequences. [SEG-B-END] [SEG-C-BEGIN] IOC Bundle: Domains=malicious-domain-example-01.com,malicious-domain-example-02.net,malicious-update-service.info; IPs=103.21.244.0,198.51.100.55,203.0.113.77; FileNames=update_service.exe,winlog_service.dll,mscore_update.bin; RegistryKeys=HKCU\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run,HKLM\\\\System\\\\Services\\\\FakeService; Mutex=Global\\\\A1B2C3D4E5F6G7H8; YARA Matches=[rule1,rule2,rule3]. [SEG-C-END] EndOfExtraInfo\",
	"Hostname": "USG1000E",
	"ModuleName": "01ANTI-APT",
	"Policy": "trust-untrust-high-risk-policy-with-deep-inspection-and-layer7-protection-enabled-for-advanced-threat-detection",
	"Profile": "IPS_default_advanced_extended_profile_with_ml_detection-long",
	"Protocol": "TCP",
	"SeverityHeader": "4",
	"SrcIp": "192.168.1.123",
	"SrcPort": "51784",
	"SrcZone": "trust-zone-with-multiple-segments-for-internal-security-domains-and-access-control",
	"SyslogId": "1",
	"ThreatName": "bbb-advanced-threat-campaign-with-code-name-operation-shadow-storm-and-related-IOCs-collected-over-multiple-incidents-in-the-wild-attached-metadata-[phase1][phase2][phase3]",
	"ThreatType": "File Reputation with additional descriptive context of multi-layer analysis engine including sandbox-behavioral-signature-ml-static-analysis-and-network-correlation-modules-working-together",
	"User": "unknown-long-user-field-used-for-simulation-purpose-with-extra-description-and-tags-[tag1][tag2][tag3]-to-reach-required-size",
	"VSys": "public-long-virtual-system-name-for-testing-extra-large-value-to-simulate-enterprise-scenario",
	"host": "127.0.0.1",
	"port": 55771,
	"source_type": "socket",
	"symbol": "ANTI-APT",
	"timestamp": "Feb  7 2025 15:07:18+08:00",
	"type": "l"
}

解析+转换结果 (Transformed):

• WarpParse:

{
	"count": 29,
	"severity": 4,
	"match_chars": "localhost",
	"num_range": 29,
	"src_system_log_type": "日志信息",
	"extends_ip": {
		"DstIp": "182.150.63.102",
		"SrcIp": "192.168.1.123"
	},
	"extends_info": {
		"hostname": "USG1000E",
		"source_type": "socket"
	},
	"wp_event_id": 1764815397395451000,
	"timestamp": "2025-02-07 15:07:18",
	"Hostname": "USG1000E",
	"ModuleName": "01ANTI-APT",
	"symbol": "ANTI-APT",
	"type": "l",
	"Content": "An advanced persistent threat was detected.",
	"SyslogId": "1",
	"VSys": "public-long-virtual-system-name-for-testing-extra-large-value-to-simulate-enterprise-scenario",
	"Policy": "trust-untrust-high-risk-policy-with-deep-inspection-and-layer7-protection-enabled-for-advanced-threat-detection",
	"SrcIp": "192.168.1.123",
	"DstIp": "182.150.63.102",
	"SrcPort": "51784",
	"DstPort": "10781",
	"SrcZone": "trust-zone-with-multiple-segments-for-internal-security-domains-and-access-control",
	"DstZone": "untrust-wide-area-network-zone-with-external-facing-interfaces-and-honeynet-integration",
	"User": "unknown-long-user-field-used-for-simulation-purpose-with-extra-description-and-tags-[tag1][tag2][tag3]-to-reach-required-size",
	"Protocol": "TCP",
	"Application": "HTTP-long-application-signature-identification-with-multiple-behavior-patterns-and-deep-packet-inspection-enabled",
	"Profile": "IPS_default_advanced_extended_profile_with_ml_detection-long",
	"Direction": "aaa-long-direction-field-used-to-extend-size-with-additional-info-about-traffic-orientation-from-client-to-server",
	"ThreatType": "File Reputation with additional descriptive context of multi-layer analysis engine including sandbox-behavioral-signature-ml-static-analysis-and-network-correlation-modules-working-together",
	"ThreatName": "bbb-advanced-threat-campaign-with-code-name-operation-shadow-storm-and-related-IOCs-collected-over-multiple-incidents-in-the-wild-attached-metadata-[phase1][phase2][phase3]",
	"Action": "ccc-block-and-alert-with-deep-scan-followed-by-quarantine-and-forensic-dump-generation-for-further-investigation",
	"FileType": "ddd-executable-binary-with-multiple-packed-layers-suspicious-import-table-behavior-and-evasion-techniques",
	"Hash": "eee1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef-long-hash-value-used-for-testing-purpose-extended-with-multiple-hash-representations-[MD5:aaa111bbb222ccc333]-[SHA1:bbb222ccc333ddd444]-[SHA256:ccc333ddd444eee555]-[SSDEEP:ddd444eee555fff666]-end-of-hash-section, ExtraInfo=\"This is additional extended information purposely added to inflate the total log size for stress testing of log ingestion engines such as Vector, Fluent Bit, self-developed ETL pipelines, and any high-throughput log processing systems. It contains repeated segments to simulate realistic verbose threat intelligence attachment blocks. [SEG-A-BEGIN] The threat was part of a coordinated multi-vector campaign observed across various geographic regions targeting enterprise networks with spear-phishing, watering-hole attacks, and supply-chain compromise vectors. Enriched indicators include C2 domains, malware families, behavioral clusters, sandbox detonation traces, and network telemetry correlation. [SEG-A-END] [SEG-B-BEGIN] Further analysis revealed that the payload exhibited persistence techniques including registry autoruns, scheduled tasks, masquerading, process injection, and lateral movement attempts leveraging remote service creation and stolen credentials. The binary contains multiple obfuscation layers, anti-debugging, anti-VM checks, and unusual API call sequences. [SEG-B-END] [SEG-C-BEGIN] IOC Bundle: Domains=malicious-domain-example-01.com,malicious-domain-example-02.net,malicious-update-service.info; IPs=103.21.244.0,198.51.100.55,203.0.113.77; FileNames=update_service.exe,winlog_service.dll,mscore_update.bin; RegistryKeys=HKCU\\\\\\\\Software\\\\\\\\Microsoft\\\\\\\\Windows\\\\\\\\CurrentVersion\\\\\\\\Run,HKLM\\\\\\\\System\\\\\\\\Services\\\\\\\\FakeService; Mutex=Global\\\\\\\\A1B2C3D4E5F6G7H8; YARA Matches=[rule1,rule2,rule3]. [SEG-C-END] EndOfExtraInfo\",
	"wp_src_key": "socket",
	"wp_src_ip": "127.0.0.1"
}

• Vector:

{
	"Action": "ccc-block-and-alert-with-deep-scan-followed-by-quarantine-and-forensic-dump-generation-for-further-investigation",
	"Application": "HTTP-long-application-signature-identification-with-multiple-behavior-patterns-and-deep-packet-inspection-enabled",
	"Content": "An advanced persistent threat was detected.",
	"Direction": "aaa-long-direction-field-used-to-extend-size-with-additional-info-about-traffic-orientation-from-client-to-server",
	"DstIp": "182.150.63.102",
	"DstPort": "10781",
	"DstZone": "untrust-wide-area-network-zone-with-external-facing-interfaces-and-honeynet-integration",
	"FileType": "ddd-executable-binary-with-multiple-packed-layers-suspicious-import-table-behavior-and-evasion-techniques",
	"Hash": "eee1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef-long-hash-value-used-for-testing-purpose-extended-with-multiple-hash-representations-[MD5:aaa111bbb222ccc333]-[SHA1:bbb222ccc333ddd444]-[SHA256:ccc333ddd444eee555]-[SSDEEP:ddd444eee555fff666]-end-of-hash-section, ExtraInfo=\"This is additional extended information purposely added to inflate the total log size for stress testing of log ingestion engines such as Vector, Fluent Bit, self-developed ETL pipelines, and any high-throughput log processing systems. It contains repeated segments to simulate realistic verbose threat intelligence attachment blocks. [SEG-A-BEGIN] The threat was part of a coordinated multi-vector campaign observed across various geographic regions targeting enterprise networks with spear-phishing, watering-hole attacks, and supply-chain compromise vectors. Enriched indicators include C2 domains, malware families, behavioral clusters, sandbox detonation traces, and network telemetry correlation. [SEG-A-END] [SEG-B-BEGIN] Further analysis revealed that the payload exhibited persistence techniques including registry autoruns, scheduled tasks, masquerading, process injection, and lateral movement attempts leveraging remote service creation and stolen credentials. The binary contains multiple obfuscation layers, anti-debugging, anti-VM checks, and unusual API call sequences. [SEG-B-END] [SEG-C-BEGIN] IOC Bundle: Domains=malicious-domain-example-01.com,malicious-domain-example-02.net,malicious-update-service.info; IPs=103.21.244.0,198.51.100.55,203.0.113.77; FileNames=update_service.exe,winlog_service.dll,mscore_update.bin; RegistryKeys=HKCU\\\\\\\\Software\\\\\\\\Microsoft\\\\\\\\Windows\\\\\\\\CurrentVersion\\\\\\\\Run,HKLM\\\\\\\\System\\\\\\\\Services\\\\\\\\FakeService; Mutex=Global\\\\\\\\A1B2C3D4E5F6G7H8; YARA Matches=[rule1,rule2,rule3]. [SEG-C-END] EndOfExtraInfo\",
	"Hostname": "USG1000E",
	"ModuleName": "01ANTI-APT",
	"Policy": "trust-untrust-high-risk-policy-with-deep-inspection-and-layer7-protection-enabled-for-advanced-threat-detection",
	"Profile": "IPS_default_advanced_extended_profile_with_ml_detection-long",
	"Protocol": "TCP",
	"SeverityHeader": "4",
	"SrcIp": "192.168.1.123",
	"SrcPort": "51784",
	"SrcZone": "trust-zone-with-multiple-segments-for-internal-security-domains-and-access-control",
	"SyslogId": "1",
	"ThreatName": "bbb-advanced-threat-campaign-with-code-name-operation-shadow-storm-and-related-IOCs-collected-over-multiple-incidents-in-the-wild-attached-metadata-[phase1][phase2][phase3]",
	"ThreatType": "File Reputation with additional descriptive context of multi-layer analysis engine including sandbox-behavioral-signature-ml-static-analysis-and-network-correlation-modules-working-together",
	"User": "unknown-long-user-field-used-for-simulation-purpose-with-extra-description-and-tags-[tag1][tag2][tag3]-to-reach-required-size",
	"VSys": "public-long-virtual-system-name-for-testing-extra-large-value-to-simulate-enterprise-scenario",
	"count": 29,
	"extends_info": {
		"hostname": "USG1000E",
		"source_type": "socket"
	},
	"extends_ip": {
		"DstIp": "182.150.63.102",
		"SrcIp": "192.168.1.123"
	},
	"host": "127.0.0.1",
	"match_chars": "localhost",
	"num_range": 29,
	"port": 51272,
	"severity": 4,
	"source_type": "socket",
	"src_system_log_type": "日志信息",
	"symbol": "ANTI-APT",
	"timestamp": "Feb  7 2025 15:07:18+08:00",
	"type": "l"
}

wpgen_test 场景说明

本用例专门用于测试 wpgen 数据生成器的性能：仅生成样本数据，不启动 wparse 解析。适用于评估数据生成能力、验证生成规则正确性，以及为其他基准测试准备数据。

场景特点

• 纯生成测试：仅测试 wpgen 生成能力，不启动 wparse
• 多规则集：支持 nginx 和 benchmark 两套规则
• 多速度档位：测试不同限速下的生成性能
• 大规模数据：默认生成 800 万行 + 600 行样本

目录结构

wpgen_test/
├── conf/
│   ├── wparse.toml     # 主配置（本用例不使用）
│   └── wpgen.toml      # 生成器配置
├── models/
│   ├── oml/            # OML 转换模型
│   ├── sinks/          # Sink 配置
│   ├── sources/        # 源配置
│   └── wpl/            # WPL 规则
│       ├── nginx/      # nginx 规则
│       └── benchmark/  # benchmark 规则
├── data/
│   └── logs/           # 日志目录
└── run.sh              # 运行脚本

快速使用

cd benchmark

# 默认测试（nginx + benchmark 两套规则）
./wpgen_test/run.sh

# 指定 profile（release/debug）
./wpgen_test/run.sh release
./wpgen_test/run.sh debug

参数说明

注意：-w 参数仅为保持与其他 benchmark 脚本接口一致，本脚本不使用。

执行流程

1. 初始化 release 环境
2. 清理旧数据
3. 生成高速 nginx 样本（800 万行，200 万行/秒）
4. 生成高速 benchmark 样本（800 万行，200 万行/秒）
5. 生成低速 nginx 样本（6000 行，1000 行/秒）

测试配置

脚本中的测试配置：

# 高速生成测试
LINE_CNT=8000000
SPEED_MAX=2000000
wpgen sample -n $LINE_CNT -s $SPEED_MAX --stat 2 -p --wpl ./models/wpl/nginx
wpgen sample -n $LINE_CNT -s $SPEED_MAX --stat 2 -p --wpl ./models/wpl/benchmark

# 低速生成测试
LINE_CNT=6000
SPEED_MAX=1000
wpgen sample -n $LINE_CNT -s $SPEED_MAX --stat 2 -p --wpl ./models/wpl/nginx

性能指标

预期吞吐

• 无限速：取决于 CPU 和磁盘 I/O
• 限速 200 万/秒：稳定达到目标速率
• 限速 1000/秒：精确控制生成速率

影响因素

• CPU 性能：规则复杂度影响生成速度
• 磁盘 I/O：文件写入瓶颈
• 规则复杂度：字段数量和类型

输出示例

gen 2000000
[STAT] generated: 8000000, speed: 2000000/s, elapsed: 4.0s
[STAT] generated: 8000000, speed: 2000000/s, elapsed: 4.0s
gen 1000
[STAT] generated: 6000, speed: 1000/s, elapsed: 6.0s

常见问题

Q1: 生成速度未达到限速值

• 检查 CPU 使用率是否已满
• 检查磁盘 I/O 是否瓶颈
• 考虑降低规则复杂度

Q2: 内存占用过高

• 减少并行度（parallel 参数）
• 分批生成数据

Q3: 生成数据格式错误

• 检查 WPL gen_rule.wpl 规则
• 使用 wpkit 验证规则语法

与其他基准测试的关系

相关文档

• Benchmark 总览
• wpgen 使用指南

Core用例

本目录收录核心端到端用例与场景化配置，便于快速验证解析、路由、过滤、度量与校验能力。

目录规范（V2）

• 每个用例的标准布局（已逐步迁移）：
  • conf/：引擎与工具配置（wparse.toml 等）
  • connectors/source.d/、connectors/sink.d/：源/汇连接器（file/syslog/kafka/DB 等）
  • models/：规则与路由（models/wpl、models/oml、models/sources/wpsrc.toml、models/sinks/{business.d,infra.d,defaults.toml}）
  • data/：运行数据目录（data/in_dat、data/out_dat、data/rescue、logs/）
  • 其它：脚本与 README 按各场景自述

常用命令（wproj / wparse）

• 初始化 & 校验
  • wproj conf clean|init|check 生成与校验 conf/、connectors/、models/（源配置默认写入 models/sources/wpsrc.toml）
  • wproj data clean|check 清理输出或校验/构建源（v2）
• 数据生成
  • wpgen conf init 生成生成器配置
  • wpgen sample -n N --stat S 生成样本到 data/in_dat/
• 解析运行
  • wparse batch --stat S -p [-n N] 批处理运行
• 统计与校验
  • wproj stat file|src-file|sink-file [--json]
  • wproj validate sink-file [-v] [--input-cnt N] [--json]

全局约定

• sink 命名
  • name：单个 sink 的名称，需在同一 sink_group 内唯一；未显式提供时按索引回退为 [0]、[1]…
  • full_name = sink_group.name + "/" + name，CLI 展示与运行期内部标识统一使用 full_name。
• filter 语义
  • filter 是“拦截条件”：表达式为 true 时该 sink 丢弃本条数据并转发至基础组 intercept；为 false 时才写入该 sink。
• 校验（validate）
  • 三层期望：defaults.expect（全局默认）→ sink_group.expect（组级）→ sink.expect（单项）
  • ratio±tol 或 [min,max] 二选一；min_samples 控制分母阈值。
• CLI 展示
  • wproj stat file 与 wproj validate sink-file 的 Sink 列统一显示 full_name。

快速开始（完整指南）

• 文档入口：docs/README.md
• 快速入门：docs/getting-started/quickstart.md

快速开始（命令摘要）

• 构建：cargo build --workspace --all-features
• 进入用例目录并运行：./case_verify.sh
• 单步：
  • 统计：wproj stat file
  • 校验：wproj validate sink-file -v

用例清单

1) getting_started（初始化示例）

• 目的：最小可运行工程模板，初始化 source/oml/sink 与基础组。
• 入口：usecase/core/getting_started/case_verify.sh
• 业务组：sink/business.d/benchmark.toml → /sink/benchmark
• 基础组：sink/infra.d/*.toml（default/miss/residue/intercept/error/monitor）

2) multi_sink（多汇与占比）

• 目的：同一 sink_group 下多种输出格式与占比校验。
• 入口：usecase/core/multi_sink/case_verify.sh
• 业务组：sink/business.d/simple.toml
  • 组名：/sink/simple
  • sinks：dat/json/kv（各 1/3 占比）

3) wpl_success / wpl_missing（规则成功/缺失场景）

• wpl_success：成功解析全链路
• wpl_missing：字段缺失容错；已统一 sink_group 为 /sink/simple，sinks 命名为 dat/json/kv
• 入口：usecase/core/wpl_success|wpl_missing/case_verify.sh

4) source_file（多文件源与对半分流）