Servicenow integration - what i've learned that maybe helpful to others

The below really should be in the ServiceNow documentation, but isn’t so here are some pointers.

Location of the default servicenow script

/opt/omd/sites//lib/python/cmk/cee/notification_plugins/servicenow.py

If [when] you modify it, you then copy it into

~/local/share/check_mk/notifications/

Turn notifications on for SNOW [Servicenow]

Troubleshooting

Note - you need to have a contact selected in the SNOW config else you will get no notifications sent out - this had me scratching my head for a while.

Turn on a higher log level by searching for ‘notifications’ under Global settings.

Keep a tail on the below logs open at the same time…

/omd/sites//var/check_mk/core/history

/omd/sites//var/log/notify.log

The main thing in the notify.log that had me scratching my head was ‘1 rules matched, but no notification has been created.’ as how was it matching but not sending any notification!? that was the issue with no contact being stated. Without an error being generated though…i was lucky to guess that was what it was as not self evident.

Just on more of a preference level, i didn’t want to have INCs being resolved automatically as i think thats a bad idea so turned off that functionality. I believe that should really be a WATO SNOW config button so you can choose without changing the script.

Enjoy the world of SNOW!

HI,
I did follow your steps the notification rule i created is matching but there are no incidents getting created on service now can you please help on the same

are you seeing the servicenow script being called in the notify.log? you will need to turn on debugging for Notifications.

1 Like

On the ServiceNow side you will also need to create a user with basic privileges of ‘ITIL’ to be able to raise an INC via the API.

1 Like

did you also specify any condition for Auto close of the incidents from checkMk in service now

I don’t recommend using auto-close as it can cloud re-occurring issues. You are either monitoring something correctly, or you are not…that’s really all there is. If you have an issue that raises an INC, and it flaps and then closes an INC, that can keep occurring until failure, and you are just delaying dealing with it.

1 Like

To put it in practical terms…if something critical fails because you have been hiding the hundreds of alerts in auto closes, would you not have rather had the actual instances annoying the hell out of your operations people. This is a process issue at the heart of it, and you don’t want to hide things just because you can as it will bite you eventually.

1 Like

It there any possibility to create only 1 alert and do some kind of correlation before creating an incidents with the notification rule in checkmk

Look into Business Intelligence rules for creating more intelligent alerts based on service structure.

You could also look at scripting and pulling from livestatus to create whatever you need. i.e if X and Y alert over time Z, do something.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.