[ZBXNEXT-555] remote monitoring of jmx applications Created: 2010 Nov 10  Updated: 2017 May 31  Resolved: 2011 Mar 29

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: Agent (G), Frontend (F), Server (S)
Affects Version/s: None
Fix Version/s: 1.9.3 (alpha)

Type: Change Request Priority: Major
Reporter: Aleksandrs Saveljevs Assignee: Unassigned
Resolution: Fixed Votes: 8
Labels: None

Attachments: PNG File bad-error-message.png     PNG File bug_19.png     PNG File bug_20.png     PNG File bug_26.png     PNG File bug_28.png     PNG File bug_29.png     PNG File bug_30.png     PNG File type-character.png    

 Description   

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



 Comments   
Comment by Steve mushero [ 2011 Feb 02 ]

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.

Comment by richlv [ 2011 Mar 09 ]

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.

Comment by Marc Schoechlin [ 2011 Mar 15 ]

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

Comment by richlv [ 2011 Mar 15 ]

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

Comment by Alexei Vladishev [ 2011 Mar 16 ]

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

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

Comment by Konstantin Buravcov (Inactive) [ 2011 Mar 25 ]

GUI part reviewed and tested: works fine for me.

Comment by Aleksandrs Saveljevs [ 2011 Mar 28 ]

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

Comment by Alexander Vladishev [ 2011 Mar 28 ]

Available from version pre1.9.3, r18732.

Comment by richlv [ 2011 Apr 04 ]

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

Comment by Aleksandrs Saveljevs [ 2011 Apr 05 ]

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.

Comment by Aleksandrs Saveljevs [ 2011 Apr 05 ]

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

Comment by Aleksandrs Saveljevs [ 2011 Apr 05 ]

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

Comment by Marc Schoechlin [ 2011 Apr 05 ]

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
Comment by Marc Schoechlin [ 2011 Jun 16 ]

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.

Comment by Al La [ 2014 Oct 29 ]

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

Generated at Thu Dec 13 14:58:33 EET 2018 using JIRA 7.3.9#73021-sha1:26adfd3d76803e1a04219c5cd05b58dbafff0dbf.