Ad Widget

Collapse

LLD best practice to use same source-data for item and host prototypes

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Brambo
    Senior Member
    • Jul 2023
    • 245

    #1

    LLD best practice to use same source-data for item and host prototypes

    I'm able tot create hosts with the discovery rule where the discovery rule is a script and this return a json formatted output with the necessary macro's. So far so good.
    However in that same script I can collect data which I want to use for item creation.
    When I want to create an Item prototype of type depending item (because any other option doesn't match) I can't select the discovery rule only a Item of the template.
    Running the same script twice seems a bit of strange to me and is unnecessary load on the host and server.

    So what would be best practice to achieve both host and item prototypes?
  • ISiroshtan
    Senior Member
    • Nov 2019
    • 324

    #2
    If you want to go this way, instead of going Discovery of "Script" type create a normal item of "Script" type that would execute the script and collect the info you need (if you dont want to store the whole output in DB - set history to 0. Dependent items will still use collected value for pre-processing). Then create a discovery of "Dependent item" type and point it to use Script time item you created as Master item. Then you can create item prototypes of "Dependent item" type and point them on existing "Master item" that gets the data.

    Such approach would mean you setting pretty low interval for your Script item, like few minutes at best. And on each execution Zabbix will be rerunning discovery process. Should not be a problem if you have enough performance.
    I would still split it a single script into 2 different scripts: one that collects only data needed for discovery (and LLD macros) and another one that would collect actual values needed for monitoring. Then you can make Discovery run the first script one once per hours (or however often you think data for discovery could be changing). And master item run the 2nd one every minute or however often you want and it will only trigger pre-processing of dependent items but not new discovery.

    Comment

    • Brambo
      Senior Member
      • Jul 2023
      • 245

      #3
      As the content which is gathered is fairly static I have chosen for a 1h interval which is for the host prototype more then enough and for the details is gather for the items also a reasonable interval as most of the times the data only changes once per 8 hours.
      I will go the "master item" route and setup that next Monday

      Comment

      • Brambo
        Senior Member
        • Jul 2023
        • 245

        #4
        I have setup the above and that is working now on several hosts. Needed to fine-tune my script to cover the various software versions of the devices. But so far so good.
        In the discovered data of the master item there are also details which i would like to pass as item value.
        Key of the discovered items is like: myname_[12345] where 12345 is the value of discovery macro, key of the item prototype: myname_[{#DNUMBER}]
        The json of the items is like this:
        Code:
        {"{#DNUMBER}":"12345","{#LONGNAME}":"longname","{#DISPLAYNAME}":"displayname","{#IPEI}":"1234567890123","{#DISPLAYTEXT}":"display text"}
        How could I pass the IPEI value to the item value?

        Comment

        • ISiroshtan
          Senior Member
          • Nov 2019
          • 324

          #5
          Preprocessing via JSONPath is the way to go. But it can be tricky to make it work. If you want me to write it please show me full json returned by your script, and please dont change JSON field names (values I don't care, feel free to replace all by XXXX or YYYY, or whatever)

          General approach for preprocessing that would work is like:
          Code:
          $[?(@.DNUMBER == "{#DNUMBER}")].IPEI.first()
          That is under assumption that in JSON the value name is actually DNUMBER and IPEI and not the {#DNUMBER} and {#IPEI}. If you have value names like {#XXX} in your JSON sent from script - it might be impossible to make it work. At least in a few cases where I was asked to look at - did not manage to make it work, had to change JSON value names to normal strings.Then again, never tried it on newer versions of Zabbix.
          Last edited by ISiroshtan; 07-11-2023, 18:31.

          Comment

          • Brambo
            Senior Member
            • Jul 2023
            • 245

            #6
            It seems to be working now. I formatted the Host Item to return json without the macro names. And even without the data start.
            {"Radios":[{"hostname":"name","IP":"ip-adress"},{"hostname":"name2","IP":"ip-adress2"}],"Dects":[{"DECTNUMBER":"323","LONGNAME":"323"}]}

            Then 2 discovery rules 1 for radios and 1 for dects, In those discovery rules pre-processing getting the main item (Radios or Dects) like $.Dects
            LLD Macro {#DECTNUMBER} = $.DECTNUMBER

            In item prototype use the macro's for name the item (and key setup) and as preprocessing: $.Dects[?(@.DECTNUMBER=='{#DECTNUMBER}')].DECTNUMBER.first() to get the dectnumber in the item value
            Hopefully this will makes it better for other in the future how to set it up

            Comment

            Working...