원클릭으로 Manus에서 모든 스킬 실행

obdiag-triage

스타160

포크40

업데이트2026년 5월 7일 12:54

未知/未分类问题的统一分诊 SOP：用户描述集群异常但症状不明确、不知从何入手，或问题无法直接对应 rca/observer-log-analysis/observer-sql-analysis 等专项 skill 时，强制先执行全量巡检 check_cluster，再根据巡检结果决定下一步路径。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

oceanbase

oceanbase/obdiag

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

未知问题分诊 SOP

触发条件

以下任意一条满足即使用本 skill：

用户描述问题但症状模糊（"集群慢"、"有报错"、"不稳定"、"有问题"等）
无法判断应走 rca、log 分析还是 SQL 分析
用户询问"应该怎么排查"、"从哪里开始"
当前无任何诊断数据，缺乏基线信息

第一步：确认配置（必须）

在执行任何诊断前，先确认集群配置已就绪：

list_obdiag_clusters()

若无集群配置 → 调用 generate_obdiag_config 引导用户完成配置，再继续。
若有多集群 → 明确告知用户当前使用哪个集群，或询问目标集群。

第二步：执行全量巡检（核心步骤，不可跳过）

check_cluster()

不加任何参数，执行完整默认巡检套件。巡检覆盖：磁盘、内存、网络、租户、参数配置等。

即使用户已有明确怀疑方向，也应先跑全量巡检获取基线，避免遗漏根因。

第三步：解读巡检结果，决定下一步路径

根据 check_cluster() 输出，按以下优先级路由：

路径 A：巡检发现 CRITICAL / WARNING 项

直接针对告警项深入分析：

告警类型	后续动作
磁盘空间不足、IO 异常	明确要 RCA 时加载 `obdiag-rca`；需要手动 SOP 时加载 `observer-storage-space-troubleshooting`，再配合 `gather_sysstat()` / `tool_io_performance()`
内存/memstore 告警	`check_cluster(cases="memory")` 精查 + 加载 `obdiag-rca` skill 按症状选 scene（如 `memory_full`、`execute_memory_high`、`major_hold`）后调 `rca_run`
网络相关告警	`gather_log(since="1h", grep="ERROR")` 过滤网络错误
租户/Session 异常	`check_cluster(cases="tenant")` + `gather_log`
参数配置不合理	向用户说明该参数的推荐值与风险

路径 B：巡检正常，但用户仍有明确症状描述

按症状路由到专项 skill：

用户症状	加载的专项 skill
SQL 慢、执行计划异常	`observer-sql-analysis`
有具体错误日志 / trace_id	`observer-log-analysis`
OBProxy 日志采集/解读	`obproxy-log-analysis`
OBProxy/ODP 路由、弱读、读写分离、连接配置	`obproxy-routing-troubleshooting`
日志盘/数据盘、-4184/-4264、文件系统、索引或副本空间	`observer-storage-space-troubleshooting`
备份、归档、恢复窗口、OSS/COS/NFS、oblogminer	`backup-archive-restore-troubleshooting`
已知故障场景（断连、合并卡住等）	`obdiag-rca` skill → `rca_run` 优先
性能抖动、CPU 高	`obdiag-performance`

路径 C：巡检正常，症状描述也模糊

采集基线数据供进一步分析：

gather_log(since="1h", scope="observer", grep="ERROR")
gather_sysstat()

然后分析采集结果，定位有无异常日志，再决定是否继续深入。

行动原则

巡检优先：check_cluster() 是任何未知问题诊断的起点，不得因"感觉不相关"而跳过。
不猜测：在没有巡检结果前，不向用户提出"可能是 XXX 问题"的判断。
逐步推进：每一步工具调用完成后，向用户汇报结果要点，再决定下一步，不要一次调用大量工具。
数据说话：所有结论必须基于工具返回的实际数据，不基于用户主观描述直接下结论。
超出能力范围：若巡检和日志分析后仍无法定位，明确告知用户需要哪些额外信息（如 OB 版本、操作时间点、业务变更记录等）。

快速流程图

用户描述问题
    ↓
list_obdiag_clusters()  ← 确认配置
    ↓
check_cluster()         ← 全量巡检（不可跳过）
    ↓
┌─────────────────────────────────────┐
│ CRITICAL/WARNING?                   │
│  Yes → 针对告警项深入分析            │
│  No  → 症状明确? → 专项 skill        │
│        症状模糊? → gather_log +      │
│                   gather_sysstat    │
└─────────────────────────────────────┘

이 저장소의 다른 Skills

같은 저장소

backup-archive-restore-troubleshooting

oceanbase/obdiag

备份、日志归档、物理恢复、恢复时间窗、NFS/OSS/COS 归档路径、对象存储权限、备租户恢复源、ob_admin 读取归档位点、oblogminer schema_meta 等问题；OMS 迁移同步问题不使用本 skill。

2026-05-07160

obdiag-check-rca

oceanbase/obdiag

标准 SOP：集群巡检 check_cluster/check_list 与 RCA 入口（rca_run/rca_list）。用户要健康检查、巡检时使用；RCA 场景映射与手动降级详见 obdiag-rca skill；与 observer-log-analysis、observer-sql-analysis、obproxy-log-analysis 分工明确。

2026-05-07160

obdiag-multi-cluster

oceanbase/obdiag

标准 SOP：多集群发现 list_obdiag_clusters、当前会话 show_current_cluster、/use 切换与 cluster_config_path 定向。多套 ~/.obdiag/*.yml、切换默认集群、或一句话点名某集群时使用。

2026-05-07160

obdiag-performance

oceanbase/obdiag

性能类采集与主机 IO：ASH、AWR、perf 火焰图、sysstat、磁盘 IO。在用户说卡顿、慢、会话堆积、要看 ASH/AWR/火焰图或主机负载时使用；与 observer-sql-analysis、observer-log-analysis 互补。

2026-05-07160

obdiag-rca

oceanbase/obdiag

OceanBase 集群所有根因分析场景的统一 SOP。覆盖事务超时/回滚/断连、内存不足、合并卡住、日志盘满、DDL 失败、Schema 泄漏、GC 异常、弱一致性读、OMS 等。始终先执行 rca_run，如 RCA 脚本无法给出结论再按本 skill 降级到手动日志采集分析。

2026-05-07160

obdiag-usage

oceanbase/obdiag

obdiag agent 工具使用指南：配置文件生成、gather/analyze/check/rca 各命令的调用方式、参数说明与典型场景。用户询问"怎么用 obdiag"、"如何采集日志"、"怎么生成配置"、"如何巡检/根因分析"，或 agent 自身不确定该调哪个工具时加载本 skill。

2026-05-07160

name	obdiag-triage
description	未知/未分类问题的统一分诊 SOP：用户描述集群异常但症状不明确、不知从何入手，或问题无法直接对应 rca/observer-log-analysis/observer-sql-analysis 等专项 skill 时，强制先执行全量巡检 check_cluster，再根据巡检结果决定下一步路径。

未知问题分诊 SOP

触发条件

以下任意一条满足即使用本 skill：

用户描述问题但症状模糊（"集群慢"、"有报错"、"不稳定"、"有问题"等）
无法判断应走 rca、log 分析还是 SQL 分析
用户询问"应该怎么排查"、"从哪里开始"
当前无任何诊断数据，缺乏基线信息

第一步：确认配置（必须）

在执行任何诊断前，先确认集群配置已就绪：

list_obdiag_clusters()

若无集群配置 → 调用 generate_obdiag_config 引导用户完成配置，再继续。
若有多集群 → 明确告知用户当前使用哪个集群，或询问目标集群。

第二步：执行全量巡检（核心步骤，不可跳过）

check_cluster()

不加任何参数，执行完整默认巡检套件。巡检覆盖：磁盘、内存、网络、租户、参数配置等。

即使用户已有明确怀疑方向，也应先跑全量巡检获取基线，避免遗漏根因。

第三步：解读巡检结果，决定下一步路径

根据 check_cluster() 输出，按以下优先级路由：

路径 A：巡检发现 CRITICAL / WARNING 项

直接针对告警项深入分析：

告警类型	后续动作
磁盘空间不足、IO 异常	明确要 RCA 时加载 `obdiag-rca`；需要手动 SOP 时加载 `observer-storage-space-troubleshooting`，再配合 `gather_sysstat()` / `tool_io_performance()`
内存/memstore 告警	`check_cluster(cases="memory")` 精查 + 加载 `obdiag-rca` skill 按症状选 scene（如 `memory_full`、`execute_memory_high`、`major_hold`）后调 `rca_run`
网络相关告警	`gather_log(since="1h", grep="ERROR")` 过滤网络错误
租户/Session 异常	`check_cluster(cases="tenant")` + `gather_log`
参数配置不合理	向用户说明该参数的推荐值与风险

路径 B：巡检正常，但用户仍有明确症状描述

按症状路由到专项 skill：

用户症状	加载的专项 skill
SQL 慢、执行计划异常	`observer-sql-analysis`
有具体错误日志 / trace_id	`observer-log-analysis`
OBProxy 日志采集/解读	`obproxy-log-analysis`
OBProxy/ODP 路由、弱读、读写分离、连接配置	`obproxy-routing-troubleshooting`
日志盘/数据盘、-4184/-4264、文件系统、索引或副本空间	`observer-storage-space-troubleshooting`
备份、归档、恢复窗口、OSS/COS/NFS、oblogminer	`backup-archive-restore-troubleshooting`
已知故障场景（断连、合并卡住等）	`obdiag-rca` skill → `rca_run` 优先
性能抖动、CPU 高	`obdiag-performance`

路径 C：巡检正常，症状描述也模糊

采集基线数据供进一步分析：

gather_log(since="1h", scope="observer", grep="ERROR")
gather_sysstat()

然后分析采集结果，定位有无异常日志，再决定是否继续深入。

行动原则

巡检优先：check_cluster() 是任何未知问题诊断的起点，不得因"感觉不相关"而跳过。
不猜测：在没有巡检结果前，不向用户提出"可能是 XXX 问题"的判断。
逐步推进：每一步工具调用完成后，向用户汇报结果要点，再决定下一步，不要一次调用大量工具。
数据说话：所有结论必须基于工具返回的实际数据，不基于用户主观描述直接下结论。
超出能力范围：若巡检和日志分析后仍无法定位，明确告知用户需要哪些额外信息（如 OB 版本、操作时间点、业务变更记录等）。

快速流程图

用户描述问题
    ↓
list_obdiag_clusters()  ← 确认配置
    ↓
check_cluster()         ← 全量巡检（不可跳过）
    ↓
┌─────────────────────────────────────┐
│ CRITICAL/WARNING?                   │
│  Yes → 针对告警项深入分析            │
│  No  → 症状明确? → 专项 skill        │
│        症状模糊? → gather_log +      │
│                   gather_sysstat    │
└─────────────────────────────────────┘