日志平台放自己机房，还是用云上的

结论先行：日志平台选本地部署还是云服务，多数讨论停在「数据敏不敏感」这一层，而真正决定成败的是另外四件事：采集侧能不能把数据送到平台、平台自身由谁来运维、容量按什么节奏扩、许可是怎么计的。这四件事的答案不同，结论就可能相反——同一个单位，接入量小的业务适合订阅，接入量大的核心区反而适合本地部署。先答这四问，再谈形态。

本文只谈平台部署形态怎么选、选完之后哪些前提要落实，不谈日志该留多久、冷热该怎么分层，不谈采集层的分类登记与覆盖率口径，也不谈平台建好之后要对接到哪几类出口。

两种形态，差别不在功能

行业里常见的两种形态：本地私有化部署，平台与数据都在自己机房；云服务形态，平台由服务方托管，按接入量或席位订阅。

两种形态在功能上通常差别不大——同一套产品往往两种都能交付。差别集中在四件事上，而这四件事恰好是项目最容易翻车的地方。

四行里，网络可达与扩容节奏两行是硬约束，平台自身运维与许可计价两行是可以谈的。顺序上应当先定硬的：网络通不通、扩不扩得动；再谈软的：谁运维、多少钱。

网络这一关，隔离区最难

本地部署看起来「采集侧都能通」，实际也有坑，主要集中在隔离区。

生产区、办公区、隔离区三段的网络策略不一样。生产区通常好办，办公区要看终端是否允许装采集组件，隔离区最麻烦——它按设计就不该有大量出网路径。

这一类通常的解法有两种：在隔离区内部署一个采集汇聚点，由汇聚点单向往外送；或者对隔离区采取降级采集，只送关键几类事件，不送全量。两种解法都不是技术难题，难点在于这一步必须在方案阶段决定，不能等到接入时再说「这段先不接」。一旦「先不接」写进了实施记录，后面就很难再补——补的时候要重新走一遍评审。

云服务形态在这个问题上更明显。数据要出网，出网这件事本身需要评审，而评审的周期往往比项目周期还长。可行的做法是在立项时就把出网路径作为一项前置条件列出，而不是当成实施阶段的技术细节。

平台自身谁来运维，边界要写在纸上

订阅云服务时，一个常见的误解是「平台不用我管了」。实际的分界通常是：平台软件的可用性由服务方负责，而采集侧、账号体系、规则配置、日志源改造这些仍然在自己这边。

三件事要说清。

升级由谁定时间。云服务的升级通常由服务方排期。如果平台的解析规则或字段定义在升级中发生变化，自己这边的报表就会跟着变。这一条要在合同里约定提前通知的时长。

故障由谁先响应。平台不可用时，先由谁判断是平台的问题还是采集的问题。这个判断如果没人做，双方的响应就会互相等。

平台自身的数据算谁的。平台自己的操作日志、审计记录、配置历史，这些在服务方托管时往往不在自己的可控范围内。而恰恰是这些记录，在需要自证的时候最有用。

扩容节奏，比单价更影响总账

日志量的特点是涨得比预期快，而且不均匀：日常平稳，遇到一次排查或一次演练，量能翻几倍。

本地部署的扩容是批次动作：估算、采购、到货、上架、扩容，一轮下来周期按月计。所以本地部署的关键动作是「提前估」，估的依据不是平均值而是峰值，并且要留出一次突发排查的余量。

云服务的扩容是即时的，但代价可能出现在账单上：超出订购量的部分按量计费，而这类突发往往发生在最忙的时候，没人会去看计费规则。可行的做法是设置用量告警，在达到订购量的一定比例时提醒。

两种形态都存在一个共同问题：扩容的触发信号是什么。可行的信号有三个——日均写入量连续两个月环比上升、查询平均耗时上升、冷数据占比上升。三个信号里，第二个最直接地反映「平台开始吃力」。

许可怎么计，按三年算

本地部署通常是一次性授权加年度维保，云服务是按接入量或席位订阅。首年比较，云服务往往更低；三年比较，结论可能反过来。

折算时要注意三件事。

一是接入量的口径。按日志源数、按写入量、按终端数，三种口径在同一环境下的结果差别很大。同一份报价，换一种口径就可能翻倍。这一项必须在对比前统一，而不是等两家都报完再来对齐。

二是硬件与机房成本。本地部署的报价里通常不含服务器、存储、机柜、电力。这部分不写进对比表，结论就是错的。

三是人力成本。本地部署要有人管平台，云服务要有人管采集与规则。两边都有人力投入，只是岗位不同。这一项最难量化，但至少要写进对比表，标注为「未计价但存在」。

三项对齐之后，剩下的才是价格比较。这一步做到位，选哪个都不会太离谱。

一个折中：分段部署

实际项目里，两种形态并非只能二选一。

常见的折中是按数据敏感度分段：核心业务区的日志本地部署、不出内网，边缘业务与办公区的日志走订阅。这样做的代价是要维护两套规则与两个查询入口，收益是核心数据不出门、边缘部分不用为小量数据建一整套平台。

另一种折中是采集本地、分析在云：采集组件部署在内网，只把处理后的结果向外送。这个做法的前提是「处理后的结果」在合规上可以被接受，这一点要提前确认，不能事后解释。

折中方案的通病是运维复杂度上升。是否值得，取决于两段的数据量比例——如果核心区占比很高，分段的意义就不大，不如整体本地部署。

落地清单

• 先答四问：网络可达、平台自身谁运维、扩容节奏、许可计价，再谈形态。
• 画一张从采集端到平台的路径图，标出需要新增放行的位置。
• 隔离区的采集方案在方案阶段定，不留「先不接」的口子。
• 云服务形态把出网评审列为立项前置条件，不当成实施细节。
• 在合同里约定升级提前通知时长与故障响应的分工。
• 把平台自身的操作记录落在自己可控的范围内。
• 扩容按峰值估，并留出一次突发排查的余量。
• 云服务设置用量告警，在接近订购量时提醒。
• 许可对比统一口径，并把硬件、机房、人力三项一并列入表内。
• 分段部署的方案要算清两段数据量比例，并接受运维复杂度上升。

深圳市奇摩计算机有限公司在日志平台类项目里，通常先把网络路径与扩容估算跑一遍，再定部署形态——原因很实际：功能对比大家都做得差不多，真正拖住项目的是路径和容量。若您正在评估日志平台的部署方案，或需要把三年的成本口径对齐后再比较，欢迎 预约咨询。