This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Custom SQL alert not resetting

We have three SEUM playback sites.  When all 3 sites agree that a URL is down (Steps 1 or 2 of the transaction), we want to raise an alert.  The custom SQL below checks for that condition and only returns rows when specific transactions are "down" from all 3 locations.  I've confirmed that the query returns blank when things are online, and returns rows when URLs are down - one row for each failed transaction, so sometimes multiple rows are returned.  When we use this query as a Trigger Condition, the Reset Condition never fires when the URL comes back online ("Reset when trigger conditions are no longer true").  The alert remains in the console indefinitely, even though the SQL query returns blank (confirmed independently in SQL Mgmt Studio).  Why won't this alert reset?

 

SELECT SEUM_TransactionsAlertsData.TransactionId AS NetObjectID, SEUM_TransactionsAlertsData.Name AS Name FROM SEUM_TransactionsAlertsData

WHERE 

(

SELECT COUNT(DISTINCT tad.TransactionId) AS FailingTransactionsOnFirstStep

FROM SEUM_TransactionsAlertsData tad JOIN SEUM_TransactionStepsAlertsData tsad

 ON tad.TransactionId = tsad.TransactionId

JOIN SEUM_RecordingSteps rs

 ON rs.StepId = tsad.StepId

WHERE tsad.Status in (0,2)

AND tad.RecordingId = SEUM_TransactionsAlertsData.RecordingId

AND rs.StepOrder in (1,2)

SELECT COUNT(DISTINCT tad2.TransactionId) AS AllTransactions

FROM SEUM_TransactionsAlertsData tad2 

WHERE tad2.RecordingId = SEUM_TransactionsAlertsData.RecordingId

)

AND SEUM_TransactionsAlertsData.TransactionId = (

SELECT MIN(tad3.TransactionId) AS FirstTransaction

FROM SEUM_TransactionsAlertsData tad3

WHERE tad3.RecordingId = SEUM_TransactionsAlertsData.RecordingId

)

 

  • Hello cdenuyl,

    The SQL query you are using is quite complex so you will need to set also a reset query for this particular alert. Following SQL query should do the work:

    WHERE  NOT ((SELECT COUNT(DISTINCT tad.TransactionId) AS FailingTransactionsOnFirstStep
                 FROM   SEUM_TransactionsAlertsData AS tad
                        INNER JOIN
                        SEUM_TransactionStepsAlertsData AS tsad
                        ON tad.TransactionId = tsad.TransactionId
                        INNER JOIN
                        SEUM_RecordingSteps AS rs
                        ON rs.StepId = tsad.StepId
                 WHERE  (tsad.Status IN (0, 2)
                         AND tad.RecordingId = SEUM_TransactionsAlertsData.RecordingId
                         AND rs.StepOrder IN (1, 2))) = (SELECT COUNT(DISTINCT tad2.TransactionId) AS AllTransactions
                                                         FROM   SEUM_TransactionsAlertsData AS tad2
                                                         WHERE  (tad2.RecordingId = SEUM_TransactionsAlertsData.RecordingId))
                AND SEUM_TransactionsAlertsData.TransactionId = (SELECT MIN(tad3.TransactionId) AS FirstTransaction
                                                                 FROM   SEUM_TransactionsAlertsData AS tad3
                                                                 WHERE  (tad3.RecordingId = SEUM_TransactionsAlertsData.RecordingId)))

     

  • At the bottom of that screenshot, I see the "exists for more than 0 seconds" field.  Is that the recommended value (0 seconds) for both the Trigger and Reset Conditions?  When we submit a new playback, often a false alert is triggered with incomplete info (SEUM ALERT: All Logins failed for ${Name}).  I'm guessing it's because the playback is saved to the DB as you navigate the wizard?  I wonder if false alarms would be mitigated by increasing the Trigger Condition to 1 minute?

  • Hello Christian,

    false alert is triggered because you have "WHERE (tsad.Status IN (0, 2)" in your query. Status "0" is "Unknown" and this is status that all new transactions or steps get when they are added. After first playback it's changed to real status received from playback.

    In your case I think you could remove "0" from condition because you care about "Down" steps, not "Unknown".

  • Thanks Lukas, your SQL query fixed our stuck alerting issue.  I greatly appreciate it.

    Thanks also to Jiri - I will look into alternatives re: Unknown status.  Currently we include Unknown to defend against the loss of a playback location.  The "all 3 must agree" logic won't fire if only 2 sites can detect the Down status.  We are looking at N+1 playbacks to mitigate this risk.

  • Jiri,

    The above query is the one you helped me create on our initial deployment. The reset logic appears to work so thank you for helping out once again.

    Is there anything on the roadmap to build in some of this logic as default alert actions?

    I would assume other clients would see the value in the ability to have alerts trigger only when multiple playback sites are in agreement as to the external status of a recording.

    If this could be built it to the product it would reduce a great deal of confusion for our end users.

  • I will work with Jiri and Lukas to create an Advanced Alert for this scenario and post it to Thwack. Based on feedback we may consider adding it to the next release of SeUM as well. However this type of logic in the Advanced Alert Manager though the pick list is not something that's currently possible for any Orion product currently. For example, if you wanted to be alerted only when all your Exchange Servers were down in APM, not just one, this is not possible using the logic builder wizard included in the Advanced Alert Manager today. This would need to be done using an Advanced SQL Alert similar to the one Lukas provided.