Introduction

Obsidian is an AIOps platform that calculates aggregated indicators at the service level through a process of service modelling and integration of information (metrics, indicators, probes, alerts, etc.) from other tools used in the organization. In addition to consuming information from other tools, Obsidian has an API with which to integrate information from its own data model.

Both types of integration are documented in the Technical manual for integrations with Obsidian, and they are described below:

Obtaining data from corporate tools and integrating them with Obsidian

Also called inbound integration, in which data is obtained from other tools to be consumed by Obsidian.

The Obsidian website contains a list of the main market tools for which Obsidian has a predefined integration package. Obsidian may also use information from any existing data source in the organization, provided that the data has been normalized to be used in conjunction with the other data sources.

Necessary information

Obsidian is a tool with a clear real-time orientation. Therefore, other tools must provide Obsidian with the latest available information for each metric, indicator, probe or alert. In other words, with that which is the most representative of the current "state of things". Where possible, sending average values of the last minutes or hours should be avoided, since this type of information is less representative of the current situation.

Information provided to Obsidian by a tool may include one or more of the following:

• A state (qualitative value) which must be adapted to the states that Obsidian uses. The main ones are: Green (compliance), yellow (close to non-compliance), red (non-compliance) and gray (unknown).
• A unique quantitative value, such as volume, percentage or deviation.
• An extended value in the form of a text string that may include one or more quantitative and status (qualitative) values.
  
  

For example, in an ideal situation, the tool provides the state (red, yellow, green), a directly usable quantitative value and an extended string with further details:

However, that is not always the case. It is possible that only some of the values are be received:

• In the first three cases, the tool continues to provide a state, and thus it can be used directly by Obsidian.
• In the last three, the tool does not provide a state, so the level of compliance must be calculated in Obsidian.
• In cases 2, 4 and 5, a directly quantifiable value is provided. Therefore, we can opt to ignore the status provided by the tool (should it exist) and calculate the state by defining specific thresholds in Obsidian.
• In cases 3 and 6, before being able to operate with the value, it is necessary to extract the desired quantitative value using a regular expression.
  
  

Normalizing the information provided by a tool

When the tool provides a state, we can operate using standard discrete values associated with each state: 

When the tool does not provide a state, or when it provides one that is to be ignored, comparison thresholds (minimum, red-yellow limit, yellow-green limit, maximum) must be defined to calculate the state. 

In the following example, 21% disk space is considered OK. If we wanted it to be WARNING or CRITICAL, we would select "State (Source)", extract the numerical value 21 with a regular expression, such as /MB \((.*?)%/, and define thresholds where the value 21 is, for example, a yellow and not a green:

That way, the source tool would provide:

But Obisidian would operate with:

...where thresholds 10 and 25 make 21 WARNING, but a discrete standard calculation value of 85 is associated to that WARNING .

The normalization process in Obsidian can be done in four ways:

In the example above, if "Normalized Value (Absolute)" were selected instead of "Status (Value)", the default thresholds for the dimension (in this case, capacity) would be used:

In this case, Obisidian would operate with:

On the other hand, choosing "Normalized Value (Relative)", manually defined thresholds would be used:

And Obsidian would operate with 27.33, a proportional value of 21 between 10 and 25, normalized to the standard thresholds 20 and 30:

Types of integration

Integration with corporate tools can mainly be performed in two ways: active integration and passive integration.

Active integration

In active integration, Obsidian periodically queries the data source to obtain the latest value for each metric and indicator. It is often used with monitoring tools, where Obsidian massively accesses large amounts of data at a low level. To do so, Obsidian implements a series of abstract classes and interfaces that must be instantiated to develop the integration with a new tool.

Passive integration

In passive integration, Obsidian expects to receive information from the tool on its REST webservice. The value of a given metric or indicator remains in effect until the webservice receives an update. It is usually used with service desk tools, where a series of complex indicators are calculated at the source for each service and, once generated, they are sent to Obsidian.

Using information calculated in Obsidian on other tools

Also called outbound integration, in which the information of the Obsidian data model is consumed by other tools, such as analytics and business intelligence platforms, through the Obsidian API.

On the Obsidian website, there are several examples of how the information provided by Obsidian can be used in BI or visualization tools. The following example shows the integration of Obsidian with Tableau: