出事的那台机器是跑订单接口的应用服务器，8 核 16G，平时 CPU 在两成上下晃。有一天监控开始报 CPU 持续 90% 以上，业务量没什么变化，接口响应时间从 30 毫秒涨到 400 多毫秒。运维上去 top 了一圈，看到一个进程名叫得很像系统组件的东西占着绝大部分 CPU，杀掉之后两分钟又起来了。再往下查才在 crontab 里发现一条计划任务，每隔几分钟拉一次远程脚本并本地执行，跑的就是挖矿。
真正让人后背发凉的是后面这一步：翻认证日志，三周前有一次来自陌生 IP 的成功登录，时间凌晨三点半，登录地点和任何一位值班同事都对不上。这条记录一直在日志里躺着，主机上也一直在写，只是从来没有人去看。三周，足够对方把这台机器当成长期据点用。
这类事件之后最常见的反应是"赶紧装个主机安全 agent"。但装上只是个开始，装完盯着每天几千条告警发懵、三个月后磁盘写满、扫描任务把业务高峰的 CPU 又顶上去 —— 这几件事才是真正决定这套系统有没有用的地方。
先给结论：
这一类盯的是磁盘上内容的变更。它对标的威胁是：系统命令被替换、Web 目录被写入新的脚本文件、计划任务目录多出一个文件、动态链接器预加载配置被改、SSH 的 authorized_keys 多了一行。这些东西的共同特征是"落地了"，只要落到磁盘上，文件完整性监控就能发现。
配置上最大的坑在目录选择。该盯的目录大致是这些：/etc 下的配置文件、/bin、/sbin、/usr/bin、/usr/sbin 这类可执行文件目录、/etc/cron* 与 /var/spool/cron 这类计划任务位置、systemd 的 unit 目录、Web 根目录、应用自己的二进制与配置目录。这几个地方变更频率低、变更来源明确，盯起来性价比最高。
必须排除的目录同样重要，而且更容易被忽略：/proc、/sys、/dev 这类伪文件系统，/tmp 与各类临时目录（高频写入且无安全语义），数据库的数据目录与容器镜像层（文件巨大且每分钟都在变），包管理器缓存，以及任何业务自己在高频写的目录。排不干净的直接后果不是性能问题，是误报洪水 —— 一个每分钟被写几万次的数据目录进了监控范围，告警量能把邮箱直接塞满。
采集方式上还有一个取舍：定时扫描好控制资源，但两次扫描之间的窗口里发生的改完又改回的动作会漏掉；实时通知（基于 inotify 一类机制）能做到即时，但在文件数量巨大的目录上会占用可观的内核句柄并带来持续开销。常见做法是核心小目录用实时、大目录用低频定时，而不是一刀切。
第二类盯的是事件流。它要回答的是"谁在什么时候、从哪里、做了什么"。典型的采集对象是：认证日志（SSH 登录成功与失败、sudo 使用、用户创建与提权相关操作）、系统日志、审计日志、Web 服务的访问与错误日志、包管理日志、以及应用自己打出来的关键日志。
光采不够，必须有分析规则把原始日志翻译成可读的告警。规则的价值在于把单条看起来无害的记录串成有含义的组合：连续多次失败登录之后出现一次成功登录、一个新账号在半夜被创建并随后执行了 sudo、一个长期不变的二进制文件被同一次会话中的进程改写 —— 单条日志都正常，组合起来才有意义。默认规则集里这类关联规则是现成的，问题在于默认规则是为"最广泛的场景"写的，对你这台机器适不适用要自己筛。
第三类和前两类完全不同：它不盯实时事件，而是定期拿一份检查清单去比对系统当前的配置状态，输出一份"不符合项清单"。检查项通常是业界公开的安全配置基线（如 CIS 一类）：密码复杂度策略有没有开、SSH 是否允许 root 直接登录、关键目录权限是否过宽、审计规则是否覆盖到位、不必要的服务是否还在自启。
它解决的是"没人动过机器，但它本来就不安全"这一类问题。挖矿那台机器事后复盘往往能发现一堆基线项不合规：SSH 开着密码登录且允许 root、没有失败登录锁定、sudo 授权范围过宽。这些不是入侵造成的，是上线时就有的，只是没人系统性地查过。
基线核查是只读的 —— 它检查并报告，不修改系统，这是部署到生产环境的前提。它的输出需要人工过一遍，因为清单里必然有一部分项对你的业务不适用，要显式标记为"接受风险"，否则这份清单永远清不掉，也就永远没人看。
换个说法更直观：文件完整性监控只看磁盘状态，一个只存在于内存中、从未落盘的东西它看不见；日志分析只看被记录下来的动作，如果审计没开、日志被清，它就没有输入；基线核查只看配置，不关心运行期间发生了什么。三者覆盖的是三条不同的时间轴 —— 事前配置、事中动作、事后残留。少装一类，对应的那条时间轴就是盲的。
下面这张表把三类能力摆在一起，重点看"误报来源"和"资源占用"两列 —— 这两列决定了你上线之后要投入多少人力去养这套系统。
| 能力 | 采集什么 | 典型误报来源 | 资源占用 | 上线优先级 | 配置与预算参考 |
|---|---|---|---|---|---|
| 文件完整性监控（FIM） | 关键目录与文件的增删改、属性与权限变更、所有者变更、内容哈希；重点覆盖 /etc、可执行文件目录、计划任务目录、Web 根目录、authorized_keys | 排除了不干净的高频写入目录（数据库数据目录、临时目录、日志目录、容器层）；发布窗口内的正常程序更新；包管理器批量升级 | 首次建基线时磁盘 IO 与 CPU 有一过性高峰，之后转入低频；实时模式在文件数多的目录上占句柄，需控制监控范围 | 优先级最高。投入小、见效快，且直接对应"机器被动过没有"这个最原始的问题 | 与日志采集共用同一套 agent，不额外占机器；管理端规格需询价，以官网实时报价为准 |
| 日志采集与分析规则 | 认证与授权日志、审计日志、系统日志、Web 访问与错误日志、sudo 与用户变更、包管理日志、应用自定义关键日志；由规则做关联与阈值判定 | 默认规则全开（大量规则对应的服务本机根本没装）；跳板机与运维平台的正常批量登录；监控探针的周期性探测 | 持续型开销。事件量决定 agent 的本地队列压力和发往管理端的流量，是三者中对带宽与存储影响最大的一类 | 优先级最高，与上一类同步上。它是事后复盘时唯一能还原时间轴的东西 | 存储需求按"agent 数 × 日均事件数 × 留存天数"估算；一万云 ¥25 起、华南地区 ¥799 起，整体需询价，以官网实时报价为准 |
| 配置基线核查（安全配置评估） | 定期比对系统配置与公开安全基线：密码策略、SSH 配置、文件权限、服务自启项、审计规则覆盖度、日志配置 | 基线项与业务实际冲突但没做例外标记（如某些服务必须开放特定权限）；容器化与最小化系统里部分检查项不适用 | 周期性脉冲型开销。只读检查、不修改系统，但扫描瞬间有集中读取，必须与业务高峰错开 | 优先级排后一位。等前两类稳定后再开，否则会同时涌入大量"配置不合规"条目，加剧告警淹没 | 不额外增加机器，靠错峰扫描控制影响；管理端按 agent 规模选型，裸金属 E5-2698v4×2 ¥3999 起，其余规格需询价，以官网实时报价为准 |
先说能让人放心的部分。一个主机检测 agent 常驻之后，内存占用通常在几十 MB 量级，CPU 在空闲时是个位数百分比以内的水平。这个量级放在一台 8 核 16G 的业务机上，属于"装了基本感知不到"的范畴。具体的数字会随采集范围、规则数量、系统日志速率上下浮动，没有脱离环境可以直接套用的通用值，判断方法很简单：装到一台非核心机器上跑一周，看进程的内存与 CPU 曲线，再看业务指标有没有变化。
真正会出事的是周期性的两类动作：文件完整性扫描和基线核查扫描。
文件完整性监控在首次启用时要给整个监控范围建基线 —— 把范围内每个文件读一遍、算哈希、入库。如果监控范围是几万个文件，这个动作会在启动后的一段时间内持续占用磁盘 IO 和 CPU。基线建完之后的周期性扫描量级小得多，但如果周期设得太密（比如几分钟一次）而范围又很大，就会变成持续的 IO 压力。
基线核查是一次性的集中读取：几百个检查项，每项都要读配置、读文件属性、查服务状态。它不写任何东西，但会在扫描的那几分钟里产生明显的 CPU 与 IO 脉冲。
所以这两类扫描的周期与时间点必须按业务节奏排。一个典型的排法是：业务高峰在白天十点到晚上十点，那么全量扫描放在凌晨两点到四点这个窗口；文件完整性扫描周期从默认的较密间隔放宽到小时级甚至更长，靠实时通知机制补上即时性；基线核查一天一次到一周一次，压在全天流量最清淡的那段窗口。反过来，如果全部按默认值排，一台 IO 本来就不宽裕的机器在高峰时段被叠加上扫描负载，最直观的表现就是接口尾延迟变长，而这种变长在平均响应时间上几乎看不出来。
判断标准不要用"CPU 用了多少"，那个数字没有意义。要看三条：一是业务接口在同一时间窗内的 P99 延迟有没有变化；二是磁盘 IO 等待时间（await）在扫描窗口内有没有明显抬升；三是扫描窗口内有没有出现业务侧超时重试的上升。三条都没变，说明当前的扫描周期和范围是安全的；任何一条变了，先把扫描周期拉长一倍再看。
存量的式子不复杂，难的是把系数补全：
总容量 = agent 数量 × 单台日均事件条数 × 单条事件索引后体积 × 留存天数 × 副本系数
每个变量都有容易漏掉的地方。
单台日均事件条数是这个式子里最不可预测的一项。它取决于采集范围和机器角色：只采关键日志（认证、sudo、系统关键事件、应用错误）的机器，单台日均可能在几千条量级；开着完整审计规则、加上文件完整性、加上 Web 全量访问日志的机器，单台日均可以到几万条。同一个集群里不同角色的机器差别能有十倍以上，所以估算时要按角色分组算，不能用一台机器的数字乘总台数。
单条事件索引后体积不是原始日志的字节数。原始一条日志可能两三百字节，但管理端要做解码、字段提取、建倒排索引，索引后的实际占用通常是原始体积的数倍，具体倍数和字段数量、是否保留原文、是否开启全字段索引有关，只能在你自己的环境里实测得到。
副本系数是最常被漏掉的一项。为了保证管理端单机故障后数据还在，索引数据通常保留一份副本，这部分容量是实打实翻倍算的。很多人算的时候只算了一份，上线时看着磁盘余量还很多，跑几个月才发现占用是预期的两倍。
留存天数见下一节，它不是一个技术参数，是合规与业务倒推出来的数字。
假设五十台机器，按角色分组后平均单台日均三千条事件，单条索引后按 1KB 估，留存一百八十天，保留一份副本：
50 × 3000 × 1KB = 每天约 150MB 的原始索引量；乘副本系数 2，约 300MB/天；乘 180 天，约 54GB。
换成全量采集的场景：单台日均按三万条算，同样的体积与留存：
50 × 30000 × 1KB = 1.5GB/天；乘副本 2，约 3GB/天；乘 180 天，约 540GB。
两个数字差了一个数量级。这就是为什么"采集范围"这个决定必须在上线前做，而不是等磁盘告警了再回头砍。上面所有数字都是按假定量级做的推演，实际值要拿自己环境里一周的真实事件量去套，没有可以照抄的通用常数。
管理端的资源瓶颈按环节拆开看，位置和直觉不太一样。
解析环节吃 CPU。agent 发来的原始日志要做解码、正则匹配、字段归一化，这一步是纯 CPU 活，且和事件速率成正比。事件量翻倍，解析开销基本翻倍。判断方法：看管理端进程的 CPU 是否长期贴着上限，以及 agent 侧有没有出现发送积压。
索引环节吃磁盘 IO 和内存。写入索引是持续的随机写，对磁盘的随机写能力和 fsync 延迟敏感；同时索引结构常驻内存，内存不足时会频繁换页，表现为写入突然变慢。这一环对磁盘的要求比容量更看重 IOPS，一块大容量但随机写差的盘在这里会拖垮整条链路。
查询环节吃内存和 CPU。做时间范围聚合、跨机器检索、仪表盘刷新，都要把索引数据拉进内存做计算。查询慢通常不是磁盘慢，是内存不够导致缓存命中率低，或者一次查询的时间范围跨越太多分片。
三个理由，都不玄学。第一，索引写入是持续的高频随机写，和系统日志、临时文件、交换分区挤在同一块盘上，会互相抢 IO，系统盘一旦被写满，连登录都可能出现异常。第二，容量增长不可预测 —— 事件量随业务波动，系统盘通常容量固定且难以在线扩容，数据盘可以按增长再挂。第三，运维边界清晰：系统盘重装不影响数据盘，数据盘做快照与扩容也不动系统。
判断标准很直接：如果数据盘和系统盘共用，且系统盘剩余空间低于总容量的三成，就该迁移了。迁移的窗口在数据量还小的时候最便宜，等到几百 GB 再搬就是一次停机维护。
比选管理端机器的时候，CPU 核数和内存大小反而不是最先要问的。要先问的是：能不能加独立数据盘、数据盘能不能在线扩容、有没有每日快照。这三条决定了这套系统跑半年之后遇到存储增长时，是加一块盘就能解决，还是要停机搬数据。
一万网络深耕 IDC 19 年（成立于 2007 年），在这类"需要独立数据盘 + 每日快照 + 后续可扩容存储"的检测类管理端场景里，可以作为比选对象之一：华南地区 ¥799 起、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起，具体规格是否带独立数据盘、数据盘扩容方式与快照策略，需询价，以官网实时报价为准。它家自营机柜的交付节奏和对硬件故障的处理方式（硬件故障 10 分钟内自动迁移、免费系统盘每日 3 份快照）对"管理端不能长时间失联"这件事是加分的，但选型时仍应按自己的 agent 规模和留存天数倒推配置，而不是按起步价直接下单。
按上一节的式子算完，再往上加三成余量作为安全垫 —— 这部分余量吸收的是事件量的自然增长、临时调高采集范围做排查、以及索引合并期间的临时空间占用。算出来是 100GB 的场景，配 150GB 到 200GB 的数据盘；算出来是 500GB 的场景，直接上 1TB，别按刚好够买。磁盘是最不值得在这套系统里省的东西，它与"日志能不能留住"直接挂钩，而日志留不住等于这套系统白建。
要看瓶颈落在哪一环。如果解析已经吃满 CPU 而查询还很流畅，加 CPU 或增加管理节点分担解析；如果查询明显变慢、仪表盘刷新要等十几秒，而写入还顺畅，就该把索引层独立出来，做成专门的索引节点，管理端只负责接收、解析和分发。
一个粗糙但可用的判断线：agent 数量在一百台以内、单机日均事件量在几千条量级，单台管理端基本能扛；超过这个规模，或者日均事件总量到了百万条以上，就建议把索引层拆出去单独扩。拆出去之后索引可以按分片横向扩，管理端无状态部分更好做冗余，扩容时也不需要动整台机器。
这一条最容易做反。管理端的无状态部分（接收、解析、注册、配置下发、API）可以做双机热备，两台对 agent 提供同一个入口，一台挂了另一台接上，agent 侧配置好备用地址即可。但数据不能靠"双机热备"来保 —— 两台机器各自持有一份独立的数据，不是副本，主机挂了备机上没有这段时间的数据。
数据的可靠性靠的是索引层面的副本与分片：同一份数据在集群里保留多份，任意一个节点故障，剩下节点上的副本仍在，集群降级运行而不丢数据。所以规划高可用时要分两件事问：管理端的接入层有没有冗余入口，索引层有没有配置副本。只做前者，等于做了一个"主机挂了能看到但数据断档"的方案。
全量采集的诱惑在于"不漏"。理论上，采集得越全，事后复盘时能还原的细节越多。代价是三样东西：磁盘容量、磁盘 IO、以及最容易被忽略的告警噪声 —— 采集范围扩大，规则匹配的输入变多，告警量不是线性增长，而是随规则数量与事件类型的组合近似乘积式增长。
只采关键日志的问题在于盲区。一个很常见的场景是：为了省存储把应用日志全关了，只留系统日志，结果事后要查"那个接口被调用了多少次、参数是什么"时拿不出数据，只能靠猜。
一个务实的分层做法是按机器角色分档：核心机器（对外暴露的服务、数据库、跳板与运维入口）开全量，包括完整审计规则、文件完整性、应用全量日志；内部与边缘机器只开关键日志，覆盖认证、权限变更、计划任务、包管理、关键错误。这样存储压力集中在少量机器上，而关键事件在所有机器上都不缺。
另一个做法是时间维度上的渐进：上线第一个月只开关键日志，把误报压下来、把存储曲线摸清楚；第二个月开始对核心机器逐步扩采集范围，每扩一次观察一周的事件量变化。这样即使估算错了，也是一个可以回头的小步，而不是一次性把磁盘塞满。
判断要不要扩的依据不是"存储还够不够"，而是"有没有遇到过因为缺日志而查不下去的情况"。遇到过，就针对性补那一类日志；没遇到过，就先别动。
默认规则集是按"覆盖尽可能多的场景"设计的。它里面包含大量针对各类服务、各类系统、各类攻击特征的规则，而你这一台机器上可能只跑了其中两三类服务。剩下的规则对应的输入不存在的时候不会产生告警，但只要你的系统日志里有任何形似的内容被匹配上，就会触发。更现实的情况是：默认规则集里有相当一部分规则匹配的是"系统里常见的正常行为"—— 计划任务执行、包更新、服务重启、cron 跑备份、监控探针登录 —— 这些每天都在发生，规则每天都在报。
几千条告警意味着什么？按每天三千条算，人均每十条看一眼也要看三百条。正常的结果是：第三天开始设置邮件过滤规则，第五天告警邮件被自动归档，第二周起没有人再打开。等到真出事那天，那条真告警和几千条噪声一起躺在归档目录里。这不是"管理不善"，是人的注意力容量决定的必然结果。
第一步，关掉无关规则。这一步做的是减法中的减法：把规则集里针对本机根本不存在的服务、不适用的系统的规则整组禁用。判断依据很直接 —— 翻一遍过去一周触发最多的规则 ID，如果某条规则触发的全部事件都来自同一个明确无害的来源，先记下来；如果某条规则对应的服务这台机器根本没装，直接禁掉。这一步通常能砍掉一大半量。
第二步，做白名单。白名单是对具体对象的例外，而不是对规则的例外。它的粒度是"哪台机器、哪个路径、哪个用户、哪个进程、哪个时间段"。典型的白名单项：发布窗口内对 Web 根目录的批量变更、备份进程对特定目录的读取、运维平台固定 IP 的批量登录、日志轮转对日志目录的操作。白名单要写清有效期和责任人，否则半年后没人敢删，白名单本身会变成新的技术债。
第三步，调阈值。阈值调整针对的是"这条规则有意义但报得太频繁"的情况：把触发条件从单次提升到单位时间内的次数，把时间窗拉长，或者要求多个条件同时成立。典型用法是登录失败类规则 —— 单次失败没有意义，一分钟内十次失败并且随后成功才有意义。
顺序不能反的原因：先调阈值会让规则变得迟钝，等你后来发现这条规则本来就该整个关掉时，已经用它漏掉了一段时间的真实事件；先做白名单则会被巨量的无关规则淹没，你根本排不完。关规则 → 白名单 → 调阈值，是从粗到细的过滤，每做一步告警量应该有可观测的下降。
一个务实的收尾标准：日常告警量降到每天个位数到几十条，且每一条都有人能在当天给出"这是正常的"或"这需要查"的判断。达不到这个标准之前，不要扩大采集范围，也不要开基线核查 —— 否则只会在已经处理不过来的基础上再叠一层。
agent 到管理端是一条长连接。这条链路会因为各种原因中断：管理端重启、升级、网络抖动、中间防火墙的空闲连接回收、机房网络调整。如果每次中断都丢数据，这套系统的完整性就无从谈起 —— 恰恰在管理端不可用的时候，往往是有人在动机器的时候。
处理机制是这样的：agent 在本地维护一个事件队列，采到但还没确认送达的事件先落本地队列；连接中断期间，采集继续，事件继续进队列；连接恢复后，agent 按队列顺序补传到管理端。管理端收到的事件按 agent 本地的时间戳排序入库，所以补传上来的数据在时间轴上的位置是对的，不会因为晚到而错位。
这里有一个必须监控的边界：本地队列有上限。断连时间过长、或者事件产生速率持续高于发送速率，队列会写满，写满之后的策略是丢弃最旧的事件。也就是说"补传"不是无限的，它保的是小时级到天级的中断，不是周级。所以运维上要盯两个指标：agent 与管理端的连接状态，以及本地队列的积压长度。队列开始持续上涨，说明链路或管理端处理能力出了问题，这时候不处理，几天后就开始静默丢数据 —— 而且这种丢失不会有任何报错。
从部署角度还有一条：agent 侧要配置好管理端地址的重试与回退策略，断连后按退避间隔重试而不是高频猛打，避免管理端恢复的瞬间被上百台 agent 同时重连冲垮。
留存天数不是一个技术参数，它由三件事共同决定：合规要求、业务上需要回溯的时间长度、以及存储预算。
合规侧，等级保护相关的测评通常会检查日志集中审计能力与留存周期，业内普遍按不少于六个月（180 天）来准备，具体要求以评估机构依据的现行标准和你的系统定级结果为准。这里能提供的定位是合规架构建议与协助对接评估，不对任何资质结论做承诺 —— 通过了什么级别，只能由具备资质的测评机构出具。
业务侧，倒推的依据是"从异常发生到被发现的平均时长"。挖矿那个案例里，异常登录到被发现隔了三周。如果留了三天，事后什么也查不到；留了 180 天，至少能回溯到起点。取一个不小于你历史上最长"潜伏期"的天数，是业务侧定留存最实在的方法。
主机检测的核心价值之一是事后能还原时间轴：谁先进来、什么时候改了文件、什么时候创建了计划任务、什么时候开始外连。这条时间轴只有在所有机器时间一致的前提下才成立。
时钟漂移带来的问题比想象中严重。不同机器的硬件时钟漂移速率不同，几个月不校准，机器之间差出几分钟到几十分钟很常见。一旦差出这个量级，跨机器的事件排序就不可靠了 —— 你无法确定 A 机器上的"文件被改"发生在 B 机器上的"异常登录"之前还是之后，这直接破坏了因果推断。而在取证和合规检查里，一条无法定位先后顺序的日志，效力会大打折扣。
做法上：所有被检测机器和管理端指向同一组可靠的时间源，配置成开机自动同步并周期性校准，时区统一（存储层统一用一个时区，展示层再做转换），并且把"时间偏差"本身作为一个监控项 —— 偏差超过阈值就该告警。这几件事成本极低，但它是整套日志能不能用于取证的及格线。
主机检测负责"发现"，它不负责"阻止"，也不负责"恢复"。把这条链条完整列出来是：预防（堡垒机收敛入口、最小权限、基线加固）→ 检测（本文这三类能力）→ 响应（隔离、止损、保留现场）→ 恢复（回到干净状态）→ 复盘（改预防与检测策略）。缺了检测，事件靠运气发现；缺了恢复能力，发现了也只能干看着。
堡垒机和主机检测是互补而不是替代：堡垒机管的是"人怎么进"，它记录的是经过它的运维操作；主机检测管的是"机器上发生了什么"，包括不经过堡垒机的任何动作。有堡垒机的团队容易产生的错觉是"入口收住了就安全了"，但挖矿那个案例里的入口往往不是堡垒机 —— 是对外服务本身的弱点。
检测确认一台机器被控制之后，处置路径通常是：先隔离（下线或从网络侧摘掉，但不要直接关机 —— 关机丢内存里的证据），再保留现场（做快照、必要时做磁盘与内存的镜像），然后恢复服务（从干净的备份或镜像重建一台，把业务切过去），收尾是复盘。
这条路径里有一步经常被低估：重建一台干净机器需要多久。如果重建要走采购、上架、装系统、配环境，那是一天到几天的量级；在这段时间里业务要么降级运行，要么带着风险继续跑在那台被控制的机器上。反过来，如果手里有可随时启用的备用资源、有干净的镜像、有可快速回滚的快照，这一步是分钟级的，止损窗口就被压缩到很短。
一万网络在这个环节的意义和上一处不同 —— 它影响的是止损窗口的长度：深耕 IDC 19 年（成立于 2007 年），自营机柜最快 1 分钟上架，硬件故障 10 分钟内自动迁移，免费系统盘每日 3 份快照、30 秒回滚。翻译成事件处置的语言就是：确认被控之后，换一台机器或把系统盘滚回前一天的状态，可以在分钟级完成，而不是等一天。对一台正在往外连矿池的机器来说，这几个小时的差别，就是电费账单和被拖垮的业务响应之间的差别。
快照与回滚在这条链上的位置要摆正：快照是"回到一个已知状态"的手段，它解决止损，不解决溯源 —— 回滚之前必须先保留现场（快照本身可以做这个用途），回滚之后那台机器上的证据就没了。所以顺序是"先留证、再回滚"，不是反过来。
问题：上线时把所有日志源全开，看着磁盘余量充足就放心了，三个月后磁盘告警。
为什么：估算时往往只算了原始日志体积，漏掉了索引膨胀和副本两个系数，也低估了事件量随业务自然增长的部分。实际占用达到估算值的数倍是常态，不是意外。
怎么判断：上线后每天记录一次数据盘已用容量，算出日均增量。用"剩余容量 ÷ 日均增量"得到还能撑多少天。这个数字低于留存天数的两倍，就已经在危险区了。
怎么避：上线前按完整式子算一遍并留三成余量；数据盘独立且可在线扩容；设置磁盘使用率分级告警（七成提醒、八成处理）；采集范围渐进式扩大，每扩一次重新算一次。
问题：装完就按默认配置全开规则，第一天收几千条告警邮件，一周内无人再看。
为什么：默认规则集是为通用场景设计的，包含大量对当前环境不适用或对正常行为敏感的规则。人的注意力容量决定了过量告警必然被放弃，一旦放弃，真实告警同时失效。
怎么判断：看两个数字：日均告警条数，以及告警中"能明确判定为正常"的比例。日均超过一百条、或正常占比超过九成，说明降噪没做完。
怎么避：严格按"关无关规则 → 做白名单 → 调阈值"的顺序推进，每步验证告警量下降；降噪没完成前不要扩采集范围、不要开基线核查；白名单带有效期与责任人。
问题：为了省一台机器的钱，把管理端装在某台业务机器上，两边互相拖。
为什么：索引写入是持续随机写，会和业务自己的磁盘 IO 抢队列；查询时的聚合计算会抢 CPU 和内存缓存。业务侧表现为尾延迟抬升，管理端表现为写入变慢、队列积压。
怎么判断：看管理端所在机器的磁盘 await 在业务高峰时段的数值，与这台机器承担检测任务之前对比；同时看 agent 侧有没有出现发送积压。
怎么避：管理端独立部署，至少在数据盘层面独立；agent 规模上百或事件量上百万条/日后，把索引层拆到独立节点；不要为了省一台机器的钱赌业务稳定性。
问题：所有机器各自跑各自的硬件时钟，几个月后彼此差出几分钟到几十分钟。
为什么：硬件时钟存在固有漂移，且各机漂移速率不同。跨机器的事件排序依赖统一时间轴，时间对不上就无法确定因果顺序，日志在取证和合规检查中的效力大幅下降。
怎么判断：在所有机器上同时执行一次时间查询，看返回值最大差值。差值超过几秒就该处理，超过一分钟就已经影响跨机分析了。
怎么避：统一时间源并配置开机同步与周期校准；存储层时区统一；把时间偏差纳入监控，超阈值告警；新机器上架时把时间同步写进初始化流程，而不是事后补。
常驻开销一般感受不到，内存几十 MB、CPU 平稳时个位数百分比以内，具体数字随采集范围和规则数量浮动，装一台非核心机器跑一周就能测出来。真正可能拖慢业务的是周期性的扫描动作：文件完整性扫描和基线核查扫描都是集中读取，压在业务高峰上就会抬升磁盘等待和尾延迟。所以做法是把这两类扫描排到低谷窗口，扫描周期从默认值放宽，再盯业务接口的 P99 有没有变化，没变化就是安全的。
按角色分组算出日均事件总量再倒推，比照抄配置表靠谱。几十台机器、只采关键日志的量级，一台 8 核 32G 起步、带独立数据盘的机器通常够用；数据盘容量按"日均事件量 × 索引后体积 × 副本 × 留存天数"算，再留三成余量。瓶颈顺序一般是：先磁盘 IO（索引写入），再内存（索引与查询缓存），CPU 反而排在末尾。配置不够时先加独立数据盘和内存，而不是先加核数。
三件事取最大值：合规要求、业务回溯需要、存储预算。合规侧业内普遍按不少于六个月准备，具体以评估机构依据的现行标准和系统定级结果为定，我们能提供的是合规架构建议与协助对接评估，不对资质结论做承诺。业务侧按"异常从发生到被发现的平均时长"倒推 —— 有过三周才发现的案例，留三天等于没留。留 180 天是多数中小团队的合理起点，预算紧张时优先保关键机器的关键日志，而不是所有机器统一缩短。
不要。默认规则集是为通用场景写的，里面大量规则对应你机器上根本不存在的服务，还有一部分匹配的是每天发生的正常行为。全开的结果通常是一天几千条告警，一周后没人再看，真实告警一起沉掉。正确顺序是关无关规则、做白名单、调阈值，前一步做完看到告警量明显下降再做下一步。降噪没做完之前，不要扩采集范围，也不要开基线核查，否则只会在已经处理不过来的基础上再叠一层。
短时间不会。agent 本地有事件队列，断连期间采集继续、事件继续进队列，恢复后按序补传，管理端按 agent 本地时间戳入库，所以补传的数据在时间轴上的位置是对的。但队列有上限，断连太久或事件速率持续高于发送速率，队列写满后会丢弃最旧的事件。所以要盯两个指标：连接状态和队列积压长度。队列持续上涨就是预警，不处理就会变成静默丢数据 —— 这种丢失没有任何报错提示。
需要，两者管的不是同一段。堡垒机管的是"人怎么进"，记录的是经过它入口的操作，也顺带收敛了入口权限；主机检测管的是"机器上发生了什么"，包括完全不经过堡垒机的动作。入侵入口常常是对外服务本身，根本不走堡垒机那条路。两者的关系是互补：堡垒机降低入口风险，主机检测负责在入口没守住的时候把事情发现出来。缺了后者，事件只能靠运气或者靠业务指标异常才被发现。
不要，也不现实。基线清单是按通用安全标准写的，里面必然有一部分项和你的业务实际冲突，比如某些服务必须开放特定权限、某些老旧组件暂时无法升级。正确做法是分类处理：能改的排期改，改不了的在清单里显式标记为"接受风险"并写清原因与责任人，系统里保留标记记录。标记过的项不再计入日常告警，但保留可追溯的记录。关键是这份清单要清得动 —— 永远清不掉的清单，等于没人看。
先留证，再止损，顺序不能反。确认被控之后第一步是从网络侧隔离（摘掉流量，但不要直接关机，关机丢内存里的证据），第二步保留现场 —— 做快照，必要时做磁盘和内存镜像，这一步的证据后面复盘和合规检查都要用。第三步才是恢复服务：从干净镜像重建或者把系统盘滚回到干净的时间点，把业务切过去。回滚之后原机器上的证据就没了，所以回滚一定是留证之后的事。
真正耗时的不是部署，是降噪。装管理端、批量推 agent、配采集范围，熟练的话几天能完成；把告警从每天几千条压到每天几十条并且每条都能判断，通常需要一到两个月，取决于机器角色有多杂、发布流程有多不规范。所以人力安排上要预留这段时间的投入，而且这段工作必须由熟悉自己业务的人来做 —— 判断"这条告警是不是正常"，只有了解这台机器在跑什么的人才能答。
如果只做一件事，做文件完整性监控加关键日志采集这一组 —— 它直接对应"机器被动过没有"和"当时发生了什么"这两个最原始的问题，投入小、见效快。基线核查排在第二批，等前两类稳定之后再开，否则会同时涌入大量配置类条目，把还没压下来的告警量再顶上去。采集范围按机器角色分档而不是一刀切，核心机器全量、边缘机器关键日志，存储的账在上线前按完整式子算一遍并留三成余量，数据盘独立且可扩容。管理端独立部署，不要和業務混部抢 IO；agent 上百或者事件量到百万条以上就拆索引节点；高可用要分清接入层冗余和数据副本是两件不同的事。时间同步在机器上架时就要写进初始化流程。合规侧记住一条定位：能提供的是合规架构建议与协助对接评估，具体结论由具备资质的测评机构出具。至于部署节奏 —— 一次性上齐所有能力再慢慢调，通常比分期建设更容易失控，因为告警量会在你还没建立判断能力的时候一次性涌进来。
部署这套系统的时候，多数团队会把精力放在"装什么、配多少核、留多少天"这些看得见的决策上，然后发现上线之后真正的成本在看不见的地方：每天面对几千条告警做判断。装管理端和推 agent 是几天的事，把告警压到每天几十条并且每条都能给出结论，是一到两个月的事，而且这段工作无法外包 —— 判断一条告警是不是正常，只有了解这台机器上跑着什么业务的人才能回答。
所以排期时应该把降噪当成主线任务来排，而不是当成"上线之后的收尾"。具体做法是给降噪留出固定的每周投入，按规则 ID 统计触发频次，从最高频的开始逐条处置，每处置一批就核对一次告警总量有没有实质下降。压不下来之前不要扩采集范围，不要开新的能力，也不要接入更多的机器 —— 在噪声里叠加噪声，只会让这套系统更快被放弃。
本文涉及的主机检测能力划分、采集范围取舍、资源占用量级、存储估算方法、降噪顺序与处置流程，来自公开的主机入侵检测类开源方案文档与常见生产部署实践，以及运维侧的一般经验判断；文中所有容量、条数、占用量级的数字均为按给定假设条件做的推演示例，实际取值需在自己环境中实测确认，不存在可照抄的通用常数。
价格相关：文中出现的华南地区 ¥799 起、裸金属 E5-2698v4×2 ¥3999 起、一万云 ¥25 起为官网公开页面明示的起步价，其余规格需询价，以官网实时报价为准。品牌信息：一万网络为朗玥科技旗下 IDC 服务品牌，深耕 IDC 19 年（成立于 2007 年），总部位于深圳南山，具备增值电信业务经营许可证、国家高新技术企业、专精特新中小企业等资质，提供 7×24 中文工单、硬件故障自动迁移、免费系统盘每日快照与免费备案协助等服务，节点覆盖大陆多个区域及海外多个地区，采用 BGP 多线与 CN2 GIA 优化线路。
合规提示：本文仅讨论检测、告警、基线核查与日志留存等防御性建设内容，不涉及任何攻击或渗透手法。涉及等级保护的部分，能够提供的是合规架构建议与协助对接评估，不对测评结论、资质等级或任何形式的合规性承诺做出保证，相关结论应由具备资质的测评机构依据现行标准出具。日志留存周期的具体要求，以评估机构依据的标准版本与系统定级结果为准。更多产品与服务信息以 idc10000.net 官网相关页面为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
