Submit a ticketCall us

Quickly Address Software Vulnerabilities
Patch Manager is an intuitive patch management software which extends the capabilities of WSUS and SCCM to not only patch Windows® servers and workstations, and Microsoft® applications, but also other 3rd-party applications which are commonly exploited by hackers. Learn more about our patch management solution.

 

Home > Success Center > Engineer's ToolSet (ETS) > Engineer's Toolset Administrator Guide > Tools Reference > Network Performance Monitor > Alert suppression

Alert suppression

Created by Aileen de Lara, last modified by Aileen de Lara on Jan 12, 2017

Views: 8 Votes: 0 Revisions: 3

Error conditions in a network can trigger multiple alerts from a single event. Likewise, some network issues may not need to trigger an alert if they occur alone, but should trigger an alert if they occur with other conditions. Alert suppression can create conditions that take into account complex situations, and alert you with the information you need to determine the root cause of the problem.

By design, alert suppression is not configured by default. Before enabling alert suppression, review the following guidelines:

  • Give considerable thought to each scenario and the ways in which alert-triggering events can occur.
  • Work with a diagram of your network.
  • Extensively test any scenario to which you apply suppression.

Proceed with caution when configuring the alert suppression. It is possible to suppress important alerts on the status of your network.

There are two choices for activating Alert Suppression:

  • Suppress the alert if any of one or more conditions exist.
  • Suppress the alert if all of two or more conditions exist.

Review the following scenarios for help with understanding when to create alert suppression rules. The location of the Toolset Network Performance Monitor computer is integral to these examples.

Failure of redundant servers

Review the following diagram. Both WServers are identical in order to provide fail over, redundancy, and load balancing. If WServer4 fails and the other server is still functioning, you may want to be alerted immediately during business hours, but not paged in the middle of the night. In this case, configure the alert for the failure of one WServer to be suppressed unless the other also fails.

File:Success_Center/New_Articles/ETS-MindTouchForReuse/050/0P0/0M0/03000023_455x184.png

Apparent failure of dependent nodes downstream of a failed device

In the following diagram, dependencies exist among devices. If Router C fails, Switch 3 and all four Workstations become unreachable by NPM. You want to know that the Workstations have failed, but only if Router C and Switch 3 have not failed. Configure the alerts for failure of the Workstations to depend on Router C and Switch 3 being operational.

File:Success_Center/New_Articles/ETS-MindTouchForReuse/050/0P0/0M0/03000024_455x184.png

Failure of a network link when a redundant link remains functional

In reference to the previous diagram, during some hours, you may want to be notified of the failure of the link between Router B and Router C only if the alternative link through Router A is also down.

Failure of load balancing between devices

If you configured your network to balance traffic across your web servers, consider configuring an alert that notifies you of very high CPU utilization only if one or more is experiencing much lower usage.

File:Success_Center/New_Articles/ETS-MindTouchForReuse/050/0P0/0M0/03000025_455x184.png

The suppression of Alerts does not preclude knowledge of critical events. Network events will still be logged in the database whether or not alert suppression is enabled.

 
Last modified
17:39, 12 Jan 2017

Tags

Classifications

Public