Skip to main content
Ben Nadel at the New York ColdFusion User Group (Sep. 2009) with: Aaron Foss
Ben Nadel at the New York ColdFusion User Group (Sep. 2009) with: Aaron Foss ( @aaronfoss )

StatsDGateway.cfc - A ColdFusion Module For Communicating With StatsD Servers

Published in Comments (2)

A while back, I wrote an experimental ColdFusion module called GraphiteD.cfc. This was intended to allow ColdFusion applications to send statsD metrics to the statsD SaaS (Software as a Service), Most of the time, however, people are running a statsD server on their local network (which is what we do at InVision App). To communicate with the local statsD servier, I've created a ColdFusion module, StatsDGateway.cfc, which will send metrics to the local statsD daemon.

View the StatsDGatway.cfc project on my GitHub account.

Writing this module was motivated partly out of a need and partly out of a desire to get better at writing modular, cohesive code. Originally, this module started out a single component. But, after watching Corey Haine's presentation - Rules of Simple Design - I felt that my single component could be broken up into smaller, more focused components that could be easily swapped-out. Now, this ColdFusion module is composed of a series of smaller ColdFusion components that are focused on a single responsibility (or, at least, as best as my unfrozen caveman brain can build).

A the top level, the StatsDGateway.cfc provides a method to create the StatsDClient.cfc with the default settings:

  • StatsDGateway.createClient( host, port, prefix, suffix )

The above arguments are all optional and, if omitted, will use default values. The default client will send metrics over UDP to the statsD server, "localhost:8125". If the default client isn't good for you, can manually create the client and provide the appropriate implementations (which is what I am doing in the unit tests).

Once you have an instance of the StatsDClient.cfc, you can use the following methods to send metrics:

  • count( key, delta [ , rate = 1 ] )
  • decrement( key [ , delta = 1 [ , rate = 1 ]] )
  • increment( key [ , delta = 1 [ , rate = 1 ]] )
  • gauge( key, value [ , rate = 1 ] )
  • incrementGauge( key, delta [ , rate = 1 ] )
  • decrementGauge( key, delta [ , rate = 1 ] )
  • timing( key, duration [ , rate = 1 ] )
  • unique( group, member [ , rate = 1 ] )

At InVision App, we started using statsD a couple of months ago; and, in that time, I've completely fallen in love with metrics! Having a metrics dashboard is like being able to watch the vital signs of your app while doing invasive surgery. And, a wonderful side-effect is that you can see which parts of your application are not being used, which can then be the evidence you need to remove deadweight from your code-base.

Shout-Out: I want to give a shout-out to Matt Walker's CFStatsD.cfc ColdFusion component. This is what we've been using up until now; and, in production, it's been really solid. Our problem is that locally, we rebuild our app with every request. This leads to the error, "Too many open files," since CFStatsD.cfc opens a socket every time it is instantiated. My module gets around this by opening and closing the socket with each message (which is part of the UDPTransport.cfc, which can be swapped out in different environments where sockets can be used more optimistically).

Reader Comments

I believe in love. I believe in compassion. I believe in human rights. I believe that we can afford to give more of these gifts to the world around us because it costs us nothing to be decent and kind and understanding. And, I want you to know that when you land on this site, you are accepted for who you are, no matter how you identify, what truths you live, or whatever kind of goofy shit makes you feel alive! Rock on with your bad self!
Ben Nadel