Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
Ben Nadel at cf.Objective() 2013 (Bloomington, MN) with: Jesse Roach and Miguel Olivarez and Adam Presley
Ben Nadel at cf.Objective() 2013 (Bloomington, MN) with: Jesse Roach@jessewroach ) , Miguel Olivarez , and Adam Presley@adampresley )

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

By Ben Nadel on
Tags: ColdFusion

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), HostedGraphite.com. 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

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.