Although OpsAlerts sits in the cloud the alerting tools are generally on site at a customer’s data centre. This is because a monitoring solution may monitor several parts of the customer’s application, database, and infrastructure that are not accessible to the cloud. For this reason, the customer’s monitoring tools are integrated with a set of probes that will sit on the customer site that will have access to OpsAlerts and the monitoring tools.
The probes will connect to OpsAlerts using a single port (4443) over SSL.
Monitoring Systems integrations
IBM Tivoli Monitoring (ITM) / Application Performance Management (APM)
ITM and APM have native integrations into Netcool/OMNIbus via EIF. An EIF Java API probe is hosted on the customer’s local network, to which the ITM/APM environments can forward alerts to. This is then forwarded to OpsAlerts cloud environment via SSL. OpsAlerts will support out of the box integrations for ITM and APM with related triggers imported and ready to start processing alerts from ITM and APM sources. This will also support the bi-directional synchronization of the alerts between the ITM / APM systems, provided inbound traffic is allowed from the secure OpsAlerts platform.
OpsAlerts will employ best practice integration practices out of the box to start with, any further customizations or enrichments to the alerts will be accommodated for based on the customer’s requirements.
The Zabbix environments will leverage the RESTful API available, we have custom integrations written to support Zabbix alerts to be forwarded on to OpsAlerts over REST API. Zabbix administrators will have to create a custom action in Zabbix to send the problem and recovery messages via our custom tool that is executed as a command hosted on the Zabbix server. This will allow us to not only register the problem events but also corre late and resolve the alerts when service has recovered in Zabbix and a resolution event is sent. Acknowledging an event in OpsAlerts will also acknowledge it in Zabbix using the Zabbix Event API, provided that inbound connections from OpsAlerts are accepted. Further customizations based on the information held in Zabbix, say in the host inventory or in a CMDB can also be leveraged using enrichments tools available in OpsAlerts.
Nagios Core / XI, Icinga, Centreon, op5
Nagios based products use an event handler to forward events to external systems. We have written a custom event handler to forward events to OpsAlerts which enables event correlation out of the box. Problem and resolution events are correlated to resolve incidents as they are
marked as recovered on the monitoring systems. The custom event handlers will need to be enabled either as a global event handler or on specific host and service templates as you see fit. If you are using Nagios XI, we can also leverage the new Nagios XI API to populate Host or Service Graphs along with the related alert information straight from the OpsAlerts console for
quick access to performance data. We can also populate the host or service’s Rapid Response URL that you can use to perform actions against Nagios related alert.
Alerts from Solarwinds are typically forwarded on as SNMP traps to external systems, we will deploy an SNMP receiver on the customer’s network which will come pre-loaded with rules to parse SolarWinds alerts and the probe will then forward the alerts to OpsAlerts over SSL. Further customisations to alert handling and severity mappings would be done to fit customer’s requirements.
Both problem and resolution traps are parsed and this will allow us to not only register the problem events but also correlate and resolve the alerts when a node or service has recovered in Solarwinds.
Microsoft System Center OperationsManager (SCOM)
OpsAlerts leverages the OMNIbus probe to provide integration into Microsoft SCOM. The Probe for Microsoft SCOM 2012 can receive and acknowledge events from, and resolve alerts in, Microsoft SCOM 2012.
The probe communicates with Microsoft SCOM 2012 using the Operations Manager Connector Framework (OMCF) API exposed by the Microsoft SCOM 2012 Software Development Kit (SDK). The connection is made over TCP and is secured using the Kerberos network authentication protocol. The alerts acquired by the probe is then forwarded onto OpsAlerts over SSL from the customer location.
Once the events have been forwarded to OpsAlerts, you can then manage these alerts on OpsAlerts and leverage our tools to define maintenance windows at all levels (Node / Service / Host Group / Service Groups, etc.) and further escalation into ITSM Incident Management solutions like ServiceNow or JIRA, etc. can also be done. Below are some of the integrations OpsAlerts can support out of the box, however, this is not an exhaustive list. Should you need integrations to other solutions please enquire and we can provide further information.
A bi-directional integration with Service-Now is achieved by leveraging the Netcool/OMNIbus Java Gateway for ServiceNow. Out of the box, the gateway connects directly via the REST API to the ‘incident’ table in the ServiceNow instance, where the gateway creates and retrieves details about tickets. This gateway will be hosted in the OpsAlerts infrastructure which will raise directly with the ServiceNow platform, for restricted access instances we will need to host the gateway on the customer’s location.
Using REST API, we can also perform various enrichment of alerts based on the CI information in ServiceNow’s CMDB. We can enrich alerts with Assignment Group, Location, Operational State, Customer Reference, etc. and this will enable customers to have much more options in terms of defining business rules on the alerts before they are raised as an Incident in Service-Now. We have helped customers achieve operational efficiency and reduce the burden on the Site Reliability / Support teams by only raising issues that satisfy the rules criteria for the various scenarios.
JIRA Service Desk
Using IBM Netcool/Impact OpsAlerts will integrate with the JIRA service desk to create ‘Incidents’ using the RESTful API. These alerts are raised as problem or incident tickets based on the nature of the alert and we can provide bi-directional synchronization with JIRA using customized policies that fit within your environment. Business rules can be defined to suggest when auto-closure scenarios will apply so as to work seamlessly with agents actively working on those tickets.
Out of the box, we have mapped key ObjectServer fields such as Node, Alert Key, Alert Group, and Summary, etc. from the alerts to build the description and title of the ticket. We also store the JIRA ticket number on the ‘TTNumber’ field for reference and can link the tickets via URL
tools to launch. OpsAlerts also provisions right click tool to action on individual alerts, should the need arise. Further custom fields and customizations to the workflow can be implemented as required.
IBM SmartCloud Control Desk (SCCD)
OpsAlerts leverages The IBM Tivoli Netcool/OMNIbus Gateway for TSRM provides bidirectional communication between Netcool/OMNIbus and IBM SmartCloud Control Desk V7.5, The gateway can create a SCCD ticket from an event in the Netcool/OMNIbus Event List by mapping fields in the ObjectServer to fields in SCCD. Once a ticket is created, you can add a journal to the original event in the ObjectServer. The gateway passes the data to the SCCD where it is converted into a work log.
If the status of the ticket within SCCD changes, the gateway passes the changed status back to the ObjectServer.
OpsAlerts will implement the IBM Tivoli Netcool/OMNIbus Java Gateway for BMC Remedy ARS works with the BMC Remedy Action Request System (ARS), which is a help desk system operating on a variety of operating system platforms. The BMC Remedy ARS uses a system of
trouble requests. The Java Gateway for BMC Remedy ARS is a bidirectional gateway that creates requests in BMC Remedy ARS from alerts sent by the OpsAlerts. In a typical environment, users define workflows within BMC Remedy ARS to create trouble requests from the requests that the gateway creates. These trouble requests are updated, according to a predefined mapping, throughout the life span of the alert. For each request that the gateway creates, BMC Remedy ARS sends back an associated request ID.
BMC Remedy ARS also passes back to the gateway any changes to the requests so that the gateway can update the OpsAlerts event. The gateway forwards journal entries from alerts in OpsAlerts to BMC Remedy ARS. Forwarding updates to BMC Remedy ARS requests when the associated events in OpsAlerts are updated or deleted