icon/x Created with Sketch.

Splunk Cookie Policy

We use our own and third-party cookies to provide you with a great online experience. We also use these cookies to improve our products and services, support our marketing campaigns, and advertise to you on our website and other websites. Some cookies may continue to collect information after you have left our website. Learn more (including how to update your settings) here.
Accept Cookie Policy

Accept License Agreements

This app is provided by a third party and your right to use the app is in accordance with the license provided by that third-party licensor. Splunk is not responsible for any third-party apps and does not provide any warranty or support. If you have any questions, complaints or claims with respect to this app, please contact the licensor directly.

Thank You

Downloading Monitoring of Java Virtual Machines with JMX
SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_264.tgz) 44cbfc4e806d0e4c3ff2bf8127d47c260351884f53975458f0c6cebec10c93ca SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_263.tgz) 6c7e293a70876e67bcf235390f8c3975b2a6d37680b7f9c38dcc9c45510de15a SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_262.tgz) d9c2134b8228e7d4ecc6308caa2313a96f213824443352a20d96718bb8179a49 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_261.tgz) 49c2954d3e00e63c191106168e72f762140e22a1d0883d2e987d5501210959e9 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_26.tgz) 46b038279e61e889c17b5e1f1a2dce31532954af872c08dacd3908777d7fa6e6 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_25.tgz) cbe8418ccfcbda3fc720a9b3bb3661a04942673dfdea31ba345993c543a6dd49 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_24.tgz) ddbe813c8ffc61cf8d320fb03fa58847b7f39bb34b376602d173d518d275fbdd SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_23.tgz) 52b106851b4fcb5d9569d3202a2174177abc3b09ada1f90f3457fa72a61d621f SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_222.tgz) 976235612bf8c49b16b756b0054500e5c7d2ab2719c026a8eca9cb59e3bfe365 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_221.tgz) 61688a71b9770c25b874232fc1d0d1ce35150ab3a210eb7b98a47cddaa12ab17 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_22.tgz) 56b85fbb5fa1b7708d2eef75cb29d3a194a2516724c2e9f2b0cae194bd5728c6 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_21.tgz) 8c5d192b47f170eeb565be01fed987165b3b33bf4b8a2f95282fc43fe0f01c26 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_204.tgz) 414af8ad906c0a7f991ff656c9c18187f977bf4fc534cf7e4b4562bbe5797411 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_203.tgz) 02560b62f83e654d192ed154ab2e0fceacd183adfa9d3935386242dc90c0867e SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_202.tgz) b012b91be77e0a95bf1297c05617f33647d00e39283c81b90ba805fa799c7bdb SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_20.tgz) 421615d7a43de30fa2194ee9bc14d7b634de17921c1b118545589d783bdf2943 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_17.tgz) 881b855dba01f44527e3bbd9fc0af2809b514a1a0215b5a2dd57b3c595db9eeb SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_16.tgz) 69793bcb18364b81de32176a62a17efccf7e34f88384bfbaf87658cde94e85a2 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_157.tgz) 459b967a70249f5b38ce3e6f4ba457980c3766256d8ea0b4f4d229505cdeeb1d SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_156.tgz) 8303892209054ba4daac9283269a0b710a7ac69c08d13727620f2a990e52795a SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_155.tgz) 098e141cef821f211d7f26ee7911aec7e4263584acff055378585773f1075ac2 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_154.tgz) 4ec3586200e56ae0775c509d0bc6cf703eccd9ab2c44a03df973b1e167b8ff8e SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_153.tgz) 6e62ac2162453958a3a283096065bc5c123cffbeaeb9582a4fb853eb9a5a16f6 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_152.tgz) 629d24e5f152132c92d7f1abf35cae43927e6ce7be86cbc7d599c2df6bff28e6 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_151.tgz) c24f6ade3996476be21bfc2c6a3f8c602dec0d61857447c86d4f1f298f641f2b SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_15.tgz) 43d127b2ebcba05161c61583ac5e49b6ec1fda65edd9cbf841f7430e5b8ff032 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_14.tgz) 4eed0cf1b522d75c7e3ea7a6772143e97a435edc12e53621f303a9cc9113abed SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_134.tgz) c82049d77f8dc72fa28eb0f61cf1ea72b2d278aa9df7af14bb05727307e86ad6 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_133.tgz) 71840a9c9f2132772e4366170e5fd33c9d621414c097076ccce535a32775ca90 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_132.tgz) c7808a6a3af4081999eb30e59e4b5a27b8d204b51e84deb6c678afd09613f159 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_131.tgz) 007f4c85d63b3858000c38e68d1ee09dd8c5dc9c361564db555a40abfaaf0eb4 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_13.tgz) 9d8095bdfd0c170e8c4d8c2b44b217c36cc5dba451d25c1e39ab545ea3fb64a4 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_129.tgz) 5bfedc4f2f82a6e6c4b9fdddc1d80e6d79c1f79bcfb7cb8a9335f80210aba51a SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_128.tgz) afeafe13f029ddbb3e90dfb230bb68459bc82b58541904201ce89c46ff87f6a9 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_127.tgz) 38f18b8ad55e5016c107ea755aca0dffe47fbaebb0d3fdc811149296cb014773 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_126.tgz) 09dfa01ca7359ef2981f6582951dfcc9f9d0f809cba87b6edb86c46f1692f8fe SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_125.tgz) 004162efa7ff893fa2202894fd031f9416a4432429726a93f9217475b4011245 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_124.tgz) f0929815c9945465cf035cc2c559ebd42cac36c84f6a6d020edf41ab97e8444f SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_123.tgz) 9f8c238c68c3a350e8ff3588eb7d1749e036cdf691ab45ea940738c796b0f223 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_122.tgz) c32da72c9d48c868caa7f9e466c6017afdc5e6b13b34e0799b936302309f876c SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_121.tgz) f7d06ad078612c4a79f7095537786769f820e93383967efec080d091dfbf4e05 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_12.tgz) 480cc033718027db484c1ad69ec0c4da71476d6d7464e58aab7d70dbd7e2398c SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_112.tgz) a14854f0436d6c3a1ff549e350cd2efb6ad94aefecbf3e0f6ab14b1df6712e17 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_111.tgz) 5cb64caa34ab122b9c4f7339950a65c87563ee9ec1741cb1c1b26e420dd7c909 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_11.tgz) 08d0f71cc59f93f5bc5835e710ae57b44db6b937d1bcb2a9cad1a72204179e52 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_102.tgz) 47c8283886bc65fea34654915b1ffc71ef5333999c6e167764d9614b0119c5f6 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_101.tgz) e4d6215e534be0aa07d37866646f852047d0871ed9d3d8a18ed35732fe3f2785 SHA256 checksum (monitoring-of-java-virtual-machines-with-jmx_10.tgz) c4056510b9b370e6e47a7a5284b5fcaf2f96125e3c6fcedb05db9b118f8ae7c7
To install your download
For instructions specific to your download, click the Details tab after closing this window.

Flag As Inappropriate

Monitoring of Java Virtual Machines with JMX

Admins: Please read about Splunk Enterprise 8.0 and the Python 2.7 end-of-life changes and impact on apps and upgradeshere.
"Monitoring of Java Virtual Machines with JMX" (formerly Splunk for JMX) can be used to poll local or remote JMX Management Servers running in Java Virtual Machines across your entire infrastructure and index MBean attributes, outputs from MBean operations and listen for MBean notifications.

Monitoring of Java Virtual Machines with JMX


This app provides the means to :

  • connect to any local or remote JVM's JMX server, either via the remote JMX interface,attaching to a local JVM process or using an MX4J HTTP based connector.
  • query any MBean running on that server
  • extract any MBean attributes (simple, composite or tabular)
  • invoke MBean operations
  • listen for MBean notifications and declare custom notification filters
  • write attributes and operation results out in a default key/value format, or plugin your own custom format, for SPLUNK indexing and searching
  • declare clusters of JVM's for large scale JVM deployments
  • manage the JMX Modular Input programmatically via the REST API

Tested to date against Hotspot ,JRockit and IBM J9 JVM's.

Currently supports the following JMX Connectors :

  • rmi (JSR160 Standard Implementation and MX4J's JSR160 Implementation)
  • iiop (JSR160 Standard Implementation and MX4J's JSR160 Implementation)
  • local (MX4J only)
  • soap (MX4J only)
  • hessian (MX4J only)
  • burlap (MX4J only)


  • Splunk 5.0+ , if you only want to use as a JMX Modular Input
  • Splunk 6.0+ , if you want to use the Simple XML dashboards also
  • Java Runtime 1.7+
  • Supported on all Splunk platforms : Windows, Linux, MacOS, Solaris, FreeBSD, HP-UX, AIX


  • Optionally set your JAVA_HOME environment variable to the root directory of you JRE installation.If you don't set this , the input will look for a default installed java executable on the path.
  • Untar the release to your $SPLUNK_HOME/etc/apps directory
  • Restart Splunk
  • If you are using a Splunk UI Browse to Settings -- Data Inputs -- JMX (Java Management Extensions) to add a new Input stanza via the UI
  • If you are not using a Splunk UI (ie: you are running on a Universal Forwarder) , you need to add a stanza to inputs.conf directly as per the specification in README/inputs.conf.spec. The inputs.conf file should be placed in a local directory under an App or User context.

Activation Key

You require an activation key to use this App. Visit http://www.baboonbones.com/#activation to obtain a non-expiring key


The data collection logic is implemented as a modular input.

You can configure your JMX inputs via Settings -- Data Inputs -- JMX (Java Management Extensions)

You will need to configure your JMX config file, this is the config file where you specify JMX server(s), MBeans and MBean attributes/operations/notifications.
You can create as many config files,with any name, as you want and place them in the SPLUNK4JMX/bin/config directory

Any changes to the config file at runtime will cause it to be dynamically reloaded

In your setup stanzas, you can optionally specify an alternate config file directory location relative to SPLUNK_HOME ie: etc/apps/someotherapp
This might come in handy if you want to create another Splunk App that depends on this JMX App , and ship your own config files.

The app sets up a default input stanza for you. To get started you should edit the default config.xml file and then enable the stanza.


Note : also refer to the configuration schema documentation in the docs directory

Included in the distribution is a comprehensive sample config.xml
This sample file queries various java.lang MBeans and obtains attributes
You can use this as a basis for creating your own config files for whatever MBeans and attributes/operations you need to poll across your environment
To try out this sample config.xml file , just set the values for your environment in the jmxserver element , and you should be good to go.

"jmxpoller" is the root xml element

A custom formatter can be specified.Only 1 may be specified for the entire configuration.
This is a Java implementation of the "com.dtdsoftware.splunk.formatter.Formatter" interface.
The formatter class must be placed on the java classpath.
If the optional formatter declaration is omitted, then the default formatter will be used.

Refer to the javadoc API in the docs directory for viewing bundled Formatter implementations or the signature of the interfaces for creating your own custom implementations.

1 or more "jmxserver" elements can be included in this XML defintion ie: if you need to accesss multiple different jmx sources within the same scheduled execution
Each "jmxserver" element you declare will be run in parallel.

"jmxuser" and "jmxpass" are optional , if not specified, they will be ignored

"host" can be a hostname, dns alias or ip address.

"jmxport" is the JMX server port to connect to.

"protocol"(default is rmi) is the jmx service protocol to use : rmi, iiop and mx4j specific protocols soap, hessian etc..

For more advanced finer grained control over the format of the jmx service URL you can also specify the "stubSource"(default is jndi), "encodedStub" and url "lookupPath"(default is jmxrmi).
Refer to the schema docs for more details.

Or, to facilitate complete user flexibility, you can enter the full jmx service url as a raw string using the "jmxServiceURL" attribute.

This is raw jmx service url in standard format "service:jmx:protocol:sap"

If this attribute is set, it will override any other set connection related attributes("host", "jmxport", "protocol", "stubSource", "encodedStub" and "lookupPath")

You can also attach directly to a locally running JVM process by specifying the Process ID in the "pid" attribute.
In this case, the "host", "jmxport", "jmxuser","jmxpass" attributes will not be used.
The host value will default to the localhost's name.

For more dynamic flexibility,rather than specifying a static Process ID value in the config xml , you can also specfy the name of a PID file that contains the JVM's Process ID.
You set this in the "pidFile" attribute.
Many long running Java processes output the PID value to a file, particularly if using a JVM Service Wrapper such as Tanuki.
Each time the mod input poller runs, it will dynamically inspect the value of the PID from this file.
This way, you dont have to alter the config.xml each time you do a JVM restart.

You can also specify the path to a command to execute to output the JVM's PID.
You set this in the "pidCommand" attribute.
This command might be a custom script that looks for the JVM process and extracts the PID to STD OUT.
On Linux you could do this with a simple script that uses ps, grep and awk.

Example : ps -eafH | grep "java" | grep -v "grep" | awk '{print $2}'

If the pidCommand outputs multiple PIDs on multiple lines , then Splunk for JMX will handle this by spawning additional JMXServer elements internally in memory.

Optionally you can also have your pid script output a seperate JVM Description for each pid in format "pid,jvmDescription"

Example :

1234,Some JVM Description
3456,Another JVM Description
6789,MOAR JVM Description

Look at the example xml config file in the bin/config directory for usage examples.

Groups of jmxserver's that share that same mbeans can be grouped together in a cluster element, so that you only have to declare the MBeans/MBean attributes/operations once ie: a cluster of JEE appservers, a cluster of Hadoop or Cassandra nodes etc...This will be useful for enterprises with very large scale JVM deployments.
MBean inheritance is supported, so you can have mbeans defined that are common to the cluster, and mbeans that are
specific to a cluster member.

At index time the "host" field is extracted and transformed into the SPLUNK internal host value.

"jvmDescription" is just meta data, useful for searching on in SPLUNK where you might have multiple JVM's on the same host

By default, no timestamp is added , instead relying on the SPLUNK index time as the event time.
However you may customise the 3 bundled formatters and configure them to prepend a timestamp if you wish.
See the examples in the default config.xml file

For MBean definitions , standard JMX object name wildcard patterns * and ? are supported for the "domain" and "properties" attributes

If no values are specified for the "domain" and "properties" attributes , the value will default to the * wildcard

The MBean's canonical objectname will be written out to SPLUNK.

If you would like the components of the MBean canonical objectname broken out into individual fields, then there is a custom formatter available which you can declare in your config XML file to achieve this :

''<formatter classname="com.dtdsoftware.splunk.formatter.TokenizedMBeanNameFormatter"/>''

Single, composite and tabular MBean attributes are supported.

You can set the "dumpAllAttributes" value to true and all of an MBean's attributes will be extracted.

ie: dump all the attributes in the java.lang domain
''<mbean domain="java.lang" properties="*" dumpallattributes="true"/>''

ie: dump all the attributes in all of the cassandra domains
''<mbean domain="org.apache.cassandra." properties="" dumpallattributes="true"/>''

Or you can specify each individual attribute you want to extract using the "attribute" element.

For attributes that are multi level ie: composite and tabular attributes , then you can use a ":" delimited notation for specifying the attribute name.
See examples of this in config.xml

MBean operation invocation is supported.
You can declare operations that return a result or not , take arguments or not.
Operation overloading is supported for methods of the same name with different signatures.

The following parameter types are supported :

  • int
  • float
  • double
  • long
  • short
  • byte
  • boolean
  • char
  • string

Internally these get autoboxed into their respective Object counterparts.

See config_operations_example.xml for usage scenarios.

MBean notification listening is supported simply by adding a "<notificationlistener/>" element as a child of any MBean.
And you can declare custom notification filters "<notificationlistener filterimplementationclass="com.foo.MyFilter/">" .
The filter is the canonical name of a class implementing the javax.management.NotificationFilter interface.

See config_notifications.xml for an example configuration.

Example output line (default formatter)

host=damien-laptop,jvmDescription="My test JVM",mbean="java.lang:type=Threading",count="47"


Simple, Composite and Tabular MBean data structures are supported.

The value obtained from the Attribute or as the return type of an Operation can be :

  1. Any primitive type(Object wrapped)
  2. String
  3. Array
  4. List
  5. Map
  6. Set

Collection types will be recursively deeply inspected, so you can have Collections of Collections etc..


When connecting directly to local JVM using a process ID, native librarys are used. You shouldn't need to do anything, they are loaded automatically.

Windows : JRE_HOME/bin/attach.dll
Linux : JDK_HOME/jre/lib/i386/libattach.so

NOTE : For some reason the Linux "attach" library is only packaged in the JRE that is part of a JDK install. Weird. So if you don't have libattach.so , you can get it from the JDK and copy it into the jre lib directory.


To set up a JMX server for remote access via jvm system properties at startup, see this :


If you wish to use MX4J as your JMX implementation for remote connectors(rmi and iiop) or use any of the MX4J specific JMX connectors(soap, burlap, hessian, local), then it is simply a matter of setting the USE_MX4J variable in the SPLUNK4JMX/bin/jmx.py script to True.

For more details about MX4J browse here : http://mx4j.sourceforge.net

Note : If using any of the HTTPS connectors(soap+ssl, hessian+ssl, burlap+ssl), the root certification authority must be present in the trusted certificates, normally stored in the "$JAVA_HOME/jre/lib/security/cacerts" file.

JVM HEAP Settings

The JMX modular input executes all of the stanzas in a single JVM instance.
If you need to boost HEAP size , then you can adjust the variables MIN_HEAP and MAX_HEAP in in the SPLUNK4JMX/bin/jmx.py script


You can dump a jar file in the "SPLUNK4JMX/bin/lib/" directory and it will be automatically loaded.
Why would you want to do this ? Well perhaps you have created a custom formatter implementation as described above.


Any classes that you need prepended to the java bootclasspath should be put in "SPLUNK4JMX/bin/lib/boot".
Why would you want to do this ? Well perhaps you are targeting a JVM with some proprietary JMX logic that requires additional libraries on the JMX client side ie: using the IIOP connector with IBM Websphere products is one such scenario I've encountered.


Any runtime errors will get written to $SPLUNK_HOME/var/log/splunk/splunkd.log

These are also searchable in Splunk : index=_internal error jmx.py


  • check your firewall setup
  • check the correct spelling/case of your MBeans and MBean attribute/operation definitions
  • check your hostname and port
  • check your user and pass
  • check that your JVM remote JMX access is correctly setup , can you connect using JConsole ?
  • check your process ID if trying to attach to a local JVM
  • ensure your XML config adheres to the XSD
  • look for errors in the log files or via Splunk search in the _internal index
  • check for JMX connection timeouts
  • check that the MBean server is not adding/removing domains and mbeans whilst you are concurrently polling them

Release Notes

Version 2.6.4
Dec. 4, 2019

correcting some minor docs errors

Version 2.6.3
May 10, 2019

cosmetic fixes

Version 2.6.2
April 23, 2019

updated docs

Version 2.6.1
April 19, 2019

added trial key functionality

Version 2.6
March 28, 2019

docs updated

Version 2.5
May 27, 2018

Added an activation key requirement , visit http://www.baboonbones.com/#activation to obtain a free,non-expiring key
Docs updated
Splunk 7.1 compatible

Version 2.4
Nov. 24, 2015

Minor HEC data handling tweaks

Version 2.3
Sept. 22, 2015

Added support to optional output to Splunk via a HEC (HTTP Event Collector) endpoint

Version 2.2.2
July 12, 2015

Tidied up a dead link in the navigation menu

Version 2.2.1
April 20, 2015

Fixed some minor typos

Version 2.2
Feb. 11, 2015

Enabled TLS1.2 support by default.
Made the core Modular Input Framework compatible with latest Splunk Java SDK
Please use a Java Runtime version 7+
If you need to use SSLv3 , you can turn this on in bin/jmx.py

Version 2.1
June 16, 2014

Config file is now dynamically reloaded if it changes
PID File contents are read in on each poller execution
PID Command is executed on each poller execution
PID Command can also return JVM Descriptions in format : 1234,somedescription

Version 2.0.4
Jan. 23, 2014

Minor change so that when using "dumpAllAttributes" , only READABLE attributes will be polled.

Version 2.0.3
Nov. 5, 2013

Added a property to optionally specify an alternate config file directory location , relative to SPLUNK_HOME

Version 2.0.2
Oct. 30, 2013

Put app icon images in the correct directory(this has changed for Splunk 6)

Fixed a classloading clash for direct process attachment jars for win32 vs linux deployments

Version 2.0
Oct. 22, 2013

NOTE : As per Splunk legal naming standard requirements , this app has now been renamed from "Splunk for JMX" to "Monitoring of Java Virtual Machines with JMX". But it is still functionally the same with everything you know and love , plus more !

Release Features:

Refactored the core data collection to be a Modular Input vs the prior versions' scripted inputs.This is much better for performance as now you can run multiple polling stanzas in 1 single JVM, versus having to fire up a JVM for every time you execute a configuration file

As the Modular Input is a Python wrapper to a JVM instance , all Splunk platforms are now supported

The app can either be run in app mode(with dashboards) or in add-on mode(just the modular input.)

Removed all Advanced XML and replaced with Simple XML

Added support for listening for MBean Notifications

All logging now goes to splunkd.log , searchable via "index=_internal ExecProcessor jmx.py"

All documentation brought up to date.

Version 1.7
Oct. 16, 2013

Updated to be compatible with Splunk 6

Version 1.6
Dec. 17, 2012

Tweaked the GC views , Added support to roll out Composite Type arrays

Version 1.5.7
Oct. 22, 2012

When using direct process attachment and specifying a PID Command script, previously Splunk for JMX would only support a single PID in the command output , now it supports multiple PIDs (delimited by newlines)

Version 1.5.6
Sept. 3, 2012

Minor cosmetic update , removed paypal links

Version 1.5.5
Aug. 30, 2012

Added heap/non-heap memory committed charts to the jvm_memory dashboard

Version 1.5.4
June 2, 2012

Added a setting to SearchSelectLister modules so that their populating searches inherit the parent TimeRangePicker selection

Version 1.5.3
April 16, 2012

++added a configuration parameter(stripPattern) for Formatter declarations in config.xml that allows you to specify a regex pattern, or list of patterns, that if matched will strip the matched text from the raw MBean attribute/operations values++

Version 1.5.2
March 20, 2012

++just a tweak to the build, some files were erroneously getting CHMOD'd executable in the tarball++

Version 1.5.1
March 20, 2012

++Converted all the demo views to Advanced XML and added in dynamic time,host,jvm selectors++The new Advanced XML views use output generated by the TokenizedMBeanNameQuotesStrippedFormatter, this is the formatter now declared in the example config xml files, the DefaultFormatter is still available if you were using and still want to use that, but won't work with the new Advanced XML demo views++

Version 1.5
Feb. 15, 2012

++Refactored core engine so you can plugin both custom Formatters and custom Transports++Bundled STDout(default), Splunk Rest, TCP,Syslog,File Transport implementations++added ability to add parameters to Formatter and Transport declarations++3 bundled Formatters can be customised with various different parameters in the configuration xml file, such as the ability to prepend a date and specify the date format pattern++updated docs

Version 1.4
Feb. 1, 2012

Added a setup screen ++ Added a MAX_TIMESTAMP_LOOKAHEAD setting in props.conf to prevent erroneous epoch time rsolutions from non time fields ++ Added links in navigation bar to pdf/html docs

Version 1.3.4
Jan. 11, 2012

++minor adjustment to logging, no more daily rolling files , now only keeping 1MB with 1 backup as the JMX logs get indexed by Splunk anyway ++ documentation housekeeping

Version 1.3.3
Nov. 15, 2011

+ More robust handling of primitive type arrays + All Formatter implementations now strip out all newlines and tabs from attribute values and replace with single space characters, thus flattening out all possible attribute values into a single line

Version 1.3.2
Sept. 22, 2011

+++Added several new demo views, tables, charts...notably, CPU usage per JVM(based on the same algorithm that JConsole uses to derive the JVMs cpu usage), garbage collection, memory pools/memory managers , more thorough OS and Runtime metrics, enhanced connectivity errors page.+++no changes to core engine or config schema, so full backward compatibility maintained

Version 1.3.1
Aug. 10, 2011

Tweaked the demo forms and navigation bar >>Added a data input to monitor the splunk4jmx error logs and also added view on the navigation menu that reports on jmx connection errors.

Version 1.3
July 18, 2011

Docs updated

Version 1.2.9
July 18, 2011

Fixed minor bug in poll_mx4j_jmx.sh script

Version 1.2.8
July 17, 2011

Added an optional "Formatter" implementation that rather than outputting the mbean name as a single canonical string, breaks up the mbean name into its constituent parts and outputs as individual fields.In your config XML file you can use this formatter by declaring.....<formatter className="com.dtdsoftware.splunk.formatter.TokenizedMBeanNameFormatter" />

Version 1.2.7
July 16, 2011

Added support for discovering and extracting ALL attributes of an MBean.Provides an alternative to having to explicitly declare each attribute you want to extract.

...a few examples....
dump the attributes from every MBean from every domain :
<mbean domain="*" properties="*" dumpAllAttributes="true" />
dump the attributes from all MBeans in the java.lang domain :
<mbean domain="java.lang" properties="*" dumpAllAttributes="true"/>
dump the attributes from all MBeans in all of the cassandra domains :
<mbean domain="org.apache.cassandra.*" properties="*" dumpAllAttributes="true" />

Version 1.2.6
July 13, 2011

MX4J support is now implemented, in addition to the standard JSR160 rmi and iiop connectors , there are now MX4J http/https connectors (hessian, burlap and soap). If your target JVM is using MX4J 3.0.2+ as its JMX implementation, then you can use these additional connectors.

In my testing, these http connectors all work well for simple attributes.

Hessian/Burlap work well with CompositeData attributes, but not so with TabularData attributes

Soap seems to have issues with CompositeData and TabularData attributes.

I would recommend the hessian connector if using an http based connector.

I have also updated the lib layout and scripts to allow easier addition of custom jar files, 3rd party jar files etc...

All documentation updated.

Version 1.2.5
July 4, 2011

>>Tested against IBM J9 JVMs >>Fixed bug with multiple cluster elements in config xml file >> Tidied up processing of TabularData

Version 1.2.4
June 30, 2011

>>>Added more thorough Java Collection type support for Attribute value and Operation return types. >>>Can now deal with Arrays, Lists, Maps, Sets and recursively deeply inspect Collections of Collections.>>>Docs updated.

Version 1.2.3
June 27, 2011

Added support for JMX operations , updated documentation.

Version 1.2.2
June 25, 2011

Created a PDF User Guide

Version 1.2.1
June 19, 2011

Added the notion of a "cluster" of JMX servers to the configuration schema.
This will be beneficial when you have many JVMs with the same MBeans ie: JEE App server clusters, large scale deployments of Hadoop/Cassandra nodes on commodity hardware, JVM's across dev/test/qual/prod environments etc..
So the "cluster" element allows you to declare the MBean attributes to extract just once, followed by a list of the JMX servers.Avoids unnecessary repetition and potential bloating of the config file.

For direct attachment to a local JVM using the Process ID , you can now also specify a script to execute to obtain the PID.
This is specified in the "pidCommand" attribute of the jmxserver.
ie: on *Nix a command such as

ps -eafH | grep "com.foo.MyMainClass" | grep -v "grep" | awk '{print $2}'

could be put in a script and used to output the Process ID of the JVM with main class "com.foo.MyMainClass" to STDOUT

Added some more documentation
javadoc API for creating a custom Formatter implementation
schema documentation for the configuration XML

Version 1.2
June 14, 2011

Added XSD and XSD validation for the config XML

Tidied up bin/config and bin directorys

Changed scripts to take the name of the config file as an argument(set from SPLUNK Manager) , rather than as a variable in the script itself.

Adding logging for error level events

Added Java API to allow users to create a custom "Formatter" for SYSOUT lines that are fed into SPLUNK indexing

Logic to write out host name when connecting to localhost or

Version 1.1.2
June 10, 2011

Tweaked windows script

Version 1.1.1
June 10, 2011

Tweaked packaging

Version 1.1
June 10, 2011

1. Added a script to provision running on Windows Operating Systems

2. Added functionality to connect directly to a locally running JVM using the JVM's Process ID or by looking up the Process ID from a PID file. This alleviates the need to remotely enable your JMX server for simple local access.

3. All features tested and working on Windows and Linux , HOTSPOT JVMs.

Version 1.0.2
June 3, 2011

Updating screenshot for splunkbase page

Version 1.0.1
June 3, 2011

Added a screenshot to the release

Version 1.0
June 1, 2011


Subscribe Share

AppInspect Tooling

Splunk AppInspect evaluates Splunk apps against a set of Splunk-defined criteria to assess the validity and security of an app package and components.

Are you a developer?

As a Splunkbase app developer, you will have access to all Splunk development resources and receive a 10GB license to build an app that will help solve use cases for customers all over the world. Splunkbase has 1000+ apps and add-ons from Splunk, our partners and our community. Find an app or add-on for most any data source and user need, or simply create your own with help from our developer portal.

Follow Us:
© 2005-2019 Splunk Inc. All rights reserved.
Splunk®, Splunk>®, Listen to Your Data®, The Engine for Machine Data®, Hunk®, Splunk Cloud™, Splunk Light™, SPL™ and Splunk MINT™ are trademarks and registered trademarks of Splunk Inc. in the United States and other countries. All other brand names, product names, or trademarks belong to their respective owners.