Datadog浏览器日志采集与RUM浏览器监控的差异及共存必要性

• 全量自定义日志采集：支持捕获业务代码中主动输出的console.log/info/warn等全量控制台日志，以及业务自定义的结构化日志（如用户操作轨迹、业务流程节点日志），而RUM仅聚焦于影响用户体验的错误、性能事件，不会采集这类非核心业务日志。
• 更灵活的日志配置与处理：可自定义配置采集规则，比如过滤特定日志、添加自定义元字段，还能通过Datadog日志管道对采集到的日志进行解析、转换、路由等精细化处理，这是RUM专属监控模块不具备的通用日志处理能力。
• 无采样的完整日志留存：在配置允许的情况下可以实现全量日志采集，不会像RUM那样默认启用采样策略（为控制成本和性能），适合需要完整日志链路用于故障回溯的场景。
• 第三方脚本日志的全面捕获：能直接捕获各类第三方脚本输出的非标准日志，即使这类日志不影响用户体验，也能完整留存，而RUM仅会记录第三方脚本引发的用户体验错误。

• 互补的监控视角：RUM从用户体验维度出发，追踪页面性能、会话质量、用户触发的错误；Browser Log Collection从调试与审计维度，提供全量控制台日志、业务操作上下文。两者结合可快速定位问题——比如RUM发现某页面错误率飙升，通过日志能查到具体的代码调试信息、用户操作路径。
• 适配不同分析场景：RUM适合做长期的用户体验趋势分析、性能优化决策；日志采集适合做实时故障排查、业务行为审计、自定义事件的追溯。
• 覆盖隐性问题排查：RUM仅捕获阻塞性或影响体验的错误，但很多非阻塞性的警告日志、业务调试日志只有日志采集能获取，这些信息对排查隐性问题（如功能异常但无报错提示）至关重要。
• 满足合规审计需求：部分业务场景需要留存全量业务操作日志用于合规审计，RUM的数据结构与采集逻辑无法满足这类需求，而Browser Log Collection的通用日志采集能力可以覆盖此类场景。

内容的提问来源于stack exchange，提问作者Warren