运维人员真正缺少的往往不是又一个查询工具，而是能够把资产、证书、数据库实例和访问凭据关联起来的统一入口。Blueking Lite 本周更新继续沿着这一方向推进：CMDB 增加 SSL 证书 TLS 握手采集和采集接入凭据管理，Oracle 采集扩展到 CDB、PDB、RAC，资产列表则增强了内网、外网 IP 的精确查询能力。
对于强调低部署资源、低使用成本和渐进式体验的轻量运维平台，这些变化的价值并不只在于“多采几个字段”，而在于减少跨应用核对信息的次数，让故障定位和日常巡检拥有更完整的上下文。
从资产清单走向可关联的运行上下文
传统 CMDB 经常停留在静态清单层面：主机有哪些、IP 是什么、数据库部署在哪里。可一旦遇到证书告警或 Oracle 集群异常，工程师仍然需要分别打开证书平台、数据库控制台和凭据系统，再手工确认它们是否属于同一套业务。
这次更新覆盖的对象可以形成一条更实用的关系链：
业务应用
└─ 主机或网络资产
├─ 内网 IP / 外网 IP
├─ TLS 服务与证书
└─ Oracle 数据库
├─ CDB
├─ PDB
└─ RAC 实例
当这些信息能够统一查看时，常见问题就可以从“到多个系统分别搜索”变成围绕资产展开：
- 某个证书即将过期时，直接确认对应 IP、主机和业务应用。
- 某个 PDB 不可用时，继续查看所属 CDB、RAC 实例及承载节点。
- 收到一个 IP 相关告警时，用内网或外网 IP 精确定位资产，避免模糊匹配带来的误判。
- 采集任务失败时，从统一管理的接入凭据入手排查，而不是在脚本和配置文件中寻找散落的账号。
这里的关键不是把所有原始数据堆进一个页面，而是建立稳定的对象标识和关联关系。例如，同一台服务器可能同时有管理 IP、内网服务 IP、NAT 后的公网 IP；如果没有区分地址类型，即使数据已经汇聚，也很难可靠联动。
TLS 握手采集：证书不再只是一个到期日期
新增 SSL 证书 TLS 握手采集后，平台可以从实际服务端点识别证书信息。相比只导入证书文件，握手采集更接近客户端真正访问到的结果，也更容易发现以下问题：
- 负载均衡器实际返回的证书与配置记录不一致。
- 使用 SNI 的站点在不同域名下返回了不同证书。
- 证书尚未过期，但主机名不匹配或证书链存在异常。
- 证书已经更新，某个节点却仍在提供旧证书。
落地时需要注意，TLS 采集必须同时记录目标主机、端口和 SNI 域名。只使用 IP 发起握手，可能拿到默认证书，从而形成错误资产记录。
用 OpenSSL 独立核验证书采集结果
下面的命令可以直接运行，用来核对某个 HTTPS 服务真实返回的证书。执行前把 HOST 和 PORT 改成待检查的地址：
HOST="example.com"
PORT="443"
echo | openssl s_client \
-connect "${HOST}:${PORT}" \
-servername "${HOST}" \
2>/dev/null | openssl x509 \
-noout \
-subject \
-issuer \
-serial \
-dates \
-fingerprint \
-sha256
输出中的 notAfter 可用于核对有效期，issuer 可确认签发机构，SHA-256 指纹则适合判断不同节点是否仍在使用同一张证书。
如果需要做批量巡检，可以将域名列表放入文本文件：
cat > tls-targets.txt <<'EOF'
example.com:443
api.example.com:443
EOF
while IFS=: read -r host port; do
echo "===== ${host}:${port} ====="
echo | openssl s_client \
-connect "${host}:${port}" \
-servername "${host}" \
2>/dev/null | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256
done < tls-targets.txt
这类命令适合作为平台采集结果的独立验证手段，而不是替代统一采集。生产环境还应设置连接超时，并避免对同一目标进行高频扫描。
Oracle 采集为何必须理解 CDB、PDB 和 RAC
Oracle 的资产模型并不等同于“一个 IP 对应一个数据库”。在多租户架构中，一个 CDB 可以承载多个 PDB；在 RAC 环境中，同一数据库又可能由多个实例共同提供服务。如果 CMDB 只登记监听地址和数据库名称，就很难回答“异常发生在哪个容器、哪个实例、哪台节点”这类问题。
本次 Oracle 采集覆盖 CDB、PDB、RAC，意味着资产模型可以进一步表达：
- CDB 与 PDB 的从属关系。
- PDB 的打开状态及容器标识。
- RAC 中实例、节点和数据库之间的关系。
- 数据库逻辑对象与底层主机资产之间的映射。
可以用以下 SQL 对采集结果进行抽查。运行前需要正确配置 ORACLE_DSN，并确保查询账号拥有访问相关动态性能视图的权限：
export ORACLE_DSN='ops_reader/password@//db.example.com:1521/ORCL'
sqlplus -s "$ORACLE_DSN" <<'SQL'
set pagesize 100
set linesize 200
set feedback off
prompt === Current container ===
select sys_context('USERENV', 'CON_NAME') as container_name from dual;
prompt === Pluggable databases ===
select con_id, name, open_mode
from v$pdbs
order by con_id;
prompt === RAC instances ===
select inst_id, instance_name, host_name, status
from gv$instance
order by inst_id;
exit
SQL
在生产环境中，不建议为了采集方便直接使用高权限数据库账号。更稳妥的做法是创建只读采集账号，仅授予查询必要视图的权限，并通过平台的接入凭据管理统一轮换和审计。
凭据统一管理的收益与边界
采集接入凭据管理看似是后台能力，却直接决定了自动化采集能否长期运行。账号密码、SSH 密钥或数据库连接信息如果散落在脚本、任务参数和个人电脑中，会带来三个问题：无法确认谁使用过凭据、轮换后大量任务失效，以及凭据泄漏时难以判断影响范围。
接入时建议至少遵循以下原则：
- 按系统和环境隔离：生产与测试环境不要共用采集凭据。
- 坚持最小权限：证书探测通常不需要登录权限；数据库采集账号只开放必要的查询能力。
- 凭据与资产分离存储：资产关系中只保存凭据引用，不直接保存明文密码。
- 轮换前做依赖检查：先确认哪些采集任务引用了即将轮换的凭据。
- 记录调用审计：至少保留调用方、目标资产、时间和执行结果，避免在日志中输出秘密值。
统一管理不代表所有人都能查看秘密内容。平台应尽可能让使用者“可以调用但不能读取”，并通过权限和审计控制凭据的实际使用范围。
采用建议：先统一标识，再扩大自动化范围
如果计划使用这些能力，可以从一组范围可控的资产开始，而不是一次性接入所有系统：
- 选择一个业务应用，确认主机、内外网 IP、域名和数据库对象能够正确关联。
- 接入少量 TLS 端点，并用 OpenSSL 抽查 SNI、有效期和指纹。
- 对 Oracle CDB、PDB、RAC 信息进行人工核验，重点检查同名对象和多实例关系。
- 为采集账号建立最小权限、轮换周期和失败告警。
- 验证精确 IP 查询是否能唯一定位目标资产，并处理重复 IP、NAT 和历史资产记录。
Blueking Lite 这次更新的核心意义，是把证书、数据库、IP 和凭据从孤立字段变成可联动的运维上下文。不过，统一视图的准确度最终仍取决于数据质量：对象标识不一致、失效资产未清理或凭据权限过大，都会削弱联动效果。先把一个应用的关系链做准确，再逐步扩展覆盖面，更符合轻量平台的渐进式采用路径。