Details

    • Type: New Feature Request New Feature Request
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.8.4
    • Fix Version/s: None
    • Component/s: Agent (G)
    • Labels:
      None

      Description

      Hi,

      thanks for writing this great piece of software.

      Many companies run java software in their productive environments - currently it´s a little
      bit difficult/uncomfortable to monitor the behavior of java-services with zabbix.
      (see: http://www.kjkoster.org/zapcat/Zapcat_JMX_Zabbix_Bridge.html and
      http://www.zabbix.com/documentation/1.8/manual/cookbook/specific?s[]=jmx#jmx)
      A handy possibility to monitor java applications would be very welcome in many datacenters!

      The java way to monitor applications is JMX (Java Management Extensions,
      http://en.wikipedia.org/wiki/Java_Management_Extensions).

      There are some specific solutions which use jmx-bridges deployed in application-servers - but existing possibilities
      have some disadvantages:

      • it´s necessary to deploy the jmx-bridge in the application to be monitored
        (this is not not a good option - especially if you have support contracts for
        that applications)
      • it´s necessary to add a UserParameter for every monitored value to every agent
      • invoking a complete jvm for getting one single value consumes a lot of resources
        (especially if you monitor i.e. 20 items every minute)

      In my opinion it would be a good idea to enhance the agent to have the possibility
      to invoke a subagent and to communicate via stdin/stdout descriptors.
      This can be used to write powerful tools which collect information in a flexible and
      efficient way.

      The configuration syntax could look like this:


      SubAgent=java-jmx-agent-activemq,/usr/sbin/java --jmx-url "service:jmx:rmi:///jndi/rmi://localhost:9999/jmxrmi"
      SubAgent=java-jmx-agent-generic,/usr/sbin/java --pidfile /var/run/jboss/jboss.pid


      Agent and subagent may chat in the following way:

      Gain list of measures

      AGENT>list
      SUBAGENT>foo
      SUBAGENT>foobar
      SUBAGENT>barfoo

      Gain a measure

      AGENT>get foobar
      SUBAGENT>10111.5

      AGENT>get barfoo
      SUBAGENT>OK

      Subagent child processes will be handeled like this:

      • they are started with the first monitoring request to the subagent item
      • they are stopped on agent shutdown with SIGTERM
      • they are restarted if subagent´s pid is missing

      What do you think about this?

      Do you have suggestion for the implementation?

      Can you recommend some source locations?

      Regards
      Marc

        Issue Links

          Activity

          Hide
          Aleksandrs Saveljevs added a comment -

          Feature ZBXNEXT-555 (hopefully, soon to be merged into trunk) might solve your problem with JMX.

          Show
          Aleksandrs Saveljevs added a comment - Feature ZBXNEXT-555 (hopefully, soon to be merged into trunk) might solve your problem with JMX.
          Hide
          Marc Schoechlin added a comment -

          This might be cool.

          Anyway - subagent support would be a great thing for enhancing the zabbix agent by complexer check-items.

          Especially:

          • for reducing start overhead of checks
          • for checks which need to track and aggregate previous measurement values
          Show
          Marc Schoechlin added a comment - This might be cool. Anyway - subagent support would be a great thing for enhancing the zabbix agent by complexer check-items. Especially: for reducing start overhead of checks for checks which need to track and aggregate previous measurement values
          Hide
          Marc Schoechlin added a comment -

          Let me describe the "aggregate" thing a little bit more detailed:

          We currently develop a commandline tool which collects statistics from a mysql database. Invoking a mysql connection for every ~300 different measurements is pretty resource consuming. To reduce the overhead of measurements my coworker created a small commandline utility (written in c) which collects all values with a single mysql-request and stores/caches them by using a shared memory segment.
          The tool is invoked for every ~300 measurements, but uses shm-caching prevent DDOS of our mysql databases

          We have to do this because there is currently no efficient way to transfer a high numbers of items/values to zabbix.

          With the possibility of using a permanent process (managed by zabbix) this can be done very easy by any sysadmin with python/perl/python/ ...scripting-capabilities.
          No need to write complex, performance-optimized and nifty tools.

          Create a platform for exchanging and publishing tools/templates like this and call it "zabbix-exchange"

          Show
          Marc Schoechlin added a comment - Let me describe the "aggregate" thing a little bit more detailed: We currently develop a commandline tool which collects statistics from a mysql database. Invoking a mysql connection for every ~300 different measurements is pretty resource consuming. To reduce the overhead of measurements my coworker created a small commandline utility (written in c) which collects all values with a single mysql-request and stores/caches them by using a shared memory segment. The tool is invoked for every ~300 measurements, but uses shm-caching prevent DDOS of our mysql databases We have to do this because there is currently no efficient way to transfer a high numbers of items/values to zabbix. With the possibility of using a permanent process (managed by zabbix) this can be done very easy by any sysadmin with python/perl/python/ ...scripting-capabilities. No need to write complex, performance-optimized and nifty tools. Create a platform for exchanging and publishing tools/templates like this and call it "zabbix-exchange"
          Hide
          Marc Schoechlin added a comment -

          It would be a cool thing to use jmxterm as a subagent (http://wiki.cyclopsgroup.org/jmxterm)
          Because establishing a jmx connection is expensive, a permanent connection via stdin/stdout to
          a subagent would be beautiful/efficient....
          --------------------------------------------
          $ java -jar jmxterm-1.0-alpha-4-uber.jar -n
          Welcome to JMX terminal. Type "help" for available commands.
          jvms
          5902 ( ) - jmxterm-1.0-alpha-4-uber.jar -n
          open 5902
          #Connection to 5902 is opened
          domain java.lang
          #domain is set to java.lang
          bean type=Memory
          #bean is set to java.lang:type=Memory
          get *
          #mbean = java.lang:type=Memory:
          Verbose = false;

          HeapMemoryUsage =

          { committed = 122421248; init = 127723648; max = 1817575424; used = 10287088; }

          ;

          NonHeapMemoryUsage =

          { committed = 24313856; init = 24313856; max = 136314880; used = 11114696; }

          ;

          ObjectPendingFinalizationCount = 0;
          --------------------------------------------

          Subagents will open a new world of agent-extensions....

          Show
          Marc Schoechlin added a comment - It would be a cool thing to use jmxterm as a subagent ( http://wiki.cyclopsgroup.org/jmxterm ) Because establishing a jmx connection is expensive, a permanent connection via stdin/stdout to a subagent would be beautiful/efficient.... -------------------------------------------- $ java -jar jmxterm-1.0-alpha-4-uber.jar -n Welcome to JMX terminal. Type "help" for available commands. jvms 5902 ( ) - jmxterm-1.0-alpha-4-uber.jar -n open 5902 #Connection to 5902 is opened domain java.lang #domain is set to java.lang bean type=Memory #bean is set to java.lang:type=Memory get * #mbean = java.lang:type=Memory: Verbose = false; HeapMemoryUsage = { committed = 122421248; init = 127723648; max = 1817575424; used = 10287088; } ; NonHeapMemoryUsage = { committed = 24313856; init = 24313856; max = 136314880; used = 11114696; } ; ObjectPendingFinalizationCount = 0; -------------------------------------------- Subagents will open a new world of agent-extensions....
          Hide
          richlv added a comment -

          hopefully jmx monitoring will be covered by the zabbix java gateway (http://www.zabbix.com/documentation/2.0/manual/config/items/itemtypes/jmx_monitoring)

          Show
          richlv added a comment - hopefully jmx monitoring will be covered by the zabbix java gateway ( http://www.zabbix.com/documentation/2.0/manual/config/items/itemtypes/jmx_monitoring )
          Hide
          Marc Schoechlin added a comment -

          Besides JMX, the subagent feature will also a cool thing to integrate complexer measurement tools with huge startuptimes of complex logic....

          Show
          Marc Schoechlin added a comment - Besides JMX, the subagent feature will also a cool thing to integrate complexer measurement tools with huge startuptimes of complex logic....
          Hide
          Marc Schoechlin added a comment -

          Possibly misunderstood, see ZBXNEXT-2098

          Show
          Marc Schoechlin added a comment - Possibly misunderstood, see ZBXNEXT-2098

            People

            • Assignee:
              Unassigned
              Reporter:
              Marc Schoechlin
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: