[mjunek]

What and why

Phase 24 (docs/ARCHITECTURE.md section 7.7, "Zabbix templates", decision 51). Stacked on #73 → #72 → #71; merge those first.

• Generator (monitoring/zabbix.py), driven by the metric catalogue: items, discovery prototypes, units and value maps. Each version (6.0 and 7.0 LTS) has its own small emitter over shared content, with stable derived UUIDs.
  • manage.py zabbix_template --version 6.0|7.0 and make zabbix-template write deploy/zabbix/devicevault_zabbix_{6.0,7.0}.yaml, which are committed.
  • A test fails if the committed files drift from the generator.
  • GET /api/monitoring/zabbix/template/?version= serves the same file as a download (400 for an unknown version). The Monitoring admin page has download buttons for both versions.
• DeviceVault by HTTP, linked to one host:
  • HTTP agent master items for summary/, device-groups/, workers/, storage-targets/ and receivers/, plus an HTTP-status item for reachability.
  • Dependent items, and dependent discovery rules for groups, workers, targets and receivers.
  • Value maps, units, threshold macros, and triggers with recovery expressions, tags and dependencies on the endpoint trigger.
  • A dashboard.
• DeviceVault Device by HTTP, linked to existing device hosts:
  • polls {$DV.RELAY.URL}/device/?ip={HOST.IP}&id={$DV.DEVICE.ID} every 15 minutes, with peer verification off for the relays' self-signed certificates;
  • triggers: not backed up by DeviceVault (switchable), overdue, failing, authentication failing, an optional flat stale threshold, no data, and data too old.
• Validation: make zabbix-validate imports both templates into real Zabbix servers (alpine-6.0.49, alpine-7.0.32) and polls a stub serving recorded responses.
  • Hosts: the DeviceVault host, a refused-token host, and device hosts answering found, not found and 503.
  • It checks every item and value and the exact set of triggers that fire.
  • It runs in the new zabbix.yml workflow on monitoring changes (not required, not part of make check).
• Docs: a Zabbix guide in DEPLOYMENT.md section 6 (import, global macros, the per-zone relay template, macros and thresholds, request rate, staleness). ROADMAP.md now marks Q4 and Q9 built and Q5 partly built.

Deviations from the plan are recorded in ARCHITECTURE.md:

• {$DV.URL} and {$DV.TOKEN} are left off the templates, so the global macros the guide asks for aren't shadowed.
• There are separate nodata period macros, because nodata() can't take a multiple of a macro.
• The device hosts are validated against the stub, not a live relay. The relay was tested by hand in feat(receiver): monitoring relay for zoned Zabbix proxies #73 and serves the same device_response.

How it was tested

• make check passes, including the PostgreSQL run.
• make zabbix-validate, for each of 6.0.49 and 7.0.32:
  • 554 items and 8 discovery rules on 5 hosts, 0 unsupported (except the intended refused-token host);
  • 427 recorded values matched;
  • exactly the 20 expected triggers fired.
• On the make dev-up stack: the template endpoint served both versions byte-identical to the committed files and returned 400 for an unknown version, and the Monitoring page loads.

Checklist

• make check passes locally
• Tests added or updated for the change
• New DV_* variables are documented in docs/DEPLOYMENT.md and the relevant *.env.example (none new)
• Model changes have generated migrations (makemigrations) (none)
• API changes keep api/serializers.py, api/views.py and frontend/src/api/types.ts / endpoints.ts in step
• Docs (README.md, docs/) updated where behaviour changed