Connect your monitoring — Zabbix, Datadog, Prometheus

1Declare your assets

A health status is attached to an asset in your CMDB. Declare your assets first in My incidents → CMDB, flagging the critical ones.

The name is enough. Your probes do not need to know internal identifiers: they send the asset name as it appears in the CMDB, and matching is automatic.

2Create the integration key

Open Connect my applications.
Create a connector of type observability.
Copy the key, formatted as ik_<tenant>_<secret>.

The key carries the tenant. It identifies your organisation without any further authentication. Treat it like a password: it is encrypted at rest on the TOONAH side; protecting it on the probe side is up to you.

3Push a status

A POST request to /v1/observability/inbound, with the key in a header.

# One asset
curl -X POST https://app.toonah.io/v1/observability/inbound \
  -H "X-Integration-Key: ik_YOUR_TENANT_YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "asset": "Payments API",
    "status": "up",
    "latency_ms": 142,
    "error_rate": 0.002,
    "source": "prometheus"
  }'

Several assets at once

curl -X POST https://app.toonah.io/v1/observability/inbound \
  -H "X-Integration-Key: ik_YOUR_TENANT_YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "asset": "Payments API",   "status": "up",       "latency_ms": 142 },
      { "asset": "Customer DB",    "status": "degraded", "latency_ms": 2100,
        "error_rate": 0.08 },
      { "asset": "SMS gateway",    "status": "down" }
    ]
  }'

Accepted fields

Field	Description
asset	Asset name as it appears in the CMDB. Alternatives: `name`, or `ci_id` if you know the internal identifier.
status	`up`, `degraded`, `down`. Any other value is treated as `unknown`.
latency_ms	Response time in milliseconds. Optional.
error_rate	Error rate between 0 and 1 — `0.08` for 8%. Optional.
metrics	Free-form object for additional measures: CPU, memory, queue depth. Optional.
source	Name of your monitoring tool, to trace the origin. Optional, 60 characters.
checked_at	Measurement timestamp. Defaults to the time of receipt.

Response. {"ok":true,"ingested":3,"unresolved":0} — unresolved counts items whose asset could not be found. If it is not zero, check that the name matches the CMDB exactly.

Sample probe

A few lines are enough to watch a service and push its status.

#!/usr/bin/env bash
# Simple HTTP probe, run by cron every 5 minutes.
KEY="ik_YOUR_TENANT_YOUR_SECRET"
ASSET="Payments API"
URL="https://api.example.org/health"
start=$(date +%s%3N)
code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$URL" || echo 000)
latency=$(( $(date +%s%3N) - start ))
# Status derives from the HTTP code and the latency.
if   [ "$code" = "200" ] && [ "$latency" -lt 1000 ]; then status="up"
elif [ "$code" = "200" ];                             then status="degraded"
else                                                       status="down"
fi
curl -s -X POST https://app.toonah.io/v1/observability/inbound \
  -H "X-Integration-Key: $KEY" \
  -H "Content-Type: application/json" \
  -d "{\"asset\":\"$ASSET\",\"status\":\"$status\",\"latency_ms\":$latency,\"source\":\"cron\"}"

Frequency. Five minutes suits most needs. A more frequent probe does not improve GRC steering: this screen shows the trend, it does not replace your real-time monitoring.

What you get

The Asset health screen shows each monitored asset's status, latency, error rate and last check time. Critical assets without a probe are flagged as such — a critical asset with no probe is a blind spot.

These statuses also feed business continuity: an asset linked to a continuity plan and unavailable for a sustained period signals that the plan should be activated.

Trouble connecting?

Write to contact@toonah.io. See also the user guide (in French).