Yes, this duplicates ZBXNEXT-1307, but does not provide solution to support multiple application instances running on same host and port. See my comments in ZBXNEXT-1307.

See also ZBXNEXT-1310

Maybe in jmx interface definition instead of defining ip or dns name of jmx target, one could put the whole jmx service url? This won't solve indentical keys per host issue, but could be a starting point.

The environment needs to be customizable, in addition to the URL. See ZBXNEXT-1338 for my patch that adds JMXMP support. That required the addition of jmx.remote.profiles and jmx.remote.sasl.callback.handler entries into the environment, in order to support SASL. It also required the call to Security.addProvider(new com.sun.security.sasl.Provider());

Doesn't ZBX-4521 aim more or less the same?

In some forum I found approach when url was instead DNS name. Max length should be 255 chars but in case of strange JMX errors try to shorten it. (Zabbix has insane length checks, sometimes cut off overlapping chars silently. I can't imagine how devs do major db changes)

This small patch allows set custom url with prefix url:// (e.g. url://service:jmx:rmi://192.168.252.3:7009/jndi/rmi://192.168.252.3:7008/jmxrmi) in DNS field, ip and port are ignored in this case.

Patch is against version 2.0.5 from Debian repository.

Bump. This same problem still seems to be present in 2.1. I haven't recompiled and tested this patch as my version is packaged due to quickness. Is the patch something feasible to be added to 2.2?

I have applied this patch to 2.0.7 (i know this is for 2.0.5)
Do we have something similar for 2.0.7 version?

I'm seeing that the JSON sent to the JMXItemChecker contains truncated version of "dns" which makes it difficult to pass the JMX url to the JMXItemChecker, which in turn causes an exception like:

2013-09-11 23:09:19.539 [pool-1-thread-4] INFO com.zabbix.gateway.JMXItemChecker - JMX URL used is -->url://service:jmx:rmi://someserveranyname.com/jndi/rmi://someser

2013-09-11 23:09:19.540 [pool-1-thread-4] WARN com.zabbix.gateway.SocketProcessor - error processing request
com.zabbix.gateway.ZabbixException: java.lang.ClassCastException: com.sun.jndi.rmi.registry.RegistryContext cannot be cast to javax.management.remote.rmi.RMIServer
at com.zabbix.gateway.JMXItemChecker.getValues(JMXItemChecker.java:115) ~[zabbix-java-gateway-2.0.7.jar:na]
at com.zabbix.gateway.SocketProcessor.run(SocketProcessor.java:63) ~[zabbix-java-gateway-2.0.7.jar:na]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [na:1.6.0_24]
Caused by: java.lang.ClassCastException: com.sun.jndi.rmi.registry.RegistryContext cannot be cast to javax.management.remote.rmi.RMIServer
at javax.management.remote.rmi.RMIConnector.narrowJRMPServer(RMIConnector.java:1897) ~[na:1.6.0_24]
at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1892) ~[na:1.6.0_24]
at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1856) ~[na:1.6.0_24]
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) ~[na:1.6.0_24]
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) ~[na:1.6.0_24]
at com.zabbix.gateway.JMXItemChecker.getValues(JMXItemChecker.java:107) ~[zabbix-java-gateway-2.0.7.jar:na]
... 4 common frames omitted

if you note the length of the JMX url is 65 chars
url://service:jmx:rmi://someserveranyname.com/jndi/rmi://someser

This means that we have the 'dns' field restricted to 65 characters in some other place as well.
I have confirmed that the in the DB the Table 'interface' contains the full jmx-url in the dns field.

Also in Web-Interface Configuration --> Hosts -->
The column Interface does show me the full JMX-url (in place of the DNS/IP info)

Any pointers to solve this?

Here is a bunch of JMX service URL examples gathered from issues on the tracker and useful reading links:

service:jmx:rmi://host:port
service:jmx:rmi://ignoredhost/jndi/rmi://myhost/myname
service:jmx:rmi://host1:9004/jndi/rmi://host:1099/myjmx
service:jmx:rmi://host1/jndi/rmi://host1:8688/host1/7676/jmxrmi
service:jmx:rmi:///jndi/rmi://localhost:1099/karaf-name1
service:jmx:rmi:///jndi/rmi://localhost:1099/karaf-name2
service:jmx:iiop://host:port
service:jmx:iiop:///jndi/cn=this,ou=that
service:jmx:iiop://ignoredhost/jndi/cn=this,ou=that
service:jmx:iiop://ignoredhost/jndi/ldap://dirhost:9999/cn=this,ou=that
service:jmx:jmxmp://127.0.0.1:5555
service:jmx:remoting-jmx://conn:port

Basically, these are meant to illustrate that JMX service URL can take a wide variety of forms. This means that creating a structured UI for creating these links (say, a dropdown to choose from "rmi", "iiop", "jmxmp" and "remoting-jmx") is not an option. So we should let the user specify the entire URL as a string, possibly with the ability to use macros. Something like:

service:jmx:rmi:///jndi/rmi://{HOST.CONN}:{HOST.PORT}/jmxrmi

Now, the question is whether this should be specified on the interface level or on the item level.

One of the considerations here is that we currently pool multiple items for a single interface and query them together. So specifying the URL on the interface level does not require any changes to the queue logic, whereas specifying it on the item level requires us to expand macros in the URL and pool together items with the same expanded URL.

Another consideration is that, if we specify it on the item level (in a separate field), it allows us to specify URLs in templates.

It seems that a better approach might be to specify URLs on the interface level. (As a separate field, not as a replacement for IP and DNS fields. Otherwise, it would be hard to resolve {HOST.CONN}-like macros in notifications, for example.) However, it then also make sense to move user name and password to the interface as well. Not only for JMX items, but also for SNMP and IPMI.

So, this is a very useful feature to have, but we cannot do it at the moment, because it is a pretty heavy development and we are already nearing beta for 2.2.

We did a bit of research on how we could monitor WebSphere Application Server and created a patch against trunk, r39265, that allows us to monitor some of the items on the default installation of WAS.

File websphere.patch does several things. First of all, it modifies the currently hardcoded JMX service URL to that of WAS. Then, it changes one of the catch clauses to protect against NoClassDefFoundError, which we otherwise do not catch or log. Finally, it adds WAS JAR files to CLASSPATH in startup.sh and sets Java options for a secure connection to WAS, similar to http://blog.monitis.com/index.php/2012/09/12/configuring-jmx-in-websphere-8-5/ .

Using the patch we were able to monitor some WAS-specific items. In order to see what items can be monitored, you can use the undocumented jmx.discovery item. It works in the same way that net.if.discovery and vfs.fs.discovery work, except it is of type "JMX agent". The reason it is undocumented is because it returns a list of JMX counters of various types, but our low-level discovery currently does not have a facility to create items whose type is not known in advance, which makes it not very useful.

Anyway, jmx.discovery can be used to explore your Java application for supported JMX counters by attaching an item prototype, similar to that in item-prototype.png, to the discovery rule. All created items will have type of "Character", which is not very useful, but it will give a nice list of supported items you can monitor and create interesting ones manually.

We like the idea of being able to specify JMX service URL on the host's interface level, as proposed in this feature request, and this is currently the approach we are considering for development. However, it requires significant effort and considering that our current focus is getting Zabbix 2.2 ready for release, we cannot do this at the moment.

In the meantime, if you could use the idea from websphere.patch, apply it to your installations (not only WAS, but other software, too) and share your experience, it would be great and might help us to do the full implementation.

Another example of software that needs a special URL is Wowza Media Server - it needs to have two different ports specified. See http://www.wowza.com/forums/content.php?217#jconsole .

This workaround may be of help to people while a solution in being worked on. My goal was to enable JBoss EAP 5 (RMI) and JBoss EAP 6 (remoting-jmx) monitoring within the same Zabbix instance, hence te need of JMXItemChecker.java handling both.

The idea is to make this possible with the least amount of effort and changes to the Zabbix code. I made a change in JMXItemChecker.java to bind a specific port number to a service URL. For example:

JMX Interface <IP>:9999 is used for RMI calls
JMX Interface <IP>:7777 is used for remoting-jmx calls

It only takes a small amount of coding in JMXItemChecker (I'm not a Java programmer so it probably can be done in a nicer way..)

Replace:

url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + conn + ":" + port + "/jmxrmi");

With:

//Dirty workaround for ZBXNEXT-1274
Integer remoting = new Integer("7777");
int retval = remoting.compareTo(port);

if (retval == 0)
{
    url = new JMXServiceURL("service:jmx:remoting-jmx://" + conn + ":" + port);
}
else
{
    url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + conn + ":" + port + "/jmxrmi");
}

Detailed example: http://www.denniskanbier.nl/blog/monitoring/jboss-eap-6-monitoring-using-remoting-jmx-and-zabbix/

We would like to test the patch files against a WAS 7 installation with Zabbix 2.0.8 but we're quite new on Zabbix. How should we use the 2 patch files and the diff? If I understood well, we should download the sources (2.0.8), expand them and execute "patch src/com/zabbix/gateway/JMXItemChecker.java websphere.patch" and finally build them with "./configure --enable-server --enable-agent --with-mysql --with-net-snmp --with-libcurl".
Is this correct? Thanks for any help

SAAR, your understanding is generally correct, except you also have to pass "--enable-java" to ./configure.

Attached "jmx-service-url.patch" adds a way to specify a custom JMX service URL and is based on Zabbix 2.2.3. Both server and gateway are patched.

The way it works is as follows. If a user macro {$JMX_SERVICE_URL} is specified, then its expanded value is passed to the gateway as the URL to connect to. In that expanded value, user macros are supported. Also, two custom macros {JMX.CONN} and {JMX.PORT} are supported that expand to the connection parameters of the interface the item is attached to.

An example could be like this:

{$JMX_SERVICE_URL} -> service:jmx:rmi:///jndi/rmi://{JMX.CONN}:{JMX.PORT}/JmxAgent:1:{$JMX_SUFFIX_1}:{$JMX_SUFFIX_2}

Another service who needs this update is the widely used Terracotta Distributed Cache Server.
It connects jmx using jmxmp instead of hardcoded rmi, someone file ZBXNEXT-1338 (duplicating current issue)

Tim Eck (terracotta engineer) says here
http://forums.terracotta.org/forums/posts/list/10414.page

Why not to go same way as JConsole/VisualVM.
It says "Usage: hostname:port OR service:jmx:<protocol>:<sap>"

The only change in code:

  public JMXItemChecker(JSONObject request) throws ZabbixException
	{
          ...
      			//allow to specify non-standard JMX service URL
			if (conn.toLowerCase().startsWith("service:jmx:")){
				url = new JMXServiceURL(conn);
			}else{
				url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + conn + ":" + port + "/jmxrmi");
			}

Are there any plan to fix this?

indeed any updates to this ? it has been ignored for too long and it`s actually an easy fix

This patch is for 2.4.1 and tested behind firewalls.

Hi.

It would be nice to get ANY feedback from zabbix to this issue.

Thank you
al

Hello,

any news about this issue?

Thanks.
Antonio

it's not on the roadmap currently (you can see the roadmap at https://www.zabbix.org/wiki/Docs/roadmap)

ok, I am going to try with this: http://zorka.io/install/index.html
Thanks.

Antonio, when considering to use Zorka be aware of ZBX-8623 and issues found on:
https://github.com/jitlogic/zorka/issues.

richlv. how can we bring it on the roadmap?

Thanks Mark.
Antonio R.

allazabbix001, by (co-)sponsoring the development:
http://www.zabbix.com/development_services.php

How is the decision process which feature needs sponsoring and which not?

they all need sponsoring of some kind
but this is not the best place for a discussion, you might want to consider irc instead : https://www.zabbix.org/wiki/Getting_help#IRC

I suggest to continue any issue unrelated discussion on IRC Channel #zabbix at FreeNode or Zabbix Forums.

yet another patch in ZBX-10975

I posted patches that are also contained here but are updated to work with Zabbix 3.0.3 source in ZBX-10975 (it also merges the TabularData patch from ZBXNEXT-2727).

I frankly find it quite questionable practice to ask for sponsored development when the community has already contributed the feature patches. If it was a request without and patches then I would understand. But this way I don't think anybody feels too eager to put down money when all the Zabbix team needs to do is apply community provided patches.

Also since this feature has been requested many times over and over again throughout the years and can be easily be implemented in non-breaking and backwards compatible ways I don't understand how this was not considered for the roadmap in the 3 years this ticket was open?

SunFire,

I understand your impression. Admittedly, I have asked myself the same originally. I've submitted quite some patches and with each new patch I was more and more annoyed about the obvious ignorance to contributions coming from the community.

However, in the course of time I recognized that almost every supposed solution I shard by patches did either not completely solve the issue, broke things in other places or provided a solution for a very specific use case of mine only. Not to mention the matter of fact that I haven't followed the coding guidelines nor provided appropriate documentation. Due to that, I started to label my contribution as PoC. As a quick win to me, and a practical testable proposal to others how it could look/feel like.
Sure, I can only speak for me and not for other submitter which probably made a much better job than me.

Zabbix is actually not that kind of FOSS where I'd like to see things hasty implemented. Whatever gets implemented must fit into the overall design - the current one as well as the visionary one(s).
To achieve that it needs to deeply investigate the underlying issue first. Not only from the perspective of the reporter of the issue resp. feature request. Then it needs to write a specification to define clearly the scope and functional requirements.

Btw, bringBackSpecsZabbix++.

Let's consider the perfect patch incl. documentation etc. It still needs to investigate and to master the whole thing to test it and to assure commercial customer support for it. Apropos test, not to forget the testing. Even an apparently perfect patch should be put to the test.

What most people overlook, Zabbix is no community project. It's a FOSS product developed by a commercial oriented company, where professional people work full-time to make their living. So why the heck should they invest all the time it still takes on a perfect patch without getting paid? That just makes no sens!

The actual sad thing to me is, while some devs are truly community-minded and eager to share ideas and knowledge on eye-level, I recently begun to doubt whether this is still, or even was ever the case for the company.

Well ANY Response from the company would help.
Even when they say 'no we don't want contribution from the community'.

I think this is one of the companies which sees how oracle behave with java and see that they still survive so who cares about the community as long as you have customer which pays the bill.

But then they should be so fair and handle like this!
jm2c

I have removed zabbix from all my servers due to amount of resource usages and not really cloud ready.
And of course not able to monitor java apps due to missing THIS feature.

Folks, lets stop this discussion here - as it is not related to the issue itself.
More appropriate places to continue the discussion on that are the #zabbix IRC channel or the Zabbix forum.

It's kind of off topic here, just a quick note.

I think Marc has summarized it quite well. Indeed, it takes time and significant effort in order to come up with a solution that is well designed, maintainable and fit nicely into existing architecture. Do you know any other software that maintains backward compatibility on functional level of all functionality since v1.0 (DM is the only exception)? Zabbix is a rare product in this respect. Even if we change something, there is a clear and automated upgrade path. It's the result of careful design decisions and our focus on long term gains.

I have to admit that the majority of all submitted patches (except very trivial ones or one liners) cannot be applied as they are without total rewrite. Therefore nearly all patches bring absolutely no value to us, unfortunately.

Of course we should have invested more time in educating community, communicating more with contributors, but it takes so much effort and energy. I'm afraid we cannot afford doing it at the moment. In the same time we already do a lot when it comes to management of community resources such as ZBX, ZXBNEXT issues, https://share.zabbix.com, forums, wikis, etc.

Hello! What i get after applying patch zabbix.patch for 2.0.5? How i must configure connect after applying it?

If it is of any help, we've had a number of remote GlassFishes working ok with the following fork https://bitbucket.org/anahata/anahata-zabbix-java-gateway

Basically, it attempts to connect over SSL first, if it can't it tries without SSL and once it connects it pools the connection so next checks are faster.

Has a bit of code to ignore SSL certificate validation so it works with self signed certificates, which is what most people have in dev / test environments.

Not a perfect solution but did what we needed. If it is of any help to anyone, feel free to clone and build it.

https://bitbucket.org/anahata/anahata-zabbix-java-gateway/src/11a2ea3b696adb5afa1b467372499f631946f759/src/main/java/com/zabbix/gateway/ZabbixJMXConnectorFactory.java?at=master&fileviewer=file-view-default

Oh, and I just want to take the opportunity to acknowledge the amazing work all these Zabbix buggers are doing. Honestly, I feel the team keeps a positive vibe, We use it and it is just cool. Moreover it is cool that we can see and modify the source code and that we get response to tickets and questions pretty much straight away, Developers are reachable through IRC, JIRA and I am sure they respond to emails as they seem to be normal down to earth people. For all those with a Java background, remember that today, the general users cannot even raise JIRAs on the Java bug tracking system, or comment or vote or follow either unless one is a JDK contributor.

For those users who contribute patches and feel a bit frustrated from their patches not being used, i just wanted to say that i know from my own experience that setting up a product with an open source licensing model that will pay for your living is on its a lifetime battle on its own, let alone expect Zabbix developers to be responsible for the happiness of the open source community around it.

I can sense Zabbix is truly wanting to get to a healthy, efficient relationship with the OS community but this is something that just takes time.

I would encourage any users of the open source community who want to see their patches merged to understand that they may have to give a bit more than initially expected if they really want to give and that clear communication with the zabbix developers will be needed.

My advise to us developers wanting to contribute is to first offer your help and then work with the Zabbix team rather than first making a patch and then getting upset for the patch not being merged.

Remember that Zabbix developers have families and bills to pay like everyone else (I am not a zabbix developer, just a user in a far away country), however nobody pays Zabbix developers for time spent in this JIRA system.

I feel Zabbix has given much more to the os community than the os community to Zabbix and I feel we need to acknowledge that.

Thank you thank you thank you
pablo

Thank you, pranahata, very much for your understanding and kind words! We appreciate it a lot!

Thank you very much for the kind words!

No worries at all guys, if you ever want to see a real kangaroo and decide to come to Australia for holiday, let us know and I'll show you a few

Zabbix Conference in Australia!

Hello, guys. Had anyone tried this patch on Zabbix 3.2.3?
I can see some changes in zbxserver.h:

Old one:

int	substitute_simple_macros(zbx_uint64_t *actionid, const DB_EVENT *event, DB_EVENT *r_event, zbx_uint64_t *userid,
		zbx_uint64_t *hostid, DC_HOST *dc_host, DC_ITEM *dc_item, DB_ALERT *alert, zbx_hashset_t *macro_cache,
		char **data, int macro_type, char *error, int maxerrlen);

New one:

int	substitute_simple_macros(zbx_uint64_t *actionid, const DB_EVENT *event, const DB_EVENT *r_event,
		zbx_uint64_t *userid, zbx_uint64_t *hostid, DC_HOST *dc_host, DC_ITEM *dc_item, DB_ALERT *alert,
		char **data, int macro_type, char *error, int maxerrlen);

Just add one NULL:

substitute_simple_macros(NULL, NULL, NULL, NULL, &hostid, NULL, NULL, NULL,
                  &url, MACRO_TYPE_COMMON, NULL, 0))

No I didn’t notice the patch I tried several things to get this working, I need this for alerts to my JBoss Iservers. I even tried following this article
https://www.denniskanbier.nl/blog/monitoring/jboss-eap-6-monitoring-using-remoting-jmx-and-zabbix/

I got to the point where Zabbix tells me it doesn’t know what to do with the returned JSON.

Which one of the attached patches should I try?

The first patch should work but after applying it you need to open
<your source code folder>\src\zabbix_server\poller\checks_java.c and change the two lines from

substitute_simple_macros(NULL, NULL, NULL, NULL, &hostid, NULL, NULL, &url, MACRO_TYPE_COMMON, NULL, 0);

to

substitute_simple_macros(NULL, NULL, NULL, NULL, &hostid, NULL, NULL, NULL, &url, MACRO_TYPE_COMMON, NULL, 0);

Just as Dimir said.
If you want to use Zabbix 3.0.x you need to add two nulls to that string, like this.

substitute_simple_macros(NULL, NULL, NULL, NULL, &hostid, NULL, NULL, NULL, NULL, &url, MACRO_TYPE_COMMON, NULL, 0);

Valery,

Exactly which of the patches above would I need to apply? I am on 3.2.3.

thanks
Don

I used only this . But don't forget to make changes mentioned above.

Added these changes to the jmx-service-url.patch for Zabbix 3.0.

jmx-service-url_1.1.patch added.

Please forgive me, it has been over 20 years since i developed on *ux platforms, i am a bit rusty. I am trying to get this patch to work with Zabbix 3.2.3 to monitor my JBoss EAP 6.4 servers, I already have JMX working on the servers, as I am able to remotely connect to them with Jconsole. Using the protocol service:jmx:remoting-jmx://ipaddr:4447 so I know all that is correct.
With the patch I am getting back an error saying CANNOT OPEN RECEIVED JSON.

I followed https://www.denniskanbier.nl/blog/monitoring/jboss-eap-6-monitoring-using-remoting-jmx-and-zabbix/ article and had to modify the patch because the patch wasn't using service:jmx:remoting-jmx://ipaddr:4447 which is what I need for JBoss.
Here is the code I modified from the patch, also the RPM forced update commands ( not sure if I am doing this right or picked the correct packages to update. )

I implemented the rest of the patch exactly as posted, only the JMXItemChecker file did I modify inorder to use the service:jmx:remoting-jmx://ipaddr:4447 format.

I compiled everything and updated these 2 packages:

sudo rpm -Uvh -vv --force zabbix-server-mysql-3.2.3-1.el7.centos.x86_64.rpm
and
sudo rpm -Uvh -vv --force zabbix-java-gateway-3.2.3-1.el7.centos.x86_64.rpm

( Did I miss a package I needed to update? )

Here is the code

	public JMXItemChecker(JSONObject request) throws ZabbixException
	{
		super(request);

		try
		{
			String conn = request.getString(JSON_TAG_CONN);
			int port = request.getInt(JSON_TAG_PORT);

                        // Dirty Solution for ZBXNEXT-1274
                        Integer remoting = new Integer("4447");
                        int retval = remoting.compareTo(port);

                        if ( retval == 0 )
                        {
		             url = new JMXServiceURL("service:jmx:remoting-jmx://" + conn + ":" + port);
                             String zUrl = request.optString(JSON_TAG_URL, null);
                             if (null != zUrl)
				url = new JMXServiceURL(zUrl);
                        }
                        else
                        {
			     url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://[" + conn + "]:" + port + "/jmxrmi");
                        }
			jmxc = null;
			mbsc = null;

Vjaceslavs,

Does this mean this will be worked on as a real patch for 3.2.3? If so if you need someone to test it to interact with JBoss i volunteer. I really need the AS7 Jboss format
service:jmx:remoting-jmx://conn:port

I have been unsuccessful in making the code work so far.

thanks

Thanks, Don! We are still planning things but it could also be true that this will go into 3.4 . Let's hope for it, we see interested in this one from lots of people. But it would definitely help if you could volunteer in testing this thing while we develop it.

Hello,

I use zabbix version: 3.2, jboss: 7.1.3
I have done these changes, but I get error message (java gateway log):

2017-03-10 08:47:51.439 [pool-1-thread-4] WARN com.zabbix.gateway.SocketProcessor - error processing request
com.zabbix.gateway.ZabbixException: java.net.MalformedURLException: Unsupported protocol: remoting-jmx

Can you help me, please?

Best Regards,
Máté

There is related issue ZBXNEXT-1989

I have made the patch working with Zabbix 3.2.4. I had to convert the spaces into tabs so I could include it in the SPEC file in order to build new RPM packages on CentOS6, 64Bit. It all compiled well. If anybody is interested in the packages, I can share them. I have also attached the modified patch here as jmx-service-url_1.2.patch
I am currently waiting for the Java-guys to test this patch with Jboss 6 and 7 and I will definitively give feedback here.

I would like to confirm the patch submitted above (jmx-service-url_1.2.patch) is working great for me monitoring Jboss 7. I have successfully tested both a Zabbix Server and a Zabbix Proxy, in the following scenarios:

• Patched Zabbix Server, no Zabbix Proxy, patched Zabbix Java Gateway connected to Zabbix Server, monitoring Jboss Server directly from Zabbix Server
• unpatched Zabbix Server, connected to a patched Zabbix Proxy which is connected to a patched Zabbix Java Gateway, monitoring Jboss Server through Proxy

I needed to download the 10.0 version of Wildfly from http://wildfly.org/downloads/ and extract the jboss-client.jar from there, which I had to place in the /usr/sbin/zabbix_java/lib directory.
My {$JMX_SERVICE_URL} macro for the jboss 7 host I am monitoring is set to the following:

service:jmx:remote+http://{JMX.CONN}:{JMX.PORT}

Next step will be testing to monitor Jboss 6.

Considering this successful test and the fact that this issue is pretty old, what would be needed in order to get the patch applied into the official sources and included in 3.4? If I can help testing some additional stuff I would be more than happy to contribute with this.

Looks like ZBXNEXT-1935 is related. Will fixing this issue also close that?

<vjaceslavs> No, ZBXNEXT-1935 is a separate issue.

(2) [I] schema.inc.php does not match database schema definition (default value of jmx_endpoint is absent in schema definition, but is present in schema.inc.php).
schema.inc.php should be created by using:

php create/bin/gen_php.php
mv create/src/schema.inc.php frontends/php/include/.

gcalenko RESOLVED r67694

vjaceslavs I added default value to DB upgrade patch as well in r67728.
CLOSED

sasha According to specification, default value for new field must be an empty string.

REOPENED

gcalenko RESOLVED r68458

sasha CLOSED

(5) [A] API validation for jmx_endpoint field is inconsistent:

• "jmx_endpoint": "" causes error Incorrect value for field "jmx_endpoint": cannot be empty. - as expected
• "jmx_endpoint": " " creates item with empty (one space) value for jmx endpoint - no trim is performed
• "jmx_endpoint": "\n" creates item with default value for jmx endpoint - not sure why

I propose to add triming to jmx_endpoint value as spaces / tabs / newlines have no meaning in endpoint and to unify all of the described example results to error Incorrect value for field "jmx_endpoint": cannot be empty.

gcalenko RESOLVED r67738, r67956

sasha I have returned all these changes in r68410. API does not make any modifications of data. It can be introduced in future.

CLOSED

iivs "jmx_endpoint": false Allows to create an item anyway.

(8) [F] Undefined variable notice when creating item prototype:

gcalenko RESOLVED r67951

vjaceslavs $data should be used in views instead of $this->data (Guidelines).
REOPENED

gcalenko RESOLVED r67957

sasha CLOSED

(9) [F] Undefined index notice in item prototype editing form:

gcalenko RESOLVED r67953

sasha CLOSED

(10) [F] Cannot export host configuration if discovery rules are present:

[error] Undefined index: jmx_endpoint [hosts.php:149 → CConfigurationExport->export() → CConfigurationExportBuilder->buildHosts() → CConfigurationExportBuilder->formatDiscoveryRules() → CConfigurationExportBuilder->formatItems() in include/classes/export/CConfigurationExportBuilder.php:706]

gcalenko RESOLVED r67958

sasha CLOSED

Frontend side has been successfully tested!

Implemented in:

• pre-3.4.0 r69523

I thought that with the configurable JMX endpoint it would be possible to connect to different application server with different endpoint at the same time.

I've tried to load java gateway with multiple protocol extension jar (jboss-client.jar and the jar suggested by websphere.patch) but it seems that souch clients can't cohexists since by activating both at the same time one works and the other fails. (some class seems to be overriden by the other).

Shoud I have multiple java gateway for each jmx endpoint string or it should be possible to have a single java gateway that monitor both endpoints?

Regards

dpeddi, that should work - anything else would be unreasonable. we are using several different endpoint types with patched older versions of zabbix java gateway,

what you are seeing could be a java issue or a zabbix issue - hard to guess without any additional information.