Schedule

墨天轮接力白求恩为用户提供了免费的 Oracle 巡检功能，从用户视角看，Oracle 离线巡检的操作并不复杂：在数据库环境中运行采集程序，得到一个 ZIP 巡检包，上传到 Bethune，等待平台生成分析报告。 真正复杂的是报告背后的处理链路。BTRobot 需要从不同版本、不同操作系统和不同部署架构的 Oracle 环境中采集数据库配置、对象、性能和 AWR 等信息；巡检包进入 Bethune 后，还要依次经过数据导入、规则分析和报告生成。Bethune 分析服务运行在两个应用节点上，过程数据与结果保存在 MogDB 中，采集端和分析端又分别由两套源码维护。 Oracle 数据库 → BTRobot 离线采集 → Oracle 巡检 ZIP 包 → Bethune Loader 导入 MogDB → Analyzer 分析 → Reporter 生成巡检报告 任何一个环节出现偏差，都可能让用户最终拿不到报告。应用日志中的一条 ERROR，背后可能是采集数据错误、ZIP 目录结构异常、Loader 解析缺陷、数据库字段宽度不足、分析规则不完整或应用源码问题。传统监控只能报告日志出现异常，维护人员仍需跨主机、数据库、数据包和代码仓库逐项还原现场。 Bethune Workspace 的 issue_174 展示了 Opsx 如何承接这项工作：Schedule 从应用日志发现异常并创建 Issue，Agent 沿 Asset Graph 跨多个 Runtime 收集证据，维护者在关键业务判断处提供正常样本，修复后的巡检包重新完成导入、分析和报告生成，经过验证的处理方法再进入 Knowledge。 一个服务故障，实际连接六个资产 Opsx 中的 svc-emcs-bethune 不是孤立的服务名称。Asset Graph 已经记录它与运行节点、数据库、采集程序和分析程序之间的关系： ...

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 会为每个目标主机创建独立的执行记录,检查以下核心指标: ...