fix(docs): remove Alerting Logic from Overview (belongs in States), add missing Nagios check names

Author: markuslf

check-plugins/cpu-usage/README.md

@@ -10,13 +10,6 @@ Perfdata is emitted for every field to enable full graphing. Extended stats (con
 
 This check is cross-platform and works on Linux, Windows, and all psutil-supported systems. The check stores its short trend state locally in an SQLite DB to evaluate sustained load across runs.
 
-**Alerting Logic:**
-
-* Thresholds apply to: `user`, `system`, `iowait`, and overall `cpu-usage`
-* Alert triggers only when threshold exceeded for `--count` consecutive check runs (default: 5)
-* Example: With default settings and 1-minute check interval, WARN/CRIT states require sustained high CPU for 5 consecutive minutes
-* Single brief spikes are ignored, focusing on persistent performance issues
-
 **Data Collection:**
 
 * System-wide aggregate CPU statistics (not per-core) via `psutil.cpu_times()`

check-plugins/fortios-network-io/README.md

@@ -4,12 +4,6 @@
 
 Monitors network I/O and link states on all interfaces of FortiGate appliances running FortiOS via the REST API. Alerts only if bandwidth thresholds have been exceeded for a configurable number of consecutive check runs (default: 5), suppressing short spikes. Reports per-interface traffic counters and link status. Authentication uses a single API token (token-based authentication).
 
-**Alerting Logic:**
-
-* WARN if link state, speed rate, or duplex mode for an interface changes compared to the inventorized baseline
-* WARN or CRIT if rx or tx bandwidth saturation (averaged over the last `--count` measurements) exceeds the configured thresholds
-* The check inventorizes your appliance on the first run. If you change any interface and want to reset the warnings, delete the `$TEMP/linuxfabrik-monitoring-plugins-fortios-network-io.db` file
-
 **Data Collection:**
 
 * Queries the FortiOS REST API endpoint `/api/v2/monitor/system/interface/select` to fetch per-interface traffic counters, link state, speed, and duplex mode

check-plugins/fortios-sensor/README.md

@@ -4,11 +4,6 @@
 
 Checks hardware sensor readings (temperature, voltage, fan speed) on FortiGate appliances running FortiOS via the REST API. Alerts when any sensor value crosses the appliance-defined thresholds (`lower_non_critical`, `lower_critical`, `upper_non_critical`, `upper_critical`). Sensors reporting a value of 0.0 are skipped automatically. Authentication uses a single API token (token-based authentication).
 
-**Alerting Logic:**
-
-* Uses the appliance's built-in threshold values for each sensor to determine WARN and CRIT states
-* Alerts separately on lower and upper threshold violations (e.g. a voltage dropping below its lower critical limit, or a temperature exceeding its upper non-critical limit)
-
 **Data Collection:**
 
 * Queries the FortiOS REST API endpoint `/api/v2/monitor/system/sensor-info/select` to fetch all hardware sensor readings and their thresholds

check-plugins/fortios-version/README.md

@@ -4,11 +4,6 @@
 
 Checks the installed FortiOS version against the endoflife.date API and alerts if the version is end-of-life or if newer major, minor, or patch releases are available. By default, alerts 30 days before the official EOL date. The offset is configurable.
 
-**Alerting Logic:**
-
-* WARN if the installed FortiOS version has reached or is approaching EOL (within `--offset-eol` days, default: 30 days before)
-* Optionally WARN when a new major, minor, or patch release is available (each independently configurable via `--check-major`, `--check-minor`, `--check-patch`)
-
 **Data Collection:**
 
 * Queries the FortiOS REST API endpoint `/api/v2/monitor/system/firmware/` to determine the installed version

check-plugins/fs-inodes/README.md

@@ -4,11 +4,6 @@
 
 Checks the percentage of used inodes on local filesystems. Fetches a list of local devices that are in use and have a filesystem. Filesystems that do not report inode usage (such as btrfs or some network filesystems) are skipped automatically. Alerts when inode usage exceeds the configured thresholds.
 
-**Alerting Logic:**
-
-* Compares inode usage percentage per mount point against `--warning` and `--critical` thresholds
-* Each mount point is evaluated independently; the overall state is the worst of all mount points
-
 **Data Collection:**
 
 * Uses `os.statvfs()` on each local disk mount point to read total and free inode counts

check-plugins/fs-ro/README.md

@@ -4,11 +4,6 @@
 
 Checks for unexpectedly read-only mounted filesystems, such as a root filesystem that switched to read-only due to disk errors. Ignores ramfs, squashfs (snapd), and other pseudo-filesystems by default. Additional mount points can be excluded via `--ignore`. Alerts when a read-only filesystem is detected that should be writable.
 
-**Alerting Logic:**
-
-* WARN if any mount point (not on the ignore list) is mounted read-only
-* Reports the device, mount point, and filesystem type for each read-only mount
-
 **Data Collection:**
 
 * Reads `/proc/mounts` and checks the mount options for each entry

check-plugins/getent/README.md

@@ -4,11 +4,6 @@
 
 Queries the Name Service Switch (NSS) for entries in system databases such as group, hosts, networks, passwd, protocols, or services using the `getent` command. Alerts if the lookup fails or if a specific key is not found. This is particularly useful for verifying that directory services (FreeIPA, Active Directory via sssd) are resolving users and groups correctly.
 
-**Alerting Logic:**
-
-* WARN if one or more supplied `--key` values could not be found in the specified `--database`
-* UNKNOWN if the database name is invalid or if enumeration is not supported for the given database
-
 **Data Collection:**
 
 * Executes `/usr/bin/getent <database> [key ...]` and evaluates the exit code

check-plugins/githubstatus/README.md

@@ -4,12 +4,6 @@
 
 Monitors the GitHub status page for service disruptions. Reports the overall status indicator, individual component states, and any unresolved incidents. Alerts on active incidents or degraded components.
 
-**Alerting Logic:**
-
-* WARN if there are any unresolved incidents
-* WARN if any GitHub component is not in "operational" state
-* WARN if the overall status indicator is not "none" (when no individual components or incidents are reported)
-
 **Data Collection:**
 
 * Queries the public GitHub status API at `https://www.githubstatus.com/api/v2/summary.json`

check-plugins/gitlab-health/README.md

@@ -4,10 +4,6 @@
 
 Checks whether the GitLab application server is running by querying the `/-/health` endpoint. This is a lightweight probe that does not hit the database or verify other backend services. A successful response confirms that the application server is processing requests, but does not guarantee that the database or other services are ready.
 
-**Alerting Logic:**
-
-* Alerts with the configured `--severity` (default: WARN) if the endpoint does not return "GitLab OK"
-
 **Data Collection:**
 
 * Sends an HTTP GET request to the GitLab health endpoint (default: `http://localhost/-/health`)

check-plugins/gitlab-liveness/README.md

@@ -4,10 +4,6 @@
 
 Checks whether the GitLab application server is alive by querying the `/-/liveness` endpoint. This probe detects deadlocked Rails controllers caused by multi-threading issues. A successful response confirms that no controllers are deadlocked.
 
-**Alerting Logic:**
-
-* Alerts with the configured `--severity` (default: WARN) if the endpoint returns an error or does not contain a "status" field
-
 **Data Collection:**
 
 * Sends an HTTP GET request to the GitLab liveness endpoint (default: `http://localhost/-/liveness`)