Topic
3 replies Latest Post - ‏2014-08-13T12:26:56Z by randybrown
kftiv
kftiv
15 Posts
ACCEPTED ANSWER

Pinned topic Number of Events for a Service Instances

‏2014-08-05T15:42:02Z |

Dear all,

TBSM maintains the attribute numRawEventsInt to represent the number of events for a TBSM Service Instance. However, in our environment, events are not immediately cleared from OMNIbus when the event is resolved (to allow easier access to events that happened a while ago), but they remain present in OMNIbus for a while.

Is there a way to manipulate the value maintained as "numRawEventsInt" or a way to introduce a new attributte which excludes the "Cleared" events in OMNIbus to provide a better interpretation of how many problem events are related to a TBSM Service Instance? E.g. when we have 1 Major and 5 Cleared Events, numRawEventsInt has a value of 6, whereas 1 would be the desired value. Another option is to manipulate the event in such a way that it no longer counts towards the number of open events.

Regards

  • randybrown
    randybrown
    59 Posts
    ACCEPTED ANSWER

    Re: Number of Events for a Service Instances

    ‏2014-08-06T01:25:42Z  in response to kftiv

    Hi,

    I am not aware of any builtin attribute for a TBSM service that would give you the value you want across all rules for a service.

    You could add a formula rule to a template and calculate the number of non-normal events for the rules on the same template. For example, the formula would have something like:

          rulename1.NumEventsSevGE3 + rulename2.NumEventsSevGE3 + ... + rulenameN.NumEventsSevGE3

    But this will only work for the simple configuration where all the object server based rules that affect a service are on the same template. You could repeat this for all templates tagged to the service, but I don't know how you would combine the results from the multiple formula rules, if there was more than one template.

    If that will not work, then there might be a way to use a data fetcher to count the events with Severity <> 0, but it would take some experimenting to figure out how to correlate the fetcher results to the right services.

    The only other thought that comes to mind is changing the object server configuration to clear the "normal" events more quickly than the default, which is some number of minutes I believe.

    I hope there is some help in this response...

     

    Randy Brown

    • kftiv
      kftiv
      15 Posts
      ACCEPTED ANSWER

      Re: Number of Events for a Service Instances

      ‏2014-08-11T19:56:34Z  in response to randybrown

      Randy, thanks for the reply. I guess counting of the events could be an option in our design since we use a generic Template to process incoming events. I quickly tested it and it seems to work. The disadvantage of course, is that the default views in the Service Viewer and also the Service Details views show the original number of events maintained as numRawEventsInt and that the events are still related to the Service Instance.

      But does it mean that as long a an event is still present in OMNIbus, it will always count towards the number of Raw Events as maintained in numRawEventsInt?

      Would clearing specific fields, like the RAD_InstanceName possibly help to unlink the cleared event from the service instance. In other words, what are the conditions to incorporate events into the numRawEventsInt value?

      Regards,

      • randybrown
        randybrown
        59 Posts
        ACCEPTED ANSWER

        Re: Number of Events for a Service Instances

        ‏2014-08-13T12:26:56Z  in response to kftiv

        Hi,

        TBSM has a couple of processing threads that must run before the event is completely removed from consideration. There is a "deleted event checker" that runs about every 30 seconds. This depends on the volume of events processed, so the clock starts after the delete processing is completed, but should not exceed 5 minutes unless the delete processing is extremely slow.

        The query for events includes a check RAD_UserFunctionName not like 'Raw', so you might try to set this column to 'Raw' when an event is cleared. Please note that I have not tried this myself.

        As for Service Details, the event will show there until it has been deleted from the object server. If you try the first suggestion, then TBSM may recognize it as gone a little sooner. This could happen with a process TBSM runs called the Consistency Checker. It is on by default and runs every 11 minutes by default, so it is more likely in most cases that the cleared event would be deleted by the object server before the TBSM Consistency Checker would have an effect.

        I hope this helps...

         

        Randy Brown