Chat now with support
Chat with Support

Foglight for Integrations 5.9.8 - User Guide

Using Foglight for Integrations Reference

Clearing Alarms

Alarms from third-party systems may provide start and end times for their alarms. These start and end times fed into Foglight are stored in the user-defined properties of the alarm. By default, any alarm being processed with an end time in the user-defined properties, are not cleared (this occurs when the Auto_Clear_Integration_Alarms_with_EndTime registry variable is set to false).

In certain instances, a third party may send an alarm with an end time in the future. This occurs when the technology monitor is unable to provide an indication that an alarm condition is no longer occurring. However, the third-party systems check again and send another alarm if the condition is still occurring. For example, a condition is checked every 15 minutes. If at 12:00 A.M. the condition is true, an alarm is sent with a start time of 12:00 A.M. and an end time of 12:15 A.M.. The end time is 12:15 A.M. because the condition is checked again at that time and if still true, another alarm is sent.

In Foglight, we may not want to automatically clear the alarm because the user would never see the alarm in the browser and know that it is occurring. We also do not want the user to have to manually clear all these alarms.

To automate the clearing of future dated alarms, the registry variable, Auto_Clear_Integration_Alarms_with_EndTime, can be changed. The default value is false. When true, the alarm with a user-defined end time is cleared automatically when the alarm is first received. When set to false, any alarm with a user-defined end time is not cleared in that manner. Otherwise, these must cleared using the user interface or by using the new Clear Integration Alarm Rule. This new rule is disabled by default. When enabled, this rule runs every five minutes. This rule looks for third-party alarms with an end time in the past that have not been cleared, and then clears the alarm. This keeps the alarm in the browser until the end time is reached.

1
On the navigation panel, under Dashboards, click Administration > Rules and Notifications > Manage Registry Variables.
2
Click Auto_Clear_Integration_Alarms_with_EndTime.
For more information on how to edit registry variables, see the Foglight Administration and Configuration Guide.

Processing Alarms

The processing of third-party alarms manages the updates made to the user-defined properties.

Table 2. Alarms

New

 

Warning, Critical or Fatal (2 - 4)

No

Single alarm received with no endtime. Severity is anything from 2 to 4

1 alarm created.

1 action fired.

 

The creation of a new alarm.

New

 

Warning, Critical or Fatal (2 - 4)

No

Single alarm with a start and endtime.

1 alarm created.

 

Alarm is cleared if registry variable specifies to do so.

1 or 2 actions fired.

 

The first action is for the alarm creation. If the registry variable specifies to clear alarms with end times, then a second action is fired.

New

 

Normal (0)

No

Single alarm received with no endtime. Severity is 0, which both map to Normal.

Ignored

None

Update

 

Warning, Critical or Fatal (2 - 4)

No

Update alarm comes in to update user-defined data on existing non-cleared alarm. Severity is the same as previous alarm.

Updates to user-defined data on original alarm.

1 action fired.

 

Update user-defined data.

Update

 

Warning,

Critical or Fatal (2 - 4)

Yes

Update alarm comes in to update user-defined data on existing non-cleared alarm. Severity is different from previous alarm.

Closes out previous alarm.

Creates alarms.

 

Old alarm user-defined data remains unchanged.

2 actions fired.

 

Closing old.

Alarm creation of new alarm.

Update

 

Warning,

Critical or Fatal (2 - 4)

No

Update alarm comes in that closes existing non-cleared alarm. New alarm has the same severity as original alarm.

User-defined data on original alarm updated. Alarm cleared if registry variable set.

1 or 2 actions fired.

 

One for the update of user-defined data. One for the clear if the registry variable is set.

Update

 

Warning,

Critical or Fatal (2 - 4)

Yes

Update alarm comes in that closes existing non-cleared alarm. New alarm has a different severity than original alarm.

Clears previous alarm, creates new non-cleared alarm. Alarm properties stored on new alarm only. New alarm is cleared if registry variable is set. Previous alarm user-defined data untouched.

2 or 3 actions fired.

 

The first two actions clear the old alarm, and creates an alarm. The optional third is if the new alarm is automatically cleared per the registry variable setting.

Update

 

Normal (0)

Any

Update alarm that sets severity to 0, which both map to Normal.

Clears previous alarm. New incoming alarm data is discarded.

1 action fired.

 

Old alarm clear.

UI — Acknowledge

No

User acknowledges alarm in the browser.

Alarm is marked as acknowledged.

1 action fired.

 

Acknowledgment of the alarm.

UI — Clear

No

User clears alarm in the browser.

Alarm is marked as cleared and no longer shows up in the browser.

1 action fired.

 

Clearing of the alarm.

Working with Configuration Items

Any monitored object coming from an external source is considered a configuration item. A Configuration Item is anything that can be monitored. For example, a host, a database, a memory component, or a CPU. The hierarchy is not pre-defined. If an event consolidator sends an event tracking an interface on a switch, a Configuration Item is created for that interface. If the Event Consolidator sends information about the switch and the relationship between the switch and the interface, then two Configuration Items are created: one for the switch and one for the interface. In addition, the “detail” property (which is inherited in the model) of the switch is set to the interface, allowing Foglight to understand that some Configuration Items are “parents” to other Configuration Items.

Each Configuration Item is unique. It has a combination of technology monitor and sourceId. The number of Configuration Items that are created depends on the types of systems sending alarms into Foglight. If two different technology monitors manage the same Configuration Item (a server for example), two different Configuration Items are created. If a technology monitor manages a Configuration Item which is the same as a device Foglight manages (and appears in the Host model), it creates a unique Configuration Item.

Foglight for Integrations provides the Foglight Administrator the capability of defining CI Properties using the CI Property view. In this view, the Administrator can define a new property along with Type and Is List options.

NOTE: In a federated environment, it is important to keep CI Properties consistent between federated Management Servers. For example, if one federated Management Server has a property called External asset id that is a type of Integer and Is List, other federated servers should have a property called External asset id that is a type of Integer and Is List. CI Properties must be consistent across federated servers.

Reviewing the Property Details of a Configuration Item

For details on the state of the Configuration Item, click the down arrow on the Additional Details view.

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating