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.

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.

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....

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

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

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

GUI part reviewed and tested: works fine for me.

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

Available from version pre1.9.3, r18732.

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

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.

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

Documentation of zabbix[java,,<param>] is now available at http://www.zabbix.com/documentation/2.0/manual/appendix/items/agent-less_items?&#internal_checks.

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

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.

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);