tim-group / java-statsd-client

a java statsd client library

java-statsd-client

A statsd client library implemented in Java. Allows for Java applications to easily communicate with statsd.

Downloads

The client jar is distributed via maven central, and can be downloaded here.

<dependency>
    <groupId>com.timgroup</groupId>
    <artifactId>java-statsd-client</artifactId>
    <version>3.0.1</version>
</dependency>

Usage

import com.timgroup.statsd.StatsDClient;
import com.timgroup.statsd.NonBlockingStatsDClient;

public class Foo {
  private static final StatsDClient statsd = new NonBlockingStatsDClient("my.prefix", "statsd-host", 8125);

  public static final void main(String[] args) {
    statsd.incrementCounter("bar");
    statsd.recordGaugeValue("baz", 100);
    statsd.recordExecutionTime("bag", 25);
    statsd.recordSetEvent("qux", "one");
  }
}

java-statsd-client's Issues

execution times > 24 days

For some purpose of mine I need to record exec times > 2^31 (they are not actual exec times but workflow length time).
Would it be okay to replace int with long ?
May I do it myself and file in a pull request ?
I think this API change would keep source-level backward compatibility since promoting int to long is supported transparently by Java.
Thanks in advance.

Add a travis build

Add a travis build for java-statd-client, and put the result on the README page.

Client stuck on PortUnreachableException

v3.1.0

We create a single client for the lifetime of our services but after a while they get stuck on this PortUnreachableException. Probably our server is unreachable for a few seconds and the client never recovers. A restart of the service fixes the issue.

java.net.PortUnreachableException: null
    at sun.nio.ch.DatagramDispatcher.write0(DatagramDispatcher.java)
    at sun.nio.ch.DatagramDispatcher.write(DatagramDispatcher.java:51)
    at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
    at sun.nio.ch.IOUtil.write(IOUtil.java:65)
    at sun.nio.ch.DatagramChannelImpl.write(DatagramChannelImpl.java:605)
    at com.timgroup.statsd.NonBlockingUdpSender.blockingSend(NonBlockingUdpSender.java:72)
    at com.timgroup.statsd.NonBlockingUdpSender.access$000(NonBlockingUdpSender.java:13)
    at com.timgroup.statsd.NonBlockingUdpSender$2.run(NonBlockingUdpSender.java:60)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

Is this project dead?

Just wondering if I need to fork it

Javadocs are incorrect for `StatsDClient#recordExecutionTime(String, long, double)`

According to

java-statsd-client/src/main/java/com/timgroup/statsd/StatsDClient.java

Line 171 in ec75702

void recordExecutionTime(String aspect, long timeInMs, double sampleRate);

, this operation Adjusts the specified counter by a given delta., which does not sound correct.

ThreadPool problem

Hi,
I am using it with Grails application. I found errors in tomcat logs when tomcat is stopped.

SEVERE: The web application [] appears to have started a thread named [StatsD-pool-4-thread-1] but has failed to stop it. This is very likely to create a memory leak.

Control over format of message reported by statsd

Hi, I'm hoping you can add support to control over the format "%s%s:%s|%s@%f" that is in the messageFor method in NonBlockingStatsdClient. Some graphite servers like HostedGraphite.com support the format "%s%s %s" - that is seperated by space.

In any case, I was wondering if you can just an overloaded constructor that allows passing in the desired format. Otherwise, for it to use the current format.

Thank you

Add support for double values for gauges

Currently, the value of a gauge must be a Long, yet statsd supports fractional values for gauges.

Technically, statsd supports fractional values for counters and timers too, yet this might be considered accidental. Nevertheless, think about adding support for double values for these too.

sampling is implemented incorrectly

This client sends a sample rate over the wire, but doesn't sample the packets sent. One bad result of this is that e.g. calling count('foo', 1, 0.5) causes foo to be double-counted.

See PR 33, which fixes this issue.

Monitoring Java Methods with StatsD

This isn't really an issue, but I thought it would be useful for users of this project to know. The open source project www.automon.org allows you to use java-statsd-client to monitor any java method (from classes you own, 3rd party classes, or jdk classes). It also monitors any exceptions that are thrown. This is all done declaratively without changing your program.

Here are some examples including one that uses StatsD.

Here is an example of the type of data that can be displayed (using graphite).

UDP packets not being sent

I'm using code similar to the example usage:

import com.timgroup.statsd.StatsDClient;
import com.timgroup.statsd.NonBlockingStatsDClient;

final StatsDClient statsd = new NonBlockingStatsDClient("my.prefix", "localhost", 8130);
statsd.recordGaugeValue("java_gauge_1", 2100);

I set up a UDP listener on port 8130 of my localhost and I don't see any packets coming through when I run this code. I know the UDP listener is working because I was able to use libraries that extend this one for Datadog and I saw packets coming through. Not sure what I'm doing wrong here.

Query size of single thread executor in NonBlockingStatsDClient

For a lot of metrics, it's is crucial to also monitor the size of the queue in the executor in NonBlockingStatsDClient. I propose opening up to supply a custom executor to the constructor. I think that's the most flexible solution. That said, is NonBlockingStatsDClient#clientSocket(...) thread safe?

hostname

Consider using NIO libraries for UDP

On the dogstatsd fork of this project, some performance improvements were made in this pull request: indeedeng@5d34f15

Consider porting these changes into the java-statsd-client. I'm not actually sure that the NIO UDP client affords any benefit, so worth doing some reading first. The batching of messages so as to fit as many as possible into the MTU will relate to #15

Is the client object lightweight?

Is the NonBlockingStatsDClient a lightweight object? I'm planning to use this in a large application and wondering about creating multiple instances of this client, one for each prefix?

Reusing one instance across the application would require us to explicitly provide the prefix for each metric (or aspect), which can be noisy.

What would you recommend?

Note: Opened another ticket here but no response so far.

Please tag releases

README states that latest version is 2.0.0, but there is no git tag for this.

Android Dev issues

Hello,

Has this been tested against Android studio and has anyone successfuly integrated this client into an Android native app ?

Thanks

NonBlockingStatsDClient handles empty or null prefixes poorly

The NonBlockingStatsDClient implementation requires a "prefix" in its constructor. It then uses this prefix in several places, here's one example:

public void count(String aspect, int delta) {
    send(String.format("%s.%s:%d|c", prefix, aspect, delta));
}

This is problematic for us as our keys already have the "prefix" baked in, we don't need prefixes added by the client (it's actually problematic in our case).

The way the count(...) (and other) code is written, instantiating the NonBlockingStatsDClient with an empty string, yields keys with just a "." prefixed to them...

org.junit.ComparisonFailure: 
Expected :'preva.FUNCTIONAL_TEST.my.logins.result.valid-login.rate-per-s:1|c'
Actual   :'.preva.FUNCTIONAL_TEST.my.logins.result.valid-login.rate-per-s:1|c'

...and instantiating the NonBlockingStatsDClient with a null string, yields keys with a "null." prefixed to them:

org.junit.ComparisonFailure: 
Expected :'preva.FUNCTIONAL_TEST.my.logins.result.valid-login.rate-per-s:1|c'
Actual   :'null.preva.FUNCTIONAL_TEST.my.logins.result.valid-login.rate-per-s:1|c'

Would you be interested in a pull-request that modified the behavior? Perhaps simply a conditional that checked for empty or null prefix-strings and "did the right thing" in those cases?

For now we can subclass the 3 methods that send(...) data. It's an easy override. But we'd very much prefer to use the "core" library without subclass customizations.

Thanks!

Gary

charset for message bytes

The character set used to encode the message bytes is unspecified.

When (the original) StatsD reads the message, the Node.js Buffer class's toString method is invoked without arguments, meaning that the default encoding of utf-8 is employed.

Batch multiple updates into single UDP packet

This was briefly mentioned in #5 but deserves its own issue, I think.

Delete ":" from metric names to allow statsd server insert them

Copy of DataDog/java-dogstatsd-client#27

I don't know if this repository is accepting issues/PRs, but just in case...

--

Hi all!

I'm currently using statsd to automatically record all the metrics provided by some spring boot application.
In my case, spring is creating some metrics with ":" in the name (for some hystrix with feign stats), and these ones are skipped by the statsd server (https://github.com/etsy/statsd).

That implementation allow to insert multiple metric types to the same metric:

$ echo "xxx:1|c:3|g" | nc -u -w0 127.0.0.1 8125 && echo "counters" | nc localhost 8126 && echo "gauges" | nc localhost 8126

Produces this output:

{ 'statsd.bad_lines_seen': 0,
  'statsd.packets_received': 1,
  'statsd.metrics_received': 1,
  xxx: 1 }
END

{ xxx: 3 }
END

This (undocumented) statsd feature does not allow me to make a PR to statsd repository... So, That's why I'm here,
would be acceptable to make you a PR (or request for the change) to simply delete the ":" in the metric names?

The statsd server is already deleting some characters from metric name:
https://github.com/etsy/statsd/blob/master/stats.js#L170

StatsdReporter does not support tags

The current implementation of the statsd reporter uses an old version of the statsd client without tags support.

The statsd client version should be updated (2.x is deprecated anyways) so tag support can be added.

String.format locale is default

String.format locale is unspecified and hence resorts to default.

Add support for setting tags for dogstatsd

See the dogstatsd events format. I might end up implementing support for this myself, but allowing the setting of optional tags for reporting metrics (e.g. Gauges) makes statsd into datadog pretty darned useful.

Java 1.5

Hi,

We would really like to use java-statsd-client in a java 1.5 project but are getting bad class errors. After a bit of poking around it seems like it is build using java 1.6. We have downloaded the project and it seems to build ok using 1.5.

Would it be possible to change the build.xml file to use 1.5?

Thanks in advance,

David

NoOpStatsDClient is final

If this class were not final it would be a lot easier to extend StatsDClient classes, for example for testing with manual mocking.

using NoOpStatsdClient for mocks

Hi, it will be nice if the NoOpStatsDClient is not final so it's methods can be overridden for mocks. Or if it supports counters for requests so it can be used in testing to verify that it's actually been called.

Convert to maven

The world has moved on (sadly).

Given how many people have forked this library and converted it to maven builds, consider doing this formally.

indeedeng@27e56ed
indeedeng@985b272
Livefyre@fe41c18
krux@402fb1b
PlanetJ@e99d225
cychenyin@aabbadf
sgp@6821d38

Further, consider adding OSGI compatibility:
sgp@429a874