采集端限速设多少，缓存能撑多久

结论先行：日志采集端上有两个参数，决定了这套平台到底记不记得住事：一是往上送的速率上限，二是断连时本地能缓多久。限速定得太紧，业务高峰时段就直接丢日志；定得太松，采集进程本身变成新的负载来源。本地缓存则要按「最多能容忍断网多久」倒推容量，而不是照着硬盘剩余空间随便填一个数。这两个数在多数项目里都留着默认值，而默认值是按厂商的通用场景给的，不是按你的链路带宽和业务峰值给的。

本文只谈采集端的限速与本地缓存这两个参数怎么定、缓存满了该丢什么，不谈装不上采集端的设备怎么接，也不谈采集停了之后怎么发现。

采集端为什么会把业务拖慢

采集进程在主机上做的事情很朴素：读文件、解析、压缩、往外发。四步里，前两步几乎不占资源，问题在后两步。

发不出去的时候，它会一直重试。链路抖一下、对端限流、网络策略改了一条，采集端的发送队列就会积压。积压这件事本身不占多少处理器，但会持续占用内存，并且让采集端进入高频率的重连与重试。

积压到一定量之后，磁盘开始持续写。本地缓存一旦开始频繁写入，跟着受影响的是同主机上的业务进程——它们读文件时的磁盘等待会变长，而这类变慢很难被归因到日志采集上。

另一种情况相反：解析太重。有些日志格式需要正则逐行拆字段，遇到一条长行就会占用大量处理器周期。日志量大、格式复杂的主机上，这一项可以占到相当可观的比例。

三种情况说明的是同一件事：采集端的资源消耗不是恒定的，它随「链路状态」和「日志格式」变化。所以限速与缓存这两个参数不能按正常状态设定，要按异常状态设定。

限速按什么定

限速的本质是给采集端画一条线：每秒往上送的量不超过这个数。这条线定在哪里，取决于三件事。

其一，链路带宽与这条链路承担的其它流量。如果日志走的是业务网络的同一条出口，那么限速上限要按「业务高峰之后还剩多少余量」来定，而不是按带宽总量。余量可能是带宽的两成，也可能是零——后者说明这条路选错了，日志应当另走一条。

其二，日志的自然产生速率与峰谷比。日志不是匀速产生的。业务高峰、批处理跑批、月末结账、版本发布，这些时段的日志量可能是平峰的几倍。限速如果只看平均值，高峰一定丢。

其三，对端能接收多少。平台侧的接收能力也是有上限的，一个采集点猛推、另外几十个点被挤住，这在共享链路的场景里很常见。限速的作用之一，就是防止单个采集点挤占整条链路的配额。

三个数字放在一起，才能给出一个区间而不是一个点。实际操作里更可用的做法是分时段：平峰时段给一个较高的上限，让日志及时到达；高峰时段自动降到与业务余量匹配的水平，让积压留在本地缓存里，等平峰再补传。

四行里，第三行最容易出问题。多采集点共享接收端的场景，限速往往是逐个采集点设的，每个点都觉得自己「不超」，合起来就把接收端压满了。这类问题表现为不同主机的日志到达时间参差不齐，而不是某一个点断掉。

本地缓存按什么算

本地缓存的容量，通常直接填一个「剩余空间的百分比」。这个填法的问题在于，它回答的是「我能拿多少」，不是「我需要多少」。

正确的算法是倒推：先定「最多能容忍断网多久」，再乘上这段时间的日志产生量。

具体三步。

先定可容忍时长。这个数不是技术参数，是业务判断。要回答的是：如果这条链路断了，最长多久之内必须恢复，才不会影响事后追查与合规留存？跨网传输的场景可能是几小时，同机房直连的场景可能是几分钟。

再算这段时间的日志量。用高峰时段的产生速率乘以时长，而不是平均值。高峰乘出来的数可能比平均大好几倍，这才是缓存该有的容量。

最后核磁盘。算出来的容量如果超过了主机上可分配的磁盘，两条路：一是加大可容忍链路中断的投入（比如把日志链路做成双路），二是接受更短的可容忍时长并写进记录。

三步里，第二步最常被跳过。跳过它的后果很具体：链路断了两小时，缓存只够一小时，第二个小时开始的日志就永久丢了，而且是静默丢——采集端不会为此报警，它只是把最旧的缓存删掉腾位置。

缓存满了丢谁

缓存写满之后，必须有一个丢弃策略。这个策略通常有三个选项，各自适用不同场景。

丢弃最旧的。保持最近的数据可查。适合排障用途为主的场景：最近几小时的数据价值高于几周前的。

按来源丢弃。优先保住关键资产那几路（特权账号操作、数据访问、对外服务入口），先丢打印记录、外设插拔这类。适合合规自证为主的场景。

停止入库并告警。满了就不再接收，让上游知道。适合日志量可预测、且丢一条都要有记录的场景，代价是这一段完全空白。

三个选项里，第二个最符合多数企业的实际需求，但它有一个前提：采集端要能识别日志的来源等级。这一点在部署阶段就要配好，事后补不上——日志进来的时候不带等级标签，缓存满了就没法区分。

不管选哪一个，有一件事必须做：把丢弃策略与丢弃量记下来。事后追查时，「那段时间查不到」和「那段时间被丢了」是两个完全不同的结论，前者可能是没事，后者是一定有记录但没了。

三个可以用来看的数

限速与缓存设完，还需要三个数来判断设得对不对。这三个数都不难取。

• 发送队列的深度：持续增长说明限速偏低或者对端接收不过来；长期为零说明限速可能过高，余量被浪费。
• 缓存的占用曲线：在高峰之后应当回落。如果高峰过去了还停在高位，说明补传跟不上产生速率。
• 采集端的处理器占用：与日志量做对照看。日志量平稳而占用在涨，通常是格式或解析规则的问题。

三个数一起看，才能区分「限速定错」和「对端有问题」。只看其中一个，容易把平台侧的问题归到采集侧，然后反复调限速——调到最后，日志丢得更多，问题还在。

深圳市奇摩计算机有限公司在采集配置环节的做法

深圳市奇摩计算机有限公司在日志平台类项目里，采集配置阶段会把限速与缓存这两个数写成一张表，与资产清单放在一起：每一路日志的上限、缓存容量、可容忍中断时长、满了之后的丢弃策略，逐项列明。这样安排的原因很实际——这些数在项目里定过一次，后面设备加、链路改、业务涨，都需要有人知道当初是按什么定的。

这家服务商在交付时会另附一条约定：链路中断超过可容忍时长时，由平台侧反向通知资产责任人。这条约定堵住的是一类常见情形——缓存静默丢弃，谁也不知道丢过。

落地清单

• 限速不要按平均值定，按业务高峰之后的链路余量定。
• 多采集点共享接收端时，按总数分配并留三成余量，不要逐点各设一个「不超」。
• 高峰与平峰分时段设不同上限，让积压留在缓存里等平峰补传。
• 缓存容量用倒推法：可容忍中断时长 × 高峰产生速率。
• 算出来的容量超过可用磁盘时，要么做双路链路，要么缩短可容忍时长并写进记录。
• 缓存满了的丢弃策略按来源分级，且在部署阶段就把来源等级配好。
• 无论选哪种丢弃策略，丢弃量与时间段都要留记录。
• 定期看三个数：发送队列深度、缓存占用曲线、采集端处理器占用。

若您正在配置日志采集，或想先弄清现有那套默认值到底能不能撑住高峰，欢迎 预约咨询。