规模与容量

本页介绍 Hilt EDR macOS 采集器的资源占用情况:单台 Mac 会生成多少事件、System Extension 与转发器消耗多少 CPU、内存和网络带宽,以及服务端采集器层如何随着 macOS 主机数量的增加而扩展。

每个端点的事件速率

macOS 采集器订阅 12 种 Apple Endpoint Security (ES) 事件类型(大多为 NOTIFY; 少数为用于 Agent 自我保护的 AUTH),外加一个每条流的网络数据源,并将它们以 JSON 行的 形式输出,由转发器发送到 Hilt 的 edr-collector。数据量极大程度上由 file_open 主导 ——单台 macOS 主机通常每分钟发出数千条 ES 事件,其中绝大多数是文件打开。Apple 自身的框架指南也指出,macOS 每台主机每分钟会发出数千条 ES 事件,我们的实时数据也印证了这一点。 下表展示了一台已注册的开发者 Mac(Zin's MacBook Pro,Apple Silicon)的一个代表性 15 分钟窗口,已归一化为每分钟速率。file_open 约占全部遥测的 95% 以上。 为何 file_open 会占主导。 进程对文件系统的每一次访问——动态库加载、字体与缓存读取、 plist 查找、IDE 索引、Spotlight、包管理器——都会表现为一次打开/创建。一台繁忙的开发者机器 在编译或运行容器时,file_open 会在短时间内飙升至每分钟数万条。这正是采集器在任何数据 离开主机之前先施加积极的用户态过滤的原因(参见 Agent 过滤)。 低频事件才是高价值信号。 exec 携带 argv、签名标识(signing_id、team_id、 cdhash)以及 code_signature 信任判定;btm_add 表示注册了一个启动 agent/守护进程 或登录项(持久化);xattr_set/xattr_delete 是 Gatekeeper 隔离标记篡改; signal 是一次终止尝试。这些事件在数据量上几乎不占份额,却正是检测工程师会去查询的事件。 完整字段清单参见 事件数据模型。

事件量分布

由于分布如此偏斜,容量规划本质上就是一个 file_open 问题。一台 Mac 发送的事件中,大约 每 20 条就有 19 条是文件打开;其余所有事件加起来——进程、网络、持久化、设备、signal、 xattr——只占百分之几。 一个实际的推论:调优 file_open 过滤器是控制端点 CPU 和摄取带宽的单一最高杠杆手段。 其他事件族即使全部启用,也不会实质性地拨动数据量的指针。

System Extension 的 CPU 与内存占用

采集器以经过公证的 macOS 应用 EDRApp.app 形式发布,其中内嵌两个在用户态运行的 Apple System Extension(不存在内核扩展):

• ESensor —— Endpoint Security system extension。这是订阅上述 ES 事件的遥测传感器。 bundle id 为 Hilt.EDRApp.ESensor。
• NetFilter —— 一个 NetworkExtension 内容过滤 system extension,提供每条流的网络归因。 bundle id 为 Hilt.EDRApp.NetFilter。

一个小型的转发器 LaunchDaemon 通过出站 HTTPS 发送 JSON 事件流。由于这些扩展运行在 Apple 的现代框架之上(无 kext、无需 csrutil disable、SIP 保持启用),其占用与普通的加固 用户态进程相当。 关于占用的说明。

• macOS 在扩展的消息队列上同步投递 ES 事件。传感器的任务是快速分类、过滤并入队,从而绝不 成为繁忙机器的瓶颈。内存主要被每进程缓存和签名标识缓存占用,它们让辅助进程可以折叠归并到 其所属应用(例如 Google Chrome Helper → Google Chrome),并传播 responsible_pid / session_id。
• 上述数值针对的是仅 NOTIFY 的遥测模式。Agent 会将少数事件订阅为 AUTH (signal、unlink、rename),纯粹用于自我保护(它可以拒绝对自身的篡改);由于这些 事件罕见,AUTH 处理增加的稳态开销可以忽略,但它确实会让传感器对这些特定操作保持在同步决策 路径上。
• CPU 随未过滤的 file_open 速率而扩展,而非随发送数据量——昂贵的工作在于检视这股洪流。 过滤发生在序列化之前,因此收紧过滤器可以同时降低 CPU 和带宽。

网络带宽

转发器以批量、压缩、出站的 HTTPS 将事件发送到所配置的 Hilt 摄取端点。不存在入站套接字, 也不存在 phone-home——只有指向那一个已配置端点的出站 HTTPS(参见 网络与安全)。 带宽同样是过滤之后 file_open 数据量的函数。每个事件都是一行紧凑的 JSON;占主导的 file_open 记录很小(路径、标志、行为主体、签名标识、应用归因)。批处理与压缩正是让这股洪流 在网络上变得可承受的关键。 是什么推高了网络成本。

• 压缩在此类负载上通常能达到很高的压缩比,因为事件 JSON 高度重复(相同的路径、bundle id 和签名标识反复出现),因此压缩后的出站流量只是原始行数据量的一小部分。
• 批处理摊薄了 TLS 与请求开销:事件被累积后一并刷出,而不是每个事件一次请求,这使得连接 开销在数据量上升时保持平稳。
• 过滤优先——由于积极的用户态 file_open 过滤在转发器看到任何事件之前就已运行,网络上的 字节反映的是过滤后的数据量,而非原始的 ES 洪流。

对于典型工作站主机群,一个实际的规划数值是每台主机每分钟个位数 MB,并在构建或大文件操作期间 出现短暂高于此值的突发。在一个工作日的时间尺度上,这完全处于正常的企业出站流量范围内,除了出站 443 之外无需任何特殊的网络配置。

采集器层如何随主机数量扩展

在服务端,macOS 主机流经与 Linux 相同的管道,并配以 macOS 专属的富化平台: 扩展特性。

• 决定该层规模的是聚合数据量,而不仅仅是主机数量。 一个粗略的主机群估算方法:将主机数量乘以 每台主机的稳态速率(混合工作站主机群可用 ~5,000–15,000 事件/min,开发者密集型群体则要高得多), 得到用于 Kafka 分区和富化消费者容量规划的聚合事件数/秒。仅一台参考 Mac 在活跃的开发者使用期间, 就在 15 分钟内产生了约 844,000 行(约 940/秒)——因此重度主机在估算中占主导。
• 优先为 file_open 路径规划容量。 由于分布如此偏斜,dag.endpoint.file 分区以及以文件 事件为键的 macOS 富化消费者,是最先饱和的组件。exec/net 路径相对轻量。
• 出站流量受压缩约束。 服务端摄取带宽随上文压缩后的每台主机出站流量线性扩展;macOS 主机在 采集器上不存在扇出放大。
• 每台主机的富化成本是均匀的。 每个 macOS 事件都携带相同的代码签名与应用归因富化,因此富化 CPU 干净地跟随聚合事件速率——不存在主机特定的富化热点。

关于与 Linux 管道共享的控制平面与基础设施容量规划细节,参见 端到端数据流。

调优杠杆

当主机群的数据量或出站流量高于预算时,可用的杠杆按杠杆效应从大到小排列如下:

1. 收紧 file_open 过滤。 这占数据量的 95% 以上;排除高频变动的缓存和构建目录,是对端点 CPU 和出站流量同时的单一最大幅度削减。参见 Agent 过滤。
2. 限定进程事件的范围。 exec/fork 本已是低数据量;大多数主机群无需采取任何措施,但它们是 每字节信号价值最高的事件,通常应保持开启。
3. 保留安全长尾事件的开启状态。 btm_add、xattr_set/xattr_delete、mount 和 signal 都是事件驱动且罕见的——它们增加的数据量可忽略,却提供了持久化、隔离标记篡改、可移动 介质和终止尝试的可见性。

本采集器不做什么

与 macOS 采集器设计的其余部分保持一致:

• 不对 System Extension 施加设备端资源上限。 扩展的生命周期由 Apple 管理;采集器不会像 Linux VM 安装程序对 systemd 单元那样,对 ES 扩展施加硬性的 CPUQuota/MemoryMax。设备端 资源上限不属于早期访问模型。
• 不存在入站侦听器。 带宽严格为出站、批量、压缩的 HTTPS,指向那一个已配置的摄取端点——不存在 需要规划容量的入站套接字,也不存在 phone-home。
• 不进行原始数据包捕获。 网络带宽反映的是 net_flow 连接元数据(目标、端口、字节数、 bundle id),而非载荷——因此网络遥测只为数据量增加约 1–2%,绝不会带来数据包捕获规模的负载。
• 不发送文件内容。 file_open 是元数据(路径、标志、行为主体、签名标识);采集器从不读取或 发送文件内容,因此文件数据量受事件数量约束,而非文件大小。