/ops-inspector

name: ops-inspector
description: AIOps-style CloudBase inspection skill. Use when users need health checks, log diagnosis, alarm interpretation (CPU alert normal?, peak QPS), metrics via queryEnv(action=metrics), fault playbooks for 429 / AI model 429 / function timeout / function 404 / ACCESS_TOKEN_INVALID / zero invocations, or a scheduled patrol that reports only new or worse findings. Triggers on 巡检, 诊断, 告警, 峰值 QPS, 限频, 调用量为 0, 定时巡检, 每天检查, 值守, troubleshooting.
version: 2.36.1
license: MIT
alwaysApply: false

Sibling skills (local only)

Sibling CloudBase skills ship beside this skill. Use local relative paths such as `../auth-tool-cloudbase/SKILL.md`.

If a referenced sibling skill file is missing from this environment, ask the user to install the full CloudBase plugin (or the missing skill). Do **not** HTTP-fetch remote skill or protocol markdown into the agent context.

Activation Contract

Use this first when

• The user wants to check the health or status of CloudBase resources (cloud functions, CloudRun, databases, storage, etc.).
• The user reports errors, failures, or abnormal behavior and wants a quick diagnosis.
• The user asks for an "inspection", "health check", "巡检", "诊断", or "troubleshooting" of their CloudBase environment.
• The user wants to review recent error logs across services.
• The user asks **告警解读** questions: whether a **CPU 告警** is normal, what **峰值 QPS** was, or whether throttle/error metrics look healthy.
• The symptom matches a fault playbook: **429 / 限频**, **AI 模型 429 / Token 额度**, **云函数超时或轮询超时（`-404005`/433）**, **云函数 404**, **ACCESS_TOKEN_INVALID**, or **调用量为 0**.
• The user wants a **patrol** rather than a one-off check ("每天帮我看看有没有变差", "定时巡检", "值守"), or asks to put an inspection on a schedule.

Read before writing code if

• The inspection reveals code-level issues in cloud functions or CloudRun services — then read the relevant implementation skill before suggesting fixes.
• The user wants to fix a problem found during inspection rather than just diagnose it.

Then also read

• Alarm interpretation baselines -> `references/alarm-interpretation.md`
• Fault playbooks (429 / AI model 429 / function timeout / 404 / token / zero calls) -> `references/fault-playbooks.md`
• Cloud function issues -> `../cloud-functions/SKILL.md`
• CloudRun issues -> `../cloudrun-development/SKILL.md`
• Database issues -> `../postgresql-development-cloudbase/SKILL.md` for CloudBase PG / PostgreSQL, `../relational-database-mcp-cloudbase/SKILL.md` for MySQL, or `../cloudbase-document-database-web-sdk/SKILL.md` for NoSQL
• Auth readiness (token failures) -> `../auth-tool-cloudbase/SKILL.md`
• Environment not visible, binding fails, or only one environment shows up -> `../cloudbase-cli/references/core.md` (*Where credentials are read from*)
• Platform overview -> `../cloudbase-platform/SKILL.md`

Do NOT use for

• Deploying new resources or writing application code. This skill is read-only and diagnostic.
• Replacing the platform's alert rules (SMS / 告警策略). A patrol catches drift and slow degradation between alerts; alert rules catch hard thresholds in real time. Do not disable alerting because a patrol exists.
• Setting up the alert rules themselves. For log-level threshold alerts (fire when `statusCode` is 502), route the user to CLS log alerting — deliver environment logs to CLS, confirm the index, then create an alert policy: https://docs.cloudbase.net/logger/alert/log-alert-guide (metric-based alerting is console-native and needs no setup guide).
• Writing to the environment on a scheduled run. See *Scheduled Patrol* — every patrol step is read-only.
• Directly fixing problems — it diagnoses and recommends; actual fixes should use the appropriate implementation skill.
• Fetching metrics by guessing cloud API Actions. For any metric `queryEnv` covers (functions, CloudRun, gateway QPS, MySQL, package usage), always use `queryEnv(action="metrics")` — never `callCloudApi`. The one exception is PostgreSQL: `queryEnv` has no PG metrics, so pull them via `callCloudApi` → `monitor` / `2018-07-24` / `GetMonitorData`, namespace `QCE/POSTGRES`, with the exact Action and dimensions pinned in the `cloud-api-operations` skill — never from memory.

Common mistakes / gotchas

• Running a full inspection without first confirming the environment is bound (`auth` tool must show logged-in and env-bound state). If binding fails or only one environment appears, credentials are being resolved **per directory** — see `../cloudbase-cli/references/core.md` (*Where credentials are read from*); it is usually neither a permissions nor a platform problem.
• Ignoring CLS log service status — if CLS is not enabled, `queryLogs` will fail; always check first with `queryLogs(action="checkLogService")`.
• Searching logs without a time range — this can return excessive or irrelevant results. Always scope searches to a relevant time window.
• Assuming one `queryFunctions(action="listFunctionLogs")` call covered a multi-day window. It is capped at **1 day and 100 rows** per call. For anything longer, loop over day-sized windows or switch to `queryLogs(action="searchLogs")`.
• Reading an empty log result as "no errors". Empty has three common causes and only one of them is good news: wrong time window, missing colon in a field comparison (`status_code>200` silently matches nothing), or CLS not capturing that log source. Say which check you ran before concluding a resource is healthy.
• Treating a single error log as the root cause without correlating across resources. A function error may stem from a database or config issue.
• Answering "峰值 QPS" / "CPU 告警是否正常" from screenshots or memory instead of `queryEnv(action="metrics")`.
• Calling `callCloudApi` with invented `GetMonitorData` / `DescribeCurveData` parameters — the metrics branch already wraps Manager SDK.
• Re-reporting the same finding on every patrol run. Without state between runs the report repeats itself, gets muted, and