SAM PowerShell Component Alert Does Not Trigger Correctly When Using Exit Codes and Thresholds

Overview of Working Configuration

The goal is:

• Up / OK when the newest file for today exists and has size = 0.
• Warning (and an alert) when the newest file for today exists and has size > 0.
• Other scenarios (e.g., older file) are handled separately or treated as OK for this particular alert.

Final, supported design:

1. PowerShell script uses only two clear exit codes:

$filesize    = $file.Length
$FileIsDate  = $file.LastWriteTime.Date
$shouldbedate = (Get-Date).Date

# Logic processing
if ($FileIsDate -eq $shouldbedate -and $filesize -eq 0) {
    Write-Host 'Statistic.FileMonitor: 0'
    Write-Host 'message: good — no files found with size > 0'
    Exit 0          # Up
}
elseif ($FileIsDate -eq $shouldbedate -and $filesize -gt 0) {
    Write-Host 'Statistic.FileMonitor: 2'
    Write-Host "message: File has non-zero size: $filesize"
    Exit 2          # Warning
}

2. Script Output / thresholds:

• Script Output #1 Unique ID: FileMonitor
• Statistic.FileMonitor values:
  • 0 = OK
  • 2 = Bad (non‑zero size)
• Thresholds:
  • Warning threshold: equal to 2
  • (Optionally Critical also = 2 or left blank)
• No thresholds on 0 (so FileMonitor = 0 remains Up).

3. Alert definition (component‑level):

• Object type: Component
• Scope: the specific Windows PowerShell component (Facets BPaaS Eligibility File Size) on the target node.
• Trigger condition (recommended):
  • Component Status is equal to Warning
    (since only the “non‑zero size” branch returns Warning),
    or, equivalently:
  • Component Status is not equal to Up
    (when only that one condition can be non‑Up).
• Reset condition: when the trigger condition is no longer true (component returns to Up).
• Evaluation interval: 1–5 minutes (e.g., “Check trigger conditions every 1 minute”).

Multiple configuration issues combined:

1. Exit codes vs. thresholds conflict

   • The PowerShell script set both:
     • Exit codes (0/1/2) to drive status, and
     • Statistic.FileMonitor values with Warning/Critical thresholds that does not align with those values (e.g., Warning threshold set to 0, which is actually the “good” value).
   • This causes the component status to be overridden or mis‑interpreted (e.g., a healthy FileMonitor = 0 being treated as Warning).

2. Alert trigger does not match actual status

   • The alert trigger is configured as:
     • Component Status = Up or Component Status = Down (Status = 1) in the XML,
   • While the PowerShell monitor, after thresholds, produces Warning (2) or Critical (3) for the “bad” condition.
   • Result: the alert engine evaluates the rule and finds 0 matching objects, so the alert never fires.

3. Alert disabled / long evaluation interval

   • The alert may be configured as:
     • <Enabled>false</Enabled> and
     • <Frequency>PT1H</Frequency> (checked only once per hour),
   • So even correct status changes during short 10–15 minute test windows are never evaluated.

Resolution

Follow these steps to create a clean, supported configuration.

1. Use a single status model per component

Pick one of these models and stay with it:

• Exit‑code model (recommended in this case)

  • Use Exit 0/1/2/3 to set Up/Down/Warning/Critical.
  • Thresholds must match the chosen values or be left blank.

• Threshold model

  • Always Exit 0.
  • Use the statistic (for example, Statistic.FileMonitor) plus thresholds to define Warning/Critical.

Do not use conflicting rules from both models at the same time.

2. Align script exit codes with the alert condition

For the example Facets BPaaS monitor:

• “OK / empty file for today” → FileMonitor = 0, Exit 0 (Up)
• “Bad / file for today has data” → FileMonitor = 2, Exit 2 (Warning)

All other cases for this alert should also use Exit 0.

3. Align thresholds with the statistic (if thresholds are used)

In Script Output #1 (Unique ID: FileMonitor):

• Warning threshold: equal to 2
• Critical threshold: optional equal to 2 or left blank
• No thresholds on 0 (so FileMonitor = 0 remains Up).

4. Fix the alert trigger

Create or edit a component‑level alert:

• Object type: Component
• Scope: That specific Windows PowerShell component (Facets BPaaS Eligibility File Size) on the node.
• **Trigger condition:** one of:
  • Component Status is equal to Warning (for Exit 2)
    – or –
  • Component Status is not equal to Up (when this is the only non‑Up scenario)
• Reset condition: When trigger condition is no longer true (component returns to Up).
• Check trigger conditions every: 1–5 minutes (e.g., 1 minute).

Confirm via an exported XML of the alert that:

• Warning is represented as Status = 2 (and Critical as Status = 3 if used), not Status = 1.

Example Working Configuration (Facets BPaaS File Size)

Script: as shown in the Error Code section above.

Script Output / Thresholds:

• Statistic.FileMonitor: 0 → Up (no threshold hit)
• Statistic.FileMonitor: 2 → Warning (threshold hit and/or exit code 2)

Alert:

• Object type: Component
• Scope: that File Size PowerShell component
• Trigger: Component Status = Warning
• Reset: when condition no longer true
• Interval: 1 minute

Verification

After applying the changes:

1. On Component Details → Last XX polls:

   • Bad condition (file for today has data):
     • Status = Warning, FileMonitor = 2, message shows non‑zero size.
   • Good condition (file cleared / size 0):
     • Status = Up, FileMonitor = 0, “good” message.

2. On Alerts & Activity → Alert History:

   • The alert triggers when the component is Warning.
   • The alert resets when the component returns to Up.

Notes

• If you need to alert on additional conditions (for example, “file missing” or “file older than today”), create separate SAM components and alerts dedicated to those scenarios. This keeps each monitor and alert simple, reduces overlap, and helps avoid false positives.