Overview
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.

Zabbix
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.

Solarwinds
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.

ITSM integrations
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.

Service Now
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.

BMC Remedy
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

Twitter Feed

OrbData Is your company ready for #GDPR? https://t.co/fGybdNrlCh
4hreplyretweetfavorite
OrbData Setting up Windows PowerShell discoveries with #IBM #TADDM https://t.co/pxMZ2eVPpo

Address

Address:
100 Longwater Avenue, Green Park, Reading, RG2 6GP, U.K.
Tel:
+44 (0) 118 945 0130
E-Mail:
This email address is being protected from spambots. You need JavaScript enabled to view it.

markerFind on Google Maps

About Us

Orb Data brings together People, Process and Technology to deliver the cornerstone of business success: the management of IT infrastructure. At our heart are our people. We have unrivalled experience, helping us to achieve an enviable reputation for excellence in project delivery. Because we’re independent, we identify actual issues and help organisations resolve them –from spec to deployment, and beyond –providing the right solution in terms of best of breed technology and support. We offer a refreshingly simple approach to the way we conduct business. We take pride in our abilities to provide first class solutions to business problems, and to conduct working relationships with honesty and integrity.

Follow Us On:

JoomShaper