Skip to content

Archive for

Instrumenting Applications

I was driving along the other day and my “Check Engine” light came on. This is an ominous occurrence because this light can be an indicator of a looming system failure within an automobile. The catalytic converter could be on its last legs (you won’t pass the emissions inspection), there could be an engine seal broken that is causing a loss of compression (or allowing something into the block), or any number of other things. In short – this light is worthless. It means you need to take it to a mechanic to read a code.

Why they couldn’t just add a little LED display onto the dash panel to help me out, I have no idea. Maybe there are a bunch of System.out statements that would generate so much noise you’d be confused. This is exactly what happens in software development. As people debug problems in their code, they implement statements to help them track the flow (this is especially true for web apps when you can’t monitor server processes). With a little bit of care, these messages can implemented as part of a framework – Log4net, for example. If you think through “what can go wrong in this section” and “what would I like to know to diagnose it” or “what conditions indicate something bad is going to happen” you can more thoughtfully instrument your code. Adding monitors on top of this implementation to alert on particular messages or conditions then becomes a trivial task. Unfortunately, all too often useless messages get generated in a non-managed way and the signal to noise ratio become unbearably small. 

As for my “check engine” light? Apparently on a cold morning when I filled up my gas tank, I didn’t turn the gas cap until it clicked 3 times. There was nothing wrong with my engine. Here’s how I imagine that poorly written code block looks:

try{

   MonitorFuelSystem()

}catch(GasCapException e){

    System.out.println(“Ignore this exception”);

}

 

Thanks for turning the light on and freaking me out over nothing.

 

  • Recent Tweets…