Ok, second request for this datafetcher monitoring in the same week. Ultimately, we need to enhance the BSM Agent for our MOSWOS self-monitoring so we can bring in the state/status and query time metrics for processing in situations, workspaces and storage in TDW.
Here’s what I’ve dug up for two approaches to this.
* Each datafetcher has it’s own log. You could build out a custom monitoring agent, log file adaptor, or similar to monitor those logs. The output of the logfile monitoring sends in events via nco_sql or maybe generates unique EIF events with postemsg or similar. You could create a simple table in Postgres as well where you insert the status and fetch time metric and then hit that with another datafetcher.
* A more straight forward approach would be using a Netcool/Impact, an internal formula rule (with custom policy) or a stand alone script to interact with RADSHELL. The output from this policy of script could be manipulated to insert events, metrics, drive state on a rule, etc. Capture the datafetcher names from the Postgres database to build a simple autopop or ESDA managed model.
The command rad.getDBPollerStatus(“datafetchername”); will provide you the state of the datafetcher.
Here is an example of the output.
Normal “Green” State for DF:
radshell> rad.getDBPollerStatus(“DB_metrics”);
Error “Yellow” State for DF:
radshell> rad.getDBPollerStatus(“DB_metrics”);
Not Running “Red” State for DF:
radshell> rad.getDBPollerStatus(“DB_metrics”);