四级台阶：L1 受控语言 → L2 结构图 → L3 交互网页 → L4 定制视频。以预发环境（release）完整部署实况为底本——真实组件、副本数、端口、Kafka topic 与解析规则——先用确定性短句建立词汇，再看结构图建立骨架，再亲手推一条日志走完七跳链路，最后看一支解说片把全链路串成故事。
自研日审引擎（综合日志审计系统）做一件事：把十万级终端的日志，安全地、不丢地、标准化地收上来，存成分层可查的证据。终端 Agent 采集加密上报 → envoy mTLS 网关接入 → audit-gateway 落 Kafka → Flink ETL 清洗标准化 → StarRocks 毫秒检索。四级台阶对它逐层下钻。
五十句确定性短句。每句一概念、一词一义，无形容词、无脑补空间。读完即拥有完整词汇表。
五张确定性结构图：预发部署总架构（可点击组件）、一条日志的旅程、Agent 双进程内部、规则解析管线、Kafka 三层 topic。
亲手「拨动」日审引擎：推一条真实 audit 日志走完七跳链路（含真实正则执行）+ 二十一题自测 + 部署排障实战参考。
3b1h 风格解说片：画面 + 中文配音 + 字幕。八个镜头、3 分 40 秒，讲完一条日志的一生。成片随本页交付。
名称：综合日志审计系统（自研日审引擎）
一句话：终端日志的「收、洗、存、审、管」一体化引擎。
解决三个老问题：存储无分层、流量不可控、运维成本高。
五件事：采集 · 清洗 · 存储 · 审计 · 远程运维。
规模设定：十万级终端、多机房对等、租户隔离。
终端日志 → Agent（采集·限流·缓存）→ envoy（:30015 mTLS ×2）→ audit-gateway（headless ×3 · 落 Kafka）→ Kafka（agent-* 原始 ×3）→ Flink ETL（规则解析·映射）→ std_clasp_agent_* → StarRocks（3FE+3BE 存算分离）
本页讲全链路故事；九个知识点（Agent / mTLS / headless / Kafka / 规则解析 / 存储 / 治理 / 洪峰 / 部署）各有独立四级页，含专属模拟器与自测。进入知识点目录 →
以下每句话都能在交接材料里找到出处（设计方案 v5、部署手册、Agent 模块梳理、Kafka Topic 列表、规则解析 JSON）。读不懂的句子，去 L2 找对应的结构图。
五张图从粗到细：先看全貌，再追一条日志，再钻进 Agent 与解析规则，最后看消息分流。每张图都是确定性的：同样的输入永远画出同样的结构。
样例是规则库里的真实数据：Linux audit「用户登录」事件。每一步右侧显示该环节真实的数据形态；第 5 步的捕获组由浏览器现场执行真实正则得出——日志可以改，改完重新推。玩过之后，下方附部署六步、端口速查与排障坑作实操对照。
用「下一步」推进，架构图上会点亮当前环节。
来自规则库 rule_linux-用户登录.json 的 sample 字段。
开始后这里逐步解释：为什么限流、为什么 mTLS、为什么 headless、正则怎么捕、字段怎么映射。
已答 0 / 21 · 正确 0 · 正确率 0%
1. envoy-gateway 的 gRPC 上游应该指向哪个 Service？
2. Agent 的正式上报入口是？
3. mTLS 握手验证成功的标志是？
4. 原始日志 topic 与标准化 topic 的关系是？
5. Agent 双进程模型中，Daemon 的职责是？
6. 控制指令的两层去重是？
7. helm 安装 Flink Operator 时的关键注意点？
8. IP 归属库 ipip-*.ipdb（141MB）部署时放在哪里？
9. StarRocks 在本系统的角色是？
10. Agent 心跳的上报间隔与内容是？
11. Daemon 与 Worker 的 IPC 怎么解决粘包？单包上限多少？
12. 端侧 EPS 令牌桶触发限流时，谁的优先级最高？
13. 设计方案里的「五通道」怎么分工？
14. 终端 Agent 升级的正确顺序是？
15. Kafka 集群采用哪种认证方式？
16. las-* 这一层 topic 存的是什么？
17. 规则解析里 recognizeStr 与 patternStr 的分工是？
18. 心跳、资产、监控这类小数据存在哪里？
19. 本系统里 Nacos 的角色与 namespace 是？
20. 「两层限流」分别护的是什么？
21. 滚动升级后发现异常，要回到指定版本怎么做？
audit-release / middleware-release；Secret 名 ctct-mssp（部分 YAML 里叫 ctyun-registry，遇到要改）
Nacos / MySQL / Redis / Kafka / MinIO（平台侧提供，确认即可）
apply audit-agent.yaml → audit-gateway.yaml → svc.yaml（依赖 Nacos、MySQL、Redis、Kafka）
gen-certs.sh → envoy-secret → envoy-cm → envoy-deployment → envoy-svc（依赖 audit-gateway）
etl-cm → data-platform → fe-cm → fe-web；上传 ipdb 到 S3 bucket audit-etl（依赖 MySQL、Redis、S3）
cert-manager → helm install flink（-n 与 watchNamespaces 一致）→ etl-flink_1.19.2.yaml（依赖 cert-manager、S3）
kubectl -n audit-release get podsget endpoints audit-gateway-headless 返回 3 个 Pod IP:8285:9901/clusters 3 个上游 healthyVerify return code: 0 (ok)python3 grpc_mtls_test.py PASSset image 滚动升级 → rollout status 观察 → rollout undo [--to-revision=N] 回滚；证书轮换：gen-certs.sh → 重建 envoy-tls-certs Secret → rollout restart → 重新分发 client 证书并重启 Agent。
| 入口 | NodePort | 容器端口 / 协议 | 说明 |
|---|---|---|---|
| Nacos 控制台 | 30002 | — / HTTP | 服务注册与配置中心 |
| Flink Dashboard | 30004 | 8081 / HTTP | ETL 作业观测（内部 REST flink-etl-rest:8081） |
| dbeaver | 30005 | — / HTTP | 数据库管理 |
| MinIO Console | 30008 | — / HTTP | S3 控制台（bucket audit-etl） |
| kafka-ui | 30009 | — / HTTP | Kafka 管理 |
| data-platform 后端 | 30012 | 80 / HTTP | ETL 平台 API |
| ETL 控制台 | 30013 | — / HTTP | ETL 平台入口 |
| envoy（正式入口） | 30015 | 8285 / gRPC+mTLS | Agent 上报唯一正式通道 |
| envoy（调试） | 30016 | 8286 / gRPC 明文 | 无需证书，仅调试 |
| envoy（HTTP） | 30017 | 8080 / HTTP+mTLS | HTTP 接口 |
| audit-agent | 30018 | 80 / HTTP | 采集/接收前端 |
| data-platform-fe | 31212 | 80 / HTTP | ETL 前端（Nginx 反代后端） |
无 selector、仅 1 个失效 endpoint。envoy 上游必须 headless（per-Pod LB + 健康检查），HTTP 上游用 ClusterIP。
部分 YAML 里写的是 ctyun-registry，统一改成 ctct-mssp；拉不到镜像去节点机取现成镜像 docker save/load。
helm install 的 -n audit-release 与 values 里 watchNamespaces: ["audit-release"] 必须一致，否则 FlinkDeployment 无人调谐。
40+ 个 topic（agent-* 全量、std_clasp_agent_*、las-*）部署前必须预先创建，否则链路数据无处可落。
141MB 的 ipip 库需上传至 bucket audit-etl，ETL 平台配置引用，漏了则 IP 归属地补全失效。
envoy 证书 SAN 必须含集群内域名；轮换后要 rollout restart 并重新分发 client 证书、重启全部 Agent，否则 mTLS 握手失败。
一支片子讲完一条日志的一生。八个镜头围绕「造引擎的十五个决定」展开，画面里的组件名、副本数、端口、正则与捕获组，全部与 L1–L3 同源——不是示意图，是部署实况。用 Remotion 逐帧渲染，画面即代码：同一时间轴永远渲染出同一帧，改一个字重渲即可。
规格：1920×1080 · 30fps · 3:40 · H.264 + AAC · 中文配音（zh-CN-Yunxi 逐句合成，26 句按字幕时间轴铺轨，句间停顿与镜头切换对齐）+ 画面内嵌字幕。画面底部常驻七跳链路进度条，随镜头推进点亮。
镜头 1 · 开场：一条日志的诞生
画面：黑场渐亮，终端机上一行 audit 日志逐字打出。
旁白：这是一条 Linux 登录日志。它将跨越七道关卡，变成一条可举证的审计记录。这是它的一生，也是自研日审引擎的一生。
镜头 2 · Agent：终端上的哨兵
画面：双进程动画——Daemon 圆环包裹 Worker 方块；Worker 崩溃，Daemon 三秒拉起。
旁白：终端上是 Agent，双进程结构。Daemon 只管保活，Worker 只管干活。断点续采靠 inode 加偏移，断网靠本地加密缓存——日志一条不丢。
镜头 3 · mTLS：互相验明正身
画面：两本证书翻开对照，握手成功后隧道点亮为绿色。
旁白：上报的第一关是双向认证。Agent 出示客户端证书，网关出示服务端证书，同一个根 CA 签名。伪造者进不来，明文出不去。
镜头 4 · 网关与削峰
画面：洪峰箭头涌入 Kafka 水坝，下游 Flink 匀速抽水。
旁白：十万终端的洪峰不能直接砸进计算层。Kafka 先把它存成三层 topic：原始层保真，标准层可查，信令层可追溯。削峰，是可靠性的来源。
镜头 5 · 规则引擎：万中选一
画面：日志流过规则卡池，recognizeStr 前缀快筛，命中卡片放大，正则捕获组依次点亮 $2 $3 $4。
旁白：一万条规则里找到那一条，先靠便宜的前缀识别，再跑完整正则。捕获组拼进模板，一条原始文本变成了结构化字段。
镜头 6 · 存储：分层与分离
画面：StarRocks 计算层浮在 MinIO 存储层之上，柱状数据落盘。
旁白：标准化数据批量直写 StarRocks，存算分离，底层是对象存储。台账进 MySQL，心跳走 LogStorage——每一类数据，都有它的位置。
镜头 7 · 管控：全局的手
画面：控制面网格俯瞰多个机房，灰度发布波纹逐环扩散，失败环自动回卷。
旁白：管控平台不碰日志流量。它管租户、配额、灰度与回滚——升级走独立通道，失败率超标自动熔断。控制面和数据面，各司其职。
镜头 8 · 收尾：证据链闭环
画面：七跳链路整条点亮，检索框输入「用户登录」，毫秒返回结果卡片。
旁白：回到开头那条登录日志。此刻它是结构化的、可检索的、可举证的。从一条日志到一次审计——这就是自研日审引擎。
① 双进程
崩溃隔离：业务易崩放 Worker，保活极简放 Daemon。
② 4B 长度头
管道字节流会粘包；长度前缀是最小分帧，1MB 防大包。
③ 磁盘指令队列
重启断电不丢指令；原子写防 JSON 损坏。
④ 两层去重
exists 防重复入队、processing 防并发；内存便宜，磁盘兜底。
⑤ 边缘终止 TLS
证书集中管理，内网明文换吞吐，轮换只动边缘。
⑥ headless 上游
per-Pod 负载均衡 + 主动健康检查，ClusterIP 做不到。
⑦ 先 Kafka 再 ETL
削峰解耦；Flink 挂了数据还在 topic，可重放回补。
⑧ topic 三层
原始保真、标准可查、信令可追溯——三个消费语义。
⑨ 前置识别
万级规则先便宜前缀筛，再跑完整正则。
⑩ 存算分离
MinIO 担成本与弹性，3FE+3BE 独立扩缩。
⑪ 五通道
大小流量互不抢占，升级洪峰不挤垮日志链路。
⑫ 两层限流
端侧令牌桶护网络，服务端配额护存储。
⑬ inode+offset
路径会变 inode 稳定；不漏采也不重采。
⑭ 机房对等自治
故障不扩散，断网本地策略独立运行。
⑮ 灰度熔断回滚
十万终端没有灰度的全量升级是事故。
① 存储冷热分层怎么切：StarRocks 热存多久、什么条件降冷到对象存储？
② 规则引擎 DSL 演进：万级正则之外，要不要引入结构化解析与规则版本管理？
③ 超十万终端后，envoy ×2 与 gateway ×3 的扩容曲线在哪里拐弯？瓶颈先出现在哪一跳？
React 组件写画面 → 逐帧确定性渲染 → 1920×1080 H.264；旁白逐句 TTS（26 句，每句实测时长必须短于自己的字幕窗口）→ 按时间轴 adelay 铺轨、统一响度（loudnorm −16 LUFS）→ 与画面合流。字体本地化落盘（Noto Serif SC / Noto Sans SC 分片 woff2，不联网取字），时间轴与字幕表分离管理：改一句文案，只改 src/timeline.ts 的数据再重渲，画面与配音自动对齐。源码在 video/ 目录，出片与配音各一条命令。