20.05.2026 Problem:
The client needed to modernize their Zabbix v7.4.8 setup by migrating a Low-Level Discovery rule away from a static, local JSON file. They required best practices and an architectural recommendation for dynamically triggering and feeding the discovery rule from an external Windows server, while ensuring reliable and efficient updates.
Process:
Step 1: Architecture Review and Assumption Alignment
The initial step involved reviewing the client’s current LLD configuration, which successfully utilized a master/dependent item pattern based on the vfs.file.contents key. Crucial assumptions were clarified, specifically ensuring that the JSON generation on the Windows side would be fully automated and that secure transport (TLS/encryption) was a strict requirement.
Step 2: Evaluation of Data Ingestion Methods
The team evaluated various Zabbix mechanisms to replace the local file-based input. The Zabbix API was ruled out as it is designed for configuration operations rather than streaming metrics. Additionally, installing a Zabbix agent directly on the Windows server was dismissed, as it would merely relocate the manual file-update issue rather than solving the core architectural limitation.
Step 3: Defining the Optimal Strategy
Because the existing master/dependent pattern was highly effective, it was determined that the LLD rule and prototypes could remain unchanged. The investigation focused solely on modifying the master item to accept external inputs securely. Two distinct approaches (Push vs. Pull) were mapped out based on potential network policy constraints.
Solution:
To resolve the issue, the team provided two primary architectural approaches, requiring changes only to the master item, alongside a set of critical best practices for the implementation:
- Option A (HTTP Agent – Pull): The recommended default. The master item type is changed to “HTTP agent” to securely pull the JSON from an HTTPS endpoint on the Windows server. This approach centralizes scheduling, retry logic, and error monitoring directly within Zabbix.
- Option B (Zabbix Trapper – Push): Designed for restricted networks. The master item is changed to “Zabbix trapper,” and a scheduled task on the Windows server pushes the JSON via zabbix_sender.exe over TCP/10051.
- Enhanced Security: Zabbix-level encryption (PSK or certificate) was mandated in addition to standard transport-layer TLS.
- Data Validation: A preprocessing step (JSONPath) was recommended on the master item to validate incoming data, ensuring that malformed payloads trigger an item error rather than silently breaking the discovery process.
- Performance Optimization: “Discard unchanged with heartbeat” preprocessing was applied so the LLD rule only executes when the JSON payload actually changes.
- System Resilience: The LLD “Keep lost resources period” was adjusted to tolerate short outages, and new triggers were recommended to alert on stale data (using a “generated_at” timestamp) or missed ingestion intervals.
Conclusion:
By thoroughly analyzing the client’s existing master/dependent item architecture, the team successfully architected a seamless transition from a static local file to a dynamic, externally driven source. The provision of tailored “Push” and “Pull” options, combined with strict data validation and resilience best practices, equipped the client to implement a secure, automated, and highly reliable Zabbix LLD process.