📚 课程目录第4章设备发现与资产自动注册

4. 设备发现与资产自动注册

在批量设备运维体系中，资产台账是所有后续操作的基础。如果设备没有被发现、没有被正确注册，那么固件升级、配置下发、健康监控都无从谈起。本节讨论如何利用SNMP、mDNS、DHCP指纹和Agent上报四种互补的发现机制，构建一条可靠的资产自动注册流水线，并重点解决重复注册与信息冲突这两个工程中最常见的问题。

四种发现机制的能力边界

没有任何单一机制能覆盖全部设备状态，因此需要理解每种机制“能看到什么、看不到什么”。

SNMP轮询：适合已配置SNMP团体名或v3凭据的设备。通过遍历sysDescr、sysObjectID、ifPhysAddress等OID，可以获取型号、序列号、网口MAC、固件版本。优点是信息结构化、可主动拉取；缺点是设备未启用SNMP时完全不可见，且轮询周期决定了发现延迟。
mDNS/DNS-SD：适合局域网内支持零配置的设备。设备通过_http._tcp.local或自定义服务类型广播自身，运维端监听即可获得主机名、IP、端口和TXT记录中的型号信息。优点是实时性好、无需预配凭据；缺点是跨网段受限，且广播可能被交换机抑制。
DHCP指纹：从DHCP请求的Option 55（参数请求列表）、Option 60（厂商类标识）、Option 61（客户端标识）以及MAC OUI中提取特征。它能在设备尚未获得完整网络配置时就识别出“这是一台Ryzen Embedded设备”，是最早的发现时机。缺点是只能提供粗粒度分类，无法给出序列号。
Agent上报：设备内运行的轻量Agent主动向注册中心发起HTTPS注册，携带完整资产信息（序列号、MAC、固件版本、CPU型号、内存容量）。这是信息最准确、最完整的来源，但前提是Agent已部署且网络可达。

四种机制的关系不是替代，而是分层互补：DHCP指纹负责“最早感知”，mDNS负责“快速发现”，SNMP负责“结构化补全”，Agent负责“权威确认”。

自动注册流程设计

注册中心收到发现事件后，不能直接写入资产表，而应经过归一化、匹配、冲突检测、裁决、入库五个阶段。

归一化：不同机制上报的字段名和格式不同。例如SNMP返回的MAC可能是00:1A:2B:3C:4D:5E，Agent上报的可能是00-1a-2b-3c-4d-5e，DHCP指纹中提取的可能是001a2b3c4d5e。注册中心统一转换为小写冒号分隔格式，序列号去除空格和连字符，IP地址统一为点分十进制。归一化后，所有事件都映射到同一组标准字段。

主键匹配：资产记录的主键选择需要兼顾唯一性和可获得性。推荐使用“序列号优先，MAC兜底”的策略：如果事件携带序列号，则以序列号为唯一键；如果只有MAC，则以MAC为唯一键；如果两者都有，先按序列号匹配，未命中再按MAC匹配。这样可以避免同一设备因网卡更换或序列号读取失败而产生两条记录。

冲突检测：当同一主键下出现不同字段值时，标记为冲突。常见冲突包括：同一MAC对应不同序列号（可能是MAC复用或伪造）、同一序列号对应不同固件版本（可能是升级过程中上报时间差）、同一设备被不同机制识别为不同型号（可能是SNMP OID解析错误或mDNS TXT记录过期）。

重复与冲突的处理策略

重复注册通常发生在设备重启、网络抖动或Agent重装后。处理原则是“幂等写入”：注册中心对同一主键的重复事件不新增记录，而是更新last_seen时间戳和来源列表。如果重复事件携带的字段值与已有记录一致，直接忽略；如果不一致，进入冲突流程。

冲突消解采用“来源优先级 + 时间新鲜度”双维度裁决。来源优先级从高到低为：Agent上报 > SNMP轮询 > mDNS > DHCP指纹。这是因为Agent直接读取设备内部信息，准确性最高；SNMP次之；mDNS和DHCP指纹属于推断性信息。当来源优先级相同时，比较事件时间戳，取更新的值。如果两个来源优先级相同且时间戳接近（例如5秒内），则标记为“待人工复核”，不自动覆盖。

实践建议：对于序列号冲突，不要自动覆盖。序列号是资产身份的核心，一旦错误会影响固件升级和许可证绑定。建议将序列号冲突事件写入独立队列表，由运维人员通过带外管理口或物理标签核对后手动确认。

注册状态机与可观测性

每条资产记录应维护一个状态字段，取值包括：discovered（仅被发现，信息不完整）、pending（已注册但等待Agent确认）、active（信息完整且最近有上报）、conflict（存在未消解冲突）、stale（超过阈值未上报，例如72小时）。状态迁移由事件驱动，每次迁移记录来源、时间和裁决依据，便于审计和排障。

可观测性方面，建议暴露以下指标：各发现机制的事件速率、去重命中率、冲突率、冲突消解平均耗时、stale资产数量。当冲突率突然升高时，往往意味着网络中存在MAC冲突、DHCP地址池配置错误或Agent版本不一致，需要及时排查。

一个可参考的注册事件处理伪代码

def handle_discovery_event(event):
    normalized = normalize(event)          # 统一MAC/序列号/IP格式
    record = find_by_serial(normalized.serial) \
             or find_by_mac(normalized.mac)

    if record is None:
        record = create_asset(normalized, status="discovered")
        return record

    # 幂等更新：刷新last_seen和来源
    record.last_seen = normalized.timestamp
    record.sources.add(normalized.source)

    conflicts = detect_conflicts(record, normalized)
    if not conflicts:
        record.status = "active" if record.is_complete() else "pending"
        return record

    for field, new_val in conflicts.items():
        old_val = record.get(field)
        if source_priority(normalized.source) > source_priority(record.get_source(field)):
            record.set(field, new_val, source=normalized.source)
        elif source_priority(normalized.source) == source_priority(record.get_source(field)):
            if abs(normalized.timestamp - record.get_time(field)) < 5:
                record.status = "conflict"
                enqueue_manual_review(record, field, old_val, new_val)
            else:
                record.set(field, new_val, source=normalized.source)
        # 低优先级来源不覆盖高优先级，仅记录
    return record

这段逻辑的核心是：先保证不重复建记录，再按优先级和时间裁决字段值，无法自动裁决的进入人工队列。实际部署时，source_priority和5秒阈值应根据现场网络质量和设备数量调整。例如在大型园区网中，mDNS和DHCP事件可能因网络延迟而时间戳偏差较大，可适当放宽到30秒。

落地时的关键检查项

确认DHCP服务器已开启Option 60和Option 61记录，否则指纹提取会缺失关键字段。
确认交换机未过滤mDNS组播（224.0.0.251:5353），跨VLAN场景需配置mDNS网关或反射。
SNMP团体名或v3凭据应通过密钥管理服务下发，避免硬编码在轮询脚本中。
Agent注册接口需支持双向TLS认证，防止伪造设备注入虚假资产。
注册中心对同一主键的写入应使用数据库唯一约束或分布式锁，避免并发重复插入。
定期清理stale资产，但保留历史记录用于审计，不要物理删除。

资产自动注册不是一次性的扫描任务，而是一个持续运行的事件处理管道。四种发现机制各自贡献不同粒度和时效的信息，注册中心负责把它们收敛成一份可信、可追溯、可运维的资产台账。把重复和冲突处理设计好，后续的批量升级、配置下发和健康监控才有可靠的数据基础。