Join us for this interactive session to learn how today's leading IT organizations are identifying and resolving IT service disruptions faster than the CEO can ask you, "What's happening?"
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