Add JVM plugin

[panda87]

Use jmx protocols

[sparrc]

@panda87 could you provide more details?

[panda87]

Yes.
in order to collect JVM metrics from JVM based applications you need to create a connector between the jmx and the jvm.
Once you connect the jmx, you are able to pull jvm metrics.
The metrics including, ThreadCount, gc, memorypool etc., what the jvm is allow.

There is a good project called jmxtrans: https://github.com/jmxtrans/jmxtrans
And also I found a Go wrapper: https://github.com/cmceniry/golokia

Thanks.

[sparrc]

thanks @panda87

[zepouet]

Very useful to consume jmx beans from JVM.

Maybe I am wrong but Golokia is dedicated to Jolokia.
Jolokia is another product like JMXTrans to expose JVM Beans as JSON over HTTP
https://jolokia.org/

Nice ideas !

[kostya-sh]

FYI it should be possible to use httpjson plugin with jolokia.

E.g. the following GET request:

http://localhost:8080/jolokia/read/java.lang:type=Memory/HeapMemoryUsage

will return

{
  "status" : 200,
  "value" :  {
           "committed" : 18292736,
           "used" : 15348352,
           "max" : 532742144,
           "init" : 0
          },
  "request" : { .... },
  "timestamp" : ....
}

http://localhost:8080/jolokia/read/java.lang:type=Memory/HeapMemoryUsage/used also works

[saiello]

Hi, I tried to develop an experimental jolokia plugin.
You can find it at:

saiello@d90e081

I really appreciate feedbacks and suggestions.

[sparrc]

@saiello 1st thing that stands out is that you should run go fmt on your code, Go should always be tab-indented.

I made a few comments, you'll also need to write some unit tests for us to merge it

[panda87]

My suggestion \ question is if we will be able to consume MBeans which are not part of what you wrote. This could be by adding conf. file

[saiello]

@sparrc i read your comment and I came up with this new version

master...saiello:6de4a08944d6508a7f054a2640308c6a85fcf10b

I will add some unit test later

@panda87 of course. sample-config reports just some example. You can consume any Mbeans

[sparrc]

awesome, 👍, thanks @saiello. Send up a PR whenever you have something ready to merge :-)

[saiello]

hi @sparrc, i sent a PR #337

[kzarzycki]

Hi! Do I understand, that the jolokia plugin is only for Jolokia-based agents? So I understand that this plugin is not going to support connecting to Remote JMX, that most of current java software use out of the box?(I think jolokia adoption is pretty narrow yet, while Remote JMX is wide).

[JulienChampseix]

@sparrc @saiello i will be interested about question from @kzarzycki

[sparrc]

@kzarzycki @JulienChampseix I don't know the answer to this as I'm not familiar with remote JMX or Jolokia. @saiello it would be helpful if you could answer this, or if anyone else is familiar with the differences between Jolokia and Remote JMX.

[saiello]

Hi, @kzarzycki yes this plugin is only for jolokia-based agent, and even though it would be awesome connecting directly to the JVM through the JMX protocol, I think it's not possible: JMX is a java world protocol based on RMI.

From jolokia site(https://jolokia.org/about.html):
"JSR-160 connectors are highly Java centric where its default protocol RMI is not available outside the Java universe"

Jolokia provide a easy way to access Mbeans exposing them through a restful interface. ( hawt.io for example uses it to connect to and manage remote JVMs http://hawt.io/faq/ )

[panda87]

First of all @saiello thanks for the Jolokia plugin and the effort.
As the comments above, I also have some problems with this plugin since most of my jvm based services are in Docker container and I don't have the ability (and maybe we don't want) to add another agent \ dependency to the container if we can get these metrics by jmx request.

This is not an easy decision for us, but as you said the RMI protocol is only for java implementation, and we wanted to only use Telegraf as our monitoring system.

[sparrc]

@saiello @panda87 Is Jolokia the only way that Remote JMX could be exposed to a non-Java application (such as Telegraf)? If so then I think we can close this case

[sparrc]

I'm going to assume that Jolokia is the best we can do for JVM metrics, if anyone has additional feedback or ideas, please feel free to re-open.

And thanks again @saiello for the Jolokia plugin! 😄

[njwhite]

@sparrc can you re-open this? I've created PR #2056 that gathers data from (Hotspot) JVMs directly, rather than via an intermediate service.

[ZhukovAlexey]

As the comments above, I also have some problems with this plugin since most of my jvm based services are in Docker container and I don't have the ability (and maybe we don't want) to add another agent \ dependency to the container if we can get these metrics by jmx request.

There are situations, where a deployment of an Jolokia agent on the target platform is not possible. This might be for political reasons or an already established JSR-160 export on the instrumented servers. In these environments, Jolokia can operate as a JMX Proxy. In this setup, the agent is deployed on a dedicated proxy JEE server (or other supported agent platform). The proxy bridges between Jolokia JSON request and responses to remote JSR-160 calls to the target server.

https://jolokia.org/features/proxy.html

[amaury-d]

I agree: this issue should be reopened so that telegraf would natively be able to consume JMX datas without going through Jolokia.

[njwhite]

@amaury-d My PR #2058 has been open almost a year!

[jindov]

+1 for native plugin to consume JMX metric

[aronneagu]

+1 for natively reading JMX metrics

[lifeofasa]

+1 for native JMX metric plugin

[njwhite]

@lifeofasa my PR #2058 that implements this is still open!

[anoppe]

@lifeofasa my PR #2058 that implements this is still open!

You PR #2058 has conflicts. It would be nice if this PR can be merged. Would be a nice addition to the Telegraf functionality without the necessity for other components...