Integration Solutions

Introduction

The diversity of objects needing to be monitored within an enterprise typically results in a multitude of disparate monitoring tools. These tools differ in their intelligence and capabilities.  While some are capable of doing advanced correlation; others can merely send email notification whenever an event is identified. 

It makes perfect sense though, that a company wanting to keep track of their business critical services will not want to monitor all these different tools.  This would require a large team of people to know the ins and outs of ALL the monitoring tools being used.  If a new tool is introduced this team would have to undergo extensive training to be able to start using it.

These complexities also exist in the asset management/tracking space, as with multiple event monitoring tools, the different inventory scanning tools vary greatly in how they represent data, making it very difficult for a centralised team to make sense of the different representations.

Where to manage?

It is far more effective to monitor the current state of the enterprise from a single point of reference, than to try and do the same monitoring using the various disparate tool sets used to capture events within the environment. This single point of reference within the enterprise should be the Service Desk. The challenge in achieving this is to implement some kind of mechanism which will automatically normalise the diverse data presented by all the different monitoring tools, and make this available to the Service Desk application in what ever format it requires.

Once in the Service Desk, incidents can be managed in the same way, regardless of their origin. In other words irrespective of the tool that is used to generate the event, the ticket will always look the same in the service desk. This facility allows people responsible for attending to incidents (I.e. a competency) to develop a simple set of unchanging skills to identify where and what needs attention.

Similarly from an asset point of view, by having a single interface to the Central Management Data Base (CMDB), normalised data from the different Inventory scanning tools can be processed in exactly the same way regardless of its origin.

Architecture

Incident management

Irrelevant of what the management tool is, the events detected by it need to be sent to a central location for processing. This task is typically accomplished by the Xpress transportation layer.

At each management tool on the client site an XPressDispatch service is installed to send the events to the XPressStation. The XPressStation is situated centrally with the X-SLM and PIETrack applications, which in turn are used to normalise and open the appropriate tickets in the Service Desk application.

In the case where the monitoring tool is only able to send an Email when an event occurs, the XEmailEater is used to consume these, do the necessary translation and present these events to the X-SLM and PIETrack applications in the exactly the same way as Xpress would.

Upon receiving these events X-SLM will qualify them, record any impact to business, and then pass this qualified event onto PIETrack. PIETrack will record the event, do the necessary de-duplication, correlation, and accordingly log the appropriate incident or problem into the Service Desk application. 

These events, incidents and problems, and their impact to business are then available for visualisation from the SXI Portal.

Inventory  Management

Inventory Data collected at the client site by disparate scanning tools are transported to a central location by Xpress. The central X-Asset application will normalise this data and pass the deltas (only what has changed) to the CMDB.

Types of integration for events

Email

Several tools are only able to send email events.  For each of these, rules are developed to translate the email into an event document that is processed by X-SLM and PIETrack. (Yellow flow)

Command line executable

Most tools are able to execute an application and pass it certain variables which describe the event.  An application has been developed for these tools which converts the data it receives at the command line into event information. (Green flow)

Application Programming Interface (API)

Some tools expose APIs in order to generate event information. (Green flow)

Modules

Some monitoring tools can have modules developed for them which glean the event data internally and can produce the required event document to be processed by the X-SLM and PIETrack components. (Green flow)

Logs

Other tools are only able to update a log file.  This log file is monitored for changes and when a new event is captured into it the Log Reader application will translate this log entry into an event document.