uimapi 500 or 404 errors when trying to acknowledge alarms in DX UIM 20.4 CU6

Products

DX Unified Infrastructure Management (Nimsoft / UIM)

Issue/Introduction

We have 2 Operator Console servers that are both having the same problem with the uimapi.

I am able to run the /alarms/{alarmid} command to retrieve alarm details.

However, when I run the /alarms/{alarmid}/ack command, I get the following error:

<ErrorResponse>

<errorMsg>An exception has occurred while performing the operation. Please check logs for additional information.</errorMsg>

</ErrorResponse>

I get the same error from both OC servers.

-----------------------------------------------------------------

Below are some results from Broadcom Lab testing...

When the ems is not running/activated you get a 500 error:

Environment

Release: 20.4
uimapi: 20.4.6

Cause

ems probe deactivated, or not up and running successfully.

Resolution

Make sure the ems probe is up and running. The ems probe log should be set to loglevel 5, use a logsize of 10000 and make sure ems log shows no issues/errors.
Using the uimapi, acknowledge the alarm using the specific NIM ID/alarm id.

Note that the response code is a little different for that result, a 204, but that is a successful return code in this case, e.g.,

Also note that you will get a 404 error if the alarm (alarm id) is already acknowledged. In the Response body of the uimapi call you will see "Alarm with given ID not found."

A simple test you can run in the uimapi is to get all alarms, Click the Get button, then "Try it out" then "Execute the call.

example output:

Additional Information

When the ems is deactivated you will see uimapi alarm calls throw 500 and 404 errors.

When the ems is activated and you execute uimapi alarm calls, in this case to acknowledge an alarm based on the given alarm ID, you can see the activity in the ems.log:

Mar 29 20:30:35:254 [attach_socket, ems] Dispatching to /acknowledge to api/nas/alarms
Mar 29 20:30:35:255 [attach_socket, ems] ServiceInvoker.invoke (1680732766) - START
Mar 29 20:30:35:259 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] Calling close_alarm callback on NAS: xxxxxxxxxxxxxxx
Mar 29 20:30:35:374 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] Querying for affected alarms.
Mar 29 20:30:35:374 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] SQL used to query alarm data
Mar 29 20:30:35:374 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] select a.*, d.cs_id, m.ci_metric_type, m.ci_id, p.cs_attr_value as primaryipv4address
from nas_alarms a WITH(NOLOCK)
LEFT JOIN cm_device d WITH(NOLOCK) on a.dev_id = d.dev_id
LEFT JOIN cm_configuration_item_metric m WITH(NOLOCK) on a.met_id = m.ci_metric_id
LEFT JOIN cm_computer_system_attr p WITH(NOLOCK) on d.cs_id = p.cs_id and p.cs_attr_key = 'PrimaryIPV4Address' where alarm_manager is null and nimid in (:nimIds)
Mar 29 20:30:35:374 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] {nimIds=[xxxxxxxxxxxxxxx]}
Mar 29 20:30:35:374 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] Max Connections Available In Pool : 30 Max Idle Connections In Pool 20
Mar 29 20:30:35:374 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] Current Active Connections In Pool : 1 Current Idle Connections in Pool : 1
Mar 29 20:30:35:393 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] Deleting nas_alarm entry with ID xxxxxxxxxxxxxxx
Mar 29 20:30:35:397 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] ServiceInvoker.invoke (1680732766) - END took 0.14s
Mar 29 20:30:35:397 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] ShiftDispatcher.getThrowableObjectEither (1035536133) - END took 0.14s
Mar 29 20:30:35:397 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] ShiftDispatcher.sendResponse (1035536133) - START
Mar 29 20:30:35:397 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] ShiftDispatcher.sendResponse (1035536133) - END took 0.00s
Mar 29 20:30:35:397 [NasAlarmServiceImpl [acknowledgeAlarms] - 67, ems] ShiftDispatcher.dispatch (1035536133) - END took 0.14s