Alarms

Alarms are indicators of abnormal conditions such as disk I/O overload or excessive packet drop rate generated by RMM/NMS systems.

Nextian RMM can bring a selection of the most important alarms from monitoring systems into Salesforce to help the following teams:

  • Account management — which services are currently experiencing alarms? What is the total affected revenue?
  • Product management — what products currently and historically experiencing alarms?
  • NOC/Support — which services are affected by alarms on elements/devices shared by multiple services?
Since an element in Salesforce can be used as a building block for multiple services, therefore a single alarm in Salesforce can affect multiple services. This enables Nextian to calculate the affected MRR for each alarm — information that is not typically available in RMM/NMS systems.

Alarms in Salesforce are a simplified representation of RMM/NMS alarms. Due to storage and usability requirements, only the most important alarms are brought over to Salesforce along with a strict retention policy.

Nextian does not bring NMS/RMM events — only alarms.

Salesforce alarm contains the following information (Alarm__c object):

FieldMeaning
ElementAn element for which the alarm was generated (element alarms are also displayed in service alarm roll-ups). The relationship between Element and Alarm is implemented as master-detail; alarms are automatically deleted from Salesforce when their parent element is deleted.
NameBrief description of the alarm, e.g., Temperature alarm (180°F exceeded)
External IdAlarm identified in the NMS/RMM system (a unique identifier, dependent on the type of NMS/RMM integrated).
SeverityNextian follows syslog (RFC5424) convention for alarm severities, with additional Summary code:

  • Emergency (0): system is unusable
  • Alert (1): action must be taken immediately
  • Critical (2): critical conditions
  • Error (3): error conditions
  • Warning (4): warning conditions
  • Notice (5): normal but significant condition
  • Informational (6): informational messages
  • Debug (7): debug-level messages
  • Summary (8): summary
StatusAlarm status:

  • Active alarm has been generated and the condition that caused the alarm still persists, e.g., temperature is out of acceptable range,
  • Cleared the condition that caused the alarm is no longer present, e.g., temperature dropped to acceptable levels.
Generated OnDate and time when alarm was generated in the NMS/RMM.
Cleared OnDate and time when alarm was cleared in NMS/RMM.
DurationHuman-readable alarm duration calculated as a difference between when the alarm was created and cleared (for cleared alarms) or now (for active ones), e.g., 11 days 0hr 28 mins.
Duration (hr)Alarm duration in hours (it is a decimal field, e.g., 15 minutes is 0.25 hrs).
Age (hr)Interval between time that the alarm was created and current, regardless of alarm status (in hours with fraction, e.g., 1hr 15min is 1.25), for active alarms it will is equal to duration. Typically used for filtering (e.g., active alarms older than 1 hour).
DescriptionOptional, RMM/NMS-provided, additional alarm description (multi-line text).
Additional InformationOptional, RMM/NMS-provided, additional information about the alarm, e.g., a list of OIDs, etc. (multi-line text).
AcknowledgedIf alarm is acknowledged, it means that a NOC/support technician has seen the alarm in started acting on it. This is a read-only field carried over from the RMM, to help account managers gain better visibility into issue resolution progress
Acknowledged OnDate and time when alarm was acknowledged in NMS/RMM system. This field is read-only and is updated from the NMS/RMM.
Acknowledged ByRMM/NMS user name that acknowledged the alarm. This field is read only and synchronized from the NMS/RMM. The value is copied as text, as NMS/RMM users will not necessarily be the same as Salesforce users.
Active ServicesAuto-calculated, number of active services (i.e., services in ‘In Service’ status) using the element that the alarm was generated against (i.e., how many services are affected by the alarm).
Active AccountsAuto-calculated, number of distinct accounts that have active services (i.e., services in ‘In Service’ status) using the element that the alarm was generated against (i.e., how many accounts are affected by the alarm).
Active MRRAuto-calculated, sum of MRR for active services (i.e., services in ‘In Service’ status) using the element that the alarm was generated against (i.e., how much revenue is affected by the alarm).

Even though alarms are read-only they are widely used:

  • On service and element details views (alarm timeline)
  • Alarm statistics available on accounts, locations and product details
  • Reports and dashboards
  • List views (e.g., Accounts With Active Alarms)
Was this page helpful?