Skip to main content

Logging to Graphite monitoring tool from java

We use Graphite as a tool for monitoring some stats and watch trends. A requirement is to monitor impact of new releases as build is deployed to app nodes to see if things like
1) Has the memcache usage increased.
2) Has the no of Java exceptions went up.
3) Is the app using more tomcat threads.
Here is a screenshot

We changed the installer to log a deploy event when a new build is deployed. I wrote a simple spring bean to log graphite events using java. Logging to graphite is easy, all you need to do is open a socket and send lines of events.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory; 
import java.util.HashMap;
import java.util.Map;

public class GraphiteLogger {
private static final Logger logger = LoggerFactory.getLogger(GraphiteLogger.class);
 private String graphiteHost;

 private int graphitePort;

 public String getGraphiteHost() {
  return graphiteHost;

 public void setGraphiteHost(String graphiteHost) {
  this.graphiteHost = graphiteHost;

 public int getGraphitePort() {
  return graphitePort;

 public void setGraphitePort(int graphitePort) {
  this.graphitePort = graphitePort;

 public void logToGraphite(String key, long value) {
  Map stats = new HashMap();
  stats.put(key, value);
 public void logToGraphite(Map stats) {
  if (stats.isEmpty()) {

  try {
   String nodeIdentifier =;
   logToGraphite(nodeIdentifier, stats);
  } catch (Throwable t) {
   logger.warn("Can't log to graphite", t);

 private void logToGraphite(String nodeIdentifier, Map stats) throws Exception {
  Long curTimeInSec = System.currentTimeMillis() / 1000;
  StringBuffer lines = new StringBuffer();
  for (Map.Entry entry : stats.entrySet()) {
   String key = nodeIdentifier + "." + entry.getKey();
   lines.append(key).append(" ").append(entry.getValue()).append(" ").append(curTimeInSec).append("\n"); //even the last line in graphite 

 private void logToGraphite(StringBuffer lines) throws Exception {
  String msg = lines.toString();"Writing [{}] to graphite", msg);
  Socket socket = new Socket(graphiteHost, graphitePort);
  try {
   Writer writer = new OutputStreamWriter(socket.getOutputStream());
  } finally {

 public static void main(String[]args) throws Exception {
  String host = args[0];
  int port = Integer.parseInt(args[1]);
  String nodeIdentifier ="tomcat.UI.planck_8080";
  Map stats = new HashMap();
  stats.put("memcache_calls", 900L);
  stats.put("num_threads", 50L);
  GraphiteLogger graphiteLogger = new GraphiteLogger();
  graphiteLogger.logToGraphite(nodeIdentifier, stats);


  1. Nice article , you have indeed covered topic in details with code examples and explanation. I have also blogged some of my experience as 10 tips on logging in Java

    10 tips on logging in Java

  2. How do you create the vertical line for deploys?

  3. Thanks for posting your Java code. I'm guessing it will give me an hour head start on my project. ;)

  4. It is a super article. and im getting some error in line
    #53 for (Map.Entry entry : stats.entrySet()) with stats.entrySet()
    #62"Writing [{}] to graphite", msg); with
    please give some idea to fix this :)

    1. this code was just for a sample, I think I used slf4j wrapper that uses {} syntax. please change the code to use"Writing ["+msg +"] to graphite");

      and it should work fine.

  5. That seems to have fixed the issue for the logger but I am also still getting the same issue Dhanushanth was getting on Line #53

    Multiple markers at this line
    Map.Entry is a raw type. References to generic type Map.Entry should be parameterized
    Type mismatch: cannot convert from element type Object to Map.Entry

  6. I updated the imports (sorry I was using a different logger and I wanted to make the code simple). Anyways I converted the code to use slf4j so try now. or you can switch it to use your logger and replace the loging code or remove it.


Post a Comment

Popular posts from this blog

Quartz stop a job

Quartz did a good job on implementing this concept. It was very easy to add this feature by implementing a base class that abstract the details of interrupt and have every job extend this class. If you can rely on thread.interrupt() then its the best way to interrupt a job that is blocked on some I/O or native call. However if its a normal job then a simple boolean flag would do the work. You would need to use scheduler.interrupt(jobName, groupName); to interrupt a running Quartz job. public abstract class BaseInterruptableJob implements InterruptableJob { private static final AppLogger logger = AppLogger.getLogger(BaseInterruptableJob.class); private Thread thread; @Override public void interrupt() throws UnableToInterruptJobException {"Interrupting job " + getClass().getName()); if (thread != null) { thread.interrupt(); } } @Override final public void execute(JobExecutionContext context) throws JobExecutionException { try { thread

Python adding pid file

I have a thumbnail generator that launches multiple processes and the correct way to shut it down is to send kill -HUP to the parent process. To automate I had to write a pid file from python, it was a piece of cake def writePidFile(): pid = str(os.getpid()) f = open('', 'w') f.write(pid) f.close()

Better Tools Happy Engineers

"The only thing constant in a Startup is Change" If you aren't changing fast enough then order and complacency sets in which leads to mediocrity and you can soon become obsolete. We do biweekly releases and want to move to weekly and then daily releases. You can increase the release cadence, if you are able to automate most of the testing. But automation can't detect everything and things may break and the intent is to establish a culture of how can you prevent it but if you cant prevent it then how fast can diagnose and recover from it. For a long time I had been pushing hard for a working centralized logging and after almost an year of trying to scale the ELK framework finally our team has been able to put a fast centralized logging system that's ingesting Terabytes of log per minute from thousands of nodes in production. This weekend we deployed a major architecture change by creating swimlanes in our cloud by directing different types of traffic to di