Date: Fri, 29 Mar 2024 12:06:56 +0000 (UTC) Message-ID: <1107098970.69983.1711714016556@ip-10-0-1-26.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_69982_1347313467.1711714016555" ------=_Part_69982_1347313467.1711714016555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
In certain environments, it is ac= ceptable for some metrics to exceed the configured alert thresholds for ver= y short periods of time, for example one refresh. Typically these exception= s last less than a minute. If you are monitoring many SQL Server insta= nces or if the amount of data collected is very high, this could produce a = significant number of alerts. The Advanced Alert Configuration window allow= s you to limit the number of these alerts that are generated by letting you= input the number of minutes a threshold violation occurs before an alert i= s raised, reducing the amount of alert "noise" you receive.
The amount of time you enter here depends= on how critical the metric is in your environment and the amount of time S= QL Diagnostic Manager waits between refreshes. If you enter a time less tha= n that of the refresh, the second consecutive refresh where the alert is ou= tside the acceptable threshold range prompts the alert.
The following table displays the length o= f time SQL Diagnostic Manager waits before an alert is raised when the sche= duled refresh occurs every six minutes and various values are entered:
Time enter= ed on the Advanced Alert Configuration window |
Alert is g= enerated |
---|---|
1-5 minutes |
Second Refresh occurs six minutes after the f= irst encounter of the problem |
6-11 minutes |
Third Refresh occurs 18 minutes after the fir= st encounter of the problem |
12-17 minutes |
Fourth Refresh occurs 24 minutes after the fi= rst encounter of the problem |