四级渐进学习法 · Flink 规则解析 · 第 5/9 篇

万条规则，先筛后捕。

一条原始日志要变成结构化审计记录，得先在万级规则库里找到「那一条」。本页讲引擎最核心的领域逻辑：recognizeStr 便宜前缀先筛 → patternStr 昂贵正则再捕 → fields 模板拼出标准字段。L3 的解析台会在浏览器里真实执行规则库原始正则。

FlinkDeployment · 1 JM + N TM operator: helm · watchNamespaces 前置依赖 cert-manager 规则库：linux 17 + win 4 + cron 1
THE FRAMEWORK

先看地图，再出发THE FRAMEWORK — 链路的第五跳

全链路七跳，本页覆盖第五跳：终端 Agent → envoy mTLS → audit-gateway → Kafka → Flink ETL（本页）→ std topic → StarRocks。Flink 从原始 topic 取数，把「洗」这道工序做完，产出可检索的标准字段。

L1

受控语言

三十三句确定性短句，分五组：部署形态、两步解析、字段映射、ETL 平台、规则库与依赖。

例：「recognizeStr 是便宜的前缀匹配。」
L2

结构图

三张图：解析管线四阶段（可点击）、万级规则两步走的性能对比、FlinkDeployment 部署拓扑。

例：对比图里一根柱子是 10000，另一根是 1。
L3

交互网页

两步解析台：可编辑日志，步进看识别命中 → 真实正则执行 → 捕获组表 → 字段映射 JSON。改日志能走「未命中」路径。加六题自测。

例：把 uid 改成别的，看 $4 怎么变。
L4

定制视频

六镜头「万中选一」：洪流进卡池、前缀快筛、正则捕获、模板拼装、平台下发、收尾。成片已交付 · 01:34。

例：一支片子讲完「找到那一条」。

本页名片（一分钟版）

主角：flink-etl（FlinkDeployment）
一句话：万条规则里找到那一条——先便宜筛，再贵正则。
三个数字：1 JM + N TM · 规则库万级（预发 22 条）· 映射表 23 张 xlsx。
解决两件事：结构化（识别·捕获·映射）· 性能（前置识别收窄范围）。

Dashboard 30004REST flink-etl-rest:8081ipdb → S3

一句话主线（背下来，全页都在展开它）

consume agent-* → recognizeStr 前缀识别（收窄到 1 条）→ patternStr 正则捕获 $2/$3/$4… → fields 映射（name/subMSG/srcProcessId/message）→ produce std_clasp_agent_* → 直写 StarRocks

L1 CONTROLLED LANGUAGE

受控语言：三十三句讲清规则解析简短、确定、一词一义——不靠形容词，只靠事实

以下每句话都来自交接材料（规则解析参考、ETL 字段映射表、部署手册）。读不懂的句子，去 L2 找对应的结构图。

部署形态

§ 1 · 7 句

两步解析

§ 2 · 7 句

字段映射

§ 3 · 6 句

ETL 平台

§ 4 · 6 句

规则库与依赖

§ 5 · 7 句
L2 DIAGRAMS

结构图：解析的真实骨架图 1 可点击四阶段 · 图 2 是本页的性能账

三张图：先看一条日志流过四个阶段，再算「万级规则为什么必须两步走」，最后看 Flink 在 K8s 里的部署拓扑。

① 原始日志（rawMsg） type=LOGIN msg=audit( 1301554080.656:8018): login pid=981 uid=0 old auid=4294967295 new auid=0 ② recognizeStr 识别 type=LOGIN msg=audit\( 前缀命中「用户登录」 规则库 regexStep 10000 ③ patternStr 捕获 $2 audit 时间戳:序列 $3 pid · $4 uid $5 old · $6 new auid $1 头信息 · $7 tty … ④ 字段映射 fields[] subMSG←$2 · srcProcessId←$3 message=用户(uid：$4)登录。 name=用户登录（固定值） → std_clasp_agent_audit_log_linux 规则来自「规则解析参考」：linux-audit 17 条 + windows 4 条 + cron 1 条；映射表见 23 张 xlsx
图 1 · 规则解析管线：识别 → 捕获 → 映射（点击阶段查看职责）
点击图中的四个阶段（rawMsg / recognizeStr / patternStr / fields），这里显示它的职责。
没有前置识别：条条硬跑 10000 次 完整正则 / 每条日志 两步走：先筛后捕 前缀筛 1 次正则 便宜的前缀先把范围收窄 贵的正则只跑命中的那一条 万级规则 × 每秒十万日志：不先筛，正则就是灾难——这就是 recognizeStr 存在的全部理由
图 2 · 性能账：10000 次完整正则 vs 前缀筛 + 1 次正则
K8s · ns: audit-release flink-kubernetes-operator helm 安装 · watchNamespaces = ["audit-release"] 前置依赖：cert-manager flink-etl（FlinkDeployment） JobManager ×1 TaskManager ×N Dashboard 30004 · REST 8081 MinIO（S3） checkpoint 存储 bucket audit-etl 调谐 checkpoint 规则配置 ← data-platform（30012）下发
图 3 · FlinkDeployment 拓扑：operator 调谐、S3 checkpoint、平台下发规则
L3 INTERACTIVE

交互探索：两步解析台可编辑日志 · 真实正则执行 · 四步走完

样例是规则库里的真实数据：Linux audit「用户登录」事件。左侧改日志、右侧步进：第 1 步看识别命中与否，第 2 步浏览器现场执行规则库原始 patternStr，第 3 步看捕获组，第 4 步看字段映射与产出。改成不认识的日志，能走「未命中」路径。

3a · 两步解析台

真实正则 · 可编辑
① 识别② 正则③ 捕获组④ 映射
按「下一步」开始：这条日志会先过 recognizeStr。
step 0 / 4
原始日志（可编辑，改完点重置再推）：

来自规则库 rule_linux-用户登录.json 的 sample 字段。

这一步发生了什么

开始后逐步解释：为什么先识别、正则怎么捕、字段怎么映射。

3b · 概念自测

6 题 · 单选

已答 0 / 6 · 正确 0 · 正确率 0%

1. recognizeStr 与 patternStr 的分工是？

一万条规则不能条条硬跑：recognizeStr 先用便宜的前缀匹配把范围收窄到一条，patternStr 再跑一次完整正则取捕获组。

2. 为什么要先做前置识别？

10000 次/条日志的完整正则是灾难；前缀筛把它变成 1 次。识别未命中时才按 regexStep 顺序继续尝试。

3. 捕获组 $3 映射到哪个标准字段？

$2→subMSG、$3→srcProcessId、$4 拼 message 模板；name 是规则名固定值「用户登录」。映射关系在 23 张 xlsx 里维护。

4. helm 安装 Flink Operator 的关键注意点？

watchNamespaces 不一致会导致 FlinkDeployment 无人调谐；operator 的 webhook 还依赖 cert-manager。

5. IP 归属库 ipip-*.ipdb（141MB）部署时放在哪里？

ETL 平台配置时从 S3 引用 ipdb，用于日志 IP 字段的归属地补全。141MB 打进镜像会让每次发版都变慢。

6. Flink Operator 的前置依赖是？

operator 的 admission webhook 需要 cert-manager 签发证书——部署顺序里它排在 helm install flink 之前。
L4 VIDEO

定制视频：万中选一六镜头 · 成片已交付 · 01:34· 分镜与解说骨架已备

六镜头沿用总览片「万中选一」意象并展开：洪流进卡池、前缀快筛、正则捕获、模板拼装、平台下发、收尾。画面里的识别串、捕获组、字段名与 L1–L3 同源。

成片 · topic-05-flink-etl.mp4　✓ 已交付

00:00 开场 · 洪流进卡池 00:15 两步 · 前缀快筛 00:32 性能账 · 一万次 vs 一次 00:47 逐条硬跑 01:05 先筛后捕 01:18 映射 · 模板说人话

规格：1920×1080 · 30fps · 01:34 · H.264 + AAC · 中文配音（zh-CN-Yunxi 逐句合成，每句实测时长均落在自己的字幕窗口内）+ 画面内嵌字幕。底部常驻进度轨随镜头推进点亮。

分镜脚本

6 镜头 · 旁白即片中字幕

镜头 1 · 洪流进卡池

画面：原始日志如卡片洪流涌入一座万格卡池，每格一条规则。
旁白：一条日志，一万条规则。逐格去试，到天亮也试不完——规则引擎的第一课：别硬试。

镜头 2 · 前缀快筛

画面：日志头部 type=LOGIN msg=audit( 六个字符如探针扫过卡池，只有一张卡亮起。
旁白：先用便宜的：一段前缀，万格速筛。一万个可能，瞬间剩下一个。

镜头 3 · 正则捕获

画面：亮起的规则卡展开为正则模板，捕获组括号依次点亮 $2 $3 $4，值被抽出行。
旁白：贵的正则，只跑这一次。括号张开口，把时间戳、进程号、用户号一个个衔出来。

镜头 4 · 模板拼装

画面：捕获值飞进字段槽位 subMSG / srcProcessId / message，name 槽自动填入「用户登录」。
旁白：模板负责说人话：用户，几号，登录了。原始文本到此变成结构化字段。

镜头 5 · 平台下发

画面：data-platform 界面上规则改一行，下发箭头直达 flink-etl，卡池同步刷新。
旁白：规则不是写死的。平台上改，作业里生效——规则配置与计算引擎，各管各的。

镜头 6 · 收尾：结构化完成

画面：std topic 中一行 JSON 落定，StarRocks 检索框输入「用户登录」毫秒返回。
旁白：从一行谁也读不懂的原文，到一条毫秒可查的记录——这就是引擎里「洗」的那一跳。

解说骨架：六个设计决定

镜头 2–5 的旁白依据

① 前置识别

万级规则先便宜前缀筛，再跑完整正则。

② 两步走

recognizeStr 定类型，patternStr 取捕获组。

③ 捕获组映射

$2/$3/$4 → subMSG/srcProcessId/message，模板拼装。

④ name 固定值

规则名即事件名，检索的直接锚点。

⑤ 平台管规则

data-platform 下发配置，Flink 只管算——规则与算力解耦。

⑥ operator 调谐

watchNamespaces 对齐 + cert-manager 前置，FlinkDeployment 才有人管。