引言
容器化让应用部署变得轻盈，却让日志管理变得沉重。当一个业务系统拆分成十几个甚至几十个微服务，每个服务运行在独立的容器中，日志就像被撒了一地的拼图碎片——你知道它们存在，但拼不出完整的画面。登录容器看日志？容器重启后日志就丢了。用 Docker 原生日志驱动？只能存到宿主机本地，检索全靠 grep。更头疼的是，多个容器的日志时间线对不齐、关键字段缺失、高频日志把存储打爆……这些问题的根源，不在于日志不重要，而在于你缺少一套统一的、自动化的日志采集与聚合体系。天翼云日志服务CLS（Cloud Log Service）提供的日志采集器，正是为解决这一痛点而生。它以DaemonSet方式部署在集群每个节点上，自动发现容器日志流，统一采集、清洗、存储、检索。但"装上采集器"和"把日志收全"之间，隔着一系列容易被忽视的配置细节。本文将从采集器的工作原理出发，拆解多容器日志聚合的完整配置流程与实战避坑指南。
一、先诊断：你的日志为什么"收不全"
在动手配置之前，必须先搞清楚日志丢失的真实原因。根据实战经验，日志收集不全通常由以下五种情况导致：
第一，采集器没有覆盖到所有节点。 很多团队只在默认节点池部署了采集器，但新扩容的节点池没有同步部署，导致新节点上的容器日志完全处于"裸奔"状态。
第二，日志路径配置错误。 容器日志的默认路径是标准输出和标准错误流，但有些应用会将日志写入容器内的自定义文件路径。如果采集器只配置了标准输出采集，那些写入文件的日志就会被遗漏。
第三，采集规则过于粗糙。 默认的采集规则是"全部采集"，但在高并发场景下，这意味着大量无价值的调试日志、健康检查日志也被一并采入，不仅浪费存储，还把真正关键的业务日志淹没在噪音中。
第四，多行日志被截断。 栈 trace、异常信息通常是多行的，如果采集器按单行切割，一条完整的异常栈就会被拆成十几条碎片，排查问题时根本无法还原现场。
第五，时间戳缺失或不准确。 日志没有时间戳，或者时间戳是容器启动时间而非日志产生时间，会导致多容器日志聚合后时间线完全错位，根本无法还原一次请求的完整调用链。
这五个问题，前两个是"收不到"，后三个是"收到了但没法用"。CLS日志采集器的配置，必须同时解决这两类问题。
二、CLS日志采集器的底层逻辑：它到底怎么工作的
CLS日志采集器以DaemonSet方式部署在CTK集群的每个工作节点上，这意味着每个节点上都运行着一个采集器Pod。采集器启动后，会自动扫描节点上所有运行中的容器，识别其日志输出源（标准输出、标准错误或指定文件路径），然后将日志流实时发送到CLS服务端进行存储和索引。
这个架构有两个关键优势：一是无侵入，不需要修改任何业务容器的配置，采集器通过挂载宿主机的容器运行时socket自动发现日志源；二是全覆盖，只要容器在节点上运行，它的日志就一定会被采集，不存在"漏采"的可能。
但"自动发现"不等于"自动收全"。采集器需要明确的配置来告诉它：采集哪些容器的日志、从哪个路径采集、怎么解析多行日志、哪些字段需要提取。这些配置通过采集规则（采集配置）来定义，是整个日志体系能否运转的核心。
三、采集规则配置：四个关键参数决定收全与否
参数一：日志路径的精确指定。 虽然采集器支持自动发现，但强烈建议显式指定日志路径。对于标准输出的容器，路径为容器运行时的标准输出流；对于写入文件的容器，需要在采集规则中明确指定容器内的日志文件路径，并挂载对应的主机路径。特别注意：如果应用将日志同时输出到标准输出和文件，两条路径都需要配置，否则必然丢失一份。
参数二：多行日志的正则匹配。 这是最容易被忽略但影响最大的配置。Java应用的异常栈、Go语言的panic信息、Python的traceback，都是典型的多行日志。如果不配置多行合并规则，这些日志会被按换行符切成碎片。配置方式是提供一个正则表达式，用于识别多行日志的"起始行"。采集器在匹配到起始行后，会将后续直到下一个起始行之前的所有内容合并为一条完整日志。正则表达式的编写需要根据实际日志格式调整，建议先采集一批日志观察格式，再编写匹配规则。
参数三：时间戳的提取与格式化为。 容器日志本身可能不包含时间戳，或者时间戳格式不统一。CLS采集器支持从日志内容中通过正则表达式提取时间戳字段，并将其转换为统一的时间格式。这一步至关重要——没有统一的时间戳，多容器日志聚合后的时间线就是一团乱麻，根本无法用于故障排查。建议将提取到的时间戳字段设置为日志的主时间字段，覆盖容器的默认时间。
参数四：字段提取与过滤。 不是所有日志内容都有价值。采集器支持从原始日志中提取关键字段（如请求ID、用户ID、错误码），并将其作为独立字段存储，方便后续检索。同时支持过滤规则：将无价值的健康检查日志、心跳日志直接丢弃，不送入CLS，既节省存储成本，又降低检索噪音。
四、多容器日志聚合：从"单条日志"到"完整调用链"
收全日志只是第一步，真正的价值在于聚合——把分散在十几个容器中的日志，按一次请求串联起来。
核心手段：请求ID透传。 这是多容器日志聚合的基石。在请求进入系统的第一层（通常是网关或入口服务）时，生成一个全局唯一的请求ID，并在后续所有服务间的调用中通过请求头透传。每个服务在输出日志时，都必须将这个请求ID打印到日志中。CLS采集器提取请求ID字段后，你就可以在检索时输入一个请求ID，瞬间拉出这次请求经过的所有服务的全部日志，按时间线排列，完整还原调用链路。
如果你的应用没有请求ID透传机制，日志聚合就无从谈起。这不是CLS的问题，而是应用架构的问题。在配置采集器之前，务必先在应用层把请求ID透传做好。
聚合视图的配置。 CLS支持日志仪表盘功能，开发者可以创建多个聚合视图，每个视图针对一类业务场景。例如，创建一个"订单服务"视图，过滤条件为服务名包含 order 且日志级别为 ERROR，时间范围为最近一小时，聚合字段为请求ID。这样，运维人员打开仪表盘就能直接看到订单服务在过去一小时内的所有错误日志，按请求ID分组，每组内按时间排序，排查效率提升数倍。
五、实战避坑：四个最容易翻车的场景
坑一：采集器与容器日志驱动冲突。 如果你在Docker运行时层面同时配置了日志驱动和CLS采集器，可能出现日志被重复采集的情况。建议二选一：要么用Docker日志驱动将日志写入宿主机文件再由采集器采集，要么直接用CLS采集器采集标准输出，不要两者同时开启。
坑二：高频日志打爆存储配额。 调试日志在开发环境有用，在生产环境就是灾难。务必在采集规则中设置日志级别过滤，生产环境只采集INFO及以上级别的日志，DEBUG和TRACE级别的日志只在需要排查问题时临时开启。
坑三：采集器本身成为瓶颈。 当节点上容器数量极多（上百个）时，采集器的CPU和内存消耗会显著上升。建议为采集器Pod设置合理的资源配额，并开启采集器的背压机制——当采集器处理不过来时，自动降低拉取频率，而不是把节点资源吃光。
坑四：日志保留策略不合理。 默认的日志保留期可能是七天或三十天，但不同类型的日志需要不同的保留策略。错误日志建议保留三十天以上，访问日志保留七天即可，调试日志可以只保留一天。CLS支持按日志主题设置差异化的保留策略，务必根据业务需求逐一配置，避免存储成本失控。
六、监控采集器自身的健康状态
很多团队只监控业务日志，却从不监控采集器本身。采集器挂了，所有日志全部丢失，而且你可能几个小时后才发现。CLS提供了采集器的运行状态监控，包括每个节点上采集器的运行状态、采集延迟、失败日志数等指标。建议设置告警：当某个节点的采集器连续五分钟未上报数据时，立刻触发告警。同时，定期检查采集器的版本，及时升级以获取最新的稳定性修复。
结语
容器日志收集不全，表面上是工具的问题，本质上是配置的问题。CLS日志采集器提供了强大的底层能力，但如果采集规则配置粗糙、多行日志没有合并、请求ID没有透传、过滤策略没有设置，再强的工具也收不全你的日志。日志的价值不在于"存了多少"，而在于"关键时刻能不能找到"。把采集规则配精细、把请求ID透传做扎实、把聚合视图建完善——日志这件事，才算真正落地。
