Cb analytics admin

Skill celticht32/Couchbase-Skills-for-Claude.ai/skills/couchbase-analytics/cb-analytics-admin

This is a collection of skills I have created for Couchbase for Claude.ai

Install

npx -y skills add celticht32/Couchbase-Skills-for-Claude.ai --skill cb-analytics-admin

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use this skill when the user wants to inspect or manage the Analytics service's runtime — checking ingestion health, killing runaway queries, restarting nodes, or diagnosing performance. Trigger when they mention "ingestion status", "active queries", "completed requests", "restart service", "cancel request", "service status", or "Analytics health".

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.6 KB, as published. Nobody here has run it

Analytics service admin

You have 7 tools for runtime management.

Status snapshot (read-only, safe)

get_service_status(cluster) — overall service state, replica lag, authorised node list
get_ingestion_status(cluster) — per-link ingestion state, pending ops
get_active_requests(cluster) — what's running right now
get_completed_requests(client_context_id=None, cluster) — recent history; pass client_context_id to filter to one request

Diagnostic workflow

When a user says "queries are slow" or "ingestion looks stuck":

get_service_status — is the service even healthy? Watch ccRevLag (replication lag).
get_ingestion_status — for each link, look at pendingOperations. A non-zero pending count after a quiet period usually means a stuck link.
get_active_requests — long-running queries appear here with elapsedTime. Anything over a few seconds is suspect.
get_completed_requests — look for a pattern of errors or unusually long durations.

Destructive operations (use with care)

cancel_request(client_context_id, cluster) — abort one in-flight query. Get the id from get_active_requests.
restart_node(cluster) — restart only the Analytics process on the local node. May briefly disrupt queries routed to that node.
restart_service(cluster) — cluster-wide Analytics restart. All active queries fail. Don't suggest this lightly; warn the user.

Confirmation patterns

When the user asks to cancel or restart anything, always confirm by naming what you're about to do, with the specific request id or cluster name. Example:

Cancel request cb-12345 on cluster prod? This will return an error to whichever client issued it.

After they confirm, run the tool and report success or failure based on the returned ok field.

What to avoid

Don't restart the service to "fix" a slow query — try cancelling it first.
Don't call cancel_request on a client_context_id that's already completed; it's a no-op but generates a confusing error.
Don't poll get_active_requests aggressively (e.g. every second). Once per few seconds is fine.

Rate limits & safety

Admin tools split across two rate-limit categories:

read (60/sec): get_service_status, get_ingestion_status, get_active_requests, get_completed_requests.
write (1/sec, intentionally conservative): cancel_request, restart_service, restart_node.

The write bucket is small on purpose. Cancelling one runaway query per second is plenty; restarting a service every second would be madness. If a RateLimitExceeded response comes back, the response includes retry_after_sec — honour it. Don't retry-storm; that just keeps the bucket empty.

Status calls share the read bucket with every other read-only tool across the server (list_users, list_clusters, ping_cluster, etc.). If you're polling status in a loop, keep the interval ≥ 2 seconds so the bucket stays healthy for other concurrent work.

Related skills

cb-analytics-query — the query tools that generate the requests you'll be monitoring and cancelling
cb-analytics-cluster — cluster-level health (nodes, rebalance, auto-failover) that underpins Analytics service health