We have separate hub and robots for db2 monitoring, Currently we are writing the db2 alerts to a log file on the db2 hub and the log file is accessed by analytics tool.Since we are no longer needed DB2 alerts from UIM and DB2 probes are generating huge number for alerts, we have disabled the nas replication. Is there any way to exclude only db2 alarm and forward other probe alarms to the next hub?
Use EXCLUDE rule in pre-processing feature in nas probe.
In the rule, you can specify probe name for exclusion.
Hope it helps.
we are writing the db2 alerts into a log file on the hub, i cannot exclude it in Pre-processing
Can you shed more light on 'writing the db2 alerts into a log file on hub'
like how it is written in the log, what all checks are involved, is it via a script etc.
Because in theory excluding the alarm from nas pre-processing should atleast not affect the log file ingestion by log analytics tool and in no way discontinue your monitoring via db2 probe it just that your db2 probe alarms won't show in UIM but still be there in db2 logs.
Unless there are some special conditions on the log file itself.
yes we are writing the alerts to logfile by the nas AO and the profile uses script. Below is the script
a = alarm.get()a.assigned_to = "db2_alarm_logger"
alert_log = io.open("d:\\tool\\db2\\uim_db2_alarms.log", "a")io.output(alert_log)io.write("TimeStamp:"..os.date("!%m-%d-%Y %H:%M:%S")..", "..a.message.."\n")io.close(alert_log)
I have given the script, so if i create pre-processing exclude rule for db2 alerts, will the below script still write the alerts to log file?
Preprocessing happens before the decision on which AO profiles match.
So if your preprocessing script returns nil on the db2 alerts you don't want, then the alarm will be thrown away before the AO profile rules are evaluated. And since the alarm won't be there, your AO will not fire.
You also don't indicate how you are set up to fire the AO (on arrival, overdue age, etc) and this will make a difference on the behavior of the script and underlying alarms.
Your AO profile executes the line "a.assigned_to = "db2_alarm_logger"" which will have no effect. It will update the in memory copy of the alarm the AO is accessing but not the one saved.
And your call to action.close() will put this alarm update message back on the queue of alarms to process so if this is an on arrival AO and isn't filtering on alarm severity then it will also fire on the close event.
And you really should check return codes on everything. alarm.get() can return nil for instance which would cause future usages of the variable a to fault.
And find the nas technical reference document - the last couple pages of that will be a huge help.