Perl API to extract event details from SAM/APM

Okay,

     First, to my knowledge there is not an "official" NLI (Notification List Interface) subscription in the Perl API.  A long time ago, a friend implemented it, but I don't think it is in the mainstream at the moment.  As a result, the code below focuses on non-SAM/OI domains and their subscription.  As you partially noted, looking into the AllNotificationsData is part of how you extract data from the SAM/OI Notification Lists since events there are objects rather than conditions to existing objects.  The existing NLI subscribers utilize a property subscription on the NotificationList with some callbacks to perform such operations.

    Second, the receiveEvent is an atomic operation intended to receive a *single* event.  You need to keep it in an unterminated "while" loop to continue to receive events.  The most simplistic example I have seen is the following:

#~ subscribe-down.pl - subscribe to UCS 'down' events and report them

#

# Copyright (c) 2003 System Management ARTS (SMARTS)

# All Rights Reserved.

#

# SMARTS provides this program 'as is' for educational and illustrative

# purposes only, without warranty or support.

#

# RCS $Id: //depot/smarts/dmt/rel/7.2/perlApi/samples/subscribe-down.pl#1 $

# $Source: /src/MASTER/smarts/perlApi/samples/subscribe-down.pl,v $

#

#   usage: see below

#

$0 =~ s|.*/([^/]+)|$1|;     ## basename of app invocation

use InCharge::session;

use Data::Dumper;

##  called by InCharge::session->init if command line error

sub usageError {

    print "Usage: perl $0 [options]\n\n"."$_[0]\n";

    exit 2;

}

## ensure log is updated after every write operation

$AUTOFLUSH = 1;

# Initialize the session session

$session = InCharge::session->init( );

# Open an observer.

$obs = $session->observer( );

# Subscribe to changes on the "Down" event on all unitary computer systems.

@ucsList = $session->getClassInstances( "ICIM_UnitaryComputerSystem" );

foreach my $name (@ucsList) {

    $session->subscribe( "::$name", "Down" );

}

while ( 1 ) {

    my @event = $obs->receiveEvent(15);

    print join( "|", @event)."\n";

}

#### eof ####                       vim:ts=8:sw=4:sts=4:tw=79:fo=tcqrnol:noet:

    The session initialization is very primitive above and should be replaced with the code you have below.  The point was to show (in context) the receiveEvent logic.

    In your example, the "ACCEPT" message is an indication that the subscription has been asked for and accepted by our internal processing systems.  It is NOT an indication that the event is active.

Regards,

Bill

@ William , thanks for the explaination .

the script mentioned by you just gives me the output

1297150807|NOTIFY|Switch|RIM-POC-SW2|Down|1
1297150877|CLEAR|Switch|RIM-POC-SW2|Down

But my need is to  get information of

event name

last notify(date time)

description

and also other fields which is visible in smarts notification console

is there a way to capture these fileds in our perl api ?

Okay, I missed that part from your original post.  As I mentioned before, there are really two "event" views.   One is what I call a traditional subscriber to an analysis domain.   Another is what we call a NotificationList subscriber which connects to  SAM or OI.  To be honest, I  will cover the questions in some detail below, but  continuing down the  path of a traditional subscriber is likely not  going to give you all of the same fields as a Notification List  subscriber.

There are really only about 6 attributes that surface  from a traditional notification subscriber (timestamp, message type,  class, instance, event, severity).  Everything else can be mined from the topology of the underlying domain through the same session.

In a Notification List, there are a larger set of fields  applicable to a subscriber, but in many cases they have specific purposes that aren't needed in a traditional subscriber.  For example, you don't need to know which analysis domains sent an event or need to know the state of an event or the first time it was ever notified.  An event in an analysis domain is either active or not.

As I mentioned in my first response, I have a Perl NotificationList subscriber, but it was written in 2008 and the code changed a bit between those times.  When I can manage to get a version that works with a contemporary SAM, I will post it here.

Alternative #1:

Under the covers, the traditional NotificationList subscriber is actually a property subscription to the attribute NotificationDataChange and NotificationDataRemoval.  These properties are data structures that contain many of the fields of the changed/removed event.  A basic view is like this:

        my $k1 = fileno($observer->{handle});
        if (defined ${nl_handle}) {
           if ($rtn[1] eq "ATTR_CHANGE") {
              @nl_event    = @{$rtn[5]};
              $nl_type     = $rtn[4];
              my $k2       = $nl_event[0];
              @rtn         = ( );
              my $not_time = $e[2];
              my $active   = $nl_event[$observer->{notification_list}->{column_numbers}{"Active"}];
              my $class    = $nl_event[$observer->{notification_list}->{column_numbers}{"ClassName"}];
              my $instance = $nl_event[$observer->{notification_list}->{column_numbers}{"InstanceName"}];
              my $event    = $nl_event[$observer->{notification_list}->{column_numbers}{"EventName"}];

...

Alternative #2:

You can also run (via exec) a sm_adapter process that handles the subscriptions and returns the data to your Perl code.  That will allow you to get a handle to the ICS_Notification object in Perl and examine any fields you choose.

Attribute Details:

Let's deal with the simple ones first.

event name

The event name  in AM/PM is what you saw below "Down".  It is always the 5th field sent  to you.  In SAM, the event name is actually the triplet of class,  instance, and event with a prefix.  So, it becomes  "ICS-Notification-Switch_RIM-POC-SW2_Down".

NOTE:  Because the underscores are used as a delimiter, any embedded  underscores in the class, instance or event are converted to alternative characters in the event name (usually a double underscore).

description

This  actually comes from the underlying domain and is obtained via the  getEventDescription Perl API call (from the Perl API Reference):

$text = $session->getEventDescription( $class, $event )

The getEventDescription() function returns a string, defined in MODEL, that describes an event.

$descr = $session->getEventDescription("Router", "Down");

last notify

This is a little trickier.  If you look at your messages closely, the first field is actually a Unix-style timestamp (number of seconds since the epoch - January 1, 1970).  There are *many* Perl routines that will convert from one to the other in any format you choose.

The important piece here is that if the event is active prior to your subscriber starting, it will print the timestamp the that message was last generated.  This is how we deal with standing events in our subscriber.  The value effectively is "last notify" but implies that you have someone always subscribed to that event.  If your subscriber is duplicating what SAM subscribes to, then you should have no problems.

Regards,

Bill