≡ Menu

Tivoli Business Service Manager (TBSM) Support Tip of the Week #14

in IBM, Implementation, Monitoring, TBSM, Tivoli

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”);