🔍diagnose

Prerequisites

1. CLI installed and logged in (see setup skill).
2. For cluster diagnosis: a cluster context, or pass --cluster-id explicitly.
3. For collection diagnosis: the cluster context must point at the cluster that owns the collection (see setup skill).

Scope

This skill performs read-only diagnosis using existing zilliz commands. It does NOT mutate clusters, collections, indexes, or data. Every recommendation is presented as a suggestion plus the exact next command the user can run themselves.

Two entry points:

When the user's intent spans both (e.g. "everything is slow"), run cluster diagnosis first — a collection-level symptom often has a cluster-level cause.

Cluster Diagnosis

Follow this checklist in order. Stop early only if you find a P0 problem (cluster not RUNNING, quota hard-stop) — surface it before running the rest.

1. Collect

Run these in parallel where possible and prefer -o json for machine parsing:

zilliz context current
zilliz cluster describe --cluster-id <id> -o json
zilliz cluster list --all -o json                       # peer clusters for context
zilliz billing usage -o json                            # quota / spend headroom

Then pull time-series metrics covering the last hour and last 24h. Use the chart output for human review and -o json if you need to compute thresholds:

zilliz cluster metrics --cluster-id <id> \
  -m CU_COMPUTATION -m CU_CAPACITY -m CU_SIZE -m REPLICA_COUNT \
  -m STORAGE -m SLOW_QUERIES \
  -m SEARCH_QPS -m SEARCH_LATENCY_P99 \
  -m SEARCH_FAIL_RATE -m INSERT_FAIL_RATE \
  --period 1h

Repeat with --period 24h for trend context.

2. Analyze

Walk each rule. Each finding must cite the evidence (command + observed value).

3. Present

Render a single report with three sections, in this order:

1. Summary — one-line health verdict (healthy / degraded / critical) + 1-3 sentence rationale.
2. Findings — table with columns Severity | Finding | Evidence | Suggested Next Step.
3. Suggested commands — copy-pasteable zilliz ... commands matching each suggestion. Never run mutating commands yourself — let the user run them.

Collection Diagnosis

1. Collect

zilliz collection describe --name <coll> -o json
zilliz collection get-stats --name <coll> -o json
zilliz collection get-load-state --name <coll> -o json
zilliz index list --collection-name <coll> -o json
# For each vector index reported above:
zilliz index describe --collection-name <coll> --field-name <field> -o json
zilliz partition list --collection-name <coll> -o json

Pull per-collection metrics for the last hour and 24h:

zilliz collection metrics -c <coll> \
  -m SEARCH_QPS -m SEARCH_LATENCY_P99 -m SEARCH_FAIL_RATE \
  -m QUERY_QPS -m QUERY_LATENCY_P99 \
  -m INSERT_QPS -m INSERT_LATENCY_P99 \
  -m ENTITIES -m ENTITIES_LOADED -m ENTITIES_INDEXED \
  --period 1h

If the cluster context is wrong or the collection lives in a non-default database, pass --database <db> on every command.

2. Analyze

3. Present

Same three-section format as cluster diagnosis. When a collection finding's true root cause is at the cluster level (e.g. CU saturation), say so explicitly and reference the cluster report.

Guidance

• Read-only. Never run delete, drop, release, resume, suspend, create, update, index create/drop, or any mutating data-plane command as part of diagnosis. Present them as suggestions only.
• Cite evidence. Every finding must reference the command that produced it and the observed value. No unsourced claims.
• Mark uncertainty. Index parameter recommendations, replica counts, and CU sizing depend on workload specifics the CLI cannot observe. Phrase as "starting point, benchmark to confirm."
• Know the limits. The CLI cannot see per-query plans, segment-level state, compaction backlog, GC, server-internal queues, or alert-rule state. If a question requires those, say so plainly rather than guessing.
• Prefer parallel collection. When multiple read-only commands are independent, run them in parallel to keep the diagnosis fast.
• JSON for parsing, charts for humans. Use -o json (optionally with --query) when comparing values against thresholds; use the default chart output when surfacing trends back to the user.
• Honor context. If the user has multiple clusters, confirm which one before collecting. If the collection is in a non-default database, thread --database through every command.