The document discusses integrating the monitoring system Zenoss with the ticketing system ServiceNow for incident management and configuration management database (CMDB) purposes. It describes why customers would want each integration, what features the integrations provide, and how the integrations work technically. The incident management integration allows for automated ticket creation and updating based on monitoring events. The CMDB integration syncs device and component data between the two systems.
Michael Shannon
Deployment Architect
mshannon@zenoss.com
Two separate integrations
Use either or both
System can open tickets automatically, reducing effort necessary to manage events
Even if tickets are opened manually, data will be automatically populated to the ticket – fewer opportunities for mistakes and typos
Supports users working out of the Zenoss event view or the ServiceNow Incident display
Enable auto-ticketing in an incremental process – identify a set of events to ticket, and enable auto-ticketing only for those events
As you identify more types of events that are getting manually ticketed, enable auto-ticketing for those events
Avoid opening tickets unintentionally
Bi-directional communication allows users working in either system to have their work show up in the other
Only new component is zenincidentpoll, which should only have one instance running, preferably on the master
All communications with ServiceNow utilize either the SOAP or JSON web service
You can have multiple notifications to populate incidents in different ways – but make sure that the same event can not trigger more than one notification!
Since the notifications run in different daemons, you’ll use different logs to troubleshoot manually created vs. automatically created incidents
Manually created incidents will log in /opt/zenoss/log/event.log
Auto-ticketed incidents will log in /opt/zenoss/log/zenactiond.log
Polling of incident information will be logged in /opt/zenoss/log/zenincidentpoll.log
Fewer opportunities for typos when populating devices from the CMDB
Consistency in naming of devices across systems
Workflows on the ServiceNow side can update device to cause it to automatically get picked up by Zenoss
Test on a test Zenoss instance! You want to make sure your filter is correct before populating your production instance
You can script moving devices from /Discovered to the appropriate class
New method of moving devices based on hardware model or OS may be coming soon!
Can also add groups directly to Impact service for more real-time updates.
Avoid restarting the daemon when possible – the initial run populates the query, and will take significantly longer.
For 4.x, make sure you only have one copy of the daemon running, don’t let it run on all collectors. For 5.x, the service definition takes care of that for you.
You can use whichever you want, but you can’t install both on the same system – this is to protect you against getting into an infinite update loop.