mevdschee/tqdev-metrics

Light-weight Java library to measure critical components in a production environment.

TQdev.com's Metrics

This is a light-weight Java library to measure the behavior of critical components in a production environment.

Requirements

• Java 8

Modules

• metrics-core stores your metrics (you always need this module)
• metrics-aspectj instruments Java methods aggregated on method name
• metrics-jdbc instruments SQL queries aggregated on prepared statement
• metrics-jetty instruments HTTP requests aggregated on HTTP verb and response status and instruments thread counts
• metrics-spring-security instruments Spring requests aggregated on authenticated username
• metrics-spring-webmvc instruments Spring requests aggregated on request path and handler name
• metrics-jvm instruments current JVM system properties
• metrics-sigar is not implemented yet
• metrics-influxdb exports metrics to disk (rotated) and HTTP endpoint using the InfluxDB line protocol
• metrics-prometheus exports metrics to disk (rotated or for node_exporter) in Prometheus text format
• metrics-jmx exports metrics over a JMX connection using the JMX RMI protocol
• metrics-spring-loaders can be component scanned to load all modules

Philosophy

Where possible things are measured as an increasing value (monotonically increasing counter). So instead of measuring 10, 10, 10 for a constant value you will have 10, 20, 30. This way you can get cheap aggregates (at any given resolution), as you don't have to visit every value.

Some values (such as "current thread count") cannot be stored as a counter. These values are not converted to monotonically increasing counters, but they are represented by long integers that are retrieved from the underlying system when they are read (on-demand).

Counters use two long integers per metric: one for duration in nanoseconds and one for invocation count. For on-demand measured values (Gauges) it also uses a long integer to unify the storage model. It is recommended that you send the metrics every 10 seconds to a time series database such as InfluxDB. In InfluxDB you can then use the "non_negative_derivative" function to graph the measured values.

Getting started

If you are using Spring you can add a "ComponentScan" annotation to your application to add "com.tqdev.metrics.spring.loaders" as a scanned package, as you can see here:

@SpringBootApplication
@ComponentScan({ "org.springframework.samples.petclinic", "com.tqdev.metrics.spring.loaders" })
public class PetClinicApplication {
    public static void main(String[] args) throws Exception {
	    SpringApplication.run(PetClinicApplication.class, args);
    }
}

This is all you have to change in your code to get started (apart from adding the dependencies to your maven or gradle config). After application has started you may connect to it using "jconsole" and see the collected metrics via JMX under "com.tqdev.metrics" (configurable).

Release It to Maven Central

$ mvn versions:set -DnewVersion=[major.minor.patch]
$ mvn clean package deploy

tqdev-metrics's Issues

Add a metrics-jdbc module

Support collection of JMX composite metric types with CollectD FastJMX

Having bellow CollectD java plugin configuration:

`<MBean "xls_tasks">
ObjectName "com.xebialabs.satellite.metrics:type=Metrics"

 <Value>
    Type "gauge"
    InstancePrefix "xls_registered_tasks"
    PluginName "XLS"
    Attribute "xlsatellite.Tasks.registered"
  </Value>
  <Value>
    Type "gauge"
    InstancePrefix "xls_executing_tasks"
    PluginName "XLS"
    Attribute "xlsatellite.Tasks.executing"
  </Value>
  <Value>
    Type "counter"
    InstancePrefix "xls-done_tasks"
    PluginName "XLS"
    Attribute "xlsatellite.Tasks.done"
  </Value>

</MBean>`

and above metrics exposed via JMX

CollectD FastJMX plugin reports below error:

[2018-05-31 10:24:07] FastJMX Plugin: Failed to collect: javax.management.RuntimeOperationsException: Operation xlsatellite not defined for this OpenMBean

From the error message it looks like the JMXReporter#getAttribute(String attributeName) can not handle attribute paths: "xlsatellite.Tasks.done", "xlsatellite.Tasks.running", ""xlsatellite.Tasks.executing", but only attribute names.

From the docs of CollectD:

"Attribute path
Sets the name of the attribute from which to read the value. You can access the keys of composite types by using a dot to concatenate the key name to the attribute name. For example: “attrib0.key42”. If Table is set to true path must point to a composite type, otherwise it must point to a numeric type."

we should be able to support lookup of not only "attrib0", but also of "attrib0.key42", as well as resolution of simple numeric type: collectD type gauge or counter.