Extend your Checkmk monitoring with packages created by community members. Or create your own packages and share the here with the rest of the community.
by otAAAh
A guided setup wizard for the Generic JSON API agent — build a monitoring rule from your API's real response, right inside Checkmk. This is the optional companion to the **Generic JSON API** package. It adds an in-site wizard under **Setup → Quick setup** that walks you from a live API response to a finished rule — no `rules.mk`, no `curl`, no leaving Checkmk. ## Requires - The **Generic JSON API** (`json_api`) package must be installed and enabled first — this Explorer only *builds* rules for that agent; it does not monitor anything on its own. - **Checkmk 2.5 or newer**, any edition. The wizard is built on Checkmk's native Quick-Setup UI, which does not exist on 2.4. ## What it does - 🧭 **Guided, step by step** — choose the target folder and host, define one or more endpoints (URL, method, auth, headers, TLS/redirect options), then pick the fields to monitor. - 🔎 **Fetches the real response** — the wizard calls each endpoint from the site and shows you the actual JSON, so you click the fields that exist instead of guessing paths. - 🎯 **Point-and-pick fields** — select values by path, set WARN/CRIT thresholds, units, a numeric transform, an aggregation over a collection, a counter's rate or a timestamp's age, string matching, or turn each element of a `[*]` collection into a Checkmk host of its own — the same options the agent supports. - ✅ **Live preview before you commit** — the review step evaluates every chosen field against the fetched sample and shows the resulting service state, so you catch a wrong path or threshold before the rule exists. - 🔐 **Secure by default** — credentials are stored in the Checkmk password store and referenced, never written in clear text; TLS verification stays on. - 🚀 **One click to create** — the wizard writes the finished Generic JSON API rule for you. ## In short Install the **Generic JSON API** agent, then install this Explorer. Open **Setup → Quick setup → Generic JSON API**, point it at an endpoint, tick the fields you care about, and press create. The services appear on your host. ## Details - Extra/companion package — install alongside, and after, the Generic JSON API agent. - Checkmk **2.5+**, any edition. - Install via `mkp add` / `mkp enable`, or **Setup → Extension packages**. - GPL-2.0-only.
by otAAAh
Monitor any JSON API in Checkmk without writing a line of code. Point it at a /health, /status, or metrics endpoint, pick the fields you care about, and get a Checkmk service for each — thresholds, graphs, and alerts included. One rule. Any API. Done. # Generic JSON API ## What you get - 🎯 **Any endpoint, unmodified** — Spring Boot, Kubernetes, vendor appliances, your own apps. No special response format required. - 🧭 **Pick fields by path** — `components.db.status`, `items[0].count`, done. - 🔁 **Auto-discover arrays *and* objects** — `nodes[*].status` becomes one service per array element, and `components[*].status` one per object key (e.g. a Spring Boot Actuator `/health` map), automatically. - 🔢 **Aggregate a collection** — where `[*]` fans out one service per element, an aggregation collapses the whole collection into one service: the **number of elements** (queue length, unhealthy nodes) or the **sum / average / min / max** of the values (`queues[*].depth`). The result is a number, so units, WARN/CRIT levels and a metric all apply. - ⏱️ **Counters and timestamps, done right** — mark a field as a **counter** and monitor its per-second **rate** instead of an ever-growing total (`requests_total`); mark it as a **timestamp** and monitor its **age**, so upper levels alert on stale data (`last_backup` older than 26 h → WARN). - 🖧 **One Checkmk host per element** — point a `[*]` field at a field holding a host name and every element becomes a **host of its own**, not just another service. An API describing a fleet gives you hosts with their own downtimes, contact groups and availability, instead of one host with a hundred services. - 🩺 **Every endpoint monitors itself** — each endpoint also gets a `JSON API <*name*>` service with the **HTTP status, response time** (thresholds optional), response size and, for HTTPS, the **TLS certificate's remaining validity** — read from the connection it is already making, so no second check against the same URL. Zero configuration; it comes with the rule. - 🐢 **Rate-limited API? Cache it** — give an endpoint a TTL and the agent reuses its last response instead of asking again, so monitoring cannot exhaust a request quota. It never caches an error and never answers a failed request from an expired cache, so a real outage still shows up. - 🔗 **Many endpoints, one rule** — poll several APIs together, each with its own method, auth, and fields; an unreachable one only affects its own services. - 📈 **Thresholds & graphs in Checkmk** — WARN/CRIT and metrics live in *your* rule, not upstream in the API. - 🧮 **Transform the numeric value** — apply a small arithmetic expression like `value / 1024 / 1024` (bytes→MiB) or `(value - 32) * 5 / 9` (°F→°C) before levels and the metric; safely evaluated, no `eval`. - 🔤 **String matching, two ways** — require a value to match a regex (pick the state when it doesn't, default CRIT), or map values like `ready` / `degraded` / `failed` straight to OK / WARN / CRIT. - 🔐 **Secure by default** — basic or bearer auth via the password store, TLS verification on. - 🧰 **Bonus field picker** — paste your JSON in the bundled explorer, click what to monitor, copy the ready-made rule. On Checkmk 2.5+, install the optional companion package **Generic JSON API – Explorer (extra)** for a guided in-site wizard that builds the rule for you from a live API response. ## In 30 seconds `GET /actuator/health` → `{"status": "UP", "components": {"db": {"status": "UP"}}}` Tick `status` (expect `UP`) and `components.db.status` → instant services `JSON Health` and `JSON Database`. That's the whole setup. ## Details - **Checkmk 2.4+**, any edition. Tested on real 2.4 and 2.5 sites. - Install via `mkp add` / `mkp enable`, or **Setup → Extension packages**. - GPL-2.0-only
by lainerp
## Palo Alto IPSec VPN Monitoring Checkmk special agent and check plug-in for monitoring the operational state of IPSec VPN tunnels on Palo Alto Networks firewalls. The plug-in queries the PAN-OS XML API for the VPN flow status. Unlike interface-based SNMP monitoring, it retrieves the actual IPSec tunnel state reported by PAN-OS. ### Features - Automatic discovery of IPSec VPN tunnels - One Checkmk service per tunnel - Active tunnels reported as `OK` - Inactive tunnels reported as `CRIT` - Other tunnel states reported as `UNKNOWN` - Secure integration with the Checkmk password store - Configurable API timeout - Optional HTTPS certificate verification - Details for peer IP, local IP, interfaces, monitoring state and tunnel IDs ### Requirements - Checkmk 2.4 - HTTPS access from the Checkmk server to the firewall management interface - PAN-OS XML API key - PAN-OS administrator role with `XML API > Operational Requests` permission ### Tested with - Checkmk Enterprise Edition 2.4.0p22 - Palo Alto Networks PA-460 ### Installation Install the MKP using the Checkmk Extension Packages interface or command line: ```bash mkp add paloalto_ipsec-1.0.0.mkp mkp enable paloalto_ipsec cmk -R ``` After installation: 1. Store the PAN-OS API key under `Setup > General > Passwords`. 2. Configure `Palo Alto IPSec VPN monitoring` under the special-agent integrations. 3. Assign the rule to the firewall host. 4. Run service discovery. ### Security The API key is resolved through the Checkmk password store. The secret itself is not exposed in verbose Checkmk output or in the special-agent process arguments. ### Disclaimer This project is not affiliated with or endorsed by Checkmk GmbH or Palo Alto Networks.
by SHER
Original check by Kai Biebel, originally packaged by Roger Ellenberger (WagnerAG). Original listing: https://exchange.checkmk.com/p/dfs-backlog Monitors DFS Replication (DFSR) backlog per folder and partner on Windows via the root\MicrosoftDFS WMI provider. One service per folder/partner/direction, with configurable file-count thresholds. Fixed: the bakery module used a removed API, so the deploy toggle silently produced no file. Migrated to register.bakery_plugin. Also adds per-pairing error isolation, so a single unreachable partner doesn't blank the section.
by SHER
Original check by Allan GooD - allan.cassaro@gmail.com, originally packaged by Roger Ellenberger (WagnerAG). Original listing: https://exchange.checkmk.com/p/dfs-state Monitors DFS Replication (DFSR) state per replicated folder on Windows via the root\MicrosoftDFS WMI provider. One service per folder: Normal, Initializing, Initial Sync, Auto Recovery, or Error. Fixed: the bakery module used a removed API, so the deploy toggle silently produced no file. Migrated to register.bakery_plugin. Also fixed an item-detection bug where folder names with spaces failed to parse.
by rsander
Agent Plugin to check SSL certificates in specified directories Now with support to check signature algorithm Windows Plugin added JSON data in agent data section Is now able to ignore certificates with a short lifetime
by simonmeggle
Robotmk integrates Robot Framework results into Checkmk.
by lgbff
This check monitors the status of ssl cert checks on ssllab.com. Changelog: - 3.2.0 no systemtime in agent output - 3.x version for cmk 2.2 - 2.1.0 change to python3 - 2.0.1 fix datasource_programm group definition - 2.0.0 insert cache for api response - 1.6.0 insert Agent status (line[3]) - 1.5.3 change default status - 1.5.2 Insert Agent Header infos - 1.5.1 cache default settings - 1.5.0 new data seperator (59) - 1.4.9 fix display JSON Error on check result. - 1.4.8 fix connect exeption - 1.4.7 add default value for timeout - 1.4.6 change timeout handling - 1.4.5 fix inventory issue while JSON issues - 1.4.4 change urlopen error handling - 1.4.3 Rename check file - 1.4.2 Fix check manpage - 1.4.1 delete modul calls from check - 1.4.0 changes for cmk version 1.4 - 1.3.1 improve error handling.