结论先行：日志平台的参数表写不好，问题不在厂商，在写法。"支持多源接入""查询性能优异""可留存半年以上"这三句话，任何一家都能写，任何一家也都不算说错。真正能用来比较和验收的参数，必须同时带上三样东西：一个数字、数字的前提、以及怎么测出来。少任何一样，这条参数在验收会上就会变成一句"我们都支持"。

本文只谈参数表怎么写才可验，不谈预算怎么算，也不谈平台该用自研引擎还是开源底座——前者是商务问题，后者是架构选择，各有各的判断依据。

为什么参数表容易写成形容词

原因很实际：写参数的人往往是从各家给的方案文档里抄的。方案文档为了覆盖面宽，写的东西必然偏抽象；采购方把这些抽象表述直接搬进需求书，就等于把"能不能比较"这件事放弃了。

结果在验收阶段集中爆发。用得最多的一句质疑是"你们当时说支持"，而服务方的回应也同样成立"我们确实支持"。争到最后，通常按合同金额和关系强弱解决，而不是按技术事实解决。

要跳出这个循环，参数只需要做一件事：把"支持"换成"多少、多快、在什么条件下"。

四类参数，各自要落到什么程度

容量类：日增量、峰值写入、留存期，三个数缺一不可

只写一个总容量是最常见的错。总容量说明不了任何问题：一天写 200GB 的平台，和一天写 20GB 的平台，同样的存储能撑的时间差十倍。

可验的写法是把容量拆成三个数：

  • 日均写入量：按现状统计，注明统计口径（是原始日志还是解析后，是压缩前还是压缩后）。
  • 峰值写入速率：一天里的高峰时段能到多少，单位为每秒条数或每秒字节。峰值决定的是链路和写入队列，不是磁盘。
  • 留存期与对应容量：在给定日增量下，留存半年需要多少可用容量，这个数字要由服务方算给你，而不是你自己估。

这三个数还有一个隐含的第四项：增长率。业务系统一年增加百分之多少的日志量，往往决定了存储是按一年买还是按三年买。

检索类：响应时间必须带数据量与并发前提

"查询秒级返回"这句话单独存在时没有意义。同样一套平台，查一天的数据和查半年的数据、单用户查和五十人同时查，差别可以是几十倍。

所以检索参数要写成一组条件加一个结果：在多大的数据范围内、多少个并发下、按什么查询方式，返回时间是多少。查询方式也要分开写，因为完全不同：按时间范围加关键字的检索、按字段条件的聚合统计、以及跨字段的关联分析，这三种在任何一个平台上耗时都不在一个量级。

如果对方只给一个数字，可以追问一句：这个数字是在哪个数据量点上测的。回答含糊的，说明这行参数需要自己补测。

留存类：留存不等于可查

合规要求日志留存不少于六个月，这一点各家都会写。但"留下来了"和"要用的时候查得到"是两件事。

留存的参数至少要分三层写清楚：热存多久（能随时检索）、冷存多久（要恢复才能查，恢复要多久）、以及到期之后怎么处置。第三层最容易被跳过，而它恰恰是审计时会问的：六个月之后这些数据是删掉、归档还是继续留，谁批准，删了怎么证明删干净了。

分层存储是个通用做法，多数平台都支持冷热分级。写参数时要问的不是"支不支持分级"，而是"分级之后冷数据的检索路径是什么、平均多久能出结果"。

接入类：源的种类要给清单，不给形容词

"支持数百种日志源"这类表述，验收时无法核对。可验的写法是两件事：给出你现网需要接入的源清单（按类型列，操作系统日志、网络设备、安全设备、数据库、中间件、应用日志、云平台各自多少路），要求逐类确认支持方式；以及确认每类的字段解析是不是现成模板，还是需要自己写规则。

这两件事的差别在实施阶段会放大。模板现成的，接一路可能只要半天；需要自己写解析规则的，一路可能要几天，而且写完还得维护——上游系统改一次日志格式，解析规则就要跟着改一次。

三个常见的坑

坑其一：把"支持"当成了"开箱可用"

很多能力确实是"支持"，但支持的方式是提供接口或插件，需要额外开发。参数表里如果只写支持，不写是否需要二次开发、由谁开发、工作量算在谁头上，这部分成本最后一定会在实施阶段以变更单的形式出现。

坑其二：只约定了功能，没约定数据准确性

日志平台最容易出的问题不是功能缺失，是数据本身对不上：同一条日志报了两次导致统计翻倍、接入端限速后丢了一部分、设备时钟不一致导致时间线错乱。这些都不属于"功能"，所以不会出现在参数表里，但它们决定了平台能不能用。

补法是在需求书里单列一节数据质量要求：重复率、丢失率、时间偏差容忍范围、以及发现偏差后的处理时限。这几项不需要很精确的数字，但需要有明确的口径和责任人。

坑其三：验收方法留到验收时才谈

参数写得再好，如果测法没有提前约定，验收时还是会被解释掉。可行的做法是在需求书里对每类关键参数附一行测法：容量类用一段真实数据跑一遍写入；检索类用固定查询语句在约定数据量上计时；接入类按清单逐类接一路验证；留存类把一份数据放到冷存再取回来看耗时。

这些测法要在合同签订前写进技术附件，而不是等验收会上临时商量。写进去之后，参数表才真正变成一份可以被检验的文件。

边界与前提

这套写法有适用范围。如果单位规模很小、日志量在每天几十 GB 以内、使用方只有运维两三个人，那么把参数写到这个颗粒度的收益有限，按现成方案买、按实际使用调整更省事。

另外一点要说明：参数写得严，不等于要卡厂商。参数的作用是让不同的方案在同一把尺子上量出来，而不是把某一家挡在门外。真正需要卡死的只有少数几条——写入峰值、检索响应、以及数据质量的底线，其余留出弹性，谈判空间反而更大。

深圳市奇摩计算机有限公司在做这类项目时，通常先陪客户把现网的日志源盘一遍，把日增量和峰值量出来，再据此写参数。这一步做完，后面不管是写需求书还是看方案，判断都会快很多。如果您手上正好有一份参数表拿不准，欢迎预约咨询，我们可以逐条过一遍。