jmxtrans: GraphiteWriterFactory does not actually write

The GraphiteWriter outputs to Graphite properly with a configuration like the following:

{
 "servers" : [
  {
   "port" : "PPPPP",
   "host" : "AAA.BBB.CCC",
   "queries" : [
    {
     "outputWriters" : [
      {
       "@class" : "com.googlecode.jmxtrans.model.output.GraphiteWriter",
       "rootPrefix" : "jmx",
       "port" : "2003",
       "host" : "127.0.0.1"
      }
     ],
     "obj" : "java.lang:type=Memory",
     "attr" : [ "HeapMemoryUsage", "NonHeapMemoryUsage" ],
     "resultAlias": "heap"
    }
   ]
  }
 ]
}

Changing the line

       "@class" : "com.googlecode.jmxtrans.model.output.GraphiteWriter",

       "@class" : "com.googlecode.jmxtrans.model.output.GraphiteWriterFactory",

let the output not working: no data reach the carbon-cache listener.

Excluding the deprecation of GraphiteWriter, there is nothing strange in the log, even at DEBUG level.

I found the behaviour in version 254 (I treid both .rpm and .jar flavour) and in version 255-SNAPSHOT20160511200238 (I tried rpm only).

About this issue

Original URL
State: open
Created 8 years ago
Comments: 18 (3 by maintainers)

Most upvoted comments

Always flushing is probably not a very good default. It would mean that we send a very small packet with a single metric each time a metric is collected. It is more efficient to batch multiple metrics in a single TCP packet. If you collect enough metrics, never flushing (and letting the underlying TCP implementation handle the buffering) is the most efficient choice. If you collect less metrics, flushing periodically make sense. It is more expensive, but allow you to get results in a timely fashion.

A better default might be to flush every minute.

gehel on Nov 3, 2016

I am currently testing these parameters and the Graphite database is receiving data using GraphiteWriterFactory. I leave the parameters running for some time, then I will report again.

marcoc610 on Nov 3, 2016

Wouldn’t it make more sense to have “always” instead of “never” as the default ?

That way it would work if we don’t set this parameter.

etiennepouliot on Nov 3, 2016

Note that if you use flushStrategy = always, there is no need to specify a flushDelay. flushDelay is only used with timeBased flush strategy. Yes, I know, documentation is not what it should be. You can have a look at FlushStrategyUtils for the details.

It might make sense to log a warning when a flushDelay is specified with a strategy that does not actually use it. Feel free to open an issue about that (or send a pull request!).

gehel on Nov 3, 2016