结论先行：分支机构一多，日志的存放位置就成了必须先定的事：全部上收到中心，还是一部分留在本地。这个决定受四件事约束——链路条件、留存时限、断网时的可用性，以及监管对数据存放地点的要求。它属于架构决策，一旦按最省事的做法铺开，事后很难只靠调配置补回来。
为什么这个决定不能留到实施阶段
日志平台的选型讨论通常集中在引擎性能、检索速度、规则丰富度上，而布点方式常常被当成实施细节。但布点决定了后面三件事的上限：分支机构的日志在网络中断时还能不能查；中心侧的存储与链路要按什么量级规划；以及数据存放地点是否满足行业监管要求。
更重要的是，它影响的是「有没有」而不是「快不快」。链路断了、缓存没配好、上报通道成了单点，丢掉的是一整段时间的证据——而日志的价值恰恰在于事后能回到那一段时间。
三种常见的布点方式
| 方式 | 日志落在哪 | 适合什么情况 | 要提前定的事 |
|---|---|---|---|
| 全部上收 | 只在中心侧集中存储 | 分支数量不多、链路稳定、带宽有余量 | 断链窗口期的容忍度；带宽占用与业务流量的优先级 |
| 中心加区域节点 | 按区域设节点，区域内本地汇聚，中心统一汇总 | 分支多、跨地域、链路质量参差 | 区域的划分依据；区域节点自身的运维归属 |
| 分支机构本地留存 | 本地保留完整日志，按需或按策略上报 | 对数据不出本地有硬要求，或链路条件很差 | 本地存多久、谁来取、取的时候怎么保证完整 |
三种方式不是互斥的。实际项目里常见的是混合：普通办公类日志上收，涉及敏感数据的类别留在本地，安全类日志既留本地也上收一份做集中分析。
决定选哪种的四件事
一、链路条件与带宽占用
日志是持续的、增量的流量，日积月累的量级通常远超最初的估算。链路带宽不足时，最典型的后果是上报延迟堆积——平台看起来在工作，但检索到的是几小时前的数据。分支链路本身还要承载业务流量，日志上收应当有明确的限速与优先级约定。
二、留存时限与存储成本
合规要求通常对日志保存周期有下限，行业内比较通行的口径是不少于 180 天，金融等受监管行业另有更细的规定。留存期一旦确定，存储量就是可以算的：日增量乘以天数，再乘上副本与索引开销。冷热分级是控制这部分成本的常规手段——近期数据用高性能介质，历史数据下沉。
三、断网时的可用性
分支机构到中心的链路中断是有可能发生的：运营商故障、割接、专线调整。布点方式决定这段时间的日志还在不在。可行的做法是让采集端在链路不可用时先落本地、限定缓存上限，恢复后从断点续传；同时把「断网补传」做成一项定期验证的项，而不是假设它一直在生效。
四、数据存放地点与检索范围
部分行业对数据存放地点有明确要求，日志里往往包含账号、地址、业务标识等信息，因此「能不能出本地」需要提前判定，而不是由技术实现顺手决定。与之对应的还有检索范围：谁能在中心侧看到分支的数据、分支自己能不能看到其他分支的数据，这些可见范围的口径建议在布点阶段一并定下来。
按规模做粗略分档
布点方式与规模大致对应：日日志量较小的场景，单组节点即可承接，采集端本地缓存足够应付短时中断；日日志量进入十 TB 到百 TB 区间的，通常会做冷热分离，并把采集与检索角色分开；再往上、且分支机构跨地域时，多区域分布式更合适——各区域本地采集与预处理，中心做统一汇总与检索。这一档只作规划起点，实际节点数要按日志类型、解析开销与留存期重新折算。
两个容易漏掉的配套项
- 时间同步。跨地域集中检索的前提是所有来源的时间戳可比。分支节点与采集端都应纳入统一的时间同步体系，否则跨源关联出来的顺序是错的，而这种错误在单个分支内部看不出来。
- 区域节点的运维归属。区域节点是新增的一层资产，需要有明确的责任团队与监控项。如果它只被当成采集端的放大器，链路或节点掉线就可能长期无人发现——因为这一层不产出日志，它只运输日志。
边界与前提
文中所述的存储周期、节点规模与带宽口径均为行业通行的参考值，具体以本单位所属行业的监管要求与项目实测数据为准；不同日志类型的解析与索引开销差异较大，规划时应以试点数据外推，而不是按来源数量估算。深圳市奇摩计算机有限公司在为客户做日志平台规划时，通常把布点方式与留存策略放在同一轮确定，因为这两项共同决定存储与链路的预算，分开定容易出现一处改了另一处跟不上。预约咨询。