Strange event behavior

I saw the following strange behaviour yesterday when testing ServiceDown and ServiceUp events from the ServiceCorrelator. Due to a misconfiguration in the Dispatcher Listeners file, two identical events would be sent to Netcool at the same time. Thus two ServiceUp events show up in the EventAdapter log, both with Severity Fatal. In the ObjectServer they are cleared immediately, and don’t correlate to the ServiceDown problem event. Fixing the dispatcher rules fixed this problem, but I have no idea what triggered it. Any ideas?

Forwarding events to ServiceCorrelator

Forwarding new fatal events to the service correlator now works. I added an automation that checks (every 5 secs) for new fatal events and sets their CorrelationStatus attribute to 1. This should work for Resolution events too, since they get correlated with the problem event and their status is set to equal that of the problem event. The event is picked up by the socket gateway. I gave the gateway a second filter that checks for CorrelationStatus = 1 and added this to a second reader that sets the CorrelationStatus to 2. This is in addition to the one that looks for Smart24Status = 1. That one needed to be retained for notifications of Resolution events.

I was afraid that Micromuse licensing would be in the way again, which it would if 1 license only covered 1 reader (W mentioned this), but the gateway seems to work fine with two readers.

Fatal events do get forwarded now, and since their Intent field is set to ComponentDown (or ComponentUp for Resolutions), they are routed correctly to the ServiceCorrelator.

Some further testing is required to check the insertion of ServiceDown and ServiceUp events by the correlator, and the forwarding of resolution events.

One interesting problem is that logical components such as services, don’t have address, class and instance set. I intend to have webservices populate class and instance with “CustomerService” and componentId, so that the default mechanism for correlating up and down works for them as well. If all is right, the service events do not even need a reference number then.