Using IP address as a condition in an alert

Hey all-

We've added some devices on the other side of the world that are always triggering our 'response time' alert.  My approach was to creat to alerts, one for APAC and one for EMEA and NA.

I tried to use the IP address of the node as a qualifier for APAC:

'when all of the following are true'

IP address begins with 10.50

IP address begins with 10.51

and for the other alert

'when none of the following are true'

IP address begins with 10.50

IP address begins with 10.51


The conditions don't seem to make a difference and I'm still getting the lower response time alerts for devices in the 10.50 and 10.51 range.

Could someone let me know how to properly qualify an IP address, or better yet a CIDR network?

tia- Brad

  • Hi,

    You should either use a Custom Property or the SNMP Location information to group your nodes and thus filter alerts more easily with conditions such as below:

  • Thanks I considered that approach.

    Is it impossible with IP Address or just noy recommended?



  • Dear bthornto,

    The conditions should be make a big difference in my point of view.

    The first condition, when ALL of the following are true, supposed IP address for a node is unique, so for this point of view, the first alert cannot find any node that are both begins with 10.50 AND 10.51.

    In second condition, when NONE of the following are true, it should be some nodes that are not begins with 10.50 and are not begins with 10.51, say 10.52.

    But I have no idea on the problem of lower response time, just share the view for the conditions, you may just ignore it if my logic or understanding is incorrect.


    Best regards,

  • Right-  The first condition should have been an 'any' of the following are true.

    I had it set up like this and got 161 emails about APAC.  We've since prefaced the SNMP location for devices in APAC with there country code so I'll test a filter on a 'begins with XX'

    I am curious why the IP address condition doesn't work though, I looked at the actual SQL query in the alert definitions and it seems like the syntax is correct.

    Should the IP address be used as a suppression rule?  I had it as a qualifier in the trigger action.

  • Late to the party but this is the solution which is working for me. Using a custom SQL Query as the alert definition:


    Author: Tony Johnson

    Date: 11/01/2017

    Description: Selects nodes based on IP address Octet Ranges



    --Get the Last Octet, and every other column from the nodes Table

    CAST(REVERSE(SUBSTRING(REVERSE(ip_address), 1, CHARINDEX('.', REVERSE(ip_address)) - 1)) as int) as "last octet", * from Nodes


    --Refine results based on required values for last octet


    (CAST(REVERSE(SUBSTRING(REVERSE(ip_address), 1, CHARINDEX('.', REVERSE(ip_address)) - 1)) as int) >= 50 OR

    CAST(REVERSE(SUBSTRING(REVERSE(ip_address), 1, CHARINDEX('.', REVERSE(ip_address)) - 1)) as int) <=20)


    --Finally, limit further based on 3rd Octet

    AND CAST(REVERSE(SUBSTRING(REVERSE(ip_address), CHARINDEX('.', REVERSE(ip_address)) + 1,CHARINDEX('.', REVERSE(ip_address), CHARINDEX('.', REVERSE(ip_address)) + 1) -CHARINDEX('.', REVERSE(ip_address)) - 1)) as int) =4

    --Any further considerations can be included here such as

    AND CPULoad >1


    To use other octets substitute as necessary with one of the following:

    1st Octet

    CAST(SUBSTRING(@Ip, 1, CHARINDEX('.', @Ip) - 1) as int) AS FirstOctet

    2nd Octet

    CAST(SUBSTRING(@Ip, CHARINDEX('.', @Ip) + 1,CHARINDEX('.', @Ip, CHARINDEX('.', @Ip) + 1) - CHARINDEX('.', @Ip) - 1) as int) as SecondOctet