Measure Anything, Measure Everything (2011)
codeascraft.etsy.com
Measure Anything, Measure Everything (2011)
1–10 of 23 posts
Re: Measure Anything, Measure Everything (2011)
#2Re: Measure Anything, Measure Everything (2011)
#3Be wary of measuring - and hence improving - the wrong thing.
Sometimes you optimize for the wrong metric. The classic example is measuring programmer output by lines of code. The are many more subtle ways this can manifest, though.
Re: Measure Anything, Measure Everything (2011)
#4Does anyone here use this?
Re: Measure Anything, Measure Everything (2011)
#5"That which is measured improves." Be wary of measuring - and hence improving - the wrong thing. Sometimes you optimize for the wrong metric. The classic example is measuring programmer output by lines of code. The are many more subtle ways this can manifest, though.
So, measure everything, including your measures.
Re: Measure Anything, Measure Everything (2011)
#6Re: Measure Anything, Measure Everything (2011)
#7"That which is measured improves." Be wary of measuring - and hence improving - the wrong thing. Sometimes you optimize for the wrong metric. The classic example is measuring programmer output by lines of code. The are many more subtle ways this can manifest, though.
We know that measuring programming output by lines of code is bad because we measured that measure. So, measure everything, including your measures.
Re: Measure Anything, Measure Everything (2011)
#8Does anyone here use this?
Implementation was easy. statsd is pretty simple to deploy and graphite wasn't too difficult either. To add statsd reporting to your code, it's essentially one line to create the statsd socket, another line of code to declare each timer or counter, and another one to increment. I think more time was spent determining what name to give each metric than it was implementing it in this project.
Now that I'm at dotCloud, I'm working with a much larger distributed system and we use it here also. We liked it enough to build some statsd hooks onto our RPC layer we use for just about everything. Now every time a component makes a remote procedure call, a counter for that call is incremented and the response time is sent to statsd. It's been very useful for troubleshooting odd behaviors and correlating events across the platform.
As people who work with complex distributed systems, we can't know exactly what they're doing. We'll think we know, and sometimes we'll be close. Other times we'll think we know, and then we'll wake up at 2AM because something failed horribly. By being able to monitor the system's behavior (sometimes in gross detail), we can get a little closer to knowing what's really going on.
Re: Measure Anything, Measure Everything (2011)
#9Why are there a negative number of cups of coffee remaining?
Re: Measure Anything, Measure Everything (2011)
#10http://www.charleshooper.net/blog/painless-instrumentation-o...