资产巡检

100 台主机、20 个数据库、30 个应用,谁在巡、谁没巡、上次检查是什么时候? 这个问题看起来简单,实际上很难持续回答。无论是专业监控平台、分散在主机上的 crontab,还是人工登录查看,它们都能发现一部分问题,但资产清单、检查规则、执行记录和后续处置往往分散在不同位置。某台机器的巡检脚本是否仍在运行、上次检查是正常还是已经告警、磁盘 92% 是今天的问题还是三个月前就存在——这些问题最终仍要靠人逐一确认。 真正困难的不是执行 df 或连接数据库,而是让检查结果成为系统可持续使用的运行事实: 发现"磁盘 92%“之后,这个状态如何进入系统认知,而不是只停留在某个终端输出? 异常出现时,如何自动关联到正确的资产、上下游关系、历史经验和可执行的处置路径? 主机、数据库、应用和云资源的健康标准完全不同,如何在统一框架下管理它们? 人工巡检的经验如何固化为可持续运行的机制,而不是每次都重新判断阈值? Opsx 接管全域资产巡检的方式,不是再增加一套"把检查结果发出来"的工具,而是把健康检查收拢到 Asset Graph: Asset 提供身份和运行拓扑 ↓ Schedule 按周期触发确定性检查 ↓ Shell 执行并计算健康状态 ↓ 结果回写 Asset metadata ↓ 异常自动进入关联资产的 Issue ↓ Agent 读取 Memory、Knowledge 和上下游关系继续诊断 巡检不再是某台机器上的孤立脚本,而是平台对真实资产持续建立运行认知的过程。本文从 MODB 和 Bethune 已经运行的主机、MogDB、应用和仓库巡检出发,说明 Opsx 如何让不同资产使用统一机制,并让健康状态成为后续诊断的确定性起点。 主机巡检:从负载、内存、磁盘到健康状态的完整链路 MODB Workspace 当前运行一条每日主机巡检 Schedule,覆盖生产环境中的关键主机资产。Schedule 配置如下: 名称: MODB Daily Host Health Check Workspace: modb 目标资产: 多个主机资产,包括 host-moapp-0002 等 Runner: shell Cron: 0 0 * * * (每日 00:00 UTC) 状态: active 每次执行时,Schedule 会为每个目标主机创建独立的执行记录,检查以下核心指标: ...