Add Mozilla HTTP Observatory API template for Zabbix 7.4#703
Add Mozilla HTTP Observatory API template for Zabbix 7.4#703redpeppers-01 wants to merge 3 commits intozabbix:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Adds a Zabbix 7.4 template to monitor Mozilla HTTP Observatory scan results via the public API, including discovery, per-target items, alerting policy, and end-user documentation.
Changes:
- Added a new Zabbix template YAML with LLD, item prototypes, trigger prototype, and macros.
- Implemented JavaScript preprocessing to normalize/deduplicate targets from
{$MOZ_API_TARGETS}. - Added a comprehensive README describing installation, usage, and troubleshooting.
Reviewed changes
Copilot reviewed 2 out of 5 changed files in this pull request and generated 24 comments.
| File | Description |
|---|---|
| Web_scenarios/template_mozilla_http_observatory/7.4/template_mozilla_http_observatory.yaml | Defines the new Zabbix 7.4 template (LLD, HTTP agent items, triggers, macros). |
| Web_scenarios/template_mozilla_http_observatory/7.4/README.md | Documents template features, setup steps, and operational guidance. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| name: 'Mozilla API {#TARGET}: Details URL' | ||
| type: HTTP_AGENT | ||
| key: 'mozilla.api.details_url[{#TARGET}]' |
There was a problem hiding this comment.
Each discovered target performs 8 separate HTTP agent POST requests to the same /api/v2/scan?host=... endpoint every interval. If the endpoint triggers (or queues) a scan per call, this multiplies external load and can lead to throttling/timeouts and unnecessary Zabbix worker utilization. Consider switching to a single 'master' HTTP agent item per target that fetches the JSON once, then implement the other metrics as dependent items extracting grade/score/status_code/tests_* (via JSONPath or JavaScript preprocessing).
| url: '{$MOZ_API_BASE}/api/v2/scan?host={#TARGET}' | ||
| request_method: POST |
There was a problem hiding this comment.
Each discovered target performs 8 separate HTTP agent POST requests to the same /api/v2/scan?host=... endpoint every interval. If the endpoint triggers (or queues) a scan per call, this multiplies external load and can lead to throttling/timeouts and unnecessary Zabbix worker utilization. Consider switching to a single 'master' HTTP agent item per target that fetches the JSON once, then implement the other metrics as dependent items extracting grade/score/status_code/tests_* (via JSONPath or JavaScript preprocessing).
| name: 'Mozilla API {#TARGET}: Error' | ||
| type: HTTP_AGENT | ||
| key: 'mozilla.api.error[{#TARGET}]' |
There was a problem hiding this comment.
Each discovered target performs 8 separate HTTP agent POST requests to the same /api/v2/scan?host=... endpoint every interval. If the endpoint triggers (or queues) a scan per call, this multiplies external load and can lead to throttling/timeouts and unnecessary Zabbix worker utilization. Consider switching to a single 'master' HTTP agent item per target that fetches the JSON once, then implement the other metrics as dependent items extracting grade/score/status_code/tests_* (via JSONPath or JavaScript preprocessing).
| url: '{$MOZ_API_BASE}/api/v2/scan?host={#TARGET}' | ||
| request_method: POST |
There was a problem hiding this comment.
Each discovered target performs 8 separate HTTP agent POST requests to the same /api/v2/scan?host=... endpoint every interval. If the endpoint triggers (or queues) a scan per call, this multiplies external load and can lead to throttling/timeouts and unnecessary Zabbix worker utilization. Consider switching to a single 'master' HTTP agent item per target that fetches the JSON once, then implement the other metrics as dependent items extracting grade/score/status_code/tests_* (via JSONPath or JavaScript preprocessing).
| name: 'Mozilla API {#TARGET}: Grade' | ||
| type: HTTP_AGENT | ||
| key: 'mozilla.api.grade[{#TARGET}]' |
There was a problem hiding this comment.
Each discovered target performs 8 separate HTTP agent POST requests to the same /api/v2/scan?host=... endpoint every interval. If the endpoint triggers (or queues) a scan per call, this multiplies external load and can lead to throttling/timeouts and unnecessary Zabbix worker utilization. Consider switching to a single 'master' HTTP agent item per target that fetches the JSON once, then implement the other metrics as dependent items extracting grade/score/status_code/tests_* (via JSONPath or JavaScript preprocessing).
|  | ||
|
|
||
| ### Item Prototypes | ||
|
|
||
|  | ||
|
|
||
| ### Trigger Prototype | ||
|
|
||
|  |
There was a problem hiding this comment.
These image links are relative to the README location. Since this README is already under .../7.4/, prefixing with 7.4/ likely makes the paths incorrect (resolving to .../7.4/7.4/files/...). Update the links to be relative to the README directory (e.g., files/img/lld_rules.png, etc.) so they render correctly in GitHub.
|  | |
| ### Item Prototypes | |
|  | |
| ### Trigger Prototype | |
|  | |
|  | |
| ### Item Prototypes | |
|  | |
| ### Trigger Prototype | |
|  |
|  | ||
|
|
||
| ### Item Prototypes | ||
|
|
||
|  | ||
|
|
||
| ### Trigger Prototype | ||
|
|
||
|  |
There was a problem hiding this comment.
These image links are relative to the README location. Since this README is already under .../7.4/, prefixing with 7.4/ likely makes the paths incorrect (resolving to .../7.4/7.4/files/...). Update the links to be relative to the README directory (e.g., files/img/lld_rules.png, etc.) so they render correctly in GitHub.
|  | |
| ### Item Prototypes | |
|  | |
| ### Trigger Prototype | |
|  | |
|  | |
| ### Item Prototypes | |
|  | |
| ### Trigger Prototype | |
|  |
|  | ||
|
|
||
| ### Item Prototypes | ||
|
|
||
|  | ||
|
|
||
| ### Trigger Prototype | ||
|
|
||
|  |
There was a problem hiding this comment.
These image links are relative to the README location. Since this README is already under .../7.4/, prefixing with 7.4/ likely makes the paths incorrect (resolving to .../7.4/7.4/files/...). Update the links to be relative to the README directory (e.g., files/img/lld_rules.png, etc.) so they render correctly in GitHub.
|  | |
| ### Item Prototypes | |
|  | |
| ### Trigger Prototype | |
|  | |
|  | |
| ### Item Prototypes | |
|  | |
| ### Trigger Prototype | |
|  |
| t = t.replace(/:\d+$/, ''); | ||
| return t; | ||
| } | ||
| var parts = String(targetsRaw || '').split(/[\n,; ]+/); |
There was a problem hiding this comment.
Target splitting currently handles newline/comma/semicolon/space but not other common whitespace (e.g., tabs). To make input handling more robust and match the README claim of 'space-separated', consider splitting on general whitespace plus separators (e.g., include \\t or use \\s along with comma/semicolon).
| var parts = String(targetsRaw || '').split(/[\n,; ]+/); | |
| var parts = String(targetsRaw || '').split(/[\s,;]+/); |
| description: | | ||
| Monitors website HTTP Observatory posture via the Mozilla API using explicit target-list discovery and per-target scan checks (grade, score, status, tests, error, details URL). Designed for community sharing with host-override macros and regex-based grade policy control. | ||
|
|
||
| Author: ://echo@dla.network [oZark oRChes✝ra✝'d] | ||
| (https://github.com/DLA-neTWorK). |
There was a problem hiding this comment.
The author line appears to have a malformed scheme (://...) and includes trailing whitespace in the description block. Consider normalizing this to a clear contact format (e.g., email without a pseudo-scheme, or a proper mailto:/URL), and remove trailing spaces to keep exported YAML clean and consistent.
Summary
Add a new Mozilla HTTP Observatory API template for Zabbix 7.4.
This contribution adds the full template structure for monitoring Mozilla HTTP Observatory scan results through the API, including discovery, item prototypes, trigger logic, macros, supporting images, and complete end-user documentation.
What Changed
Mozilla HTTP Observatory APItemplate for Zabbix 7.4{$MOZ_API_TARGETS}{$MOZ_API_BASE}{$MOZ_API_TARGETS}{$MOZ_API_ALLOWED_GRADES_REGEX}Default Behavior
^(A\+|A|A-)$NOT_FOUNDhandling is excluded from alerting logicWhy
This template adds a reusable way to monitor external web security posture in Zabbix using Mozilla HTTP Observatory results. It provides a structured template implementation with discovery, policy-based alerting, and documentation for deployment and operational use.
Notes