ZABBIX FEATURE REQUESTS

remote monitoring of jmx applications

Details

  • Zabbix ID:
    NA

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
    2011 Feb 02 15:43
  2. bug_19.png
    61 kB
    2011 Feb 15 10:15
  3. bug_20.png
    58 kB
    2011 Feb 16 12:08
  4. bug_26.png
    55 kB
    2011 Mar 10 15:01
  5. bug_28.png
    34 kB
    2011 Mar 10 15:33
  6. bug_29.png
    70 kB
    2011 Mar 24 12:13
  7. bug_30.png
    162 kB
    2011 Mar 24 12:17
  8. type-character.png
    69 kB
    2011 Jan 31 09:35

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.

People

Vote (8)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: