Send alert state to Nagios or Icinga
SZ-MCP can send its alert problems to Nagios or Icinga as passive check
results: one service per enabled alert rule, plus an SZ-MCP summary
service, all on one host. A changed result goes out within a minute, and every
result is sent again at each interval, so a freshness check on your side tells
you if SZ-MCP stops sending. Set it up under Configure › Integrations.
To have your monitoring system poll SZ-MCP instead, see Can my monitoring system poll the alert state?
What rules apply to every integration?
Section titled “What rules apply to every integration?”These rules apply to all seven integration kinds (Nagios, Icinga 2, Zabbix, Splunk, syslog, ServiceNow and NetBox):
- Admins only. Only an admin or the owner can add, edit, remove or Send now. Every member can see the list, each integration’s last result, and Recent deliveries.
- Up to 5 integrations per organisation, of all kinds together. A sixth is refused with “Up to 5 integrations.”
- https to a public host. URLs must be
https://and resolve to a publicly routable address. TLS servers need a publicly trusted certificate. Internal systems can’t be reached. Errors read “url: the URL must be https” or “url: host ”…” is not publicly routable”. - Secrets are write-only. A token or password is stored encrypted and never shown again. When editing, leave it blank to keep it. Changing the URL, server, port or kind needs the secret again: “secret: enter … again to change where it is sent”.
- The kind can’t be changed once saved. Remove the integration and add a new one.
- Failures and state changes are logged under Recent deliveries on the
Integrations page, as
nrdp:<name>oricinga2:<name>. The periodic re-send is not logged.
How do I set up Nagios (NRDP)?
Section titled “How do I set up Nagios (NRDP)?”- In Nagios, have NRDP running and note its URL and token.
- In SZ-MCP, open Configure › Integrations, click Add an integration, and choose Nagios (NRDP).
- Enter a Name, the NRDP URL (for example
https://nagios.example.com/nrdp/) and the NRDP token. Adjust the fields below if you need to, then click Save. - Click Config on the integration. It opens Nagios object definitions for the host and one passive service per result. Add them to your Nagios configuration and reload Nagios.
- Click Send now to send every result at once.
How do I set up Icinga 2?
Section titled “How do I set up Icinga 2?”- In Icinga 2, create an API user with the
actions/process-check-resultpermission. - In SZ-MCP, open Configure › Integrations, click Add an integration, and choose Icinga 2 (API).
- Enter a Name, the Icinga API URL (for example
https://icinga.example.com:5665), the API user and the API password, then click Save. - Click Config. It opens Icinga 2 DSL for the host and its services. Add it to your Icinga configuration and reload Icinga.
- Click Send now.
Icinga 2 results are sent one service at a time. A service that doesn’t exist in Icinga is reported by name: “Icinga: no service sz-mcp!… (add them from the generated config)”. Add services again from Config whenever you add alert rules.
What do the fields do?
Section titled “What do the fields do?”| Field | Default | Effect |
|---|---|---|
| Host name in Nagios / Icinga | sz-mcp | The one host every service sits on. Letters, digits, _ . -, up to 63 characters |
| Service name prefix (optional) | none | Put before each rule’s name, for example sz- (up to 20 characters). The SZ-MCP summary keeps its name |
| Send everything every (minutes) | 5 | 1–60. Every result is re-sent this often, as well as whenever it changes |
| The SZ-MCP summary service | On | A service judging all problems together |
| Acknowledged, in-downtime and unreachable problems raise the state too | Off | See below |
| Enabled | On | Off stops sending without removing it |
What state does each service report?
Section titled “What state does each service report?”A service’s state is the worst unhandled HARD problem of its rule. Acknowledged problems, problems in downtime and unreachable problems (their upstream is down) are counted in the output and perfdata, but they don’t raise the state unless you tick the “raise the state too” option. SOFT problems never raise it. With no problems, the service is OK. Disabled rules get no service.
Each rule’s 100 worst problems are judged, so one busy rule can’t push another rule’s problems out of view. When there are more, the output says so.
How does the freshness check work?
Section titled “How does the freshness check work?”The generated config marks each service stale after three intervals without a
result (15 minutes at the default 5). A stale service goes UNKNOWN with “No
result from sz-mcp within the freshness threshold”, which means SZ-MCP stopped
sending. For Nagios, the config defines the szmcp_ok and szmcp_stale
commands on check_dummy. For Icinga, it defines a szmcp-passive service
template on the dummy check command.
Generate the config again after changing the interval, adding rules, or changing the host or prefix.