结论先行：日志平台的容量与检索体验，很大程度上不是被技术决定的，而是被接入决策决定的。可行的做法是把「接日志」变成一道有门槛的评估：先回答用途、范围、周期与责任人四个问题，通过了再建采集任务，并把这个结论留档。
为什么接入需要设门槛
日志的接入成本看起来很低——多配一个源、多建一个采集任务。但成本并不会消失，只会转移到后面：存储与索引资源被低价值日志挤占，检索时被大量噪音干扰，审计时又要从几千个源里找那几十个真正有用的。更麻烦的是，日志一旦接进来就很少有人主动去关，于是平台会沿着「越接越多、越查越慢、越慢越没人用」的路径往下走。
设门槛的目的不是少接日志，而是让每一个接入决定都有依据。合规要求留存的和排查故障需要的，优先级天然不同，处置方式也应该不同。
准入要回答的四个问题
| 问题 | 要确认的内容 | 答不上来的后果 |
|---|---|---|
| 为什么接 | 用途属于合规留存、安全分析、故障排查还是业务统计，是否有明确的使用场景 | 接了没人看，长期占用资源 |
| 接什么 | 需要哪些字段、哪些级别，敏感字段如何处理 | 全量照收，检索噪音大且带来新的合规风险 |
| 留多久 | 留存周期、归档方式与到期处置口径 | 容量估算无从下手，后期被动扩容 |
| 谁负责 | 源侧的配置责任人、平台侧的使用责任人 | 掉线无人发现，出问题互相推 |
这四个问题里，第三个最容易被跳过。留存周期直接决定容量与成本，而容量又决定了后续能不能按期上线。建议在接入评估阶段就给出量级估算，哪怕只是粗略的日均量与保留天数。
四类常见场景怎么区别对待
合规留存类
这类接入的驱动力来自监管要求，重点是完整性、可信时间与留存周期，而不是检索速度。建议单独规划存储策略，把「必须留存」与「便于检索」两类需求分开处理，避免为了合规把全量数据放进高成本存储。
安全分析类
这类接入对字段完整性的要求较高，尤其是源、目的、账号、时间四类字段。接入前要确认设备侧是否具备标准外发能力，以及时间同步是否可靠——时间不可信的数据在关联分析里价值很低。
故障排查类
这类接入宜按业务重要性排序，先接核心链路。接入时同步确认是否具备链路关联所需的标识字段，否则接进来仍然串不起来。对于日志量特别大的应用，考虑先做级别过滤或采样，把噪音挡在门外。
业务统计类
这类需求往往可以走接口或数据同步通道，不一定要进日志平台。接入评估时把这一点问清楚，能省下不少存储。
准入流程怎么落地
建议做成一张表：接入申请由使用方提出，填写四个问题的答案；平台侧据此给出容量估算与采集方案；双方确认责任人与留存周期后建立任务，并把这份记录留档。上线之后，把「已接入源与台账应接入源的比值」以及「每个源最近一次上报时间」纳入定期巡检，长期零上报的源要有清理动作。
一个容易被忽略的细节是：源侧的采集配置由谁维护。主机侧通常归服务器团队，网络与安全设备通常归网络团队，接口对接可能涉及业务方。如果不在接入时就写明，出事时最常见的场景就是「都以为别人接了」。
边界与前提
其一，准入评估的严格程度应与平台阶段匹配，项目初期重点是覆盖关键源，不宜为了流程完备拖慢上线。其二，评估结论需要定期复核，业务调整后原有用途可能已经不存在。其三，字段级过滤要谨慎，过度裁剪可能破坏后续的关联分析能力，建议先明确分析场景再决定裁哪些。
落地清单
- 制作一张接入评估表，固定「用途、范围、周期、责任人」四项必答内容。
- 对现有已接入源做一次回溯评估，识别用途不明的接入。
- 按识别出的用途分类设置存储与保留策略，区分合规留存与检索需求。
- 确认每个源的采集配置责任人与平台侧使用责任人。
- 把接入源覆盖率与上报活跃度纳入周期巡检，定期清理长期零上报源。
- 每年复核一次留存周期与容量估算，与业务变化同步。
日志平台的价值取决于进来的是不是有用的数据。奇摩在日志平台交付项目中，会把接入评估表与责任人清单作为交付物之一，让平台在建设期之后仍然可控。需要梳理日志接入口径与容量规划，欢迎 预约咨询。