Details

    • Team:
      Team A
    • Sprint:
      Sprint 2, Sprint 3, Sprint 4, Sprint 5, Sprint 6, Sprint 7, Sprint 8, Sprint 9, Sprint 10, Sprint 11
    • Story Points:
      5.6

      Description

      Currently jmx endpoint is hardcoded into JMXItemChecker.java:

      service:jmx:rmi:///jndi/rmi://" + conn + ":" + port + "/jmxrmi"

      However some applications use different endpoints for jmx management, for example jboss as7:

      service:jmx:remoting-jmx://conn:port

      Suggestion is to make this endpoint configurable per host in the frontend on the CONFIGURATION OF HOSTS screen.

      1. jmx-service-url_1.1.patch
        7 kB
        Marcus Behrens
      2. jmx-service-url_1.2.patch
        3 kB
        Christian Anton
      3. jmx-service-url.patch
        3 kB
        Aleksandrs Saveljevs
      4. service_jmx.patch
        12 kB
        Al La
      5. websphere.patch
        2 kB
        Aleksandrs Saveljevs
      6. zabbix.patch
        4 kB
        Petr Masopust
      7. zabbix-2.2.2-sql_schema.diff
        4 kB
        dakol
      1. item_prototype_edit.png
        7 kB
      2. item_prototype.png
        9 kB
      3. item-prototype.png
        28 kB

        Issue Links

          Activity

          Hide
          Zbigniew Tokarczyk added a comment - - edited

          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.

          Show
          Zbigniew Tokarczyk added a comment - - edited 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 .
          Hide
          Oleksiy Zagorskyi added a comment -

          See also ZBXNEXT-1310

          Show
          Oleksiy Zagorskyi added a comment - See also ZBXNEXT-1310
          Hide
          Zbigniew Tokarczyk added a comment -

          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.

          Show
          Zbigniew Tokarczyk added a comment - 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.
          Hide
          Tim McCune added a comment -

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

          Show
          Tim McCune added a comment - 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());
          Hide
          Marc added a comment -

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

          Show
          Marc added a comment - Doesn't ZBX-4521 aim more or less the same?
          Hide
          Petr Masopust added a comment -

          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.

          Show
          Petr Masopust added a comment - 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.
          Hide
          Gareth Brown added a comment -

          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?

          Show
          Gareth Brown added a comment - 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?
          Hide
          Veerendra Jote added a comment -

          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?

          Show
          Veerendra Jote added a comment - 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?
          Hide
          Aleksandrs Saveljevs added a comment - - edited

          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.

          Show
          Aleksandrs Saveljevs added a comment - - edited 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.
          Hide
          Aleksandrs Saveljevs added a comment -

          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.

          Show
          Aleksandrs Saveljevs added a comment - 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.
          Hide
          Aleksandrs Saveljevs added a comment -

          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 .

          Show
          Aleksandrs Saveljevs added a comment - 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 .
          Hide
          Dennis Kanbier added a comment - - edited

          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/

          Show
          Dennis Kanbier added a comment - - edited 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/
          Hide
          SAAR added a comment -

          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

          Show
          SAAR added a comment - 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
          Hide
          Aleksandrs Saveljevs added a comment -

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

          Show
          Aleksandrs Saveljevs added a comment - SAAR, your understanding is generally correct, except you also have to pass "--enable-java" to ./configure.
          Hide
          Aleksandrs Saveljevs added a comment - - edited

          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}
          
          Show
          Aleksandrs Saveljevs added a comment - - edited 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}
          Hide
          David Canós added a comment -

          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

          Show
          David Canós added a comment - 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
          Hide
          Vitaly Rudensky added a comment -

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

          The only change in code:

          JMXItemChecker.java
          
            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");
          			}
          
          Show
          Vitaly Rudensky added a comment - Why not to go same way as JConsole/VisualVM. It says "Usage: hostname:port OR service:jmx:<protocol>:<sap>" The only change in code: JMXItemChecker.java 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" ); }
          Hide
          Al La added a comment -

          Are there any plan to fix this?

          Show
          Al La added a comment - Are there any plan to fix this?
          Hide
          DRAGOS SURDU added a comment -

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

          Show
          DRAGOS SURDU added a comment - indeed any updates to this ? it has been ignored for too long and it`s actually an easy fix
          Hide
          Al La added a comment -

          This patch is for 2.4.1 and tested behind firewalls.

          Show
          Al La added a comment - This patch is for 2.4.1 and tested behind firewalls.
          Hide
          Al La added a comment -

          Hi.

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

          Thank you
          al

          Show
          Al La added a comment - Hi. It would be nice to get ANY feedback from zabbix to this issue. Thank you al
          Hide
          Antonio Rueda added a comment -

          Hello,

          any news about this issue?

          Thanks.
          Antonio

          Show
          Antonio Rueda added a comment - Hello, any news about this issue? Thanks. Antonio
          Hide
          richlv added a comment -

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

          Show
          richlv added a comment - it's not on the roadmap currently (you can see the roadmap at https://www.zabbix.org/wiki/Docs/roadmap )
          Hide
          Antonio Rueda added a comment -

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

          Show
          Antonio Rueda added a comment - ok, I am going to try with this: http://zorka.io/install/index.html Thanks.
          Hide
          Marc added a comment -

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

          Show
          Marc added a comment - Antonio Rueda , when considering to use Zorka be aware of ZBX-8623 and issues found on: https://github.com/jitlogic/zorka/issues .
          Hide
          Al La added a comment -

          richlv. how can we bring it on the roadmap?

          Show
          Al La added a comment - richlv. how can we bring it on the roadmap?
          Hide
          Antonio Rueda added a comment -

          Thanks Mark.
          Antonio R.

          Show
          Antonio Rueda added a comment - Thanks Mark. Antonio R.
          Hide
          Marc added a comment - - edited

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

          Show
          Marc added a comment - - edited Al La , by (co-)sponsoring the development: http://www.zabbix.com/development_services.php
          Hide
          Al La added a comment -

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

          Show
          Al La added a comment - How is the decision process which feature needs sponsoring and which not?
          Hide
          richlv added a comment -

          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

          Show
          richlv added a comment - 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
          Hide
          Marc added a comment -

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

          Show
          Marc added a comment - I suggest to continue any issue unrelated discussion on IRC Channel #zabbix at FreeNode or Zabbix Forums .
          Hide
          richlv added a comment -

          yet another patch in ZBX-10975

          Show
          richlv added a comment - yet another patch in ZBX-10975
          Hide
          Thorsten Kunz added a comment -

          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?

          Show
          Thorsten Kunz added a comment - 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?
          Hide
          Marc added a comment - - edited

          Thorsten Kunz,

          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.

          Show
          Marc added a comment - - edited Thorsten Kunz , 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.
          Hide
          Al La added a comment -

          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.

          Show
          Al La added a comment - 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.
          Hide
          Marc added a comment -

          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.

          Show
          Marc added a comment - 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.
          Hide
          Alexei Vladishev added a comment - - edited

          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.

          Show
          Alexei Vladishev added a comment - - edited 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.
          Hide
          Dmitriy P. added a comment - - edited

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

          Show
          Dmitriy P. added a comment - - edited Hello! What i get after applying patch zabbix.patch for 2.0.5? How i must configure connect after applying it?
          Hide
          Pablo added a comment -

          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

          Show
          Pablo added a comment - 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
          Hide
          Pablo added a comment -

          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

          Show
          Pablo added a comment - 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
          Hide
          dimir added a comment -

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

          Show
          dimir added a comment - Thank you, Pablo , very much for your understanding and kind words! We appreciate it a lot!
          Hide
          Alexander Vladishev added a comment -

          Thank you very much for the kind words!

          Show
          Alexander Vladishev added a comment - Thank you very much for the kind words!
          Hide
          Pablo added a comment -

          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

          Show
          Pablo added a comment - 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
          Hide
          dimir added a comment -

          Zabbix Conference in Australia!

          Show
          dimir added a comment - Zabbix Conference in Australia!
          Hide
          Valeriy Zabawski added a comment -

          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);
          
          Show
          Valeriy Zabawski added a comment - 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);
          Hide
          dimir added a comment -

          Just add one NULL:

          substitute_simple_macros(NULL, NULL, NULL, NULL, &hostid, NULL, NULL, NULL,
                            &url, MACRO_TYPE_COMMON, NULL, 0))
          
          Show
          dimir added a comment - Just add one NULL: substitute_simple_macros(NULL, NULL, NULL, NULL, &hostid, NULL, NULL, NULL, &url, MACRO_TYPE_COMMON, NULL, 0))
          Hide
          Don Viola added a comment -

          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?

          Show
          Don Viola added a comment - 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?
          Hide
          Valeriy Zabawski added a comment - - edited

          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);
          Show
          Valeriy Zabawski added a comment - - edited 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);
          Hide
          Don Viola added a comment -

          Valery,

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

          thanks
          Don

          Show
          Don Viola added a comment - Valery, Exactly which of the patches above would I need to apply? I am on 3.2.3. thanks Don
          Hide
          Valeriy Zabawski added a comment -

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

          Show
          Valeriy Zabawski added a comment - I used only this . But don't forget to make changes mentioned above.
          Hide
          Marcus Behrens added a comment -

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

          jmx-service-url_1.1.patch added.

          Show
          Marcus Behrens added a comment - Added these changes to the jmx-service-url.patch for Zabbix 3.0. jmx-service-url_1.1.patch added.
          Hide
          Don Viola added a comment - - edited

          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

          This is what I have
          	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;
          
          Show
          Don Viola added a comment - - edited 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 This is what I have 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 ;
          Hide
          Don Viola added a comment -

          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

          Show
          Don Viola added a comment - 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
          Hide
          dimir added a comment -

          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.

          Show
          dimir added a comment - 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.
          Hide
          Máté Kungl added a comment - - edited

          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é

          Show
          Máté Kungl added a comment - - edited 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é
          Hide
          Rostislav Palivoda added a comment -

          There is related issue ZBXNEXT-1989

          Show
          Rostislav Palivoda added a comment - There is related issue ZBXNEXT-1989
          Hide
          Christian Anton added a comment - - edited

          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.

          Show
          Christian Anton added a comment - - edited 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.
          Hide
          Christian Anton added a comment - - edited

          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.

          Show
          Christian Anton added a comment - - edited 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.
          Hide
          dimir added a comment - - edited

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

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

          Show
          dimir added a comment - - edited Looks like ZBXNEXT-1935 is related. Will fixing this issue also close that? < Vjaceslavs Bogdanovs > No, ZBXNEXT-1935 is a separate issue.
          Hide
          Vjaceslavs Bogdanovs added a comment - - edited

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

          Gregory Chalenko RESOLVED r67694

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

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

          REOPENED

          Gregory Chalenko RESOLVED r68458

          Alexander Vladishev CLOSED

          Show
          Vjaceslavs Bogdanovs added a comment - - edited (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/. Gregory Chalenko RESOLVED r67694 Vjaceslavs Bogdanovs I added default value to DB upgrade patch as well in r67728. CLOSED Alexander Vladishev According to specification, default value for new field must be an empty string. REOPENED Gregory Chalenko RESOLVED r68458 Alexander Vladishev CLOSED
          Hide
          Vjaceslavs Bogdanovs added a comment - - edited

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

          Gregory Chalenko RESOLVED r67738, r67956

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

          CLOSED

          Ivo Kurzemnieks "jmx_endpoint": false Allows to create an item anyway.

          Show
          Vjaceslavs Bogdanovs added a comment - - edited (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. Gregory Chalenko RESOLVED r67738, r67956 Alexander Vladishev I have returned all these changes in r68410. API does not make any modifications of data. It can be introduced in future. CLOSED Ivo Kurzemnieks "jmx_endpoint": false Allows to create an item anyway.
          Hide
          Vjaceslavs Bogdanovs added a comment - - edited

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

          Gregory Chalenko RESOLVED r67951

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

          Gregory Chalenko RESOLVED r67957

          Alexander Vladishev CLOSED

          Show
          Vjaceslavs Bogdanovs added a comment - - edited (8) [F] Undefined variable notice when creating item prototype: Gregory Chalenko RESOLVED r67951 Vjaceslavs Bogdanovs $data should be used in views instead of $this->data ( Guidelines ). REOPENED Gregory Chalenko RESOLVED r67957 Alexander Vladishev CLOSED
          Hide
          Vjaceslavs Bogdanovs added a comment - - edited

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

          Gregory Chalenko RESOLVED r67953

          Alexander Vladishev CLOSED

          Show
          Vjaceslavs Bogdanovs added a comment - - edited (9) [F] Undefined index notice in item prototype editing form: Gregory Chalenko RESOLVED r67953 Alexander Vladishev CLOSED
          Hide
          Vjaceslavs Bogdanovs added a comment - - edited

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

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

          Gregory Chalenko RESOLVED r67958

          Alexander Vladishev CLOSED

          Show
          Vjaceslavs Bogdanovs added a comment - - edited (10) [F] Cannot export host configuration if discovery rules are present: [error] Undefined index: jmx_endpoint [hosts.php:149 &rarr; CConfigurationExport->export() &rarr; CConfigurationExportBuilder->buildHosts() &rarr; CConfigurationExportBuilder->formatDiscoveryRules() &rarr; CConfigurationExportBuilder->formatItems() in include/classes/export/CConfigurationExportBuilder.php:706] Gregory Chalenko RESOLVED r67958 Alexander Vladishev CLOSED
          Hide
          Alexander Vladishev added a comment - - edited

          Frontend side has been successfully tested!

          Show
          Alexander Vladishev added a comment - - edited Frontend side has been successfully tested!
          Hide
          Gregory Chalenko added a comment - - edited

          Implemented in:

          • pre-3.4.0 r69523
          Show
          Gregory Chalenko added a comment - - edited Implemented in: pre-3.4.0 r69523

            People

            • Assignee:
              Unassigned
              Reporter:
              michael
            • Votes:
              83 Vote for this issue
              Watchers:
              64 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Agile