Overview
Opsview (fault monitoring software) is the preferred, established platform for systems monitoring within Yale ITS. One of its features is out-of-the-box integration with Service Desk functions, including RT/Jira/ServiceNow.
Opsview is a commercial fork of Nagios. Their codebases are extremely similar and have many of the same integration points.
There is a Confluence Space dedicated to Yale's implementation of Opsview here.
Opsview Integration Architecture
The opsview-servicedesk-connector
package for Red Hat Enterprise Linux (RHEL) allows for this integration via opsview-notifications
. Core nagios events hit an external notifier. These spool to disk and are pulled into a relational db via the notifications daemon. It also sends this same data offsite to Service Now. Once Service Now items have attributes set/changes (ticket number, ownership change, etc), relevant details are brought back down to Opsview via the same notifications daemon.
In order to interface with Service Now, the YML necessitates username, password, and instance URL.
Opsview Vendor Documentation
Opsview maintains a fairly deep wiki online. The following are relevant documentation pages regarding their Service Desk Connector as it related to Service Now integration.
Overview
Architecture
Installation
Configuration
Concerns
There is a lot of state change within Opsview. Sometimes this state change is considered spiurious upon human inspection while its always deemed a genuine issue per Opsview. Yale should tread carefully regarding opening this Opsview dataflow up to Service Now so as to avoid a firehose condition.
Moreover this integration should be used as a lightning rod to initiate and push for amending the monitoring stack where appropriate to dial back the amount of state change.
-nick, 20120305
Tickets
Opsview
- OVS-3105 servicedesk notifications db on external mysqld and not localhost?
- OVS-3107 curious about how opsview treats state when service now incident record isnt created
- OVS-3110 notifications not received by service now ; need help debugging
- OVS-3111 userland configurability of fields sent to service now during servicedesk-connector use?
- OVS-3113 support for running servicedesk-connector @ slaves in cluster as opposed to master
- OVS-3114 describe use of Contact Variables in Notification Methods
- OVS-3115 notifications never make their way to notifications db, service now
- OVS-3116 support for admin purging of events at spool for servicedesk connector
Next Steps
- Bind creds @ Service Now
- Verify least privledge through Opsera + Service Now
- https://secure.opsview.com/jira/browse/OVS-3110
- Need Service Now ticket
- Generate dummy data in SN sbx ECC queue to verify conduit function
- http://docs.opsview.com/doku.php?id=servicedesk-connector-latest:configuration#testing
$ NAGIOS_LASTHOSTCHECK=1234567891 NAGIOS_LASTHOSTUP=1234567890 NAGIOS_HOSTOUTPUT="Test failure" NAGIOS_HOSTADDRESS=10.11.12.13 NAGIOS_LONGDATETIME="Dec 1 2009" NAGIOS_HOSTALIAS="temp host 1" NAGIOS_LASTHOSTDOWN=0 NAGIOS_LASTHOSTSTATECHANGE=0 NAGIOS_NOTIFICATIONTYPE=PROBLEM NAGIOS_HOSTSTATE=DOWN NAGIOS_HOSTNAME=host1 /opt/opsview/notifications/bin/opsview_notifications servicenow Notification submitted
- Egress packet filter in the way. Eval scalable means to open up.
- Verify endpoints for Service Now for egress packet filter purposes (Yale firewalls outbound)
- Is 199.91.136.0/21 too much, too little, etc?
- Bootstrap Notification Methods
- Verification of fields being fixed, unchangeable
- Consider keywords for service now only ; not all events would enter SN only those we say to per tags