/zabbix

name: zabbix
description: "Read Zabbix monitoring state, inspect monitored hosts, summarize current or recent problems, and prepare guarded incident-response context without exposing Zabbix credentials."
user-invocable: true
requires:
  bins:
    - node
credentials:
  - id: ZABBIX_API_TOKEN
    kind: bearer
    required: true
    secret_ref:
      source: store
      id: ZABBIX_API_TOKEN
    scope: "https://<zabbix-frontend>/api_jsonrpc.php Authorization bearer"
    how_to_obtain: |
      Create a Zabbix API token in the Zabbix frontend. Set
      `ZABBIX_API_TOKEN` through browser admin at
      `/admin/secrets`; if browser admin is unavailable,
      use `/secret set ZABBIX_API_TOKEN "<token>"` in browser `/chat` or TUI;
      local console fallback:
      `hybridclaw secret set ZABBIX_API_TOKEN "<token>"`.
metadata:
  hybridclaw:
    category: production-ops
    short_description: "Zabbix monitoring reads for incident triage."
    tags:
      - zabbix
      - monitoring
      - incident-response
      - production
      - r21
    related_roadmap:
      - R21
      - R32
      - R33
    issue: 1045
    stakes_tiers:
      green:
        - api-version
        - host-inventory
        - problem-read
        - trigger-problem-read
        - incident-summary
      amber:
        - event-acknowledge
        - event-suppress
      red:
        - event-close
    escalation:
      writes: confirm-each
      route: f14
    cost_measurement:
      system: UsageTotals
      sub_limit_key: zabbix

Zabbix

Use this skill for Zabbix production monitoring reads: API health checks, monitored host inventory, current or recent problems, problem-state triggers by severity, and concise incident summaries that can feed R29 cards. Zabbix tells us what is broken; local or SSH maintenance skills investigate and remediate on the affected host.

This v1 skill is read-only. Do not acknowledge, suppress, close, update, or delete Zabbix objects through this skill. If a later task adds write operations, each write must be amber/red, require an exact operator grant through F8/F14, and include the Zabbix event id and action in the approval text.

Credential Rules

Set or update the API token in this order:

1. Browser admin: open the active HybridClaw admin URL ending in `/admin/secrets` and set `ZABBIX_API_TOKEN`. 2. Browser `/chat` or TUI fallback: `/secret set ZABBIX_API_TOKEN "<zabbix-api-token>"`. 3. Local console fallback:

hybridclaw secret set ZABBIX_API_TOKEN "<zabbix-api-token>"

For live calls, run the helper to build a gateway `http_request` payload and pass only the emitted `httpRequest` object to the built-in `http_request` tool. The helper sets `bearerSecretName: "ZABBIX_API_TOKEN"` for authenticated Zabbix methods so the gateway injects the bearer token server-side. It never prints `Authorization` headers, token values, usernames, passwords, or Zabbix session tokens.

When a terminal-side live smoke test is needed, pass `--live` to the same `http-request` command. It posts the same `httpRequest` object to the HybridClaw gateway `/api/http/request` route and stops after the first Zabbix 401/403 response. Set `HYBRIDCLAW_GATEWAY_URL` and `HYBRIDCLAW_GATEWAY_TOKEN` only for gateway access; do not store those as Zabbix credentials.

Do not call Zabbix with `curl` when the gateway `http_request` tool is available. Do not ask the user to paste a Zabbix API token, username/password, or session token into chat.

If the operator has a tenant-specific frontend path, pass it with `--base-url` or set `ZABBIX_BASE_URL` in the runtime environment. The helper accepts both `https://zabbix.example.com/zabbix` and `https://zabbix.example.com/zabbix/api_jsonrpc.php` and normalizes both to the JSON-RPC endpoint. HTTPS is required by default. Use `--allow-http` only for a trusted local or private Zabbix frontend where plaintext HTTP is an intentional operator choice.

Command Contract

Show helper usage:

node skills/zabbix/zabbix.cjs --help

Build an unauthenticated API smoke-test request:

node skills/zabbix/zabbix.cjs --format json http-request api-version \
  --base-url https://zabbix.example.com/zabbix

List monitored hosts and interfaces:

node skills/zabbix/zabbix.cjs --format json http-request hosts \
  --base-url https://zabbix.example.com/zabbix \
  --monitored-only

Read current or recent problems:

node skills/zabbix/zabbix.cjs --format json http-request problems \
  --base-url https://zabbix.example.com/zabbix \
  --recent \
  --limit 50

Read triggers in problem state:

node skills/zabbix/zabbix.cjs --format json http-request triggers-problem \
  --base-url https://zabbix.example.com/zabbix \
  --limit 50

Run one live gateway-proxied request, with no retry loop:

node skills/zabbix/zabbix.cjs --live --format json http-request problems \
  --base-url https://zabbix.example.com/zabbix \
  --recent \
  --limit 50

The helper prints a wrapper such as `{ "command": "http-request", "httpRequest": { ... } }`. Pass only the `httpRequest` value to the built-in `http_request` tool.

Official API references: [Zabbix API overview](https://www.zabbix.com/documentation/current/en/manual/api), [`host.get`](https://www.zabbix.com/documentation/current/en/manual/api/reference/host/get), [`problem.get`](https://www.zabbix.com/documentation/current/en/manual/api/reference/problem/get), and [`trigger.get`](https://www.zabbix.com/documentation/current/en/manual/api/reference/trigger/get).

Filters

Use IDs when filtering by host or host group because Zabbix JSON-RPC read methods filter most reliably on `hostids` and `groupids`:

node skills/zabbix/zabbix.cjs --format json http-request problems \
  --base-url https://zabbix.example.com/zabbix \
  --host-id 10084 \
  --group-id 2 \
  --severity high \
  --unacknowledged \
  --unsuppressed \
  --tag service=postgres \
  --time-from 1767225600 \
  --limit 25

Sup