Queue AIops

Governed AI-ops for redis + rabbitmq. queue-aiops is for the team running their own cache and message broker — a redis that "suddenly eats memory", a rabbitmq whose queues quietly grow until publishers block — without an enterprise observability suite. It gives an AI agent (or a human at the CLI) a governed toolset over both: transparent root-cause analyses for memory pressure, latency, queue backlog, and connection churn, plus the handful of writes an operator actually needs (config set, client kill, purge/delete queue, policies) — every call audited, budgeted, risk-tiered, and undo-recorded by the built-in governance harness.

Disclaimer: Community-maintained open-source project, not affiliated with, endorsed by, or sponsored by the Redis or RabbitMQ projects or their respective owners. Redis and RabbitMQ are trademarks of their respective owners.

Verification: behaviour is covered by a mock-based test suite; not yet validated against live brokers. Both redis and rabbitmq are free/self-hostable (one lab container or package install each), so a lab check is easy — queue-aiops doctor is the fastest live probe, and docs/VERIFICATION.md is the checklist.

Quick start

As a Claude Code plugin

One install gives an agent both the skill and the MCP server:

/plugin marketplace add AIops-tools/marketplace
/plugin install queue-aiops@aiops-tools

The MCP server is fetched with uv and pinned to the package version this plugin declares, so an audit row can be traced back to the code that wrote it. Credentials are still configured with queue-aiops init — see below.

As an OpenClaw plugin

The same bundle is published on ClawHub, where one install delivers the skill and its MCP server together:

openclaw plugins install clawhub:@zw008/queue-aiops
openclaw skills info queue-aiops          # expect: Visible to model: yes

Restart the OpenClaw gateway afterwards so it loads the plugin. The MCP server is fetched with uv, pinned to this exact release, so uvx has to be on PATH — without it the skill still installs but reports Visible to model: no. Credentials are configured exactly as below.

As a CLI or standalone MCP server

uv tool install queue-aiops

queue-aiops init      # wizard: pick platform (redis/rabbitmq), host/port, encrypted secret
queue-aiops doctor    # config + secret + connectivity check (PING / /api/overview)
queue-aiops overview  # one-shot health summary for the default target

Then the interesting parts:

queue-aiops analyze memory     # redis memory-pressure RCA (maxmemory, eviction, frag, big keys)
queue-aiops analyze latency    # redis latency RCA (slowlog digest, fork/AOF stalls)
queue-aiops analyze backlog    # rabbitmq queue-backlog RCA (consumers, unacked, watermarks)
queue-aiops analyze churn      # connection churn, both platforms
queue-aiops redis bigkeys      # SCAN-budgeted big-key sample (never KEYS *)
queue-aiops rabbitmq queues    # deepest backlog first

What this tool does, and does not, decide

It delivers broker operations — reads and writes — accurately and efficiently, and records every one of them. It does not decide whether a write is allowed to happen. That is the agent's judgement, or the permission of the account you connect it with: give the Redis connection an ACL user restricted to read commands, or the RabbitMQ management user only the monitoring tag, and the writes fail at the broker — the place that actually owns the permission.

So there is no read-only switch, no policy file, no approval gate to configure. The one thing the tool guarantees is that nothing is silent: every call, over MCP and over the CLI alike, lands an audit row in ~/.queue-aiops/audit.db, and reversible writes still capture their before-state and record an inverse.

Each tool declares a risk_level, kept in agreement with its [READ]/[WRITE] documentation tag by a test, and carried into the audit row as a descriptive tier — so a reviewer can see at a glance that a row was a high-risk delete. It is a label, not a gate.

Running a smaller / local model? See agent-guardrails.md — it lists the guardrails this tool now enforces for you (so you don't spend prompt budget restating them) and gives a ready-made system prompt for what's left.

Support scope

28 MCP tools — 20 reads (incl. 4 flagship RCAs) + 8 governed writes.

The four RCAs are transparent heuristics that report their numbers — thresholds are named constants, every finding carries its evidence, never a black-box verdict. Big-key sampling walks at most 10,000 keys with SCAN and sizes at most 200 with MEMORY USAGE — never KEYS * — and reports its coverage.

Governance

Every MCP tool — and every CLI write, which routes through the same governed functions — runs through the bundled @governed_tool harness (queue_aiops.governance — no external dependency). It records; it does not authorize whether a write may happen (see above):

• Audit — every call lands in ~/.queue-aiops/audit.db (relocatable via QUEUE_AIOPS_HOME), secret-redacted. The CLI writes the same row the MCP path does — there is no unaudited entry point.
• Budget / runaway guard — a safety backstop, not an authorization gate: call/time ceilings (QUEUE_MAX_TOOL_CALLS, QUEUE_MAX_TOOL_SECONDS) + a runaway-loop breaker stop a stuck agent from burning unbounded calls/time.
• Risk tier — a descriptive label on the audit row derived from risk_level; it gates nothing. QUEUE_AUDIT_APPROVED_BY / QUEUE_AUDIT_RATIONALE are optional annotations recorded on the row (who/why), never required and never blocking.
• Undo — reversible writes capture the real before-state first: redis_config_set records the prior value from CONFIG GET; set_policy/delete_policy record the prior policy; delete_queue records the queue's definition and its undo re-declares it (the messages are not restored — the descriptor says so). Irreversible writes (purge_queue, redis_kill_client) record priorState only.
• Dry-run + double-confirm — every write takes dry_run=True (MCP) / --dry-run (CLI); CLI writes double-confirm and execute through the same governed twins, so they land in the audit log too. purge_queue and delete_queue are risk=high with dry-run + double confirmation at the CLI.
• Credentials live encrypted in ~/.queue-aiops/secrets.enc (Fernet + scrypt master password; QUEUE_AIOPS_MASTER_PASSWORD for non-interactive use). Redis passwords are optional — an auth-less lab instance is a supported target.

MCP configuration

{
  "mcpServers": {
    "queue-aiops": {
      "command": "uvx",
      "args": ["--from", "queue-aiops", "queue-aiops-mcp"],
      "env": {
        "QUEUE_AIOPS_MASTER_PASSWORD": "your-master-password"
      }
    }
  }
}

env-block caveat: MCP clients launch the server with a minimal environment — your shell profile is not sourced. Anything the server needs (QUEUE_AIOPS_MASTER_PASSWORD, a relocated QUEUE_AIOPS_HOME, and any optional QUEUE_AUDIT_APPROVED_BY/QUEUE_AUDIT_RATIONALE audit annotations) must be set in the env block above, not just in your terminal.

Or, with the package installed: queue-aiops mcp.

CLI reference (short)

queue-aiops init | doctor | overview | mcp
queue-aiops secret set|list|migrate ...
queue-aiops redis info|memory|clients|slowlog|config-get|keyspace|bigkeys
queue-aiops redis config-set <param> <value> [--dry-run]
queue-aiops redis kill-client --id <id> | --addr <ip:port> [--dry-run]
queue-aiops rabbitmq overview|queues|queue|connections|channels|policies|nodes
queue-aiops rabbitmq purge|delete-queue|declare-queue <name> [--vhost /] [--dry-run]
queue-aiops rabbitmq set-policy|delete-policy <name> ... [--dry-run]
queue-aiops analyze memory|latency|backlog|churn

Verification status

Live-verified against Redis 7.4.9 and RabbitMQ 3.13.7 (2026-07-19/20). Connectivity, every Redis read (cross-checked against redis-cli ground truth), all four analyses, and the full governance loop (real redis_config_set → audit row → undo restoring the prior value) were exercised against a real server. That run found and fixed a real defect: integer quantities — key counts, client counts, byte totals — were rendered as floats (202.0 keys), which equality assertions cannot catch.