Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

The Enterprise Instrumentation Framework

The Enterprise Instrumentation Framework (EIF) provides an easy-to-use and unified API for writing trace messages out to any and all event sinks including: the event log, WMI, text files, MSMQ, etc.


advertisement
e've all faced those irritable questions about our applications running in production. Typically a system administrator will spring one on you on a Friday afternoon just when you're finishing out the week with a game of foosball.
  • Why did this request fail?
  • What is causing so many disk IO spikes?
  • What requests are failing as a result of this error?
  • Why is the application running so slowly?
  • Why are all the resources being gobbled up on the Web server?
These questions often make us stare blankly for a while, mumble something, and then scramble back to our cave (or server room) for hours on end trying to provide answers,

What if things could be different? What if you could give the system administrator enough information to troubleshoot most basic issues and only come to you with the tough ones? What if, when she came to you, you could flip a switch and your application would start giving you the answers and you could get back to the Friday afternoon foosball tournament? Sounds like a dream, right? Enter the Enterprise Instrumentation Framework (EIF). The EIF allows you to generate all sorts of data about your applications executing on the production servers. With a few well-placed, single-line static method calls into the EIF API, data can be streaming out of your applications, collected, parsed and displayed to answer any number of questions. And, of course, you provide access to the switch—turning up the volume on some transactions and hitting the mute button on others.

Instrumentation and the Goals of the EIF
The word "instrumentation" makes a simple process sound very complicated (as is often the case). As you may have guessed, instrumentation is a reference to actual instruments (like a tachometer) found in the physical world. A car's engine, for example, provides diagnostic and performance data to both drivers and mechanics. This data gets transmitted and processed by "listening" instruments. The process of embedding sensors into a system (a physical vehicle or a software application) for the purpose of diagnosing problems is referred to as instrumentation. In fact, most cars today can be connected to the ultimate instrument, a computer. This computer can be used to turn on all kinds of diagnostic information (at runtime) and then provide mechanics useful data to solve most problems without going back to the manufacturer for a fix.

What if you could give the system administrator enough information to troubleshoot most basic issues and only come to you with the tough ones?
In the software realm, instrumentation involves trace code (sensors) placed inside key areas of the application (components). The goal is to allow administrators (like mechanics) to turn this diagnostic information on and off as required, and thus use this information to solve issues without having to go back to the application's developer (or manufacturer).


Sounds like a great idea—and it is! However, in the real world, instrumentation gets pushed aside and all too often left out of the majority of applications. The reasons for this are:

  • The environment may not support good instrumentation
  • The instrumentation code is verbose and thus compromises code readability
  • The instrumentation code is hard to write, and even harder to justify given a typical, aggressive development schedule
  • The instrumentation code does not provide enough good information to make it worthwhile
  • The instrumentation code degrades performance
We designed the Enterprise Instrumentation Framework to eliminate every one of these reasons not to leverage instrumentation in your applications. In fact, the goals for the EIF are right in-step with countering each of these issues:

  • Provide a single, unified API for outputting instrumentation data to all data stores
  • Provide a simple, one-line method call for instrumenting
  • Provide a lot of good information in an easy to use format
  • Provide the ability to trace a business request across method calls and across process boundaries
  • Allow instrumentation to be turned on/off and up/down as required
Let's take a look at how the EIF realizes these goals.


Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date