This module groups all different output writers.
Different output writers have different dependencies. To ensure that those dependencies do not leak to other
output writer, or that we can limit to number of dependencies at runtime, output writers are split into
separate modules based on the dependencies they use. For example, the CloudWatch output writers depends on the
AWS SDK, which is quite large and not used by any other output writer. If you only want to send metrics to
Graphite, there should be no need to have the AWS SDK in your classpath at runtime.
Some dependencies are also problematic. They can introduce incompatibilities. For example, a few writers are
based directly on log4j or logback. This direct dependence breaks the use of SLF4J. By isolating those output
writers to a specific module, we can ensure this has minimal impact.
This module groups all different output writers.
Different output writers have different dependencies. To ensure that those dependencies do not leak to other
output writer, or that we can limit to number of dependencies at runtime, output writers are split into
separate modules based on the dependencies they use. For example, the CloudWatch output writers depends on the
AWS SDK, which is quite large and not used by any other output writer. If you only want to send metrics to
Graphite, there should be no need to have the AWS SDK in your classpath at runtime.
Some dependencies are also problematic. They can introduce incompatibilities. For example, a few writers are
based directly on log4j or logback. This direct dependence breaks the use of SLF4J. By isolating those output
writers to a specific module, we can ensure this has minimal impact.
This is the source code repository for the jmxtrans project.
This is effectively the missing connector between speaking to a JVM via JMX on one end and whatever logging / monitoring / graphing package that you can dream up on the other end.
jmxtrans is very powerful tool which uses easily generated JSON (or YAML) based configuration files and then outputs the data in whatever format you desire. It does this with a very efficient engine design that will scale to communicating with thousands of machines from a single jmxtrans instance.
The core engine is very solid and there are writers for Graphite, StatsD, Ganglia, cacti/rrdtool, OpenTSDB, text files, and stdout. Feel free to suggest more on the discussion group or issue tracker.
Join the Google Group if you have anything to discuss or follow the commits. Please don't email Jon directly because he just doesn't have enough time to answer every question individually.
JarCasting
