FIDO: Object Suppression
The first stage of suppression; for a given module, suppress writing out an alarm for every monitored item if every monitored item is down. Instead, an alarm is created that indicates that all objects for a given module are in alarm. It may be that the management machine is isolated or the test has really gone astray.
The second stage of suppression is specific to the SNMP module.
From fido_snmp.configmark_unknown_as = [string] # valid values are 'node unreachable' or suppressedBy setting 'node unreachable', any alarm that is dependent on a snmp_node failure will be added to the status file and will show up as a 'correlated' object in the Fido GUI.
By setting 'suppressed', any alarm that is dependent on a node will NOT be put into the status file. Instead of showing up as a correlated object, the parent item will have a [suppressed] tag shown in the GUI. The suppressed tag will be an integer representing the number of alarms that were not added to the status file because of this setting.
Any item that was already in the FIDO report when it became candidate
for suppression will remain in the FIDO report file. This is so that
when the parent node becomes reachable again, the original outage and
comments will be intact.
As of late 2013, I am using JSON::XS and not Storable. The below original content is archived for historical reasons.
FIDO uses the perl 'Storable' module to write hash files to disk. While Storable is an admirable performer most of the time, I found that the write speed of Storable was very non-linear.
file construction | creation | read file | write file |
---|---|---|---|
10,000 keys with 15 subkeys with values | 1 sec | 1 sec | 3 sec |
40,000 keys with 15 subkeys with values | 2 sec | 2 sec | 180 sec* |
The 180 sec was highly variable. Sometimes this number would be much smaller. Since the campus FIDO is watching 50,000+ interfaces, I implemented suppression.