Details
-
Improvement
-
Resolution: Fixed
-
Minor
-
reference-0.15
-
None
Description
The current alarm log looks like this:
Date Raiser Alarm code Description 2012-06-18T09:13:13.797+02:00 kbpillar2 INCONSISTENT_REQUEST Collection integrationtest1 does not have file "evo" 2012-06-18T09:12:53.821+02:00 kbpillar2 INCONSISTENT_REQUEST Collection integrationtest1 does not have file "eov" 2012-06-18T09:12:25.316+02:00 kbpillar2 INCONSISTENT_REQUEST FileID evo is not present in collection. 2012-06-18T09:08:39.319+02:00 kbpillar2 COMPONENT_FAILURE Failed to register an audit trail event 2012-06-18T09:08:10.262+02:00 reference2 COMPONENT_FAILURE java.lang.NullPointerException 2012-06-18T09:07:12.665+02:00 kbpillar2 COMPONENT_FAILURE Failed to register an audit trail event 2012-06-18T09:07:12.650+02:00 kbpillar2 COMPONENT_FAILURE Failed to register an audit trail event 2012-06-18T09:07:12.644+02:00 kbpillar2 COMPONENT_FAILURE Failed to register an audit trail event 2012-06-18T09:07:12.637+02:00 kbpillar2 COMPONENT_FAILURE Failed to register an audit trail event 2012-06-18T09:07:12.623+02:00 kbpillar2 COMPONENT_FAILURE Failed to register an audit trail event
9 out of 10 alarms are from the KB-pillar, which is spamming the alarmlist. We should run through the KB-pillar alarms and filter out all the none-relevant/none-critial.
Apparently the KB-pillar sends alarms if it is unable to find a file for a given request, this seems far to verbose. We might also consider defining a way of preventing multiple larms in case of a recurring failure, like, the failure to register audit trail events.
