|
So the plan is to convert every imaginable source of data for low-level discovery into JSON with a specific preprocessing step? It is relatively for CSV, but I'm not sure it is the best approach in the long-term.
First of all, JSON capabilities are limited. Imagine I have XML I want to use for discovery:
<data>
<element key="attribute1">
<key>entity1</key>
</element>
<element key="attribute2">
<key>entity2</key>
</element>
</data>
Note that the "key" stands for both an attribute name and a nested tag. How can such XML be converted into JSON?
Secondly, since every input format needs a very specific preprocessing step to convert it into JSON, it will take a very long time to implement even most frequently used scenarios (CSV in 4.2, XML in 4.4, YAML in 5.0, etc.) In the meantime many users will have to resort to scripting or will simply choose a different monitoring solution.
In my understanding, preprocessing pipeline for LLD rules should be just like preprocessing of regular items right to the point where we have an array of some sort (JSON array, XML array, array of /.../g regexp matches, you name it). Then there should be a breaking point stating the type of array we've got. And from there Zabbix should start a bunch of independent preprocessing pipelines to extract values of every LLD macro user needs (I would use XPath here in case of my XML example: string(element/@key) ⇒ {#ATTRIBUTE}, string(element/key) ⇒ {#ENTITY}), each ending with a name for the end result (conventional {#MACRO}). Implementation costs should be fairly low because Zabbix already knows how to iterate JSON and XML arrays, adding iteration of regexp matches or CSV rows shouldn't be difficult. And the end solution will be very flexible and extendable, because user will be able to use all the available preprocessing steps, both to prepare data and extract macro values.
| 
ACC - Support preprocessing for LLD rules - v1.1 .pdf
zbx_export_hosts_2_log.xml
Team A
