资产发现最佳实践：让“设备到底有没有被监控”不再是一个问号

想象一下这个场景

厂区扩建，新交换机上线了，业务跑起来了，但监控里没有它。直到某天凌晨，核心链路断了，值班人员翻遍Excel台账才发现——这台设备压根就没被纳管。

这种事，一次就够了。

而现实往往是：设备几百上千台，网段七零八落，厂商五花八门，凭据散落在不同人的电脑里。实施人员拿到一份“老旧不一”的设备清单，IP 有下线也有新增，SNMP团体名在另一张表里，数据库账号还要挨个去找应用负责人。进入监控平台后，每一台设备都要靠经验判断类型、选模板、填凭据，录完还要逐台验证。一台两台还能忍，几百台呢？

这不是技术问题，这是“人力被重复劳动吞噬”的泥潭。

Perseus资产发现，到底解决什么？

一句话：把“人找设备”变成“设备找人”。

Perseus采集的资产发现，以自动发现为核心，通过三类手段识别在线资源：

• 网段扫描：自动扫IP和网段，发现未登记设备；
• Agent扫描：已纳管主机上自动发现数据库、中间件等基础软件；
• 云平台发现：通过云密钥自动发现云资源。

发现之后，系统自动匹配对象类型、监控模板和采集凭证，再配合“自动扫描 + 自动纳管”，实现：

新设备上线 → 自动发现 → 自动纳管 → 进入监控 旧设备下线 → 自动识别 → 标记清理 → 台账同步

这不仅是效率提升，更是把“漏纳管”这种隐性事故，从源头掐断。

适用场景

适用于厂区或机房设备规模达数百台以上，网络设备、服务器、操作系统、数据库、存储、中间件、虚拟化、云资源和URL并存，仍靠Excel台账和逐台配置监控的环境。

基于资产发现的设备纳管最佳实践：

结合现场资产规模与设备类型，采用自动发现 + 批量纳管为主、手动纳管为辅的规划策略：支持自动识别或批量处理的对象优先批量纳管；特殊设备、小众硬件和临时设备手动补齐。

前置准备

凭证管理支持多套SNMP团体名和账号密码，扫描时自动轮询；发现凭证异常后修正再重扫即可。

各设备类型纳管必要条件

• 网络设备：启用并配置SNMP协议，建议SNMPv2；开放UDP161（162）端口。
• 硬件服务器：接入带外管理口；开放UDP 161、623；准备管理口账号和团体名。
• 操作系统：Linux/AIX准备root或itops权限，Windows管理员权限；开放Agent端口10073；AIX需bash。
• 数据库：准备有会话和SQL执行权限的账号；开放实例端口。
• 中间件：Java程序配置JMX端口；开放服务端口或JMX端口。
• 存储：接入带外管理口；支持SNMP则启用，否则准备monitor组账号；按厂商开放22、5989、UDP 161、623。
• 虚拟化平台：准备只读账号；开放TCP 443。
• 链路：网关配置SLA或NQA；开放UDP 161。
• 网站/URL探测：URL可访问；模拟登录不能有验证码；不支持TLS 1.0及以下。
• 云平台：准备密钥和密钥ID；确认账号、地域和资源范围。

建议发现顺序按“基础设施发现→基础软件发现→云平台发现”推进：

典型应用场景：

场景一：多套凭证集中管理

问题：现场凭据常常分散在不同表格和工单里：网络设备是多套SNMP团体名，操作系统和数据库是不同账号密码。实施人员每次纳管都要重新翻表、问人、复制粘贴；某台设备失败后，还要先判断是策略不通还是密码填错。

解决：在凭证管理中按对象类型集中维护全局SNMP、操作系统账号、数据库账号、云平台密钥等凭据。纳管和扫描时复用同一套凭证配置，由系统自动轮询匹配。

效果：实施人员不用再逐台粘贴密码，也不用记住每个厂商用哪套团体名；后续账号统一变更时，只需要维护凭证配置。

场景二：网段扩展后的自动扫描纳管

原有问题：项目初期只规划纳管20-80网段，业务扩容后突然要用90-100网段。设备和系统不是一天上完，而是今天几台服务器、明天几台交换机；实施人员只能反复问进度、补表格，稍有延迟，新设备就已经承载业务但还没有监控。

解决：在基础设施发现规则中补充90-100网段并开启自动扫描。系统按周期定时扫描，只要凭证正常且资源尚未监控，就自动添加监控；如果发现凭证异常，修正后重扫即可。

效果：业务扩展后不用再靠人工盯新增设备；扫描范围和凭证正确时，新上线设备能自动进入监控，减少漏纳管和监控空档。

这是效率工具，更是“安全兜底”

Perseus采集 · 资产发现的价值，不只是省人力。它让监控不再是“人工补丁”，而是持续自我完善、自动响应变化的体系。

设备越多，网段越散，业务增长越快，它的价值就越明显。

一句话总结：

台账让人焦虑，发现让人安心。

当设备规模几百上千台时，你需要的不是更勤奋的录入员，而是一套自动发现纳管的机制。

乐维社区已经开放乐维运维智能体免费版，欢迎下载使用！