Submit a ticketCall us

Solarwinds & Cisco Live! Barcelona
Join us from the 29th of January to the 2nd of February at Cisco Live 2018 in Barcelona, where we will continue to show how monitoring the network with SolarWinds will keep you ahead of the game. At our booth (WEP 1A), we will demonstrate how SolarWinds network solutions can help. As a bonus, we are also hosting a pre-event webinar - Blame the Network, Hybrid IT Edition with our SolarWinds Head Geek™, Patrick Hubbard on January 24th - GMT (UTC+0): 10:00 a.m. to 11:00 a.m. There's still time to RSVP.

Home > Success Center > Server & Application Monitor (SAM) > Disabled components still trigger alerts for Other Statuses

Disabled components still trigger alerts for Other Statuses

Overview


This article describes the issue when component status alerts are being fired for components even though the status has been set as disabled on the application level.
 

Components Disabled the Application Level

image003 (1).png

 

Alerts Still Firing at even though the Component has been disabled

 

dasda.png

Environment

SAM version 6.4 and earlier

Cause 

This is a known limitation of the Advanced Alert Manager. These disabled components triggered an alert at the time they were disabled which means, their state has not cleared from the Advanced Alert Manager. 

 

This is a known issue & currently, There are two problems which cause this to occur
1. The IsDisabled flag in APM_Component table is set to NULL
2. There is no record in APM_CurrentComponentStatus for disabled components so the Status field returns a default value 0 (Unknown) or Last polled value instead of Disabled (27).

The value from the APM_CurrentComponentStatus is used in used in alerting/reporting & thus causes the false alerts

Resolution

  1. This bug which is tracked under SAM-5818 & is addressed in SAM 6.5 which was released Q4 2017
  2. As a workaround, to fix without upgrading. This script marks all disabled components on the template level as a disabled component on the application level, where it is working properly.

 

* Please take a backup or have a backup or the Orion Database before performing this Query
* Run the below Query via SQL Server Management Studio. 

 

DECLARE @ComponentID int

DECLARE @ApplicationID int

 

DECLARE db_cursor CURSOR FOR  

SELECT c.ID, c.ApplicationID FROM APM_ComponentTemplate ct

INNER JOIN APM_Component c ON c.TemplateID = ct.ID

WHERE ct.IsDisabled = 1 AND ISNULL(c.IsDisabled, 0) = 0

 

OPEN db_cursor   

FETCH NEXT FROM db_cursor INTO @ComponentID, @ApplicationID

 

WHILE @@FETCH_STATUS = 0   

BEGIN   

 

UPDATE APM_Component SET IsDisabled = 1 WHERE ID = @ComponentID

 

UPDATE APM_ComponentSetting SET Value = 'True' WHERE ComponentID = @ComponentID AND [Key] = '__Disabled'

IF @@ROWCOUNT = 0

INSERT INTO APM_ComponentSetting(ComponentID, [Key], [Value], [ValueType], [Required])

VALUES (@ComponentID, '__Disabled', 'True', 3, 0)

UPDATE APM_CurrentComponentStatus SET Availability = 7, [TimeStamp] = GETUTCDATE(), ComponentStatusID = 0, ErrorCode = 0 WHERE ComponentID = @ComponentID

IF @@ROWCOUNT = 0

INSERT INTO APM_CurrentComponentStatus (ComponentID, ApplicationID, Availability, [TimeStamp], ComponentStatusID, ErrorCode)

VALUES (@ComponentID, @ApplicationID, 7, GETUTCDATE(), 0, 0)

 

FETCH NEXT FROM db_cursor INTO @ComponentID, @ApplicationID  

END   

 

CLOSE db_cursor   

DEALLOCATE db_cursor 

 

 

 

Last modified

Tags

Classifications

Public