...
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
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 Sbx SN sbx ECC queue to verify conduits conduit function
- http://docs.opsview.com/doku.php?id=servicedesk-connector-latest:configuration#testing
No Format $ 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