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.

Can you pass data/variables between alert conditions?

Let's say the Primary Section Alert Condition for the Alert trigger is what I initially care about in terms of identifying nodes I want to alert on.

Then let's say I enable complex conditions and in the Secondary Section I want to look at those identified nodes from the Primary Section, and maybe use them in a custom SWQL Alert... 

Can you pass data/variables between alert conditions?

  • I haven't done it but it seems possible, have you tried? You could probably just as easily write the whole alert in SWQL?

  • How complex is the condition in your primary section? If you're expecting to write the secondary section as a custom SWQL alert, you're probably best off writing the alert condition as a single SWQL query. 

    Can you describe the primary and secondary conditions here? 

  • The idea is to have the primary conditions be any legitimate alert, secondarily to then check if the node in question already has an active unacknowledged alert. I have the SWQL for the secondary and obviously since this should work for any Node based trigger, for it to work the secondary section would need to know which node to use in the query to search for.

    Since you cannot query on alerts it has to be done via SWQL. The purpose of this would be to say, for example, CPU on a server hit threshold X and triggered an alert, then a 2nd alert for a higher threshold for CPU's you can check for the existence of the lesser alert. Maybe you want to escalate the first rather than cut another ticket. This would allow for that to happen.

    Today you can escalate in an alert but the criteria is the same as the initial trigger and the escalation is time based. Really it comes down to changing severity of an already cut ticket, or, checking to see if an alert was previously run with the TriggeredDateTime and do something based on that.

    I'd prefer to keep it separate too because then we can use the logic from the gui primary section.

    The SWQL, should you be interested in testing it looks something like this:

    join Orion.AlertDefinitions ad on ad.Name = nodes.AlertObjects.AlertConfigurations.Name
    where  nodes.AlertObjects.AlertActive.TriggeredDateTime is not null and nodes.AlertObjects.AlertActive.Acknowledged is null and ad.Name = '[NW] - Bananas for Testing these damn monkeys!!!!'

  • Anyone know if this is possible to pass data/variables between conditions whether they be alert conditions or trigger conditions? That would be useful if you needed to formulate something and massage some data then use it in the next condition/step...

  • You can use a subquery in the custom SWQL bit to do what you describe, can be a bit fiddily to work with.

    Your use case sounds like you're trying to get alerting levels into the product, i think, I've not seen anyone do this without getting another tool involved. Seems possible, though will make your alert fairly hard to understand for a newbie, recommend adding a lot of comments.

    I think in practice you'd want to select from the layer you eventually care about (nodes here), then specifically right or left join a subquery to white/blacklist the stuff you do/dont care about