Archive for May 2006
but check whether /cust is full before you do this. There is a reason why it is not running…
I made a small proof-of-concept ping script in Perl for use as a right-click tool in Netcool and operator portal. The script is passed in the serial number of an alert (or a list of serial numbers), and a user name. It’s URL is http://ip.ad.dr.ess/ping?serial=%5Bserial%5D &user=[username]. It loads the alerts from netcool through the Netcool Dataserver, using json. It iterates through the alerts and pings the IP in the Node field of each. It also sets the archivable flag of each alert and writes the ping result to the alert’s journal.
To make it easy to write these scripts, I extracted the code to retrieve alerts and to archive alerts into a separate library called Smart24::NetcoolScripting. The library exports 3 methods
- alerts. This takes the serial number, or comma separate list of serial number is a string and retrieves the alerts. It optionally also takes a list of fields to retrieve for the alert. The default fields are Node and Serial. for example, use
my $alerts = alerts($serial);It returns an array of alerts retrieved. Each alert is a hashtable of attribute value pairs. In case of an error, it returns
- archive. Takes alert, user and text parameters. The alert parameter is a hashtable, as returned by the alerts method. The user should be a valid netcool user. If the user is invalid, the archive function will fallback on a configurable default user. The text parameter is the script result to be added to the journal. Nothing will be written in the journal if this parameter is missing or does not contain text.
- settings. Retrieves a hash of the settings parameters for the netcool scripts. The settings are defined in
$APPS_DIR/conf/netcoolscripts.yaml. The idea is that each script can create a new key for itself in this file and store script specific values underneath this key.
The library checks for errors at the HTTP, JSON and SQL level. If an error is found, it is reported on the result page.
The new alert archiver is nearing completion. Here are the highlights:
- For each unique alert, only one base record is stored in the Smart24 database. For scripts and selected actions, small delta records are inserted that are linked to this base record
- The content of these delta records is taken directly from the Journal for each alert. This means that the history for each alert in Netcool is also viewable simply by looking at the Journal
- The Netcool Data Server was updated with two URL’s.
- “journal” to read the journal for an alert. It takes care of merging the 16 journal text files, and it takes “serial”, “from”, “to” and “format” parameters
- “archive” to signal that an alert should be archived, and optionally pass in some descriptive text (e.g. script result). Parameters are “serial”, “user”, “text”, “format”. This command should be issued using a POST request
- Automatic and Manual clears and reinserts of new are archivable events and write to the journal.
The ODBC way
- Install iODBC (that means, download, unpack, compile and install)
- Recompile FreeTDS with ODBC support. See here. The ./configure command line is as follows:
./configure --prefix=/usr/local --enable-shared --with-iodbc=/usr/local --disable-static --disable-libiconv --disable-server --disable-pool --enable-sybase-compat --disable-debug --with-pic --with-tdsver=5.0
- Install DBD::ODBC
- Make sure there is a file called odbcinst.ini in /etc. Make sure it maps a name to the freetds ODBC driver:
- Add a record to freetds.conf, like this:
[SMART24] host =ip.ad.dr.ess port = 1433 tds version = 7.0
Note that the tds protocol version should be 7.0 for SQL server 2000
- Use a connection string like this when connecting from perl DBI:
The Sybase way
- Use the same freetds.conf entry as for ODBC
- Pretend SQL server is Sybase, and use a connection string like this:
- I wish I found out about the Sybase way a bit sooner
- Check this