Ad Widget

Collapse

Creating trigger depending on contents of discovered OIDs

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • myRCzabbix
    Member
    • Jun 2018
    • 39

    #1

    Creating trigger depending on contents of discovered OIDs

    Hi,

    We're trying to monitor a fleet of printers which, unfortunately, the supplier is unable to explain why, when we poll the OID for the toner level, in some instances the printer will ask to replace the toner at say, 5% but will not ask to replace a toner with a level of 0%.

    The only way we can know which toner to replace is to poll the sub-tree of an OID for error messages. This main OID (iso.3.6.1.2.1.43.18.1.1.8.1) will create a sub-tree (iso.3.6.1.2.1.43.18.1.1.8.1.xxx) that contains various error messages (e.g. iso.3.6.1.2.1.43.18.1.1.8.1.1 = "toner is out (cyan)" and iso.3.6.1.2.1.43.18.1.1.8.1.2 = "paper jam tray 1").

    I've managed to figure out how to create a discovery rule that will return item prototypes that will contain all error messages present.

    Click image for larger version

Name:	zabbix1.png
Views:	461
Size:	66.4 KB
ID:	363531

    Click image for larger version

Name:	zabbix2.png
Views:	411
Size:	64.1 KB
ID:	363532

    Click image for larger version

Name:	zabbix3.png
Views:	420
Size:	28.7 KB
ID:	363533

    Now my problem is, how do I create a trigger that searches thru these item prototypes for a specific string like "toner is out (cyan)"? Please note, at any given time, there could be any number of items under the main OID.

    Any help is appreciated.

  • myRCzabbix
    Member
    • Jun 2018
    • 39

    #2
    I've created the following trigger prototypes but they don't seem to work. Anyone know what I am missing / not doing correctly?

    Click image for larger version

Name:	zabbix5.png
Views:	462
Size:	215.1 KB
ID:	363548

    Comment

    • myRCzabbix
      Member
      • Jun 2018
      • 39

      #3
      Nevermind. It actually works. The only reason I wasn't finding data was because I had set the intervals too short and before it could "get" the data, the prototype seems to be re-created/scanned again. At least, that's what I suspect is the cause because all I had to do was to increase the interval between updates.

      I had to shorten the interval because I didn't want to wait for a long time to see the changes when I modify the rules when I am testing them.

      Comment

      Working...