24 类日志，
真正要记的只有一条链。
这是自研日志审计系统首批接进来的 6 个规则组。下面不止列清单——每一类都回答同样四个问题：谁写的、凭什么才写、写成什么样、能证明什么。最后给一套可以照着练的认知方法。
主线：日志不是被"采集"到的，是被触发出来的。
你看到的每一条记录，背后都有人先做了一个"要不要记"的决定。
先把 24 类放进同一条流水线里
分组看起来是按系统分的，其实是按"谁来解析、从哪个管道进来"分的。看清这一点，才不会把管道规则当成日志类型去背。
上图依据截图中的 6 个规则组绘制；"审计目录"在截图中出现两次，可能对应不同的监控路径或 key，此处合并为一条。
分组与数量按你提供的截图逐字；右侧"清洗解析 → 字段归一 → 存储索引 → 检索 → 规则检测 → 告警"是通用流水线示意，不代表你系统里的实际模块划分。
这 24 类里，只有 21 类会产生事实——Windows 4 类、Linux cron 1 类、Linux audit 16 类。剩下 3 类（纯转发、日审-windows分流、定义事件时间）不产生任何新事件，它们只做搬运、路由和定标。
这是新手最容易走偏的地方：把管道规则当日志类型背下来，背得再熟也解释不了"为什么这条日志里没有我要的字段"。因为字段不是管道给的，是源头给的；管道只能让它更整齐，或者更乱。
24 类逐条拆开看
左边选一类，右边按"四问"给出答案。这四问会在后面反复用到。
这是查阅，不是模拟。交互在这里的作用是让 24 类能一屏扫完、随手抽查，不是让某个量变化给你看——第 02 节那 21 张卡已经把答案静态摆好了，这里按需展开。
图有说服力，事实以台账为准 · 台账见第 10 节
先让每类日志，用四句话说完
上一节把 24 类摆进了流水线，那是地图。这一节换个角度：一类日志，只用四句话说完——谁写的、什么时候才写、写出来长什么样、能证明什么。
这是卡帕西四级的 R1。它不如图好看，也不如页面好玩，但后面每一级的事实都以它为准。
每张卡分两层。上半是中文，用来记；下半是同一份内容的英文 STE 原文，用来看"一句一事实"落到真句子上是什么样子：一个 record 从头用到尾、不换同义词，否定句永远以 does not prove 起头，和中文的不证明一一对齐。
写这 21 张卡遵守的五条规矩（ASD-STE100 的中文用法）
① 一句只说一件事 ② 用主动语态 ③ 用现在时 ④ 一个词只留一个意思——"写"专指产生记录，"证明"专指证据能力 ⑤ 说不清的地方写"不证明"，不写"可能""或许"。
原规范是英文的（约 900 个批准词、程序句 ≤20 词）。所以每张卡的下半层照英文原样写，上半层用中文按同样精神改写：不追词表，只追"一句一事实、不留歧义"。
21 类，点名字直接跳过去
Applications write the Application channel. Installers also write it.
An application writes one record when it crashes, reports an error, installs, or upgrades.
The record holds the event ID, the provider name, the level, and the time.
It proves that an application crashed or was installed at a given time. It does not prove who started the application.
Drivers and system components write the System channel.
The system writes one record when a service starts or stops, a driver fails to load, or the machine shuts down abnormally.
The record holds an event ID, for example 6005, 7036, 7045, or 41.
It proves that the system state changed. It does not prove who gave the command.
The Local Security Authority writes the Security channel.
It writes a record only when the audit policy is on. With the policy off, it writes nothing.
The record holds the event ID, the logon type, the account, and the source address.
It proves who logged on, and when. It does not prove what the user did after logon.
A kernel driver and a user-mode service write Sysmon. Sysmon is not installed by default.
Sysmon writes one record when a process starts, a network connection opens, or a file is created. The configuration XML selects the events.
The record holds the process hash, the parent process, the command line, and the target address.
It proves what a process did. It does not prove whether the action was allowed.
The crond daemon writes cron.
crond writes one record when a scheduled job runs.
The record holds the time, the host, the process ID, the user, and the command.
It proves that a user ran a command. It does not prove that the command succeeded.
The kernel audit subsystem writes this type. It watches the given path.
It writes one record when the watched directory changes, or when its attributes change. The watch does not include subdirectories. Add each subdirectory as a separate watch.
The record holds the path, the inode, the owner, the key label, and the syscall context.
It proves that someone touched the directory. It does not prove what content changed.
A PAM session module writes user login.
PAM writes one record after a successful logon.
The record holds the account, the source IP, the terminal, and the result.
It proves who logged on, and from which host. It does not prove what happened in the session.
systemd writes service stop through audit.
systemd writes one record when it stops a unit.
The record holds the unit name, the command, the process ID, and the result.
It proves that a service stopped at a given time. It does not prove who issued the stop command.
systemd writes service start through audit.
systemd writes one record when it starts a unit.
The record holds the unit name, the command, the process ID, and the result.
It proves that a service started at a given time. It does not prove that the service is safe.
A PAM authentication module writes this failure record.
It writes one record when authentication fails. It also writes when the user name does not exist.
The record holds the account, the source address, the terminal, and the result failed.
It proves that someone tried to log on and failed. It does not prove whether this was an attack or a typing error.
A PAM account module writes account accounting.
It writes one record when the account check runs. The check tests whether the account is expired, locked, or restricted.
The record holds the account, the result, and the source.
It proves whether the account was usable at that time. It does not prove whether the password was correct.
A PAM credential module writes credential acquisition.
It writes one record when the system gets credentials successfully.
The record holds the account, the result, and the terminal.
It proves that the authentication chain reached this step. It does not prove that the user received a new password.
A PAM session module writes session start.
It writes one record when the session opens.
The record holds the account, the source address, the terminal, and the session ID.
It proves that the session started here. It does not prove what the session did.
A PAM credential module writes credential refresh.
It writes one record when the system renews credentials. A sudo timestamp renewal is a typical case.
The record holds the account, the result, and the command.
It proves that credentials were renewed. It does not prove what happened after the renewal.
A PAM session module writes session close.
It writes one record when the session ends normally. It writes nothing when the network drops, the power fails, or a process kills the session.
The record holds the account, the terminal, the session ID, and the result.
It proves that the session ended normally. It does not prove that the session did not continue elsewhere.
A PAM authentication module writes the authentication record.
It writes one record at the authentication stage. It writes for both success and failure.
The record holds the account, the source, the terminal, and the result.
It proves whether the password passed. It does not prove whether the account was locked.
The kernel audit subsystem adds the working directory to other records.
Every audited syscall carries the current working directory. It never produces a record by itself.
The record holds one absolute path.
It proves which directory the command ran in. It does not prove what the file was.
A kernel security module writes denied access.
It writes one record when a security policy denies an access. SELinux must be in enforcing or permissive mode.
The record holds the denied action, the source context, the target context, and the class.
It proves that the policy blocked the access. It does not prove whether this was an attack or a misconfiguration.
The kernel audit subsystem writes this type. It watches the authentication files.
It writes one record when a process writes /etc/passwd, /etc/shadow, or a file under /etc/pam.d/.
The record holds the path, the change type, the owner, and the key.
It proves that someone changed an account or a PAM file. It does not prove who changed it. Add a SYSCALL rule for that.
The kernel audit subsystem writes allowed access.
It writes one record when a process accesses a watched object, and the policy allows the access.
The record holds the object, the result yes, and the key.
It proves that the access happened. It does not prove that the access was legitimate.
auditd writes this type. It collects the records that match no other type.
The system puts a record here when the record matches no specific rule.
The structure varies with the record type.
It proves that other records exist. It does not prove that these records are unimportant.
21 张卡读完，你该能做到三件事
① 听到任何一个日志名，先说得出它由谁写。② 被问"这条日志能证明什么"，先答"能"，再答不能。③ 拿到一张新列表，指得出哪几条根本不是日志类型。
第二件最容易漏。每一张卡的最后一行都是同一种句式——"它证明……不证明……"。这一行比前三行都值钱：日志分析出错的绝大多数情况，不是没读到记录，是把记录读得比它能承载的更多。
"如何触发"这个问题，其实有四种答案
同一句"这条日志是怎么来的"，在四类日志上有四种完全不同的答案。分不清这四种，就只能死记硬背。
代表：Windows-Security（审核策略）、Linux audit 全部 16 类（auditctl 规则）。
代价：没配就是永久盲区，而且盲区不会报错。
代表：Windows-Application、Windows-System、Linux cron。
代价：量大、字段随意、噪声高，而且你没得选记什么。
代表：Windows-Sysmon。
代价：要部署、要调配置，配错了比没有更危险。
代表：纯转发、日审-windows分流、定义事件时间。
代价：会造成"假可见"——看着有日志，其实没有语义。
前三种决定能不能看见，第四种决定看见的能不能用。
排查"日志里查不到"时，先问自己：是没发生、没记录、没采集，还是采集了没解析？这四个答案对应四个完全不同的修法。
一条日志的完整链路（每一类都走这六步）
六步是本文抽象出的模型，不是你系统里的模块名；实际部署可能把"清洗归一"拆成多个节点。
把这条链记住，你会发现后面 24 类的描述都是在填同一张表。这就是体系化的起点——不是记 24 个名词，是记 1 个模板填 24 次。
一堵墙里住着四户人，各记各的账
Windows 的四类不是并列的四个文件，而是四种不同的记账方式：应用自己记、系统自己记、安全子系统按你的吩咐记、Sysmon 拿放大镜记。
开关：应用自己决定。
开关：开机即有。
开关：审核策略（关键）。
开关：配置文件（关键）。
最容易踩的那一脚：Security 日志是"策略驱动"的
很多人第一次做审计，装了采集器、配了规则，然后发现安全日志里什么都没有。原因通常不是采集失败，而是那台机器从来没开过审核策略——没开审核，安全子系统根本不会写这条事件，采集器再努力也采不到不存在的东西。
这个坑的本质是：Security 属于"策略触发"，它的可见范围完全由你声明。所以做 Windows 审计的第一件事，永远是核对审核策略，而不是看采集器日志。
4624 里的那个 LogonType，是判断"他是怎么进来的"的关键
拖动滑块，看不同登录类型分别意味着什么。同一个"登录成功"，含义可以差出十万八千里。
Sysmon 和 Security 为什么不能互相替代
这个问题面试常问，实际工作也常吵。答案很简单：它们记的不是同一件事。
Security 能告诉你：张三在 10:02 从 10.0.0.5 用 RDP 登录成功（4624，LogonType=10）
Sysmon 能告诉你：张三登录后第 8 秒，powershell.exe 带着 -enc 参数启动，父进程 explorer.exe，外连 45.x.x.x:443
一个管身份，一个管行为。查"谁进来了"靠 Security，查"进来干了什么"靠 Sysmon。缺哪个，故事都断一半。
补充一句实话：Sysmon 默认配置抓不到命令行。必须在配置里显式打开进程创建的 CommandLine 包含项，否则你拿到的 Event ID 1 只有进程名——这个问题在真实项目里出现频率极高。
16 类里，只有 1 类是"一条记录"，其余都是"一次事件的碎片"
这是 audit 最难理解、也最能体现专业度的地方：你在日志里看到的连续 6 行，其实是同一个动作被拆成了 6 块。
这条链是 Linux 的标准实现（标准事实）；右侧"采集器 / 审计系统"是通用示意。
一次 execve，被拆成 6 条记录
下面这段是真实的 audit 日志形态。同样一个 msg=audit(...:8421) 出现 6 次——序号 8421 就是这次事件的身份证。审计系统要做的第一件事，就是把这 6 条拼回 1 条。
上面 6 行是同一个动作被拆开的碎片。点一下，看它们怎么合成一件能读懂的事。
注意最后一行 PROCTITLE——它是十六进制编码的。这是审计里一个反复出现的细节：看日志看到一串十六进制，先别以为是乱码，那是故意编码的。不解码，你就看不到真正的命令行，也就看不到 curl ... | bash 这种典型动作。
顺便纠正一个常见误解：SOCKADDR（记录了目标 IP 和端口）并不属于这次 execve 事件。它出现在 connect 类系统调用的事件里。想把"执行了 curl"和"连到了 45.9.x.x"串起来，需要跨事件关联，而不是在同一个 id 里找。
16 类 audit，按"一次登录的生命周期"重排
截图上按字母/编号排列，看起来是散的。按 PAM 阶段重排，你会发现它们其实是同一条线上的先后顺序。
阶段顺序按 PAM 标准（标准事实）；中文规则名到记录类型的对应是推理，依据是阶段语义而非厂商文档（见台账 ①）。
这张图解释了一件事：规则粒度不等于日志粒度。一条 USER_AUTH 记录，成功时归到"用户登录认证"，失败时归到"用户名错误导致登录失败"，同一条记录可能同时满足多条规则的匹配条件。所以规则组里出现两条看起来重名的"审计目录"，也就不奇怪了——它们的 key 或监控路径不同。
剩下 8 类，按用途分四堆
这是 audit 最值钱的部分：后门账户、改 sudoers、读 shadow，全在这里留痕。
关掉防火墙、停掉审计服务，这类动作会在这里露出马脚。
价值在"串起来"：单独一条信息量很小，8 条连起来才能还原完整登录过程。
它的量在涨，说明你的规则集落后于系统变化了。这是最容易被忽视的健康指标。
三个"不是日志类型"的类型
这 3 条规则不产生任何事件，但没有它们，前面 21 类就是一堆没法用的字符串。
什么时候用：新设备先接进来占位；第三方系统暂时没有解析器；合规要求"原始留存"。
危险在哪：它让你以为"已经接入了"。实际上你只能按关键词全文搜索，做不了任何结构化关联。
为什么要有：Security 的量级是 System 的几十倍，混在一起查会拖垮检索。
危险在哪：分流键定错了，后面所有关联分析都要返工。分流是"一次定终身"的设计。
为什么它最关键：时间是所有关联分析的坐标系。同一台机器日志里是本地时间、另一台是 UTC、网络设备又是另一种格式——只要有一个没对齐，你算出来的"先 A 后 B"就可能是反的。
三个时间必须分清：事件时间（事情真的发生在那刻）、摄入时间（系统收到它的那刻）、处理时间（规则跑它的那刻）。丢了前两个，只剩第三个，你连"延迟多久"都算不出来。
一条判断标准，可以拿去验收任何新接入的日志
问一句：这条日志能不能回答谁、在什么时候、对什么、做了什么、结果如何？
五个空填不满，就不是"可审计的日志"，只是"存下来的文本"。
怎么把 24 个名词，变成一套能长在自己身上的东西
下面三个工具，是我建议你真正带走的部分。清单会过时，方法不会。
工具一：四问一链
遇到任何一类没见过的日志，不要先问"这是什么"，按顺序问这四个问题，第五步补上链路：
看清产生者，就看清了可信度。应用自述的日志，应用自己可以撒谎。
这一问直接决定"会不会漏"。策略触发的日志，没配就是零。
把枚举值背下来，比背日志名有用得多。比如 LogonType 的 2/3/10。
这一问决定你会不会过度解读。看到 4625 就说"被攻击了"，是典型误读。
第五步 · 补链路：把这一类放回"事件源 → 开关 → 写入口 → 采集 → 清洗 → 检测"六步里，标出它在哪一步可能丢。丢在哪，盲区就在哪。
工具二：五阶认知阶梯（本文自建）
"我算不算懂这类日志"，用这五阶自评。绝大多数人卡在 L2 就以为到顶了。
先划清界限：这套 L0–L4 量的是"你懂到哪一层"，跟卡帕西那套 R1–R4 不是一回事——那套量的是"同一份知识用什么形态交付"。下一节单独讲。
L4 的标志：能设计采集策略、算覆盖率、主动发现盲区——而不是等出事才去翻日志。
L0–L4 是本文自建的认知模型，没有外部标准可对照；分界处的例子只是示范。
一个具体的判断：如果你能说出"4624 里 LogonType=3 是网络登录"，那是 L2。如果你能接着说"所以内网一台机器上突然出现大量 LogonType=3 且账户是普通用户，说明有人在横向移动"，那才是 L3。L3 到 L4 的差别是：L3 会用日志，L4 会造日志。
工具三：卡帕西四级 —— 同一份知识，四种交付形态
上面那个阶梯是竖轴（你懂多深），这一节是横轴（同一个知识，用什么形态递到你手上）。Karpathy 在 2026-10-02 提的这套东西，核心一句话：换输出格式，就是换理解杠杆。模型干重活，人负责理解。四级从低到高：
硬约束：约 900 个批准词、一词只留一义；程序句 ≤20 词、一句一个动作；描述句 ≤25 词、一段 ≤6 句；主动语态；名词串 ≤3 词。
解决什么：文字冗长含糊、一句话塞三件事。
日志审计怎么用：写交接 SOP、值班手册。"首先……然后……同时……"这类句子会被逼成一步一步。
解决什么：线性文字讲不清结构与关系。文字是一条线，读者只能从头读到尾；图是一个平面，眼睛可以自己决定先看哪。
日志审计怎么用：数据流、规则拓扑、一次登录的生命周期、16 类 audit 的先后顺序。
本页对应：第 01 节的全景图、第 05 节的 PAM 重排图，都是 R2。
解决什么：静态内容没法探索。读者可以自己把参数调大，看会发生什么——每往上一阶，读者自己拼凑理解的活儿就少一点，转移到生产端。
日志审计怎么用：就是你现在看的这个页面。漏斗的四个率可以拖，24 类可以筛，LogonType 可以从 0 拉到 11。
本页对应：整站即 R3（单文件、零外链）。
解决什么：需要时间维度上的引导——先讲什么、后讲什么，节奏本身就是信息。这是 Karpathy 最看好的一级，原话是"this is actually starting to work"，注意他加了个"开始"。
日志审计怎么用：新人培训、月度复盘。
代价：必须先有 R1 文字稿当骨架。视频会把错误放大得最厉害，没有文字稿直接做视频，等于把错误镀了金。
这四级有个反作用力，必须一起记
每升一级，格式的说服力在放大，但事实的准确性一点没变。
一段文字写错了，读者会怀疑；一张图画错了，读者会相信；一个能拖动的页面展示了一个错的关系，读者会记住它。
所以规矩是：升级格式之前，先把事实固定在一份文字稿上；每升一级，回到那份文字稿核一次。这也是本页第 10 节台账存在的原因——图越好看，越要说清哪句是图上抄的、哪句是我推的。
配套一条判据：交互只用在"变化本身有解释价值"的地方
这句话是从一个讲 Kubernetes 的四级页面里学来的，很短，但砍得掉一半的交互想法。判断只要一步：把这个交互做成静态的，信息会损失吗？不损失，它就不是解释，是装饰。
本页 5 个交互件，按这条判据过了一遍，结果留在这里：
第一条是关键：探索器算不上"变化有解释价值"，它只是内容太多、一屏放不下。该保留就保留，但要诚实地叫它查阅，不能当成"交互设计"来邀功。把这一条想清楚，页面上就不会出现那种"拖了半天什么也没学到"的滑块。
本页的 R4：把这条主线做成一支片子
四级讲完了，这一级得拿出东西来。下面这支片子讲的是整页的主线——日志不是被采集到的，是被触发出来的。四道门，一次乘法，五个答案。
两轴怎么配：别给 L0 的人做视频
认知层级 × 输出形态，最划算的组合其实很固定：
R4 什么时候真值得做：一是给零基础的人第一次建立整套框架，二是同一套内容要讲给一批人（培训、复盘）。单个概念不值得做视频——那是拿最贵的格式，讲最轻的内容。
工具四：可见性漏斗
这是我认为最值得反复看的一张图。它解释了为什么"我们接了日志"和"我们能看见"之间差着一条鸿沟。
拖动四层滑块，看最终有多少真实事件真正变成你能看到的告警。
每层都只丢"一点点"，乘起来就是灾难。四层各留 90% 已经算理想，结果是 65.6%；现实往往比这更低。
这张图最有用的地方，是把"为什么没查到"从一句玄学，变成了四道可以逐个排查的算术题。发现问题时不要笼统地说"日志不全"，要问是在哪一层丢的：是策略没开（记录率）、Agent 没覆盖这台机器（采集率）、字段没解析出来（解析率），还是规则根本没写（检出率）。
四层之间不是独立事件，实际会相互影响。这里用乘法只是为了建立一个量级直觉，不是严谨的概率模型。默认的 90 / 85 / 70 / 50 是假设值，不是你系统的实测——换成你自己的数，结论可能完全不同（见台账 ④）。
顺手带走：日志的"价值密度"
同样是日志，有的每天百万行没一条有用，有的一年出现三次、每次都要拉警报。下面把 21 类事实型日志按"体积"和"证据力"摆开。
体积与证据力是经验评分，不是实测数据（见台账 ②）；象限分界是示意。
四个象限对应四种处理策略：左上全部保留并重点告警；右上是检测工程的主战场，要写规则、要做基线；右下必须降采样或只留聚合值，否则存储先崩；左下只在取证时按需拉取。
专业和不专业的分水岭，往往就在这张图上：不专业的人想"全部采集、全部保留"，三个月后存储告警；专业的人会先问"这条日志进哪个象限"，再决定保留策略。
从"认得 24 个名字"到"能设计采集方案"
按 30 / 90 / 180 天三段走。每一段都以"能做成一件具体的事"为毕业标准，不以"看完多少资料"为标准。
做三件事：
1. 用四问给自己讲一遍全部 24 类，讲不通的打标记；
2. 在真实环境里找到每一类的第一条原始样本，存成自己的样本库；
3. 把 Windows 常用事件 ID 和 audit 记录类型各抄一遍（手抄，不复制）。
毕业标准：给你一条陌生日志，30 秒内说出它属于哪一步、开关是什么。
做三件事：
1. 自己造三个场景：一次失败爆破、一次计划任务持久化、一次异常提权，然后只用日志把它们还原出来；
2. 练习跨源关联：用 Security 的 4624 找"谁来了"，用 Sysmon 找"他干了什么"，拼成一条时间线；
3. 把 audit 的 6 条记录合并成一条事件，手工做一遍，理解合并逻辑。
毕业标准：拿到一个时间点，能说清"这五分钟里这台机器发生了什么"。
做三件事：
1. 给一个业务系统做接入方案：采什么、不采什么、保留多久、怎么分流；
2. 用可见性漏斗给自己的方案算一遍覆盖率，写出四层的薄弱点；
3. 定期检查"审计日志大类"的增长趋势，把它当成规则集健康度的仪表盘。
毕业标准：能回答"这套方案看不见什么"，而不是只回答"这套方案能看见什么"。
步骤：
1. 先确认规则存在：auditctl -l | head；
2. 执行一次 sudo -k; sudo id（强制重新认证）；
3. 在 /var/log/audit/audit.log 里按时间找到这批记录；
4. 把它们按 msg=audit(...:N) 分组，数一数一次 sudo 产生了几个 id；
5. 用一句话写出来：谁、从哪、在什么时间、做了什么、结果如何。
验证：能写出这句话就算成功。最可能的失败：打开日志发现是空的——那就是规则没装，回到第 1 步。
日常可以做的四个小练习
一、每次看到新日志，先不看文档，自己猜它的"开关"是什么，然后去验证。
二、每周挑一条告警，反问：这条告警如果误报，最可能误在哪一层？
三、每月看一眼"兜底类"日志占比，涨了就说明规则集落后了。
四、把每次"查不到"的事故记下来，标注断在哪一步。三个月后你会发现断点高度集中。
十道题，先选再揭晓
分三类：回忆（记没记住）、应用（会不会用）、迁移（换个场景还灵不灵）。答错不丢人，答错才知道该补哪一层。
哪些是图上的，哪些是我推的
讲解类内容最大的风险是"越好看越可信"。这里把三类信息分开列清楚，方便你核。
24 条规则名称，与截图完全一致（含"用户名计帐"这一写法）。
规则拓扑中的 JSON格式化 / 数据转发，以及关联任务名称（终端心跳/资源/任务、日审windows数据接入、日审linux-cron数据接入）。
Linux audit 记录类型（USER_AUTH、USER_ACCT、CRED_ACQ、USER_START、CRED_REFR、USER_END、USER_LOGIN、SERVICE_START/STOP、PATH、CWD、SYSCALL、EXECVE、PROCTITLE、AVC）；auditd 链路与配置路径；cron 的日志格式。
② 价值密度散点图中的"体积"与"证据力"评分，是经验判断，不是实测数据。
③ 触发四型（策略/事件/探针/管道）的分类框架，是本文提出的认知工具，非标准术语。
④ 可见性漏斗的乘法模型，是量级直觉，不是概率模型。
界面底部显示"共 22 条"，与图中可数的 24 条叶子规则不一致，可能是分页或统计口径差异。
"用户名计帐"疑为"记账"的异体写法，本文沿用截图原文。
本文是学习材料，不是合规审计意见，也不能替代针对你所在环境的实际核查。事件 ID、记录类型的含义会随系统版本变化，落地前请以目标环境的官方文档与实测样本为准。
图有说服力，事实以台账为准。越漂亮的图，越容易让人忘记它只是对事实的一次翻译。
日志类型专题学习 · 依据自研日志审计系统首批接入清单（6 组 24 类）· 单文件自包含，无任何外部依赖