结论先行：日志平台验收时把接入率、留存达标率、检索响应三项都定成"越高越好"，这三个数字必然互相拉扯，验收会拖成一场辩论。正确做法是先定这套平台主要给谁用，主口径跟着用途走，另外两项降成门槛值写进验收表。少了这一步，签的是三个愿望，不是一个判据。
本文只谈日志平台交付验收该拿哪个口径判定，不谈采集侧怎么部署，也不谈平台上线后的季度巡检怎么做。
三个数字，量的根本不是同一件事
接入率，量的是"该出数的源头有没有在出数"。它的盲区在于出数不等于有内容。一台边界设备配了转发，只送会话日志、不送策略变更日志，接入率照样是接近满的；可审计真要的那几类操作，一条都没有。按设备算和按日志类型算，得出的接入率能差三十个百分点。
留存达标率，量的是"到期的日志还在不在"。等保层面普遍要求日志集中留存不少于六个月，平台侧常见承诺是 180 天以上。这个数字本身不难达标，难的是达标之后的可用性——冷热分层之后，热区只留最近一个月，越老的日志沉得越深。真去查第 150 天的一条记录，能不能在可接受的时间内调出来，这一条不在"留存达标率"里。
检索响应，量的是"查一次有多快"。厂商参数表上的数字通常有前提：单集群百万级每秒的接入能力，每日数百 TB 入库，千亿条记录在一定复杂度下按秒返回。同一个平台，查询从三个过滤条件加到十几个、跨几百个源、还对非索引字段做模糊匹配，秒级就会变成分钟级。参数没错，前提没写在验收表上。
为什么三个凑不齐
有三条机制在背后固定地拉扯：
- 接入源越多，查询越慢。每加一类源就多一套解析规则，字段命名不一致，同一个查询要在更多索引上扫一遍。
- 留存越久，检索越慢。为了压成本，冷数据要压缩、要换低成本介质，常见做法是把索引压到原来的三成左右。省下来的存储费，是用查询时间换的。
- 检索越快，存储越贵。要让查询快，就得把索引建全、热区留长。热区多留一个月，存储和内存的账都跟着涨。
这三条不是某个产品的问题，是这类系统共同的结构。所以验收表上写"三项均达到九成五以上"，等于要求供应商在一个三元约束里同时取到边界值——做不到的时候，只能在某一项上含糊过去，而含糊的那一项，通常就是几个月后出问题的那一项。
按用途选主口径
先回答一个问题：这套平台一年之后被打开，主要原因是什么。答案通常落在三类里。
以排障为主
主口径定检索响应，按"最近七天、常用字段、不带模糊匹配"这组条件测，取分位值而不是平均值。接入率作为门槛值（比如不低于九成五，且关键日志类型逐项点名）。留存只要求三个月热区可查。这类单位的日志量增长快，把留存压到够用，比追求长留存更划算。
以审计取证为主
主口径定留存达标率与不可篡改性，具体到"某一天的某条记录，今天能不能原样取出来并证明没被改过"。检索响应放宽到分钟级完全可接受——取证不是秒级业务。接入率这时要按日志类型逐项核，不能按设备台数核。这一类的验收失败，往往失败在"关键操作日志缺失"，不在速度。
以安全分析为主
主口径定关联字段完整度：同一个用户在不同系统里的标识能不能对上，源地址、账号、操作对象这几个字段在各类源里是否齐全。这一项不过，后面的关联分析全是空转。响应与留存都退成门槛值。
三个常见的验收踩空
- 拿厂商参数表当验收值。参数表描述的是理想负载下的能力，验收要测的是本项目自己的数据形状。同样千亿条，字段多寡不同，结果差很远。
- 接入率按设备算。设备全接进来，日志类型缺一半，数字好看，用起来才发现查不到。
- 只按上线当天的数据量验收。上线三个月后数据量翻几倍，冷热分层的比例会变，当初通过的检索响应可能不再成立。验收表里加一条"满三个月按当时数据量复测"，是成本极低的保险。
落地清单
- 先写下这套平台一年的主要用途，只能选一类。
- 主口径按用途定，写清测试条件：数据范围、字段范围、查询复杂度、取分位还是均值。
- 另外两项写成门槛值，并注明不达标的处理方式。
- 接入率按日志类型核，逐项点名关键操作日志。
- 验收表加一条满三个月复测条款。
这件事的实际意义在于，选口径本身就是一次需求确认。一家做数据中心运维的服务商在给客户做日志项目时，如果连"你主要拿它干什么"都没问清就送来一张三项全优的验收表，那张表大概只是模板。深圳市奇摩计算机有限公司在交付这类项目时，习惯把口径讨论放在方案阶段而不是验收阶段——因为到了验收阶段，改口径的成本已经由双方共同承担了。
至于采集侧怎么排、平台上线后每个季度查什么，是另外两个题目，这里不展开。真要落到自己单位，先做一件事：把过去一年里被打开过的排查场景列十条出来，看其中多少条靠日志解决的。答案会告诉你主口径该定哪一项。