05-06-2019 12:09 AM - edited 05-06-2019 02:20 AM
for batch purge:
in cmd line, I could use "alarms purge-alarms older-than { days 1 } alarm-status cleared" to purge the alarms already cleared, but don't know how to use restful API to process this action.
I tried with https://csgnsolab.webex.com/api/running/alarms/_operations/purge-alarms with POST, and body contains json with {"alarm-status": "cleared", "older-than": {"days": 1}}, not work.
for single alarm purge:
I frist use GET https://csgnsolab.webex.com/api/operational/alarms/alarm-list/alarm to fetch all the alarms, below is the snapshot.
{
"collection": {
"tailf-ncs-alarms:alarm": [{
"device": "BTS01-WXBB-PE01",
"type": "tailf-ncs-alarms:connection-failure",
"managed-object": "/tailf-ncs:devices/device[name='BTS01-WXBB-PE01']",
"specific-problem": "",
"is-cleared": false,
"last-status-change": "2019-04-09T01:00:02.555199+00:00",
"last-perceived-severity": "major",
"last-alarm-text": "Failed to connect to device BTS01-WXBB-PE01: connection refused: Connection refused in new state",
"status-change": [{
"event-time": "2019-04-09T01:00:02.555199+00:00"
}],
"operations": {
"purge": "/api/operational/alarms/alarm-list/alarm/BTS01-WXBB-PE01,al:connection-failure,\"/ncs:devices/ncs:device[ncs:name='BTS01-WXBB-PE01']\",\"\"/_operations/purge",
"compress": "/api/operational/alarms/alarm-list/alarm/BTS01-WXBB-PE01,al:connection-failure,\"/ncs:devices/ncs:device[ncs:name='BTS01-WXBB-PE01']\",\"\"/_operations/compress",
"handle-alarm": "/api/operational/alarms/alarm-list/alarm/BTS01-WXBB-PE01,al:connection-failure,\"/ncs:devices/ncs:device[ncs:name='BTS01-WXBB-PE01']\",\"\"/_operations/handle-alarm"
}
}
}
}
When I try to call the purge method offered in the operations/purge json, POST https://csgnsolab.webex.com/api/operational/alarms/alarm-list/alarm/BTS01-WXBB-PE01,al:connection-failure,"/ncs:devices/ncs:device[ncs:name='BTS01-WXBB-PE01']",""/_operations/purge, it always return below error message:
<errors xmlns="http://tail-f.com/ns/tailf-rest-error">
<error>
<error-tag>unknown-element</error-tag>
<error-message>wrong number of identifiers</error-message>
</error>
</errors>
How to run the batch purge or single purge through restful API
Solved! Go to Solution.
05-06-2019 08:36 AM
05-06-2019 08:36 AM
05-06-2019 10:29 PM
05-07-2019 06:55 AM
Chris,
Sorry, I missed the second half of your post, alarm-specific purge...
Just tried a quick test and unfortunately, I see the same issue as you:
$ curl -X POST -v -H'Content-Type: application/vnd.yang.operation+json' -u admin:admin http://127.0.0.1:8080/api/operational/alarms/alarm-list/alarm/ncs1004-0,al:connection-failure,"/ncs:devices/ncs:device\[ncs:name='ncs1004-0'\]",""/_operations/purge
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
* Server auth using Basic with user 'admin'
> POST /api/operational/alarms/alarm-list/alarm/ncs1004-0,al:connection-failure,/ncs:devices/ncs:device[ncs:name='ncs1004-0'],/_operations/purge HTTP/1.1
> Host: 127.0.0.1:8080
> Authorization: Basic YWRtaW46YWRtaW4=
> User-Agent: curl/7.63.0
> Accept: */*
> Content-Type: application/vnd.yang.operation+json
>
< HTTP/1.1 404 Not Found
< Date: Mon, 06 May 2019 16:50:13 GMT
< Cache-Control: private, no-cache, must-revalidate, proxy-revalidate
< Content-Length: 106
< Content-Type: text/json
< Vary: Accept-Encoding
< Pragma: no-cache
<
{"errors": {"error": [{"error-message": "wrong number of identifiers", "error-tag": "unknown-element"}]}}
* Connection #0 to host 127.0.0.1 left intact
I suspect that this is the problem: The empty string ("") at the end of this section of the URL:
/ncs1004-0,al:connection-failure,"/ncs:devices/ncs:device\[ncs:name='ncs1004-0'\]",""/
is getting removed by curl processing - from the command debug:
/ncs1004-0,al:connection-failure,/ncs:devices/ncs:device[ncs:name='ncs1004-0'],/
This section of the URL is the 'key' to the alarm list, when that 4th key (see yang below) is missing on the incoming URL NSO reports the"wrong number of identifiers", error:
I quickly tried various quoting and escaping on this section of the URL to no avail...
Hoping someone else can provide the special sauce in the URL to make the 'empty string' survive the trip to NSO when curl is used.
-Larry
from tailf-ncs-alarms.yang:
list alarm {
key "device type managed-object specific-problem";
description
"The list of alarms. Each entry in the list holds one
alarm for a given alarm type and device, managed object.
An alarm can be updated from the underlying device or
by the user. These changes are reflected in different lists
below the corresponding alarm.";
<...>
leaf device {
type string;
description
"If a managed device is associated to the alarm, this leaf
is the name of that device. All alarms may not
be possible to associate to a specific device, thus
this leaf is a string and not a leafref.
For alarms associated with NCS, this leaf has the value 'ncs'.";
tailf:info "The alarming device";
}leaf type {
type alarm-type-t;
description
"This leaf and the leaf 'specific-problem', together provides a
unique identification of the alarm type.
Different managed object types and instances can share alarm
types, but if the same managed object reports the same alarm
type, it is to be considered as the same alarm state.";
tailf:info "Unique identification of the alarm type";
}
leaf managed-object {
type managed-object-t;
description
"The alarming object. See also 'alt-managed-object'.";
tailf:info "The alarming object";
}
leaf specific-problem {
type string;
description
"This leaf is used when the 'type' leaf cannot uniquely
identify the alarm type. Normally, this is not the case,
and this leaf is the empty string.";
tailf:info "Alarm type refinement";
}
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide