DX NetOps

 View Only
Expand all | Collapse all

Alarm Title from CLI

  • 1.  Alarm Title from CLI

    Posted May 07, 2013 05:03 AM
    Hi Everyone

    I'm looking for a way to retrieve an Alarm Title from the CLI.
    I can retreive the event message from CLI, but can't seem to find a way to get the alarm title.

    Thanks,
    Lawrence


  • 2.  RE: Alarm Title from CLI

    Posted May 08, 2013 10:26 AM

    sirlagz wrote:

    Hi Everyone

    I'm looking for a way to retrieve an Alarm Title from the CLI.
    I can retreive the event message from CLI, but can't seem to find a way to get the alarm title.

    Thanks,
    Lawrence
    There's no easy way through CLI. My preferred way to do this is through the REST Web API. I prefer to use Perl scripts calling curl. I've also used Powershell with System.Net.WebRequest for windows.
    curl -u 'username:password' -k -X POST --header "Content-Type:application/xml" -d @$xml $url
    
    -u : Spectrum username/password
    -k : ignore certificate errors
    -X : HTTP Method
    -d : xml file to post data from. the value of $xml should be the location of the file, not the contents of the file (e.g. /opt/spectrum/models.xml)
    $url : url for the REST function, e.g. http://<hostname><:portnumber>/spectrum/restful/alarms[?attr=<attr_ID>][&landscape=<landscape_handle>][&throttlesize=<num>]
    --header : always "Content-Type:application/xml"


  • 3.  RE: Alarm Title from CLI

    Posted May 08, 2013 09:45 PM
    Thanks for that.
    Unfortunately my Spectrum install is on Windows, so curl isn't available.
    Is there a link to doco on the REST web api at all ? I wasn't aware of it's existence :*)

    Also, is there a way to get the id of the alarm that is not the uuid ?
    i.e. the alarm id that is shown when running ./show alarms from the cli


  • 4.  RE: Alarm Title from CLI
    Best Answer

    Posted May 09, 2013 02:56 PM

    sirlagz wrote:

    Thanks for that.
    Unfortunately my Spectrum install is on Windows, so curl isn't available.
    Is there a link to doco on the REST web api at all ? I wasn't aware of it's existence :*)
    In the OneClick client go to Help->CA Spectrum Documentation

    sirlagz wrote:

    Also, is there a way to get the id of the alarm that is not the uuid ?
    i.e. the alarm id that is shown when running ./show alarms from the cli
    Appendix A of the API Guide has what fields you can choose that are returned when you search alarms. By default the "long id" is returned and I believe the following is the "short id"

    0x11f9c Alarm ID Octet String


  • 5.  RE: Alarm Title from CLI

    Posted May 10, 2013 03:38 AM
    Thank you all for all your help.

    I will have to look into how I can put this all together

    Thanks again !


  • 6.  RE: Alarm Title from CLI

    Posted Aug 12, 2013 11:47 PM
    I've finally gotten around to getting back to doing this
    I can get the Alarm Title from the REST API, but that doesn't provide me with the Event Message.
    Is there a way I can get the Event Message as well for the alarm ?

    And in a similar vein, can I get the maintenance schedules that models are in from the REST API ?


  • 7.  RE: Alarm Title from CLI

    Posted Aug 13, 2013 08:35 AM
      |   view attached
    You cannot get the event message from an alarm through the rest api. You can get a full list of what attributes can be read from an alarm by opening the Model Type Editor and looking at model type GlobalAlarm.

    We added custom writable attributes to the GlobalAlarm model (page 39 of OneClick Customization Guide) to add a little more flexibility with the messages it can contain. It can be written to directly with either trap mappings in the AlertMap file or Event Procedures in the EventDisp file (attached picture).
    While this does not scale well for all event messages, it does allow the REST API to query the contents of the custom attributes directly.

    Maintenance Schedules are Modeltype_Handle 0x10456. To see what models they are applied to you can use either the CLI or REST "Associations" methods.

    .


  • 8.  RE: Alarm Title from CLI

    Posted Aug 13, 2013 10:22 AM
    Thanks a lot !
    I'll look into it when I get into work tomorrow


  • 9.  Re: Alarm Title from CLI

    Posted Nov 10, 2016 01:42 AM

    Hi,

     

    Can you please help me how you access the web service in windows from perl as it seems you were successful in doing that.

     

    Regards

    Ajit C



  • 10.  RE: Alarm Title from CLI

    Posted May 09, 2013 01:58 PM
    As far as I can tell, you cannot get the alarm title using the CLI, the closest thing you can get is probably looking at the event data [./show event mh= ]
    You will need to use the rest API if you want the title though, since you don't have curl you should do what Lutelewis said: " I've also used Powershell with System.Net.WebRequest for windows."

    You can download the rest documentation, its called "Web services API guide"

    Good luck!


  • 11.  RE: Alarm Title from CLI

    Posted May 09, 2013 02:08 PM
    The "show alarms" CLI command with the "-x" option displays the text of the probable cause at the end of the output. The following is an example where "MANAGEMENT AGENT LOST" is the Alarm Title.
    ./show alarms -x mh=0x400067
    ID Date Time PCauseId MHandle MName MTypeNam
    e Severity Ack Stale Assignment Status
    1246 05/09/2013 08:32:03 0x10701 0x400067 Lab-B3 Rtr_Cisc
    o MAJOR No No

    0x10701 MANAGEMENT AGENT LOST SYMPTOMS: Model is no longer responding to prima
    ry management requests (e.g. SNMP or EPI), but appears to be responsive to other
    communication protocol (e.g. ICMP). PROBABLE CAUSES: 1) Management agent has
    gone down. 2) Device may be "dropping" management requests in favor of device p
    erformance and/or functionality. 3) Incorrect SNMP community string. 4) Invali
    d SNMPv3 credentials or SNMPv3 credentials have become stale. RECOMMENDED ACTI
    ONS: 1) Verify SNMP community strings seen on both the SPECTRUM model and the d
    evice. If both strings seem to be in sync and correct, then the user may wish t
    o wait for the condition to correct itself. If the condition does not appear to
    be temporary, there may be a firmware problem at hand. 2) For devices managed
    via SNMPv3, resetting the SNMPv3 authentication( Reconfiguration->Reset SNMPv3 A
    uthenticaiton ) will remove existing cached credentials and allow fresh negotiat
    ion of credentials.