无侵入式日志采集落地：选型、可靠性设计与验证

上周又被拉去救了一次火。某条跑了七年的业务线出了线上问题运维只能一台台登机器grep日志散在三台虚机的四个目录里故障复盘会都开完了日志还没捞全。团队不是没想过改造——代码里全是String.format拼出来的字符串想加结构化埋点动一行要走两轮评审上线窗口排到三个月以后。这种局面下唯一能落地的路子就是无侵入式日志采集业务代码一个字不改进程不重启靠一个独立运行的采集 Agent 把已经落到磁盘或输出到控制台的东西捞出来、解析、送走。这个方案听起来简单真做起来坑比想象多得多——位点丢了重复采、日志轮转后文件被漏掉、多行堆栈被切成一堆碎片、Agent 自己内存吃爆把宿主机拖垮每一个都能让你在半夜被叫起来。这篇就把我这几轮落地过程中摸出来的东西摊开讲从技术路线选型到可靠性设计再到验证方法适合正在做日志治理、可观测性建设或者手上有一堆改不动代码的老系统的同行参考。1. “无侵入”这三个字的实际边界改代码之外的四种侵入面很多人对无侵入的理解停留在“不修改业务代码”这一层觉得只要不 import 任何 SDK、不加一行埋点就算无侵入了。这个理解在评审会上很容易被架构师一句话问穿那你多起了一个进程算不算侵入你把日志格式改了算不算侵入你在宿主机上装了个内核模块算不算侵入所以动手之前先把“侵入”这个词拆开看比急着选型重要得多。1.1 代码侵入只是四个维度里的一个我把侵入面拆成四层每一层都有自己的验收标准谈方案的时候逐层过一遍能避免大量后期的扯皮。代码侵入最好理解指是否需要改动业务源码、引入新的依赖库、修改编译脚本。真正严格的无侵入要求连配置文件都不动业务侧的因为配置文件往往也在业务仓库里改一次同样要走发布流程。运行时侵入指采集动作是否进入了业务进程的地址空间。像动态链接库预加载、JVM 的 Agent 挂载、字节码增强这些虽然不用改代码但实实在在地把代码注入到了业务进程里会影响它的内存布局、类加载顺序、甚至崩溃时的堆栈信息。这一层的侵入在故障定位时是有代价的——业务进程 OOM 了你得先排除是不是采集组件引起的。运维侵入指是否要求业务方改变现有的部署方式、启动脚本、容器镜像构建流程。比如要求业务容器必须挂载一个 sidecar、要求启动命令前加个包装脚本、要求调整文件描述符上限这些都是运维侵入。它不体现在代码里但会体现在发布单和变更评审里。组织侵入最容易被忽略但杀伤力最大是否需要另一个团队的审批、是否要拉一次跨部门的架构评审、是否要占用业务线的发布窗口。有些方案技术上无侵入但流程上要盖五个章落地周期比改代码还长。1.2 一张判定表什么系统才真的“可无侵入采集”在给一个系统定方案之前我会先填一张表把它的日志落地形态、运行环境、变更权限逐项确认。这张表填完方案基本就唯一确定了不需要再争论。维度关键问题影响的技术选择日志落地形态写文件、写 stdout、还是走网络直发决定采集入口是 tail 还是运行时钩子还是旁路是否有固定磁盘路径路径是否可配、是否按日期分目录决定文件发现策略进程是否可控能否重启、能否加启动参数决定能否用需要重启才生效的方式运行形态物理机、虚机、容器、Serverless决定采集组件的部署位置日志框架是否有统一的日志门面、是否可改配置决定能否从配置文件层做轻量接入数据敏感度是否含个人信息、是否需要脱敏决定解析链路上是否要加过滤环节最理想的情况是日志写固定路径的滚动文件、进程可重启、日志框架有统一门面——这时候纯文件采集就能搞定是标准意义上的无侵入。最麻烦的是日志只写 stdout、进程一天重启八次、还跑在弹性伸缩的容器里这种就得靠容器运行时层或者节点级采集来做。提示判定表里“进程是否可控”这一项经常被误判。业务方说“可以重启”实际含义往往是“下个季度可以重启”。把时间窗口问清楚很多需要重启才生效的方案可以直接出局。2. 从日志落地形态倒推采集路径五条技术路线的适用面技术选型这件事我见过最常见的错误是先定了工具再去找场景结果发现工具的能力和日志的落地形态对不上硬凑出来的方案又慢又不稳。正确的顺序是反过来先看日志最终以什么形式存在再倒推用哪条路径去捞工具只是路径的实现载体。2.1 文件落盘型tail 加 inode 追踪是最扎实的地基绝大部分后端服务的日志最终还是落地成文件这是最友好的一种形态因为文件系统提供了完整的语义路径、inode、偏移量、修改时间。采集器的核心逻辑说白了就是三件事——发现文件、跟踪偏移、处理轮转。发现文件这一步很多人直接用目录轮询每隔几秒扫一遍stat。这在文件数量少的时候没问题几千个文件以上就会明显吃 CPU。更省的做法是结合文件系统事件通知机制监听目录变化只在事件触发时才做stat轮询作为兜底。这里有个细节事件通知在容器里跨挂载点经常不可靠尤其是宿主机目录挂进容器的情况事件可能丢失。所以我自己的实现里事件通知只作为加速手段兜底轮询周期设在 5 到 10 秒宁可多扫几次也不能漏。跟踪偏移量必须绑定 inode 而不是文件名。原因很直接日志轮转时旧文件被重命名新文件在同一个路径上创建如果按文件名记录偏移你会把新文件的读取位置错误地继承成旧文件的偏移直接丢掉一整个文件的内容。按 inode 记文件被重命名后依然能继续读完剩余内容新文件是新的 inode从零开始读逻辑自洽。2.2 stdout 与容器运行时日志根本不在你的文件系统里容器化之后情况变了。很多服务把日志打到标准输出由容器运行时接管最终落在宿主机上的某个目录里路径里带一长串容器 ID。业务方看不到这个路径也不该依赖它。这种场景的采集点其实有两个。一个是节点级在每台宿主机上跑一个采集 Agent直接读运行时管理的日志目录。好处是资源统一管理一个节点一个 Agent容器起停不影响采集器生命周期。坏处是你得知道运行时的目录布局而且不同运行时的布局规则不一样版本升级还可能变。另一个是容器级 sidecar每个业务 Pod 配一个采集容器通过共享的日志卷读取。好处是隔离性好业务和采集生命周期绑定。坏处是资源开销按 Pod 数量线性放大一个节点上三十个 Pod 就是三十份额外的内存和 CPU而且共享卷的配置本身就要改部署描述文件这已经是运维侵入了。我一般的判断标准是Pod 数量多、单 Pod 日志量小走节点级Pod 数量少、日志量大且需要独立配额走 sidecar。中间地带就看团队更擅长运维哪种形态。2.3 用户态钩子不重启也能接进去但代价要想清楚有些系统的日志根本不落盘也不走标准输出而是自己攒在内存缓冲区里定期批量发往某个内部地址。这种就得在用户态做文章了。常见的手法有三类动态链接库预加载拦截底层的写调用、JVM 的运行时挂载注入、以及字节码增强。预加载这条路原理是在进程启动时把自定义的库塞到最前面拦截write、fwrite这类符号把内容复制一份出来再交给原始实现。优点是对任何语言都生效缺点是最致命的一条——必须重启进程才生效因为预加载发生在启动阶段。另外它跟静态编译的程序、Go 这类自己实现运行时的语言基本无缘。JVM 挂载的好处是可以在进程运行中动态附加不需要重启。它会加载一个代理包进目标进程然后通过字节码改写把日志框架的输出方法包一层。这条路技术上很优雅实际用起来有两个必须提前确认的点一是目标进程的 JVM 参数里是否允许附加有些生产环境为了安全把附加能力关掉了二是字节码改写对启动耗时和内存的影响得在预发环境实测不能拍脑袋。2.4 内核态采集能力最强代价也最需要量化系统调用层的采集是在内核里挂钩子把进程的写操作在系统调用入口处截下来。这条路的最大优势是彻底的语言无关——不管你是 Java、Go、还是某个十年前写的 C 程序只要最终调用了写系统调用就能被看见。同时它完全不需要重启也不需要改任何配置。代价有两块。第一块是性能高频小写入的场景下每次写都要过一次钩子开销是可测量的必须用压测对比开关前后的吞吐和延迟不能凭感觉说“影响很小”。第二块是环境依赖它需要较新的内核版本需要特定的权限在一些受管控的运行环境里根本装不上。我在评估这条路的时候第一件事不是看功能而是拿目标机器的内核版本和权限策略去对对不上就直接排除省得做完 PoC 才发现上不了线。2.5 旁路与网络侧日志本来就要发出去的时候还有一类系统日志是通过网络协议直接发往某个采集端点的比如走系统日志协议或者自定义的 TCP 通道。这种场景下最省事的做法是改采集端点地址让流量先经过你的采集层再转发出去。这算不算侵入我认为算轻量侵入——配置要改但改的是配置不是代码而且如果原本就支持多目标输出连改都不用改加一个目标就行。前提是业务侧的日志框架确实支持多目的地输出这一点务必要确认很多自研的日志组件只支持单目标那就退化成要改代码了。2.6 五条路线的选型对照把上面几条路线放在一起比判断的维度其实就四个要不要重启、要不要改配置、语言是否无关、性能开销量级。路线需重启需改配置语言无关相对开销典型适用文件 tail否否是低日志落固定路径节点级容器日志采集否否是低容器化、Pod 密集sidecar 采集否是是中需要独立配额用户态钩子视方式视方式部分中日志不落盘内核态采集否否是中高完全无法干预进程选型的时候还有个隐性维度可回退性。文件采集出问题停掉 Agent 就行业务无感用户态钩子出问题可能要重启业务进程才能摘掉这个差别在故障预案里是决定性的。我倾向于优先选可回退性最好的方案哪怕它的功能弱一点。3. 采到只是开始日志解析链路上的四个硬骨头数据从文件里读出来只是拿到了原始字节流。真正决定这套方案好不好用的是解析这一层。我见过太多项目在采集环节做得很漂亮结果解析出来的字段错位、时间戳乱序、堆栈被切碎下游查询根本没法用最后整套东西被判定为“不可信”而废弃。3.1 多行日志合并堆栈是你最大的敌人一条异常堆栈在文件里是十几行每行看起来都像独立日志。如果按行切一条异常就变成十几条互不相关的记录排查的时候根本串不起来。合并逻辑必须做但做得不对会引入新问题。判断“这一行是不是上一条的延续”最稳的信号是行首格式。先确定一个行首模式比如以时间戳开头、或者以固定的日志级别标记开头凡是匹配不上的行就归到上一条。这个方法对绝大多数框架输出有效成本也低。问题出在边界情况上。第一日志文件的第一条记录可能就是延续行——因为你在文件中间开始读前面那条日志的头部在上一段。这时候没有“上一条”可挂只能单独处理通常做法是先缓存等下一个合法行首出现时再决定丢弃还是补一个合成头部。第二相邻的两条日志间隔很久你无法判断是业务静默还是采集卡住了需要加超时刷出机制超过窗口没有新行就强制把缓冲区内容发出去不然一条孤立的堆栈可能永远卡在内存里。超时窗口怎么定太短会把完整堆栈切断太长会拖高延迟。我的经验值是根据日志产生速率来调高频服务用 500 毫秒到 1 秒低频后台任务用 2 到 3 秒。这个值必须做成可配置的上线后按实际数据调不要写死。3.2 时间戳与时区采集时间永远不等于业务时间采集器会自然带上“我什么时候读到这条日志”的时间这个时间只能用于计算采集延迟绝不能当作业务事件时间写进数据里。业务事件时间只有日志正文里的那个时间戳才是准的。正文时间戳的解析有几个常见麻烦。一是格式不统一同一个系统里不同模块用了不同的时间格式甚至同一行里出现两种。这时候要做格式探测按优先级依次尝试全都不中就把这条标记为解析异常而不是硬塞一个默认值。二是时区缺失很多日志只写“2024-05-11 14:23:01”不写时区。这时候只能按运行环境的本地时区推断并且要在数据里明确打上“推断得来”的标记避免后面做跨机房分析时把不同时区的数据混在一起排序。三是精度问题。有些日志精确到秒有些到毫秒有些到微秒混在一起排序时会因为精度不一致出现视觉上的乱序。我的处理办法是在解析层统一补齐到同一个精度并把原始精度记在元数据里下游做严格时序分析时把它作为参考。3.3 编码、截断与超长行那些让解析器崩掉的输入日志文件里出现非法字节是常态尤其是在业务代码用默认编码输出、而机器 locale 又不统一的环境里。解析器如果对编码不做容错遇到一个坏字节就可能整条丢弃甚至抛异常中断整个读取循环。处理原则是解码永不失败。遇到非法字节序列时用替换字符占位同时把这条记录标记为编码异常保留原始字节的十六进制摘要方便事后定位是哪段代码输出的。这么做的前提是原始文件不能被删掉所以采集层必须保证“只读不删”清理策略交给独立的归档流程。超长行同样要防。有些业务在异常处理里把整个请求体打进日志一条日志几百 KB还有的把二进制内容 base64 后直接输出单行几兆。采集器如果按行读取且不设上限内存会被瞬间打满。必须设单行长度上限超过就截断并标记同时记录原始行长度。这个上限不能设得太小我一般设成 256 KB既能覆盖绝大多数异常输出又不会让缓冲失控。注意截断操作一定要留下明确的标记字段。我曾经遇到过截断后没有标记下游看到一条看似完整的 JSON 被切掉后半段解析失败却查不出原因排查了半天才发现是采集侧截的。3.4 字段化正则不是长久之计把半结构化的日志文本变成结构化字段最常见的做法是写正则。正则上手快、表达力强但维护成本随时间线性增长——业务加一个字段正则改一遍业务改了字段顺序正则再改一遍某天出现一个不带某字段的日志正则匹配失败整条数据变成“未解析”。我的做法是分两层。第一层是通用提取只抓那些位置固定、格式稳定的部分比如时间戳、日志级别、线程名、类名用一组相对宽松的正则兜底。第二层是业务字段提取优先推动业务方输出键值对格式哪怕只是把user123这种简单形式塞进消息末尾也比纯文本好解析得多。这一步严格说算轻量侵入但只改日志输出格式不改业务逻辑评审成本低很多实际推动起来阻力没想象中大。实在没法推动退而求其次用分组的正则模板按日志来源配置多套模板匹配时按顺序试。模板数量上去之后要加缓存把“行首特征到模板”的映射缓存起来避免每行都跑全部模板。这个优化在日志量大时效果非常明显。4. Agent 自身的可靠性断点、背压与被采集方的隔离带采集 Agent 是个长期运行的独立进程它自己也会出问题。我见过最惨的一次事故不是采集丢数据而是采集器内存涨到几个 G触发了宿主机上的资源管控把同机的业务进程一起带走了。所以这一层的设计原则只有一条采集器可以丢数据但绝不能影响被采集方。4.1 位点持久化inode、偏移量、文件指纹三件套位点记录的是“某个文件我读到哪了”最少需要三个信息inode、偏移量、文件指纹。少了任何一个都会出问题。只有路径和偏移量轮转后必然错乱加上 inode 能解决轮转问题但如果文件被删除后重建inode 可能被复用新文件继承了旧位点就会从头跳过一大段。所以还要加指纹通常用文件的前 N 个字节的哈希读文件前先比对指纹不一致就认为这是一个新文件位点归零。持久化的频率也要权衡。每条都写盘IO 压力大写得太稀进程崩溃时回退的距离长会重复采集。我的经验是两条线同时用按时间每秒落一次按数据量每积累 64 KB 或每 N 条落一次两者谁先到就触发。写入用先写临时文件再原子重命名的方式避免写一半崩溃导致位点文件损坏。位点文件损坏了怎么办要有降级策略。我的做法是保留最近两份位点快照主文件解析失败就读备份两份都坏就从头读该文件并打上“可能重复”的标记让下游做去重。宁可重复不可丢失这个原则在日志场景基本是共识。4.2 日志轮转的三种形态坑各不一样轮转方式决定了采集器要处理的具体情况很多人只考虑了第一种上线后被后两种打得措手不及。重命名式当前文件改名为带日期后缀的名字然后创建同名新文件。这是最常见的形态采集器靠 inode 追踪能正常读完旧文件。坑在于旧文件改名后可能很快被压缩或者删除所以采集器要优先把已轮转但未读完的文件排在前面并且设一个“追赶”机制短时间内提高读取速率。复制加截断式先把内容复制到归档文件然后把原文件截断为零长度。这种最阴险因为 inode 没变文件还是同一个但内容没了。如果采集器只看 inode 和偏移量会发现偏移量已经超过文件大小这时候必须能识别出“文件被截断”这个事件把偏移量重置为零重新读。判断依据就是当前文件大小小于记录的偏移量。按序创建式按序号命名比如.1、.2、.3每轮转一次序号整体后移。这类日志的特点是文件数量固定、内容不断变化。采集器要能识别出序号语义不能把它当成普通的新文件反复重读。这类场景不多但确实存在遇到的话老实按规则解析序号别想通用方案。4.3 背压与内存水位什么时候该主动丢日志采集器读到数据后要经过缓冲、解析、序列化、发送几个阶段。只要下游发送慢下来上游还在源源不断读缓冲区就会涨。如果不设上限涨到最后就是 OOM。正确的做法是在链路上设多级水位每一级的处理策略不同。先算一下实际情况假设一个服务每秒产生 2000 次请求每请求 3 行日志平均每行 220 字节那么日志产生速率大约是 1.3 MB/s一天就是 110 GB 左右。如果下游因为网络抖动停了 30 秒需要缓冲的数据就是 40 MB停 5 分钟就是 400 MB。这个量级决定了你不能只靠内存扛。水位阈值示例处理动作低水位队列占用 40%正常读取中水位40% 至 70%降低读取速率触发批量合并发送高水位70% 至 90%落盘缓冲暂停新文件接入超高水位 90%按优先级丢弃记录丢弃计数与原因关键在于“按优先级丢弃”这一条要提前设计好。什么是高优先级我的规则是错误级别日志、首次出现的日志模板、来自核心路径的日志优先保留重复度高的信息级日志优先丢。丢弃必须计数并且上报绝不能悄悄丢——静默丢数据比明确丢数据危险得多因为没人知道数据不完整。磁盘缓冲也不是无限的要设配额并且配额要按节点上所有被采集服务的日志量总和来估。我的做法是给缓冲区一个明确的字节上限写满之后回绕覆盖最旧的数据同时打点告警。回绕而不是停止是为了保证最近的日志一定在这符合排障的实际需求。4.4 资源硬约束把 Agent 关进笼子里不管采集器写得多好都要假设它会出 bug。所以必须在外部给它套笼子CPU 配额、内存上限、句柄数上限、磁盘配额一条都不能少。内存上限怎么定我的算法是基础常驻内存 单文件读取缓冲 × 并发文件数 队列内存上限 解析缓冲。假设基础 80 MB单文件缓冲 1 MB同时跟踪 200 个活跃文件队列上限 128 MB解析缓冲 32 MB加起来就是 440 MB 左右那么设置 640 MB 的硬上限留出余量。这个数字不是拍出来的是算出来的而且要按“最坏情况”算不是按平均值算。句柄数容易被忽略。每个被跟踪的活跃文件占一个句柄轮转后旧文件在读完之前还要继续占着所以要按活跃文件数的 2 倍来估。200 个活跃文件就是 400 个句柄加上网络连接、位点文件、临时文件设 1024 比较稳妥。如果业务方的容器本身就把句柄限制压得很低这一个约束就足以让方案不可行必须提前确认。CPU 限流要在 Agent 内部自己做不能只依赖外部限制。做法是给读取循环加节流每读取 N 个字节检查一次累计耗时超过预算就主动短暂休眠把 CPU 让出去。这个机制在日志突发时尤其重要——业务高峰产生大量日志如果采集器拼命读会把 IO 和 CPU 抢走直接影响业务。5. 上线前的验证方法如何在不动业务的前提下证明方案可行方案做完了最大的风险不是跑不起来而是“跑起来了但数据不对”。日志这种数据有个特点少了没人及时发现多了也没人及时发现等真出事要用的时候才发现缺了三天那就彻底被动了。所以验证环节必须做得比功能本身更扎实。5.1 影子采集先并跑再切换我一般的做法是先做影子采集也就是新方案上线但不下掉旧链路两路数据同时产出在下游做比对。这个阶段不接管任何查询纯粹用来验证正确性。影子阶段至少要覆盖三类场景正常业务流量、日志轮转触发、业务进程重启。第二类场景很多人不主动构造就等着自然发生结果等了半个月没等到上线后第一次轮转就出问题。轮转是可以手动触发的写个脚本把日志文件改名或者直接把当前日志写满触发按大小轮转都能在十分钟内造出来。第三类是进程重启重启前后的位点续接、重复采集情况必须实测。比对的方式是抽样对账不是全量比对。从旧链路和新链路各取同一个时间窗口的数据比较总条数、各级别条数、按来源模块分组的条数误差在万分之一以内就算通过。为什么不是零误差因为两边的读取时机不同窗口边界上必然有几条差异这是正常的但不能有系统性偏差。5.2 一份可以照着打勾的上线核对清单下面这份清单是我每次上线前都会过一遍的看着啰嗦但每一条都对应过至少一次真实事故。检查项验证方法通过标准位点续接正确停止 Agent 十分钟后重启不丢不重或仅有极少量重复轮转不丢数据手动触发重命名式轮转旧文件剩余内容被完整读完截断能被识别手动清空当前日志文件从零开始读不出现读取错误多行合并正确构造一条 20 行堆栈合并为一条行数记录准确超长行不崩写入一条 1 MB 的单行日志被截断并标记进程稳定非法编码不中断写入含非法字节的行该行被标记后续行正常读取下游断开不丢内存停掉下游五分钟队列不超上限落盘生效资源上限生效压测至超限CPU 与内存被限制在设定值内丢弃有计数制造超水位场景丢弃数量与原因可查询到这张表里最容易被跳过的是“下游断开”和“丢弃有计数”两项。前者因为不好测后者因为觉得不会发生。真实情况是这两个场景一旦发生没有准备就是灾难。5.3 出问题时的排查链路从现象到根因的完整路径线上真出问题时最怕的是没有排查路径东一榔头西一棒子。我把常见的现象归成四类每类有一条固定的排查顺序。现象一下游查不到某段时间的数据。先看采集器自身指标那段时间的读取速率是否归零。归零就往上一层看是文件发现环节没找到文件还是位点错误导致跳过了。发现环节的话检查文件是否被移动到了未被监控的目录或者文件名模式没匹配上。位点问题的话直接读位点文件比对 inode 和当前文件是否一致不一致基本可以确认。如果读取速率正常但下游没有问题就在发送环节看队列是否积压、下游是否返回错误再看是否有网络侧的连接问题。现象二数据有重复。先确定重复的边界特征是完全相同的记录重复还是内容相同但时间戳不同。后者往往是多行合并时超时刷出导致的一条日志被拆成两次发送。前者一般位点回退导致去找那段时间是否有 Agent 重启、位点文件是否写失败。如果重启时间对得上就是位点持久化频率太高导致回退调低频率或者缩短持久化间隔。现象三采集器内存持续上涨。按内存构成逐项排查。先看队列长度如果队列持续满载说明下游跟不上这是最常见的原因。队列正常但内存还是涨看活跃文件数是不是异常多某些场景下日志目录里堆了几万个历史文件采集器把它们全纳入跟踪内存和句柄都会被吃掉这时候要加文件数量上限和按修改时间过滤。这两项都正常就看解析环节是否有某个正则在大文本上回溯爆炸这种情况通常伴随 CPU 也居高不下。现象四业务方反馈性能下降。这个是最高优先级的先停采集器验证因果关系不要花时间争论“应该不会”。确认相关之后按 IO 和 CPU 两条线查IO 方面看读取是否过于激进是不是该加节流CPU 方面看解析和序列化是否占用了太多尤其是正则匹配和 JSON 序列化这两处。还有一个隐蔽的原因是采集器和业务在同一个磁盘上大量顺序读把页缓存挤掉了导致业务的文件读命中率下降。这种情况的解法是给采集设置读取速率上限或者错峰读取历史文件。6. 一次完整形态的落地复盘某内部遗留系统的采集改造说个具体形态的案例把上面这些零散的点串起来。项目背景是一个内部业务系统代码十年没大改过日志用自研的一个薄封装输出格式是自己拼的字符串落盘路径按天分目录单文件到 512 MB 触发轮转。整个系统跑在六台虚机上没有容器进程一周重启一次。6.1 约束条件决定了方案空间有多窄第一条约束是代码不能动评审周期按季度算。这一条直接排除了所有需要改日志框架配置的方案——配置文件虽然不在代码仓库里但改动同样要走变更流程而且业务方明确表示不愿意在这个季度碰。第二条约束是不能重启只能等每周的例行重启窗口。这意味着用户态预加载这类方案要么等到下周要么放弃。第三条约束是机器上已经装了安全管控软件禁止加载内核模块。内核态采集这条路直接封死。三条约束一叠加剩下的就只有文件采集这一条路。好在日志确实落了固定路径的滚动文件这条路是通的。6.2 方案拼装时的几个具体取舍路径发现这块按天的目录结构意味着每天会有新目录出现监控的根目录固定但要递归发现子目录。我用了事件通知加轮询兜底的方式兜底周期设 10 秒因为这台机器上文件数量不多轮询开销可以接受。位点存储用的是本地文件加内存缓存双层结构。为什么不用外部存储因为这台机器网络到外部存储的链路不稳定一旦外部存储不可达位点写不进去整个采集就得停。本地文件最可靠代价是如果整机挂了位点会丢但那台机器上的日志本来也读不到了影响可接受。多行合并这块遇到了一个实际问题这个系统的日志行首格式不统一有的模块以时间戳开头有的以方括号包起来的模块名开头。最初的实现只认时间戳结果以模块名开头的那些日志全部被判为延续行粘到了上一条后面。改法是先把行首模式做成一组命中任意一个就算合法行首另外加一条规则如果连续 N 行都不匹配任何模式强制断开避免正常日志被无限粘连。解析这块没有强行做全字段结构化只提取了时间戳、级别、模块名三个字段剩下全部放在原始消息里。原因很现实这套日志的格式太随意做全量字段化需要维护几十条正则维护成本远高于收益。先把数据完整采上来结构化的事情后面慢慢做顺序不能反。6.3 上线后的实际效果和没解决掉的问题上线跑了一个月日均采集量 90 GB 左右采集延迟的 99 分位在 3 秒以内没有出现过 Agent 导致业务异常的情况。资源占用稳定在单实例 CPU 5% 左右、内存 380 MB和当初估算的 440 MB 上限基本吻合。没解决掉的问题有三个。一是历史文件追溯方案上线前的日志没法补采只能靠归档系统里的压缩包但那些包里的时间戳格式和现在不完全一致查询时需要额外处理。二是某些模块的日志会在运行中切换输出路径切换瞬间可能丢几条这个属于业务侧的行为采集层没法完全避免只能在位点里加路径变更检测降低影响面。三是日志里包含一些不该长期留存的内容脱敏逻辑加在了发送前但原始文件还是原样躺在磁盘上这部分要靠归档流程的清理策略解决采集层管不了。最后分享一个我在这个项目里学到的小经验采集方案的价值不取决于它多先进而取决于它在出问题时能不能被快速关掉。这个项目最后之所以能顺利推下去很大程度上是因为方案里有一条明确的回退路径——停掉 Agent 进程业务完全不受影响这条承诺让业务方在评审时的抵触小了很多。所以每次设计采集方案我都会先想清楚“怎么关”再想“怎么开”。