结论先行：采集端能不能装，卡点常常不在功能，而在它要以什么身份运行。容器以特权模式启动、进程以 root 起、挂载宿主机目录——这三条在多数企业的安全基线里是明令禁止的，而且禁得有道理：一旦观测工具本身被利用，它就是一个现成的攻击入口。可行的做法是先定运行身份，再谈采什么；身份定不下来，谈采集项清单没有意义。
安全基线卡的不是功能，是身份
安全基线的评审通常不看你采了哪些指标，只看三件事：这个进程以什么用户运行、这个容器声明了哪些特权、它挂载了哪些宿主机路径。三项里任一项触线，申请就会被退回来补材料，而补材料这件事往往要排到下一个评审周期。
把这件事当成流程障碍是误解。一个以高权限运行、又能读到全部业务数据的采集端，实际上把观测面和攻击面重叠在了一起。所以稳妥的顺序是：先确认能不能用受限身份把大部分数据采到，再针对拿不到的那一小部分单独设计，而不是反过来先按最高权限装上去、再去做豁免审批。
三条身份路径，各自的前提与上限
| 运行身份 | 前提条件 | 能采到什么 | 上限 |
|---|---|---|---|
| 普通用户加只读授权 | 目标进程的可读范围对采集用户放开，或通过用户组授权 | 应用日志、接口与调用链、进程级性能、慢调用堆栈 | 需要内核态信息的能力（部分网络抓包、内核级指标）拿不到 |
| 受限用户加容器无特权注入 | 编排侧支持以不带特权的挂载方式下发采集组件 | 容器资源用量、Pod 级指标、跨服务的调用链 | 容器内受限路径读不到，宿主层部分文件不可见 |
| 高权限或特权容器 | 安全基线豁免审批，且通常需要长期挂账 | 全部，含内核态指标与全流量抓包 | 每次升级与合规检查都要重新解释一遍 |
表格的读法是：前两条路径能覆盖日常排障所需要的大部分数据，第三条换来的主要是内核态与全流量那一小块。如果这一小块不是当前排障的主要手段，就没必要为了它整体拔高权限。
无特权时，缺的那部分怎么补
- 内核态与流量类数据走旁路。不装在被观测的机器上，改用网络侧镜像、独立采集节点的方式取，业务机器上的进程保持最低权限。
- 把拿不到的部分写清楚，而不是含混过去。验收表里对每一项标「覆盖」「部分覆盖」「不覆盖」，不覆盖的写明替代手段。含混的表述在事后复盘时会变成争议点。
- 补不到又不影响主流程的，就明确放弃。一个诚实的缺口，比一个假装完整的覆盖清单更有用。
怎么验，三个动作
- 用受限身份在测试环境跑一轮完整的采集，把日志里出现「权限不足」的采集项逐条列出来，这张清单才是真实的覆盖范围。
- 看采集进程实际以什么用户起来的、容器声明里有没有特权字段与宿主机路径挂载。声明的和实际跑起来的经常不一致，以实际为准。
- 抽一条真实业务请求走一遍，确认受限身份下调用链没有断点。断点通常出现在跨进程或跨容器的那一跳。
为什么这件事要放在采购前谈
运行身份属于部署架构的一部分。装完再改身份，意味着重装、重排变更窗口、重做一轮灰度对照，前面攒的基线数据基本作废。更麻烦的是审批链条：基线评审、变更审批、安全评估通常是三拨人，改身份等于三处重走。把身份定在采购与设计阶段，成本最低。
本文只谈采集端以什么身份运行、以及受限身份下哪些采集项拿不到；不谈采集端占多少处理器与内存，不谈谁能关掉它、关掉要不要留痕，也不谈同一套采集端在不同开发语言上的采集深度差异。
深圳市奇摩计算机有限公司在做接入准备时，会把「运行身份」和「采集项清单」放在同一张表上逐行核对，先确认哪些项在受限身份下拿得到、哪些要换旁路，再排部署窗口，避免装到一半退回重来。如果你正在为一份被退回的接入申请补材料，可以预约咨询，我们帮你把这张表一起填。