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 : Page 2

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
A Single, Unified Instrumentation API
If you've been around long enough to get an actual application into production (congratulations!), you have undoubtedly experienced: "runs on my machine," or "runs in the development environment" answer to the question, "why is this action failing on the production server?" To help answer this question, you might have checked out the offending source code, littered it with writes to the event log, and then shoved the DLL up to the production server. You then sit and monitor the event log. Once you gather enough information (and hopefully fix the issue) you then have to strip all the event log calls out of your code and again update the server. This can be a tedious process to be sure. EIF works in the same manner but without the tedium, and with a much more structured and controllable approach. Without EIF, you have a lot of choices (and a big decision) to make regarding what data store you wish to target with your tracing code. You can do all of the following to trace your application:

  • Write to the event log using the System.Diagnostics.EventLog class
  • Fire messages to WMI using the System.Management namespace
  • Use the System.IO namespace to write to a text file
  • Call into the System.Messaging namespace to output information to a message queue
  • Log trace messages to the database using System.Data
  • Output messages with System.Diagnostics.Trace
  • Target performance counters
Once you choose a means to output your tracing and target your choice's associated event store, you are essentially stuck with that decision. All your trace code will be written to specifically target the underlying event store. In fact, you may be writing to the event log today but would prefer to write to SQL server—no small change. Clearly, what you have now is a separate API for every event store. What you want is a common approach to allow developers to instrument their code, targeting all existing event stores (WMI, event log, text file, etc.) and all new event stores that might be created post application release. This unifying tracing API is the EIF. Here is how it works.

Instrumentation—The Basics
Instrumentation is often one of the last tasks a developer does before checking in their code (or passing code review). Like commenting, instrumentation is easy to skip when the schedule is tight and the code is difficult to implement. In addition, you don't want your instrumentation code to be a distraction when you view the core functionality of the application. To help solve these issues, instrumentation should be easy to implement and the code should be minimal. You will soon see that the EIF API offers just that. In fact, applying the EIF is a straight-forward, two-step process:



  1. Instrument your code with the EIF API calls (messages that trace important steps/data in your application)
  2. Create a configuration file that is used to control the amount of trace messages your application emits and to what listeners
Let's take a look at a simple example of this in action.


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