XMLWordPrintable

    • Icon: Incident report Incident report
    • Resolution: Duplicate
    • Icon: Trivial Trivial
    • None
    • 3.0.3
    • Server (S)

      This is my json, generated automatically by a powershell script:

      {
       "data":[
         { "{#INS}" : "MSSQL$TESTE_INST", "{#INL}" : "TESTE_INST", "{#DBS}" : "master" },
         { "{#INS}" : "MSSQL$TESTE_INST", "{#INL}" : "TESTE_INST", "{#DBS}" : "tempdb" },
         { "{#INS}" : "MSSQL$TESTE_INST", "{#INL}" : "TESTE_INST", "{#DBS}" : "model" },
         { "{#INS}" : "MSSQL$TESTE_INST", "{#INL}" : "TESTE_INST", "{#DBS}" : "msdb" },
         { "{#INS}" : "MSSQL$TESTE_INST", "{#INL}" : "TESTE_INST", "{#DBS}" : "ReportServer$TESTE_INST" },
         { "{#INS}" : "MSSQL$TESTE_INST", "{#INL}" : "TESTE_INST", "{#DBS}" : "ReportServer$TESTE_INSTTempDB" },
         { "{#INS}" : "MSSQL$TESTE_INST", "{#INL}" : "TESTE_INST", "{#DBS}" : "DBA" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "master" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "tempdb" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "model" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "msdb" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "ReportServer" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "ReportServerTempDB" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "SQL_SERVER_MONITORING" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "ORACLE_MONITORING" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "DBA_MONITORIA" },
         { "{#INS}" : "SQLServer", "{#INL}" : "SQL Server", "{#DBS}" : "DBA" }
       ]
      }
      

      It is clear that I have two levels here, one for instances (represented by {#INS} and {#INL} values), and another level for databases (represented by {#DBS} values). Level 1 includes level 2, of course (instances do host databases).

      However, when Zabbix Server receives this json code, it's not smart enough to figure it out, and it gets creating items and triggers, etc., in the first level repeatedly, i.e. not once, but multiple times, for each line in the json code. And I get these errors on the frontend:
      http://i.imgur.com/nmF2hJx.png

      These "first level" prototypes only take into consideration {#INS} and {#INL} values, and they ignore the {#DBS} ones. And it works. That's how Zabbix works today. Zabbix ignores the values that it wasn't asked to look at (in prototype), it's smart enough to do that. But it "forgets" that it created an item by ignoring one value from a json string, and it tries to create it again for the following line containing that combination of values.

      The solution, to me, is pretty simple. This LLD function in Zabbix's code, should simply "remember" in a hash/dictionary, what combinations of values were used to create new items while ignoring values at the same time. If it remembers that, it shouldn't even try to create it again in the first place, and thus these errors would never be fired. Makes sense? I think so. Otherwise, I should create two (or more) separate explicit LLD rules (nested LLD rules), what I'm not going to do since Zabbix supports this wonderful feature of ignoring values that I don't need in a prototype.

            Unassigned Unassigned
            emmanux Naruto
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: