Skip to content

forter/riemann-java-client

 
 

Repository files navigation

Getting started

This project encompasses:

  1. A Java client for the Riemann protocol
  2. The Riemann protocol buffer definition, and
  3. Its corresponding (autogenerated) Java classes

Artifacts are available through clojars which you can add to your maven repository like so:

<repository>
  <id>clojars.org</id>
  <url>http://clojars.org/repo</url>
</repository>

Example

RiemannClient c = RiemannClient.tcp("my.riemann.server", 5555);
c.connect();
c.event().
  service("fridge").
  state("running").
  metric(5.3).
  tags("appliance", "cold").
  send();

c.query("tagged \"cold\" and metric > 0"); // => List<Event>;
c.disconnect();

Clients will automatically attempt to reconnect every 5 seconds. Writes will fail instantaneously when no connection is available.

.send() proceeds asynchronously and returns as soon as Netty flushes the write possible. .send() returns a com.aphyr.riemann.client.IPromise containing the response from the write (which also supports Clojure's Deref protocol). If you do not deref this promise, the client makes no guarantees about event delivery: it will, for example, discard writes when there are too many messages outstanding on the wire, when Riemann cannot keep up with load, and so on. You should deref and retry IOExceptions on important writes.

try {
  if (!c.event().
      service("fridge").
      state("running").
      send().
      deref(1, java.util.concurrent.TimeUnit.SECONDS)) {
    throw new IOException("Timed out.")
  }
} catch (IOException e) {
  retry();
}

This code blocks for 1 second before retrying, returns a Message if the write succeeded, null if the promise is still outstanding, and throws if a failure is known to have occurred. This means you can send multiple copies of an event if latencies exceed 1000 ms. There is no reliable way to distinguish between failure and delay in an asynchronous network, so think ahead. .deref() blocks indefinitely, but will return as soon as the Netty connection fails, so it may be the safest option when arbitrary delays are acceptable.

Each client allows thousands of outstanding concurrent requests at any time, so a small number of threads can efficiently pipeline many operations over the same client. I suggest performing writes on a special monitoring thread or threads, and pushing the response futures onto a threadpoolexecutor for derefing.

For higher performance (by orders of magnitude) you can also send multiple events batched in a single message. Use RiemannClient.aSendEvents(...) to send multiple events at once.

Hacking

You'll need protoc 2.5.0. After that, mvn package should build a JAR, and mvn install will drop it in your local repository.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Java 99.0%
  • Other 1.0%