Troubleshooting: Alarm Not Generated for Threshold Violation

Troubleshooting: Alarm Not Generated for Threshold Violation

When a monitor attribute exceeds its defined threshold but fails to generate an alarm, the cause is usually related to data collection gaps, retry logic, or suppression rules. Follow these steps to diagnose the issue.

Step 1: Verify Data Collection Status

An alarm cannot be triggered if the system is not successfully collecting data for the attribute.

  • Action: Navigate to the Monitor Details page and check the Polled Data for the specific attribute.

  • Verification: Ensure there are no gaps in the data timeline during the period the violation occurred. If data is missing, troubleshoot the monitor's connectivity or credentials first.

Step 2: Check Probe-Level Association

In distributed architectures, the threshold must be correctly synchronized and associated at the Probe server level.

  • Action: Log into the Probe server UI.

  • Verification: Confirm that the Threshold Profile is actively associated with the monitor attribute specifically on the Probe where the monitor resides.

Step 3: Review "Polls to Retry" Logic

If the customer has configured retries, alarms will only be triggered after the specified number of consecutive threshold violations.

How to check at the Global Level:

  1. Go to Settings → Action / Alarm Settings

  2. Scroll to the bottom of the page

  3. Check the value configured for Consecutive Polls Count

How to check at the Threshold Profile Level:

  1. Go to View Thresholds

  2. Select the configured threshold

  3. Enable Show Advanced Options

  4. Check the Polls to Try value for each severity (Critical, Warning, Clear)

Note: If “Polls to Retry” is enabled, a single violation will not immediately generate an alarm. The threshold must be breached continuously for the configured number of polls.

Step 4: Inspect Health attribute Dependencies

If the monitor's overall Health is configured to depend on specific attributes, a misconfiguration here can suppress alarms.

  • Action: In the Probe server, check the Dependent Attribute List for the monitor's Health attribute.

  • Verification: Ensure the dependency rule is set to "Depends on any 1 selected attributes" and that your specific attribute is included in that selection.


Step 5: Audit Business Hour Constraints

Thresholds can be tied to specific Business Hours. If a violation occurs outside of these hours, the system is designed to ignore the event.

  • Action: Open the Threshold Profile configuration.
  • Verification: Check if a "Business Hour" is selected. If so, verify if the expected alert time fell within an "Off-Hour" period.

Information to Collect for Developer Analysis

If the configuration is correct but alarms still fail to generate, collect the following data for the development team:
  1. Poll Data Report: A screenshot or export of the attribute's polled data during the time the alert was expected.

  2. Probe Association Proof: A screenshot from the Probe Server showing the threshold association to the attribute.

  3. Threshold Config: A screenshot of the entire Threshold Edit page (ensure "Advanced Options" are visible).

  4. Debug Logs: * Enable 'Print all Logs' in settings.

    • Perform a manual "Poll Now" for the monitor.

    • Once the poll completes, generate and download the latest log zip.

                  New to ADSelfService Plus?