结论先行：日志平台把每条记录关联到"哪台机器、哪个业务、谁负责"，靠的是 IP。IP 一旦回收再分配，历史日志的归属就会悄悄错位，告警发错人、责任判到别人头上。这不是平台功能问题，是地址与归属的对应关系没人持续维护。
一条日志要回答的四个问题
值班的人打开一条日志，心里想的其实是四件事：这台机器是什么、跑的是哪个业务、出问题该找谁、这台机器重不重要。日志正文里通常只有 IP 和主机名，剩下三个要靠外部数据补——资产库、业务系统清单、责任人台账。补齐这一步，靠的是 IP 与资产的对应关系。
问题就出在这个对应关系上。它不是一个静态表，而是一直在变的东西。
三种常见的错法
其一：地址回收后再分配，旧日志跟着换了主人
一台服务器下线，IP 收回地址池，几个月后分配给一台新机器。日志平台上，那段时间的历史记录依然挂着这个 IP。查三个月前的登录记录，系统告诉你归属是"新机器所属业务"，而当时在跑的是那个已下线的系统。查历史事件时看到的名字是对的，含义是错的。
其二：动态地址段里的漂移
办公网、测试环境、临时接入区常用动态分配。同一个 IP 上午属于一台测试机，下午属于另一台。日志按 IP 归到责任人，等于把两个人的操作记在了一个人身上。这类错法在排查"谁动了配置"时最伤人。
其三：经过地址转换之后，所有人的操作挤成一个人
内网访问外网、或跨域访问经过转换设备，日志里留下的源地址是转换后的。平台按这个地址反查归属，结果所有经过同一出口的操作都归到同一台设备、同一个负责人。影响面看上去很大，实际是谁做的就查不出来了。
四个能看出归属在失控的信号
- 归属为空的比例在上升。日志里有一批记录匹配不到资产。少量正常，持续上升说明资产库没跟上变更。
- 一台主机对应多个业务。按 IP 反查出来的业务名出现多条，通常是地址复用或资产条目重复。
- 责任人集中在少数几个人身上。本该分散到各业务线的责任人，集中到运维组或某一个人，多半是归属没配到业务层。
- 历史查询和当时查询结果不一致。同一个时间窗、同一条日志，今天查出来的归属和事发当天不一样——说明归属是按当前资产库实时计算的，没有留当时的快照。
上线前该对齐的几项
- 资产库要有时间维度。不只是"这台 IP 现在归谁"，还要能查"某年某月某日归谁"。没有时间维度，历史归属就永远是错的。
- 地址回收与再分配要走流程。IP 释放时同步在资产库标记停用时间，再分配时记新启用时间。两个时间点都在，归属才有边界。
- 动态段单独标注。动态地址段、转换后的地址段，在资产库里标明类型。查询时提示"该地址为动态分配，归属仅供参考"，比给出一个确定的错答案要好。
- 定期对一次账。把日志里出现过的源地址与资产库里的在用地址做一次比对，两边对不上的拉出来处置。这件事做成月度的，比事后追查省力得多。
深圳市奇摩计算机有限公司在做日志平台实施时，会把资产归属对齐放在接入阶段，而不是等出了归属纠纷再补——这一项没做，平台装得再整齐，取数时还是没人敢用。
本文涉及的错法与信号来自实施过程中的常见情形归纳，具体到某个项目，以现场资产数据与实测结果为准。
本文只谈日志侧按 IP 反查归属这一条链，不涉及资产台账"规划"与"实际"两份清单的差异治理，也不涉及告警字段怎么设计。
如果你们的日志平台已经上线，但查历史记录时不敢确认归属对不对，欢迎预约咨询。