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 mbunkus
Unifi devices by querying controller API This is a fork of the "check-unifi-controller" project updated to the 2.3.0 API & compatible with 2.4.0. On top of those it adds a couple of fixes & adds more supported device types.
Monitor Hitachi NAS (HNAS) systems via the NAS File Storage REST API (v8, TCP port 8444) using a special agent — no SNMP required. Monitored components: - Filesystems — space usage with configurable levels (default 80%/90%), thin provisioning state (enabled/valid, states configurable), mount status (unmounted filesystems are reported as WARN by default), read-only flag, snapshot space usage - Snapshots — per filesystem: number of snapshots, age of the oldest snapshot (detect forgotten snapshots consuming space) and time since the last snapshot (detect that snapshot creation has stopped working) - Storage pools (spans) — space usage with configurable levels, health state (CRIT if the pool reports unhealthy) - Virtual servers (EVS) — status mapping ONLINE/DISABLED/OFFLINE/NOT_CONFIGURED - Cluster nodes — node status, model, firmware version and uptime - System drives (LUNs) — drive status, degraded and access state Features: - Authentication via API key (X-Api-Key, recommended by Hitachi) or username/password — stored as Checkmk secrets - Full WATO configuration: special agent rule plus check parameter rulesets for filesystems, snapshots and storage pools - Metrics, graphs and perfometers for filesystem and storage pool usage, snapshot count and snapshot age - Service descriptions included for all checks Setup: Create an API key on the HNAS (apikey-create), then configure the rule Hitachi HNAS via REST API under Setup > Agents > Other integrations. Requires Checkmk 2.4.0 or later. Developed and tested against NAS File Storage REST API v8.
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. - 🔢 **Count elements** — flip a switch to monitor *how many* elements a path holds (array length or object keys) instead of the value: queue length, number of unhealthy nodes, ... The count is a number, so units, WARN/CRIT levels and a metric all apply. Where `[*]` fans out one service per element, `count` collapses the whole collection into one "how many" service. - 🔗 **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 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, element counting, or string matching — 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 SHER
SMART monitoring for Synology NAS via SNMP. Creates one service per disk (named by drive bay, incl. expansion units) and alerts on DSM-reported attribute failures plus rising pre-failure counters: reallocated, pending, and uncorrectable sectors, and UDMA CRC errors. Thresholds adjustable per service via an optional rule set. Validated on DSM 6.2, 7.0 and 7.1+.
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.