cb-analytics-admin

name	cb-analytics-admin
description	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".
license	MIT

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":

1. get_service_status — is the service even healthy? Watch ccRevLag (replication lag).
2. get_ingestion_status — for each link, look at pendingOperations. A non-zero pending count after a quiet period usually means a stuck link.
3. get_active_requests — long-running queries appear here with elapsedTime. Anything over a few seconds is suspect.
4. 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