This project is read-only.

State or Abstraction in instrumentation helper classes

Topics: Event Log, Health Modeling, Instrumentation, TSMMD
May 20, 2008 at 8:41 AM

I am missing the opportunity to keep state in the generated instrumentation helper classes, or some abstraction (interfaces, abstract classes).

An example: Let’s say you have a web application and a health definition with an aspect looking at database connectivity. Each request coming in to the web application grabs a connection from the pool. If this fails a ConnectionFailed event is raised, which makes OpsMgr enter into Red Health State. If getting a connection was a success I raise a ConnectionEstablish event – this way it will go from Red to Green Health State.
But if we are already in a Green Health State I don’t really want to know that a connection was established – It would spam my event log if the number of requests is high enough.

If I somehow could keep state in my instrumentation helper classes so it would only raise events when necessary, that is, when Health state is changed (maybe redirecting “unnecessary” events to a log file instead).

Now this is probably too specific to put into the helper classes and I think it would be fine if I were to write this myself. But it would require some abstraction on the helper classes which I don’t find (otherwise I would have to rewrite whenever changing the health definition), see also (I am looking at v2.1)

What's your opinion on this?