1. 适用场景
适用于厂区或机房设备规模达数百台以上，网络设备、服务器、操作系统、数据库、存储、中间件、虚拟化、云资源和 URL 并存，仍靠 Excel 台账和逐台配置监控的环境。2. 为什么要用资产发现功能
设备逐台录入，人力耗在重复操作上
- 旧清单、新设备、已下线 IP 混在一起，实施人员不敢直接批量导入。
- 团体名和账号分散在多份表格，填错后只能逐台回退排查。
- 设备类型和监控模板靠经验判断，同类配置也要重复填写。
- 网段扩展或业务新增后，又要重新收集、录入、验证一轮。
Perseus 采集用发现管理扫描网段、识别对象和模板，用凭证管理集中维护并自动匹配凭据，减少人工判断和逐台录入。
3. 基于资产发现的设备纳管最佳实践
结合现场资产规模与设备类型，采用 自动发现 + 批量纳管为主、手动纳管为辅 的规划策略：支持自动识别或批量处理的对象优先批量纳管；特殊设备、小众硬件和临时设备手动补齐。3.1 前置准备
凭证管理支持多套 SNMP 团体名和账号密码，扫描时自动轮询；发现凭证异常后修正再重扫即可。
3.2 各设备类型纳管必要条件
- 网络设备： 启用并配置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；确认账号、地域和资源范围。
3.3 建议发现顺序
按“基础设施发现 → 基础软件发现 → 云平台发现”推进：
4. 典型应用场景
场景一：多套凭证集中管理
问题： 现场凭据常常分散在不同表格和工单里：网络设备是多套 SNMP 团体名，操作系统和数据库是不同账号密码。实施人员每次纳管都要重新翻表、问人、复制粘贴；某台设备失败后，还要先判断是策略不通还是密码填错。 解决： 在凭证管理中按对象类型集中维护全局 SNMP、操作系统账号、数据库账号、云平台密钥等凭据。纳管和扫描时复用同一套凭证配置，由系统自动轮询匹配。 效果： 实施人员不用再逐台粘贴密码，也不用记住每个厂商用哪套团体名；后续账号统一变更时，只需要维护凭证配置。
场景二：网段扩展后的自动扫描纳管
原有问题： 项目初期只规划纳管 20-80 网段，业务扩容后突然要用 90-100 网段。设备和系统不是一天上完，而是今天几台服务器、明天几台交换机；实施人员只能反复问进度、补表格，稍有延迟，新设备就已经承载业务但还没有监控。 解决： 在基础设施发现规则中补充 90-100 网段并开启自动扫描。系统按周期定时扫描，只要凭证正常且资源尚未监控，就自动添加监控；如果发现凭证异常，修正后重扫即可。 效果： 业务扩展后不用再靠人工盯新增设备；扫描范围和凭证正确时，新上线设备能自动进入监控，减少漏纳管和监控空档。