Uploaded image for project: 'ZABBIX FEATURE REQUESTS'
  1. ZABBIX FEATURE REQUESTS
  2. ZBXNEXT-1648

Improve Zabbix JMX Discovery to query for MBeans using wildcards

    XMLWordPrintable

    Details

    • Type: New Feature Request
    • Status: Closed
    • Priority: Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Java gateway (J)
    • Labels:

      Description

      Currently, the Zabbix Java Gateway supports the key "jmx.discovery" which will list the meta data about all the MBeans registered on the remote Java server. This isn't really practical though to use for low level discovery because different items will have different data types and different collection intervals based on what the data is etc. I'm proposing adding new jmx.discovery key that will allow querying of MBeans given a wildcard format. So for instance the format would be:

      jmx.discovery[<ObjectNameWildcard>]

      I have a custom Zabbix Java Gateway project that has this commit here: https://bitbucket.org/ryanrupp/zabbix-java-gateway/commits/d67451dcee677974bea37b6369cfadf08eb1b988
      I plan on cleaning up that and providing a patch for this Jira.

      Here's a writeup I have for this feature:

      New Discovery Options
      Before utilizing this you should understand how Zabbix low level discovery works, this is documented here

      A new JMX discovery option has been added to both the standard Zabbix JMX checker and Jolokia checker. This discovery option allows you to search for specific MBeans by using a wildcard in the ObjectName. The format is as follows:

      jmx.discovery[<ObjectNameWildcard>]
      This helps solve issues such as dynamically named MBeans for both the Memory Pool and Garbage Collectors as their names may vary depending on the JVM or arguments passed to the Java process. Here's an example using the Memory Pool MBeans, for my particular JVM I have the following MBeans for the Memory Pool:

      java.lang:type=MemoryPool,name=CMS Old Gen
      java.lang:type=MemoryPool,name=CMS Perm Gen
      These are prefixed with "CMS" due to the use of Concurrent Mark Sweep on my particular JVM - this will vary depending on the garbage collector used, for instance if the Parallel Scavenge Collector is being used the MBean name would be "PS Old Gen". Now, to resolve this with the new discovery feature you create a Zabbix Discovery item with the following item definition (JMX item):

      jmx.discovery["java.lang:type=MemoryPool,name=*"]
      You'll notice the name isn't specified but rather a wildcard here. This means return all MBeans whose object names match the beginning section (Memory Pool) but retrieve any "name" value. The Zabbix Java Gateway will then respond with this using the Zabbix discovery format:

      {
      "data": [
      {
      "

      {#NAME}": "CMS Old Gen",
      "{#JMXOBJ}": "java.lang:name=CMS Old Gen,type=MemoryPool",
      "{#TYPE}": "MemoryPool"
      },
      {
      "{#NAME}

      ": "CMS Perm Gen",
      "

      {#JMXOBJ}": "java.lang:name=CMS Perm Gen,type=MemoryPool",
      "{#TYPE}": "MemoryPool"
      }
      ]
      }
      The macro {#JMXOBJ}

      is returned for each matching MBean found, this is the full name of the MBean that was found and can be used then in Zabbix prototype items via Zabbix Discovery. Additionally, for each property in the MBean's ObjectName a macro is returned. So, in this example there were two properties in the ObjectName - Type and Name, the Type being MemoryPool and the Name being whichever Memory Pool it was. These can also be used in your Zabbix prototype definitions. For instance I could make a prototype item with the item name:

      {#NAME}

      Memory Used
      The Zabbix discovery process in the previous example would then result in two items:

      CMS Old Gen Memory Used
      CMS Perm Gen Memory Used

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              rrupp Ryan Rupp
              Votes:
              5 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: