Discrepancy in NPTF Jobstream Alert Counts Between AAI Environments

Products

• Automation Analytics & Intelligence

Issue/Introduction

Customers may observe a significantly higher number of "Not Predicted to Finish" (NPTF) alerts in one environment (e.g., Development) compared to another (e.g., Production) for the same jobstreams running against the same scheduler data. This can lead to:

• A perception of "false" alerts in the busier environment.
• Concerns that version differences (such as v24.3 vs v24.4) have changed the alerting logic.
• Discrepancies in SLA breach reporting between environments.

Environment

Product: Automation Analytics & Intelligence (AAI) Versions: 24.3.x, 24.4.x 

Cause

This behavior is by design and is typically caused by differences in the Jammer Cycle frequency between the two environments.

1. NPTF Alert Logic: An NPTF alert fires when AAI cannot calculate a predicted end time. AAI records the "root cause" (the specific upstream job blocking the prediction).
2. Re-fire Rule: A new NPTF alert is generated only if the root cause has changed since the last check. If the root cause is the same, the alert is suppressed to prevent duplicates.
3. Cycle Speed Impact:
   • If Environment A (Dev) has a faster Jammer cycle (e.g., 100 seconds), it will detect short-lived transitions where the blocking job flips back and forth. Each transition triggers a new alert.
   • If Environment B (Prod) has a slower Jammer cycle (e.g., 170 seconds), it may step over these transitions. By the time it checks again, the blocker may have reverted to the previous job, causing AAI to see the "same" cause and suppress the alert.
4. Environmental Factors: Production environments often have longer cycles due to higher job volumes, more complex configurations, or additional schedulers (like CA7) being active, which Dev may not have.

Resolution

No product defect exists; the alerting service is functioning correctly in both environments. The environment with more alerts is simply providing a higher resolution of the batch activity.

To verify this behavior:

1. Check Jammer Cycles: Review the jaws.log or the AAI System Settings to compare the Jammer Interval or actual cycle completion times in both environments.
2. Analyze Stable vs. Oscillating Blockers:
   • Jobstreams with a stable blocker (a job that stays in a failed/running state for hours) should show identical alert counts in both environments.
   • Jobstreams with oscillating blockers (jobs that fail/restart quickly or chains where the failure point moves rapidly) will show higher alert counts in the environment with the faster cycle.
3. Inventory Jobstreams: Ensure the higher count is not also being inflated by "Test" or "Clone" jobstreams in the Dev environment that are configured to alert but do not exist in Prod.

Workaround: If the goal is to synchronize the alert volume, the Jammer cycle speeds must be aligned. This is usually achieved by adjusting the Jammer Interval in the AAI configuration, though caution should be taken to ensure the server can handle the increased load of faster cycles.