---
# System prepended metadata

title: <center><i class="fa fa-edit"></i> RIC Alarm System</center>
tags: [RIC]

---

# <center><i class="fa fa-edit"></i> RIC Alarm System</center>
###### tags: `RIC`

:::warning
**References:**
- [RIC Alarm System from O-Ran Wiki](https://wiki.o-ran-sc.org/display/RICP/RIC+Alarm+System)
- [RIC Alarm System from O-Ran Docs](https://docs.o-ran-sc.org/projects/o-ran-sc-ric-plt-alarm-go/en/latest/user-guide.html#ric-alarm-system)
:::

## Overview
RIC alarm system consists of three components: Alarm Manager, Application Library and Command Line Interface.

Architecture of RIC Alarm System:
![](https://i.imgur.com/Wl9KTMo.png)

	


**The Alarm Manager** is responsible for managing alarm situations in RIC cluster and interfacing with Northbound applications such as Prometheus Alert Manager to post the alarms as alerts. Alert Manager takes care of de-duplicating, silencing and inhibition (suppressing) of alerts, and routing them to the VES-Agent, which, in turn, takes care of converting alerts to faults and sending them to ONAP as VES events.

**The Alarm Library provides** a simple interface for RIC applications (both platform application and xApps) to raise and clear alarms. The Alarm Library interacts with the Alarm Manager via RMR interface.

---
## Alarm Manager
The Alarm Manager listens alarms coming via RMR and REST interfaces. 

An application can raise or clear alarms via either of interfaces. Alarm Manager listens also commands coming from CLI (Command Line Interface). 

In addition Alarm Manager supports few other commands that can be given through the interfaces. 
Such as: 
- List active alarms 
- List alarm history
- Add new alarms definition
- Delete existing alarm definition 
- Re-raise alarms
- Clear all alarms. 
 
Those are not typically used by applications while running. Alarm Manager itself re-raises alarms periodically to keep alarms in active state. The other commands are can be used through CLI interface by operator or are used when applications is starting up or restarting.

Maximum amount of active alarms and size of alarm history are configurable.**By default**, the values are **Maximum number of active alarms = 5000, Maximum number of alarm history = 20,000.**

Alarm definitions can be updated dynamically via REST interface. Default definitions are read from JSON configuration file when FM service is deployed

---
## Alarm Library

The Alarm Library provides simple interface for RIC applications (both platform application and xApps) to raise and clear alarms. A new alarm instance is created with **InitAlarm()**-function. ManagedObject (mo) and Application (ap) identities are given as parameters for Alarm Context/Object

The Alarm object contains following parameters:
- **SpecificProblem**: problem that is the cause of the alarm. Example value: 8007.
- **PerceivedSeverity**: The severity of the alarm. Possible values: possible values: UNSPECIFIED, CRITICAL, MAJOR, MINOR, WARNING, CLEARED or DEFAULT
- **ManagedObjectId**: The name of the managed object that is the cause of the fault. Example string: RIC
- **ApplicationId**: The name of the process raised the alarm.  Example string: UEEC
- **AdditionalInfo**: Additional information given by the application.
- **IdentifyingInfo**: Identifying additional information, which is part of alarm identity. Example string: INFO-1example string: INFO-1

:::success
ManagedObjectId (mo), SpecificProblem (sp), ApplicationId (ap), and IdentifyingInfo (IdentifyingInfo) make up the identity of the alarm.
:::


All parameters must be according to the alarm definition, i.e. all mandatory parameters should be present, and parameters should have correct value type or be from some predefined range. Addressing the same alarm instance in a clear() or reraise() call is done by making sure that all four values are the same is in the original raise() / reraise() call.

Alarm Manager does not allow raising “same alarm” more than once without that the alarm is cleared first. Alarm Manager compares ManagedObjectId (mo), SpecificProblem (sp), ApplicationId (ap) and IdentifyingInfo (IdentifyingInfo) parameters to check possible duplicate. If the values are the same then alarm is suppressed. If application raises the “same alarm” but PerceivedSeverity of the alarm is changed then Alarm Manager deletes the old alarm and makes new alarm according to new information.

---
### Command Line Interface
Through CLI operator can do the following operations:
- Check active alarms
- Check alarm history
- Raise an alarm
- Clear an alarm
- Configure maximum active alarms and maximum alarms in alarm history
- Add new alarm definitions that can be raised
- Delete existing alarm definition that can be raised

---
:::info
#### Additional Information:
[RIC Alarm System Source Code](https://gerrit.o-ran-sc.org/r/gitweb?p=ric-plt/alarm-go.git;a=tree;hb=refs/heads/master)
:::
