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 schau87
# Quantum Scalar i3 SNMP Monitoring Community MKP for monitoring **Quantum Scalar i3** tape libraries with Checkmk. This package adds native-style SNMP checks for devices using the Quantum Scalar i3 / i6 MIB branch: `1.3.6.1.4.1.3697.1.10.15` It is intended for Scalar i3 systems, not for the existing Checkmk `quantum_libsmall_*` checks, which are designed for Quantum Small Tape Libraries. ## What you get - Overall Scalar i3 health status - Library control, drive and media RAS health - Robotics and magazine state - I/E area state - Open RAS ticket count - Tape drive discovery, one service per physical drive - Logical library / partition discovery - Power supply discovery and power consumption - Temperature and humidity sensor monitoring - Capacity monitoring for storage slots, I/E slots, media and cleaning media - HW/SW inventory for Scalar i3 model, firmware, serial-numbers and components ## Created services The package can create services such as: - `Quantum Scalar i3 health` - `Quantum Scalar i3 I/E area` - `Quantum Scalar i3 RAS tickets` - `Quantum Scalar i3 capacity` - `Quantum Scalar i3 drive serial-number` - `Quantum Scalar i3 logical library name` - `Quantum Scalar i3 power supply location` - `Quantum Scalar i3 sensor name` The exact number of services depends on the hardware configuration and the data exposed by the device SNMP walk. ## Requirements - Checkmk 2.5 - SNMP access to the Quantum Scalar i3 - Device must expose the Quantum Scalar i3 MIB branch under `1.3.6.1.4.1.3697.1.10.15` ## Installation Install via mkp add / mkp enable, or Setup >> Extension packages.
by alex23
This MKP is an early version and not final yet. Feedback, suggestions, and improvements are very welcome. The VMware Avi Special Agent monitors: - Alerts - Certificates - Clouds - Controller clusters and nodes - Pools - Service Engines using piggyback data - Virtual Services The package includes configurable monitoring rules, performance metrics, graph definitions, and a preconfigured dashboard for VMware Avi environments. **When upgrading from version 0.2.0, existing VMware Avi Special Agent and Virtual Service rules must be deleted before the update and recreated afterward. Version 0.2.0 also contains a severe parsing error and should no longer be used.** For installation instructions, configuration details, monitored metrics, upgrade notes, and the complete changelog, see the linked GitHub repository.
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 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.