同一条日志报了两遍，统计就翻了一倍

结论先行：日志平台的接入方案通常是按资产逐类配置的，配置由不同的人在不同时间完成，于是一台设备同时走了两条通道是常见的结果。重复本身不会报错，它只表现成三件事：检索结果变长、统计数字翻倍、告警次数虚高。等到有人质疑报表口径，往往已经积累了几个月的数据。去重必须在接入设计阶段就定下来，而不是事后清洗。

本文只谈同一份日志被多条通道重复采集之后的识别与处理，不谈哪类资产装不上采集端，也不谈采集停掉之后怎么发现。

重复是怎么产生的

成熟的日志平台通常提供四条接入通道：本地采集端、设备主动推送、专用插件、既有可观测数据对接。四条通道覆盖的资产类型不同，边界却并不严格——重叠地带就是重复的来源。

• 采集端与推送并存。服务器上装了采集端读取系统日志，同时系统本身又配置了向日志服务器发送同样的内容。两份内容一致，只是来源标识不同。
• 插件与推送并存。数据库既通过插件直接读取审计表，又在数据库侧开了审计日志外发。前者是按周期抽样，后者是逐条推送，条数与字段都不一致。
• 既有对接与原始采集并存。已有指标平台把部分事件汇聚了一次，日志平台又通过对接把这份汇聚结果接进来，同时自己也采了原始记录。一份是聚合后的，一份是原始的，混在一起统计必然错。

这几种情形的共性是：单看任何一条通道都是对的，合起来才是错的。

重复的三种表现，和它们分别骗过谁

三种表现里，第三种最难被发现。因为它不表现为异常，而表现为两个部门对着两份数字争执，最后往往以「口径不同」收场，问题被归档而不是被解决。

识别重复：先做三张表，不动数据

去重之前要先确认重复存在，这个判断不需要写规则，只需要三张清单。

其一，通道与资产的对应对照表

把每一类资产标上走的是哪条通道。同一个资产出现两行，就是重复的候选。这张表在接入阶段本来就该产出，只是多数项目没有把它留到最后。

其二，时间窗内的内容比对

取一段十分钟的窗口，把同一台主机、同一时间段内的日志按「时间戳加主体内容」比对，命中两次以上的即为重复。重点看主体内容而非全部字段，因为两条通道写入的采集器标识、接收端口这些元数据本来就不同。

其三，采集器标识的分布

同一台主机在平台上出现的接收标识通常不止一个。这个数字本身就是一个可观测指标：一台主机对应一个接收标识是常态，出现两个以上就要解释。

处理重复的三种方式，各适用什么场景

• 源头停一条。最干净的做法，适用于两条通道取到的内容完全一致的情形。前提是确认停掉的那条不影响其他用途——有些推送通道同时被安全设备之外的系统消费，停之前要问清楚。
• 入库前丢弃。在解析环节按规则丢弃其中一类来源。适用于无法改动源头配置的情形，代价是占用了带宽与接收资源，只是不落库。
• 入库后按主键折叠。保留全部原始记录，在查询与统计时按业务主键去重。适用于两类记录互为补充、字段各有缺失的情形——此时并不真的重复，而是同一事件的两个侧面，折叠会丢信息。

选哪一种，取决于两条通道拿到的是不是同一层级的东西。同样是「有日志」，采集端拿到的可能是原始文件行，推送拿到的却是设备整理过的摘要。这种情况不该简单丢弃一条，而应当在建模阶段区分用途，统计时按用途取其中一条。

把去重做成一次性的动作，会重新长出重复

去重最容易被当成项目收尾时的一次清洗。清洗完确实干净了，但接入是持续发生的：新上线的业务系统自带推送配置，新买的设备默认开启日志外发，外包团队按自己的习惯装采集端。半年之后重复会以新的形态回来。

可行的做法是把「同一资产只走一条主通道」写进接入规范，并在平台侧保留两个常看的指标：单台主机的接收标识数量、以及同一内容在窗口内的重复率。两个指标都不需要复杂实现，但能把重复从「事后清洗」变成「持续可见」。

落地清单

• 接入设计阶段产出「资产—通道」对照表，一行一个资产，不允许出现两行。
• 明确主通道与辅助通道，辅助通道只用于补充主通道取不到的字段。
• 在解析环节对已知的重复来源配置丢弃规则，规则带生效范围与到期复核时间。
• 平台侧固定看两个指标：单台主机接收标识数量、十分钟窗口内容重复率。
• 统计口径文档里写清「同一事件取哪条通道」，随报表一起交付。

边界与前提

三点说明。其一，本文所述的多通道接入与数据清洗方式，取自通用日志平台方案的公开描述，属对行业通行做法的一般性梳理，不针对任何具体产品与项目。其二，重复判定依赖时间戳精度与内容一致性，各设备的时钟同步状况会影响比对结果，实施前应先确认时间同步机制是否可靠。其三，文中数字为示意，实际比例以本项目实测为准。

深圳市奇摩计算机有限公司在日志类项目里做的是服务这一端：接入方案、去重规则、口径文档，都在交付清单里逐项对齐，而不是上线之后靠报表争议来发现。预约咨询，可以先从那张「资产—通道」对照表看起。