Does the Orion Alert Manager build bad SWQL code?

Thank-you for reading this post with the Clickbait-esque title but I do have a legitimate concern about the SWQL that is generated for an alert using a SAM component by the Orion alert manager.

First, the scope of the alert is a SAM component. That appears to be important as I look at other alerts for NPM-specific data and didn't see the malformed code.

Second, I am not a SWQL (or SQL) expert by any extent so this may be a false alarm but I'm pretty good a copy/paste so I don't think so.

Third, the alert logic follows the best practice of separating scope conditions from the trigger conditions. I don't know if that matters but it might.

The Scope of the Alert

The Actual Trigger Condition

Because I wanted to validate the alert logic in SWQL Studio I clicked on the drop down on the top green bar and selected 'Show SWQL'

When I pasted the logic into SWQL Studio is looked like this but it wouldn't run.

SELECT E0.[Uri], E0.[DisplayName]FROM Orion.APM.Component AS E0 WHERE ( ( ( E0.[Application].[ApplicationAlert].[ApplicationName] = 'Windows_OS' ) AND ( E0.[ComponentAlert].[ComponentName] = 'Win_Processor_Queue_Len' ) AND ( E0.[Application].[CustomProperties].[a_mute] = '0' ) AND ( E0.[Application].[Node].[CustomProperties].[n_mute] = '0' ) AND ( E0.[Application].[Node].[CustomProperties].[n_ResourceAlerts] = 'App' ) AND ( E0.[Application].[Node].[CustomProperties].[n_AppGroup] IS NOT NULL ) AND ( E0.[Application].[Node].[CustomProperties].[n_CPUCount] IS NOT NULL ) AND ( ( E0.[Application].[Node].[CustomProperties].[n_sn_environment] = 'Prod' ) OR ( E0.[Application].[Node].[CustomProperties].[n_sn_environment] = 'Production' ) OR ( E0.[Application].[Node].[CustomProperties].[Prod_State] = 'PROD' ) ) AND ( NOT ( E0.[Application].[Node].[CustomProperties].[n_sn_site_id] LIKE 'EC0%' ) AND NOT ( E0.[Application].[Node].[CustomProperties].[IDMLocationCode] LIKE 'EC0%' ) ) ) AND ( ( ( E0.[Application].[Node].[CustomProperties].[CPU_Crit] IS NULL ) AND ( E0.[Application].[Node].[CPULoad] >= 'Win_Processor_Queue_Len'0 ) AND ( E0.[MultipleStatisticData].[NumericData] > E0.[Application].[Node].[CustomProperties].[n_CPUCount] ) ) OR ( ( E0.[Application].[Node].[CustomProperties].[CPU_Crit] IS NOT NULL ) AND ( E0.[Application].[Node].[CPULoad] >= E0.[Application].[Node].[CustomProperties].[CPU_Crit] ) AND ( E0.[MultipleStatisticData].[NumericData] = E0.[Application].[Node].[CustomProperties].[n_CPUCount] ) ) ) )

The code turns the error

When I looked closer I saw this:

I tried removing the 0 thinking that it was an errant character but then I get the following error:

Am I doing something wrong or is Orion messing with me?

Find more posts tagged with

Alert

orion

SWQL

SWQL Studio

Accepted answers

All comments

jbiggley

I made a few small changes but I am still seeing an issue. Most notable is that the SWQL behind this alert is NOT capturing the appropriate values in the trigger conditions clause.

Here is the updated condition blocks built primarily so that it is easy to read for admins -- but it is only a snippet:

Here is a snapshot of the SWQL below. Notice that the component name is NOT being converted correctly. I've bolded them below. I will be opening an incident with support.

AND ( ( E0.[ComponentAlert].[ComponentName] = '0'0 ) AND ( E0.[ComponentAlert].[StatisticData] > E0.[Application].[Node].[CustomProperties].[n_CPUCount] ) ) ) OR ( ( E0.[Application].[Node].[CustomProperties].[CPU_Crit] IS NOT NULL ) AND ( E0.[Application].[Node].[CPULoad] >= E0.[Application].[Node].[CustomProperties].[CPU_Crit] ) AND ( ( E0.[ComponentAlert].[ComponentName] = '0'1 ) AND ( E0.[ComponentAlert].[StatisticData] > E0.[Application].[Node].[CustomProperties].[n_CPUCount] ) ) ) ) )

Because it is important, we are running Orion 2016.2.100 and SAM 6.3.0

jhandberg

I am seeing this but only on the alert with longer (more stuff or conditions) in the blocks. I don't know what to make of it either. My alerts appear to be working correctly.

jbiggley

This *might* be an issue with the function that generates the SWQL as I checked the XML trigger condition in the [AlertConfigurations] table and it looks OK.

jbiggley

Yeah, I ended re-writing a bunch of my SAM-based alerts. What I found was that having some odd combination of multiple components and/or scoping for the application name itself seemed to cause of the problem. I do have a case open with support and I've already talked with them, sent them diags, done some more testing on my side, etc. but it feels pretty wonky to me.

I am running a release behind right now and they did recommend an upgrade (which we have planned to do) but I feel like we're still trying to scope exactly what the issue might be..

I might have to up logging for a bit so that I can see the actual SWQL queries being executed for alerting....

jhandberg

We are on the latest NPM 12.1 here. So at least in my case, the newer version is still showing the anomaly you discovered on longer alerts. I am not sure if I can re-scope ours. They got long due to special requests and conditions and the like. Fortunately, it is only a small number of alerts affected here and like I said, they appear to be working as intended.