Alarms cleared in NAS still showing in REST-API

[Keith Clay]

We have an alarm that has been cleared for a couple hours in nas but it still shows in the rest-api. How do we get it cleared in the rest-api?

[Gene Howard]

Sounds like you have something CASHING the response.
Are you using an API gateway or some type of load balancer that is caching the information?

If you make the REST call directly on the UMP box using the IP does it do the same thing?

------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Keith Clay]

I did check it directly on the UMP box. It fired at 03:26 am today. nas shows it as cleared.

[Gene Howard]

The API and UMP do not have any built-in cache that I know of.
What call exactly are you making?
How are you double-checking that is cleared?

------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Keith Clay]

The alarm is not showing in the nas probe.

I'm calling /rest/alarms.  The current alarm from rest api but nas shows the alarm as closed

current alarm:
<alarm>
<alarmToken>as#service.ha.restored_remot_hub_contact</alarmToken>
<devId>DBC853FC9CB941AFDE9C3FC7F6F8C0CF0</devId>
<domain>VFC</domain>
<hostname>robot</hostname>
<hub>PrimaryHA</hub>
<id>BF70126083-36905</id>
<level>1</level>
<message>Restored contact with remote Hub /DOMAIN/HUB/robot/hub</message>
<metId>M013CEAF09C91C85D6BEE2DF19A424908</metId>
<nas>PrimaryHA</nas>
<origin>PrimaryHA</origin>
<prevLevel>0</prevLevel>
<probe>HA</probe>
<robot>robot</robot>
<severity>Info</severity>
<source>IPADDR</source>
<subsystem>HA</subsystem>
<subsystemId>1.2.3.8</subsystemId>
<suppressionCount>1</suppressionCount>
<suppressionKey>HA/state</suppressionKey>
<timeArrival>2020-08-13T03:24:15-04:00</timeArrival>
<timeAssigned>1969-12-31T18:59:59.999-05:00</timeAssigned>
<timeLast>2020-08-13T03:25:25-04:00</timeLast>
<timeOrigin>2020-08-13T03:24:15-04:00</timeOrigin>
<visible>true</visible>
</alarm>

[Gene Howard]

So the rest API is not talking to the NAS probe it is doing a query on the nas_alarms table.
Is the alarm still there?
If so you have a problem with NAS synching with your back end database.
This usually has to do with large *.db files in the nas folder. This can be caused by having a large number of open alarms or alarms with high counts.
or a corrupt database.
You can check your nas loglevel 5 logs for errors with sync with the database.
It could also be an index issue on the backend NAS_* tables causing a problem.

------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Keith Clay]

All the other alarms I've cleared before and after it have cleared in rest-api and nas.  How do I remove this one from the rest api?

[Gene Howard]

The alarm is not in the rest api it is in your back end database tables.
You could be able to go into the nas_alarms table or go to USM and acknowledge it.

------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Keith Clay]

database.db is 12 mb
transactionlog is 36 mb
nisQueue is 12 kb

[Gene Howard]

I would check logs sounds like a problem with nas communicating with your back end database for some reason.

------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Keith Clay]

But this is the only one. How do I remove it from the database?

[Gene Howard]

run a delete query

------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Gene Howard]

Are you sure this is not an EMS alarm that do not by default show in NAS and only in USM?

------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Keith Clay]

It shows in nas because I cleared it in nas this morning.  Not even sure what an EMS alarm is. I deleted from nas_alarms.