Monitoring Aiops

Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by SolarWinds, Paessler, Zabbix, or any monitoring vendor. SolarWinds, Orion, SWQL, THWACK, PRTG, Paessler and Zabbix are trademarks of their respective owners. MIT licensed.

Governed AI-ops for network / infrastructure monitoring across three NOC platforms in one server — SolarWinds Orion (SWIS REST + SWQL, port 17774 with an automatic fallback to the legacy 17778, HTTP Basic auth), Paessler PRTG (web API, port 443/8080, API token), and Zabbix 6.x/7.x (JSON-RPC 2.0 at /api_jsonrpc.php, API token) — with a built-in governance harness: unified audit log, policy engine, token/runaway budget guard, undo-token recording, and risk-tier labelling on the audit trail. One config can span all NOCs; each target names its own platform.

What it does

Answers the questions a NOC operator actually repeats, and guards the writes that follow:

• Canned-SWQL library — the most-asked THWACK questions shipped as named, validated queries (nodes_down, flapping_interfaces, muted_report, high_cpu_nodes, volumes_full, unmanaged_scheduled), plus a validated read-only SWQL passthrough (SELECT-only) for everything else.
• Active-alert dedup / rollup — collapses an interface-flap or node-down storm into a single counted entry instead of a wall of near-identical alerts, across SolarWinds, PRTG, and Zabbix (problems, with the 0-5 severity scale mapped to canonical levels).
• Triple SolarWinds + PRTG + Zabbix coverage — one MCP server spans all three NOCs; no incumbent hobby MCP does.
• Governed writes — mute/unmute, maintenance windows (incl. Zabbix maintenance.create with a replayable delete-undo), unmanage/remanage, node removal, and PRTG sensor pause/resume — each audited, risk-tiered, and the destructive ones gated with dry-run + double-confirm. Suppression and maintenance writes are time-boxed (they require an end time / duration).

What this tool does, and does not, decide

It delivers NOC 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 it a SolarWinds/PRTG/Zabbix account with read-only monitoring scope and the writes fail at the server — 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 ~/.monitoring-aiops/audit.db, and destructive writes still capture their before-state and record an inverse where one exists.

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 node removal. 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.

Capability matrix (42 MCP tools)