Details

      Description

      Zabbix should support remote monitoring of JMX applications. Ideally, it should also be possible to discover JMX counters automatically.

      1. bad-error-message.png
        62 kB
      2. bug_19.png
        61 kB
      3. bug_20.png
        58 kB
      4. bug_26.png
        55 kB
      5. bug_28.png
        34 kB
      6. bug_29.png
        70 kB
      7. bug_30.png
        162 kB
      8. type-character.png
        69 kB

        Activity

        Hide
        Steve mushero added a comment -

        If you do this, need to carefully think about both how to select the JVM to monitor (by port ?) and allow any JMX key, and how to deal with the comma in JMX keys that Zabbix doesn't allow but is needed. In some cases we monitor 10+ JVMs on a host with a custom check we have that takes the port and key, but not clear how you'd put this in the agent as it's a TCP/IP connection, may require authentication, etc. but something simple would be nice. Happy to share how we do it.

        Show
        Steve mushero added a comment - If you do this, need to carefully think about both how to select the JVM to monitor (by port ?) and allow any JMX key, and how to deal with the comma in JMX keys that Zabbix doesn't allow but is needed. In some cases we monitor 10+ JVMs on a host with a custom check we have that takes the port and key, but not clear how you'd put this in the agent as it's a TCP/IP connection, may require authentication, etc. but something simple would be nice. Happy to share how we do it.
        Hide
        richlv added a comment - - edited

        Q: just wondering... with this feature, will it be possible to monitor on the same host a few jmx and a few normal items (assigned to different interfaces on the host, of course) - after all, it isn't possible to only make some items be queried by a proxy...

        A: Yes, only items of type "JMX agent" and a few internal items ("zabbix[java,...]") will be processed through Java proxy. Other items will function as always.

        <asaveljevs> Note that "one key per host" restriction still applies, so it will not be possible to monitor two Java applications will similar JMX counters on the same host. Maybe we should separate the key from the JMX counter, like it is done for SNMP items: key and OID?

        <richlv> ok, first part sounds good enough. as for separate jmx counter, that probably somewhat depends on needs and time required to implement it (but it's not a unique approach - as mentioned, it's used for snmp and ipmi items)

        <asaveljevs> Considering that we wish to merge this as soon as possible, I propose we do it under a separate issue when there is need for it.

        Show
        richlv added a comment - - edited Q: just wondering... with this feature, will it be possible to monitor on the same host a few jmx and a few normal items (assigned to different interfaces on the host, of course) - after all, it isn't possible to only make some items be queried by a proxy... A: Yes, only items of type "JMX agent" and a few internal items ("zabbix [java,...] ") will be processed through Java proxy. Other items will function as always. <asaveljevs> Note that "one key per host" restriction still applies, so it will not be possible to monitor two Java applications will similar JMX counters on the same host. Maybe we should separate the key from the JMX counter, like it is done for SNMP items: key and OID? <richlv> ok, first part sounds good enough. as for separate jmx counter, that probably somewhat depends on needs and time required to implement it (but it's not a unique approach - as mentioned, it's used for snmp and ipmi items) <asaveljevs> Considering that we wish to merge this as soon as possible, I propose we do it under a separate issue when there is need for it.
        Hide
        Marc Schoechlin added a comment -

        See also ZBXNEXT-701(https://support.zabbix.com/browse/ZBXNEXT-701), the monitoring mechanism should be lightweight.....invoking a JVM for every monitored item would be bad.

        If there is already(it looks like) some code, i would be glad to have the chance to write a comment....

        Show
        Marc Schoechlin added a comment - See also ZBXNEXT-701 ( https://support.zabbix.com/browse/ZBXNEXT-701 ), the monitoring mechanism should be lightweight.....invoking a JVM for every monitored item would be bad. If there is already(it looks like) some code, i would be glad to have the chance to write a comment....
        Hide
        richlv added a comment -

        as far as i understand, there's a single java instance, responsible for querying all jmx items.
        you should be able to look at the existing code in svn://svn.zabbix.com/branches/dev/ZBXNEXT-555

        Show
        richlv added a comment - as far as i understand, there's a single java instance, responsible for querying all jmx items. you should be able to look at the existing code in svn://svn.zabbix.com/branches/dev/ZBXNEXT-555
        Hide
        Alexei Vladishev added a comment -

        >invoking a JVM for every monitored item would be bad.

        Don't worry, no forks involved. It is designed to be high performance.

        Show
        Alexei Vladishev added a comment - >invoking a JVM for every monitored item would be bad. Don't worry, no forks involved. It is designed to be high performance.
        Hide
        Konstantin Buravcov added a comment -

        GUI part reviewed and tested: works fine for me.

        Show
        Konstantin Buravcov added a comment - GUI part reviewed and tested: works fine for me.
        Hide
        Aleksandrs Saveljevs added a comment -

        Server part seems to be reviewed and tested, except for (33).

        Show
        Aleksandrs Saveljevs added a comment - Server part seems to be reviewed and tested, except for (33).
        Hide
        Alexander Vladishev added a comment -

        Available from version pre1.9.3, r18732.

        Show
        Alexander Vladishev added a comment - Available from version pre1.9.3, r18732.
        Hide
        richlv added a comment -

        what about internal item to monitor busy javapoller processes ?
        new zbxnext ?

        Show
        richlv added a comment - what about internal item to monitor busy javapoller processes ? new zbxnext ?
        Hide
        Aleksandrs Saveljevs added a comment -

        If you mean Java pollers on the server side, then they can be monitored already using items like zabbix[process,java poller,avg,busy].

        If you mean threads in Java proxy's thread pool, then yes, a new ZBXNEXT might be useful. It has not been documented yet, but Java proxy already supports internal items zabbix[java,,ping] and zabbix[java,,version], so the infrastructure for internal item is already in place.

        Show
        Aleksandrs Saveljevs added a comment - If you mean Java pollers on the server side, then they can be monitored already using items like zabbix [process,java poller,avg,busy] . If you mean threads in Java proxy's thread pool, then yes, a new ZBXNEXT might be useful. It has not been documented yet, but Java proxy already supports internal items zabbix [java,,ping] and zabbix [java,,version] , so the infrastructure for internal item is already in place.
        Hide
        Aleksandrs Saveljevs added a comment -

        First attempt at documenting remote JMX monitoring is available at http://www.zabbix.com/documentation/2.0/manual/jmx_monitoring.

        Show
        Aleksandrs Saveljevs added a comment - First attempt at documenting remote JMX monitoring is available at http://www.zabbix.com/documentation/2.0/manual/jmx_monitoring .
        Hide
        Aleksandrs Saveljevs added a comment -
        Show
        Aleksandrs Saveljevs added a comment - Documentation of zabbix [java,,<param>] is now available at http://www.zabbix.com/documentation/2.0/manual/appendix/items/agent-less_items?&#internal_checks .
        Hide
        Marc Schoechlin added a comment -

        Pretty nice Having powerful JMX support will be a unique selling point for zabbix:

        Some suggestions for enhancing the implementation:

        • put agent configuration in zabbix-agent configuration
        • add support to the zabbix agent to maintain start and stop of the zabbix-jmx-bridge
          => zabbix agent should maintain proper availability of the bridge
          => restart bridge if not available
          => start/stop bridge with agent
        • zabbix-jmx-bridge should only listen at 127.0.0.1 (default)
          => communication of zabbix agent and jmx-bridge using unix domain sockets would be great
          (no duplicate port pitfalls, security, performance, ...)
        • jdk/java binary should be configurable
        Show
        Marc Schoechlin added a comment - Pretty nice Having powerful JMX support will be a unique selling point for zabbix: Some suggestions for enhancing the implementation: put agent configuration in zabbix-agent configuration add support to the zabbix agent to maintain start and stop of the zabbix-jmx-bridge => zabbix agent should maintain proper availability of the bridge => restart bridge if not available => start/stop bridge with agent zabbix-jmx-bridge should only listen at 127.0.0.1 (default) => communication of zabbix agent and jmx-bridge using unix domain sockets would be great (no duplicate port pitfalls, security, performance, ...) jdk/java binary should be configurable
        Hide
        Marc Schoechlin added a comment -

        Probably you can eliminate the need for an extra listen port of the zabbix-jmx-bridge by using STDOUD/STDIN (open2).

        This will be more reliable (zabbix agent can manage zabbix-jmx-bridge), improves usability (no duplicate port problems) and will provide better security.

        A configurable run-useraccount for the zabbix-jmx-bridge would be great.

        Show
        Marc Schoechlin added a comment - Probably you can eliminate the need for an extra listen port of the zabbix-jmx-bridge by using STDOUD/STDIN (open2). This will be more reliable (zabbix agent can manage zabbix-jmx-bridge), improves usability (no duplicate port problems) and will provide better security. A configurable run-useraccount for the zabbix-jmx-bridge would be great.
        Hide
        Al La added a comment -

        In case you update to 2.4.1 you test the patch service_jmx.patch in https://support.zabbix.com/browse/ZBXNEXT-1274

        You must also change the db.

        In case you use mysql you can execute this

        mysql zabbix

        ALTER TABLE interface CHANGE dns dns varchar(255);

        Show
        Al La added a comment - In case you update to 2.4.1 you test the patch service_jmx.patch in https://support.zabbix.com/browse/ZBXNEXT-1274 You must also change the db. In case you use mysql you can execute this mysql zabbix ALTER TABLE interface CHANGE dns dns varchar(255);

          People

          • Assignee:
            Aleksandrs Saveljevs
            Reporter:
            Aleksandrs Saveljevs
          • Votes:
            8 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: