feat(file): 海量日志采集优化：有界读取、批处理与可选 eBPF · Pull Request !1 · deepflowio/vector

## 当前范围

本 PR 基于 Vector **v0.43.1**，包含 L0～L3 文件采集优化、独立 eBPF 探针、发行包集成，以及后续兼容性和重启恢复修复。功能实现、九场景台架对比、限定平台安装态验证、DeepFlow 实验环境功能联调及两场景集成性能确认已完成；**不等同于所有场景全面降载、正式发布或银行生产验收完成**。

当前源提交：`c7343a69e13de527071a6a5fb0fba0157a8831c6`。本 PR 不升级 Vector，也不包含 DeepFlow Agent 仓库的改动。

## 复现步骤与问题背景

一个业务进程按业务场景写入数千至七万个日志文件，既有“海量冷文件、少量活跃”的情况，也有“数千文件同时写入”的情况。社区 file source 的文件库存遍历、常驻读取器和空读检查会带来 CPU、内存、文件句柄和系统调用开销。

优化目标是按文件活动驱动读取、限制同时打开的日志文件，并降低多热文件的排队时延。优化不能以日志缺失换取低资源占用，也不能将“更低时延”直接解释成“更低 CPU”。

## 原因和解决方案

### 采集模式

| 对照名称 | 文件活动来源 | 读取与调度方式 | 独立探针 |
|---|---|---|---|
| 社区原版 | 社区原有轮询路径 | 原始 file source | 不需要 |
| L1 | 本 PR 引入的 inotify 通知 | 有界读取器、逐文件调度 | 不需要 |
| L2 | eBPF 写入提示，inotify 管理创建、重命名、删除等生命周期 | L1 的有界读取器与逐文件调度 | 需要 |
| L3-1 | eBPF 写入提示＋inotify 生命周期 | 有界读取器＋有界批处理 | 需要 |
| L3-2 | inotify 通知 | 有界读取器＋有界批处理 | 不需要 |

这里的 **L1/inotify 不是“社区原生 inotify”**。L3-1 与 L3-2 共用一套产品代码，通过配置选择通知后端，不复制两套实现。

### 主要修改

- **有界读取与活动队列（L0/L1）：** 按需打开文件，以 LRU 控制读取器数量；维护文件身份、读取位置、检查点与确认进度，处理轮转、截断、删除、发现异常和恢复。
- **独立 eBPF 探针（L2）：** 使用 libbpf/CO-RE 发送写入与截断活动提示，Vector 仍从文件读取正文。探针不依赖、不链接、不加载 DeepFlow Agent；提供预检、pid-file 跟踪、版本化 Unix 套接字协议和降级诊断。保留生命周期 inotify 及周期性全量核对，避免将提示当作可靠日志传输。
- **有界批处理（L3 共用）：** 活跃文件去重排队，一轮读取多个文件，按文件访问次数、字节、事件数和时间预算限制批次；未读完的文件公平重排，非空结果及时发送。低负载不为凑批等待；复用读取缓冲和逻辑位置，补齐 eBPF 尾部复查、半行竞态与扫描期限处理。
- **发行交付：** 增加独立探针产物清单、archive/DEB/RPM 包、systemd 模板、安装路径与运行库检查、配置保护和跨包哈希校验；发行工作流约束 Vector 与 Probe 使用同一源码引用。
- **现有能力兼容（`955dfbad6c`）：** 同步 Agent 已有的 Prometheus `scrape_delay` 补丁，保留 `none`、`auto`、固定延迟配置，避免更新 Vector 依赖时回退既有能力；不是新的日志优化算法。
- **重启恢复修复（`c7343a69e1`）：** 处理进程退出后残留的 eBPF 接收套接字。Linux 接收器持有路径锁，仅在受控目录内安全回收本用户拥有、已无接收器的旧 socket；保护活动接收器、普通文件和符号链接，绑定失败输出明确错误并继续兜底采集。无需修改宿主进程的全局退出逻辑。

## 影响范围与配置

- 核心实现及直接 Rust 回归位于 `lib/file-source/`、`src/sources/file.rs` 和相关内部指标；现有 Kubernetes 调用点保持原行为。探针产品源码位于 `scripts/file-activity-probe/`。
- 外部黑盒、性能、可靠性和安装态验证工具统一位于 `scripts/file-source-validation/`，不参与产品运行；源码、方案、验证工具与结论按阶段拆分提交。详见下方文件归属索引。
- **默认不启用优化路径。** 保留现有 `l0_prototype` 配置名，通知后端和调度方式可分别配置；省略 `scheduler_mode` 仍为 `single_file`。关闭优化可回到当前二进制的原文件采集路径。
- `max_open_files` 是可配置的日志读取器上限，不是文件库存上限，**没有自动自适应**。通知、输出和锁文件等其他句柄不计入此上限；每个启用 eBPF 提示的 source 新增 1 个路径锁 FD。
- 套接字应位于运行用户拥有、组和其他用户不可写的专用目录。真正的路径冲突解除后需重载 source 或重启，不包含后台自动重试；不要在运行期间删除锁文件。
- 保留 source ID、`data_dir` 和检查点；文件指纹策略迁移需单独验证。`multiline`、`encoding` 等配置仍受现有优化路径校验限制，不宣称支持任意社区 file source 配置组合。
- 正常测试按唯一 ID 检查无缺失、无重复；断连或崩溃恢复仍按**至少一次**语义，可能出现可归因的重放。提示与全量核对不能恢复采集前已被截断或覆盖的正文；缺少 V2 截断提示时不承诺快速 `copytruncate` 的严格即时语义。

## 验证方案与结果

### 1. 性能对比：九场景、五种实现

统一对比社区原版、L1、L2、L3-1、L3-2；场景涵盖单文件、1,000/3,000 个热文件，以及同样负载叠加至 70,000 个文件的库存。单业务进程使用 `write + flush`，不逐行 `fsync`。

以下摘录 **L3-2 相对社区原版**的变化，负值表示降低，正值表示增加；五种实现的绝对值、P99、FD、调用分项和完整性见[九场景完整性能报告](https://gitee.com/deepflowio/vector/blob/c7343a69e13de527071a6a5fb0fba0157a8831c6/docs/vector-stage-performance-matrix-2026-09-10.md)。

| 场景 | 文件总数 / 热文件数 | 总速率（条/秒） | CPU | 峰值 RSS | 十类系统调用合计 |
|---|---:|---:|---:|---:|---:|
| S1 | 70,000 / 50 | 250 | −92.86% | −34.57% | −98.21% |
| S2 | 1,000 / 1,000 | 250 | −80.64% | +0.19% | −96.09% |
| S6 | 70,000 / 1,000 | 250 | −91.45% | −37.68% | −97.33% |
| S3 | 1 / 1 | 15,000 | +17.85% | −13.14% | +63.65% |
| S7 | 70,000 / 1 | 15,000 | −43.05% | −54.29% | −57.48% |
| S4 | 3,000 / 3,000 | 3,000 | −41.92% | −25.81% | −67.96% |
| S8 | 70,000 / 3,000 | 3,000 | −67.54% | −45.43% | −78.98% |
| S5 | 3,000 / 3,000 | 15,000 | +60.37% | −41.97% | +216.69% |
| S9 | 70,000 / 3,000 | 15,000 | −17.79% | −60.46% | −22.76% |

测量口径：

- 使用冻结的 v0.43.1 工件、相同输出链路和 TSC 时钟；空闲预热、写入、停写观察各 30 秒。CPU 为写入及后续观察期累计核秒，RSS 为采样峰值，CPU/RSS/P99 为三轮无跟踪结果的中位数；P99 包含起写阶段，不代表长期稳态。
- 系统调用是**独立单轮、有效写入期 20 秒、十类调用**的合计，不是所有系统调用，也不是三轮中位数或每条日志成本；没有用加跟踪后的 CPU 作为正式性能结果。
- S7 社区版使用同一社区二进制，将每文件读取预算从 2 KiB 调到 1 MiB 后完成三轮比较；其他场景保持社区默认预算。所有有效轮次 FD 额度为 131,072。不能把默认未收敛轮混入性能排名，也不能将 S3/S7 解释为社区配置完全相同。
- eBPF 模式计入 Vector 与独立 Probe 的进程资源合计；RSS 不等于独占物理内存，该口径也不覆盖全部内核及业务写入线程承担的探针开销。
- 有效正常轮按源日志、输出和接收账本逐条审计，完整且无重复。上述数据沿用已验收的九场景测试；后续兼容性和套接字修复做的是定向功能回归，**没有冒称重新跑过最新提交的全部性能矩阵**。

结论：海量文件、部分活跃时优先验证 L3-2；多热文件下批处理明显改善排队时延。S3/S5 的 CPU 和调用数仍高于社区版，因此“所有规模都不劣于社区”尚未实现。eBPF 是可选能力，不保证在 L1 或 L3-2 基础上继续降载；旧描述中的约 40%～50% 分项调用降幅不再作为当前五实现对比的总体结论。

### 2. 单元回归、构建与发行包

| 验证项 | 已完成结果与范围 |
|---|---|
| L3 共享实现整理时的回归 | `file-source` 115 项、file source 集成 72 项、内部指标 4 项，以及格式和两层 Clippy 通过；属于对应历史批次 |
| 最新套接字修复 | 新用例先在旧实现复现 `AddrInUse`；修复版 `file-source` 126/126、额外并发恢复 30/30、格式检查通过 |
| Agent 依赖与兼容回归 | 4 处 Vector 引用及 22 个同源包锁定当前提交；配置/组件测试 7/7，涵盖四模式透传、默认关闭及 `scrape_delay` 兼容；1 项依赖真实 K8s serviceaccount 的既有测试按计划过滤，未计为通过 |
| Agent 构建与测试镜像 | 实际依赖功能组合的 Release 构建及 amd64 测试镜像成功；源码身份、工具、运行库、镜像内外二进制一致性与镜像导出 5/5 检查通过 |
| archive/DEB/RPM 安装态 | 已有指定最小功能包的真实构建、安装、配置保护、升级、回退及卸载验证；Rocky 9.7 节点连续账本 800/800、无缺失/重复。DEB 在 Ubuntu 24.04 容器验证包管理流程，不冒称已实启 systemd 服务 |

发行包验收基线早于最后两项兼容/重启修复；含最新修复的 Agent 测试镜像已重新生成，但不能把旧独立包当作当前提交的新发行包，也不能将 Agent 功能组合构建视为独立 Vector 全默认功能正式发布构建。

### 3. DeepFlow 实际链路与重启恢复

已在 Linux/amd64 实验环境完成“控制器下发独立采集组配置 → Agent 内嵌 Vector 读取 → Agent 日志入口 → DeepFlow 入库 → 查询逐条核对”的链路，不再处于“等待控制器开启”的状态。本 PR 只修改 Vector；Agent 依赖集成在另一工作树验证，尚未提交到 DeepFlow 仓库。

重启恢复定向清单 **7/7 通过**。同一 writer 持续打开 4 个日志文件，日志读取器上限 2，保持 source ID、检查点与文件身份，各阶段追加 200 个唯一 ID：

| 阶段 | 本阶段入库 | 累计入库 | 验证内容 |
|---|---:|---:|---|
| L2 初启 | 200/200 | 200 | 接收器与提示正常 |
| L2 真实重启 | 200/200 | 400 | 不手删残留 socket，自动恢复接收，检查点续采 |
| L3-1 热切换 | 200/200 | 600 | Agent PID 不变，有界批处理正常 |
| L3-1 真实重启 | 200/200 | 800 | 再次自动恢复接收器，无重读重复 |
| Probe 独立重启 | 200/200 | 1,000 | Agent PID 不变，探针重新连接 |
| 普通文件占址 | 200/200 | 1,200 | 文件内容及 inode 不变，明确错误，兜底扫描完成采集 |
| 恢复正确路径 | 200/200 | 1,400 | 接收器和 eBPF 提示重新可用 |

- 正常提示阶段将全量核对周期设为 3,600 秒，在 source 就绪后向已有文件续写，单阶段观察小于 120 秒；同时确认 socket 实际可连接、进程持锁及 Probe 成功发送，排除只看“数据完整”而由定期扫描掩盖提示故障。普通文件冲突阶段改为 2 秒兜底且不启动 Probe。
- 6 个启用 Probe 的阶段成功发送合计 30 个活动报文，发送失败、环形缓冲区失败均为 0；报文数不是日志条数。
- 最终源文件与入库结果 **1,400 个唯一 ID 逐条一致，零缺失、零重复、零意外值**；恢复原环境后再次查询仍一致。测试结束恢复原二进制、配置、组归属及停止状态，原始账本、配置、日志和产物已独立归档。
- 现场使用的是同次镜像构建对应的 Agent 二进制。L2 初启使用首批修复产物，其后使用补齐版本元数据的最终产物，两者 Vector 源码均为当前提交；没有替换控制器节点的 Server/Agent 镜像，也未把本次小规模功能验证作为生产性能结果。

### 4. DeepFlow 实际链路性能确认（两个场景）

在实际“日志文件 → Agent 内嵌 Vector → Agent 日志入口 → DeepFlow 入库 → Querier 查询”链路中，比较原依赖 Agent、L3-1、L3-2。Agent 源码基准均为 `cb547fe1015ffec39cbcd0eb74d603666dd2aedd`；原依赖为 `v0.43.1-df-patch.1`（`868dd048`，file 采集代码与社区 v0.43.1 相同），优化依赖为本 PR 当前提交 `c7343a69e1`。这不是独立 Vector 输出到丢弃端的测试，也不是仅在同一优化二进制上关闭开关作为基线。

测试方法与统计口径：

- Linux/amd64、4 vCPU、TSC，实际运行标准 Release Agent 二进制，通过控制器下发配置；保持服务端镜像不变。为隔离日志负载，关闭 Agent 的其他 eBPF/网卡抓包采集，不代表所有采集功能同时满载。
- 两个场景、三种实现各一轮。每组独立目录、检查点和进程；Vector 就绪后准备 30 秒，单进程连续写入 90 秒，总速率均为 250 条/秒，每条 160 字节，逐行 `write + flush`，无逐行 `fsync`；停写后继续等待采集及入库完成。
- 稳态 CPU 和采集端 P99 取写入后 30～90 秒。CPU 的 100% 表示一个核，包括 Agent 主进程、watchdog 及可选 Probe；RSS 是采样期间同一时刻这些进程内存合计的峰值，不是 PSS 或全机内核成本。
- 各组均使用相同本机 HTTP JSON 输出，`batch.timeout_secs=1`；NOFILE=131072。优化路径 `max_open_files` 分别为 S1=50、S2=256，兜底扫描周期均为 60 秒；日志 FD 是停写后快照。
- 本轮正式资源测试无系统调用跟踪、无抓包。与上方独立九场景的输出链路、采样窗口不同，不能拼接原始值或混用降幅。

**S1：70,000 个文件，50 个热文件，总计 250 条/秒。**

| 实现 | 稳态 CPU（单核%） | CPU 相对原依赖降幅 | RSS 峰值（MiB） | 日志 FD | 稳态采集端 P99（ms） |
|---|---:|---:|---:|---:|---:|
| 原依赖 Agent | 110.53 | — | 497.12 | 70,000 | 1340.773 |
| L3-1（eBPF＋有界批处理） | 10.17 | 90.8% | 257.25 | 50 | 6.505 |
| L3-2（inotify＋有界批处理） | 9.61 | 91.3% | 222.92 | 50 | 45.262 |

**S2：1,000 个文件全部低速写入，总计 250 条/秒。**

| 实现 | 稳态 CPU（单核%） | CPU 相对原依赖降幅 | RSS 峰值（MiB） | 日志 FD | 稳态采集端 P99（ms） |
|---|---:|---:|---:|---:|---:|
| 原依赖 Agent | 66.49 | — | 187.04 | 1,000 | 14.941 |
| L3-1（eBPF＋有界批处理） | 10.07 | 84.9% | 211.06 | 256 | 5.633 |
| L3-2（inotify＋有界批处理） | 9.72 | 85.4% | 182.27 | 256 | 9.556 |

结果与边界：

- **实际集成收益成立：** 两个场景 CPU 分别降低约 91% 和 85%。S1 的 L3-1/L3-2 内存分别降低 48.3%/55.2%；S2 的 L3-2 内存基本持平（实测降低 2.5%），L3-1 计入约 34.6 MiB 的独立 Probe 后内存增加 12.8%，不是所有指标都下降。
- **完整性：** 六组各 22,500 条、合计 135,000 条全部入库；唯一序号和按序正文 SHA256 与源文件一致，无缺失、无重复；结束后再次查询计数仍一致。
- **P99 口径：** 表中仅为“日志写入 → Vector 读出并生成事件”，不包含后续输出批处理、传输和服务端入库。没有测得 DeepFlow 接收端或入库 P99，也没有本批次系统调用数量；停写到全部可查询约 8～14.5 秒的观测值不能称作 P99。
- 本次是两个场景的单轮方向性确认，不替代九场景对比、密集高速负载、长期稳定性或银行生产验收，也不据单轮微小差异宣称稳定排名。测试结束已恢复原环境并归档证据。

## 尚未覆盖与后续交付

1. **正式发布：** Agent 依赖改动的提交/合并、正式 CI 镜像发布及实际容器部署验收尚未完成。现有测试镜像使用公开同版本 openEuler 基础镜像，不是正式私有 CI 发布物；如交付独立 Vector 包，需从最终提交重新生成并验收。
2. **平台兼容：** 当前 Probe 面向 Linux x86_64，已验收 Rocky 9.7/内核 5.14，用户态要求 glibc ≥ 2.34、libbpf ABI ≥ 1.0，并依赖 BTF、hook 和权限预检。旧发行版、其他内核与架构不在当前已验证范围；不能因工作流存在就声称远端完整发布矩阵已通过。
3. **生产验收：** 实际客户的长时间负载、轮转/截断方式、下游背压和资源预算仍需灰度；九场景短测、两场景集成确认与功能联调不能替代这一阶段。
4. **性能与自动化边界：** S3/S5 的资源回退已明确保留；没有自动识别负载并切回社区路径、也没有自适应 FD 上限。它们是后续方案选择，不是已交付能力。

## 涉及分支与审阅入口

- 源分支：`codex/vector-l0-prototype`；目标分支：`prepare-v0.43.1`，保持 v0.43.1 基线，不直接面向其他版本的 `master`。
- [产品代码、直接测试与外部验证工具归属](https://gitee.com/deepflowio/vector/blob/c7343a69e13de527071a6a5fb0fba0157a8831c6/docs/file-source/README.md)
- [L3-1 / L3-2 实施与交付计划](https://gitee.com/deepflowio/vector/blob/c7343a69e13de527071a6a5fb0fba0157a8831c6/docs/file-source/plans/2026-09-03-vector-file-source-dense-hot-scheduling.md)
- [L3-2 配置、回退与适用范围](https://gitee.com/deepflowio/vector/blob/c7343a69e13de527071a6a5fb0fba0157a8831c6/docs/vector-l3-2-inotify-bounded-batching.md)
- [独立 Probe 构建、兼容与套接字恢复说明](https://gitee.com/deepflowio/vector/blob/c7343a69e13de527071a6a5fb0fba0157a8831c6/scripts/file-activity-probe/README.md)
- [发行包与安装态验收报告](https://gitee.com/deepflowio/vector/blob/c7343a69e13de527071a6a5fb0fba0157a8831c6/docs/vector-file-source-package-validation-2026-09-22.md)

上述报告按各自批次保留原测试身份和结果；其中较早文档的“等待联调”等历史状态，由本 PR 的最新实际链路功能与性能验证说明补充，不表示重新执行了旧性能或发行测试。

## 检查项

- [x] 依赖与兼容性已说明：文件通知依赖、Probe 运行库要求，以及 Agent 需锁定本分支提交。
- [x] 共性问题已覆盖：直接退出留下 socket 的恢复，不依赖特定宿主执行 Rust 析构。
- [x] 编译通过：已声明功能集的 Vector/Probe 包及 Agent 实际依赖组合；不是任意平台和全功能发布矩阵。
- [x] 单元与定向现场验证通过：批次、数量和唯一过滤项见上文。
- [x] 正常测试完整性通过；故障恢复保持至少一次语义，性能回退与未验证范围已披露。
- [x] DeepFlow 两场景集成性能确认：六组数据完整，CPU/RSS/FD及采集端P99口径与边界见上文。
- [ ] 正式 CI 发布、目标环境兼容矩阵及客户长期灰度验收。

类型	指派人员	状态
审查	taloric	进行中 (0/1人)
测试	taloric	进行中 (0/1人)

deepflowio / vector .gitee-modal { width: 500px !important; }

搜索帮助

deepflowio / vector