Docs

# CMDB and Service model

This section contains background information about Service Model (SM) and its objects. For information on SM configuration, go to Operations Center.

Service Model (SM) or CMDB (Configuration Management Database)* is a logical service model that describes the composition and relationships of a set of configuration items (resources) that together provide the service at an agreed level. In Acure, it is a network graph containing information about model entities and their relationships. You can find the SM graph in the Operations Center section, and the CMDB in tabular view in the CMDB View section.

There are several views of the SM graph:

  • Health Graph - displaying the health status of dependent elements
  • Structure Graph - showing the hierarchy tree of Configuration Items (CIs)

SM is used in the following management processes of IT infrastructure:

  • Managing Service Level
  • Managing Operation processes
  • Managing Availability
  • Managing Configurations
  • Managing Changes

The Service Model is one of the main components of the Acure product. It is intended to store information about objects and entities, including relationships in the User's IT environment.

SM is involved in all major functions and services of the software:

  • Building representations
  • Event model
  • Making of Availability reports
  • Differentiation of access rights

# Configuration items

A configuration item is an object of the Service Model that represents an element of the user's infrastructure. A configuration item can be either a physical object, such as a router, or a logical element of the system, such as a service.

Each CI has a set of fields:

  • ID
  • Name
  • Description
  • Owner - Workgroup that has full access to Read, Edit and Access settings for the CI
  • Type - used solely for the convenience of the user and differ only in the icon of the object (see details)
  • Links
  • Parent object (CI) – an object in relation to which the current CI is a subordinate
  • Status (see details)
  • Health (see more)
  • CMDB (details)
  • Access rules - a list of Workgroups with access to Read or Edit the object
  • Attached files (Questionnaires, Documents, Images)
  • Personal attributes (details)
  • CI Type attributes (details)

# Type

  • Default
  • Virtual server
  • Storage
  • Information System
  • Channel
  • Cluster
  • Switch
  • IS module
  • Router
  • Application
  • Web resource
  • Service
  • Equipment
  • Firewall
  • UPS
  • ATE
  • Business service
  • Web Service

# Connections

SM objects can be linked by one of two types of connections:

  • Subordination
  • Influence
  • Information

A connection of type Subordination denotes a relationship between parent and child. For example, Personal Account is an integral part (child object) of Online Store – in terms of SM, the Personal Account is subordinate to the Online Store.

A connection of type Influence denotes influence of infrastructure objects on service or other infrastructure objects. For example, the health of the Server of databases affects the health of the Online Store as a whole.

# Features and Limitations of Relationships

# Informational Relationship

  1. There can't be more than one relationship of this type between two CIs.
  2. Any CI can have as many relationships with other CIs as needed.
  3. Working with this type of relationship is only possible through the public API. Displaying data about these relationships in the interface will be implemented in later versions.

# Impact Relationship

  1. There can't be more than one relationship of this type between two CIs. A CI can only influence one component out of all the available components of another CI. However, it can influence multiple components of other CIs simultaneously.
  2. Relationships must not form a loop.
  3. A Dependent CI can have any number of relationships directed towards any of its components from different CIs.
  4. An Influencing CI can have any number of outgoing relationships.
  5. Working with this type of relationship is possible through:
    • The public API
    • On the SM graph, using the "Health" view.

# Hierarchy Relationship

  1. There can't be more than one relationship of this type between two CIs.
  2. Relationships must not form a loop.
  3. A Parent CI can have any number of incoming relationships.
  4. A Child CI can only have one outgoing relationship.
  5. Working with this type of relationship is possible through:
    • The public API
    • On the RSM graph, using the "Structure" view.

# Status

Some of the main properties of a Configuration Item (CI) are its Status and Health - these indicators are essential for monitoring event tracking and automation.

Status - a practical indicator used in the process of event formation and monitoring.

The CI's status is calculated based on the health of its components, the CI itself, and the signals that affect the CI.

Statuses are dependent on health, and their model can be unique for each CI type. The intervals for statuses (in terms of health percentages) can be set at the CI type level in the SM Metamodel. There's also the option to remove any of the statuses.

It takes one of the following values:

  • Emergency
    • 1st priority
    • 2nd priority
    • 3rd priority
    • 4th priority
  • Normal (OK)
  • Maintenance (Service)
  • Undefined

The CI status is determined by the values of associated synthetic triggers.

# Health

CI health is a visual tool for assessing the state of the CI tree. This parameter does not affect the generation of events. First of all, it serves to visually assess the condition of the SM map. It is a function of the CI's own status and the health of subordinates and influencing CIs:

H = min ( h_direct, h_ratio ), where

  • h_direct – critical influence, h_direct = ( min ( h1, h2, h3, h4 ) )

    h – health values of influencing objects,

  • h_ratio – weighted influence, h_ratio = ( k1 \* h1 + k2 \* h2 + k3 \* h3 + k4 \* h4 )

    h - health values of influencing objects,
    k - weight coefficients calculated by the formula ***( k1 = h1 / sum of all weights )***.

The same object can have both the critical influence property and weight calculation points at the same time.

Health can take values from 0 to 100, where 0 is completely inoperable, 100 is an ideal state.

The table shows the numerical correspondence of CI health to its Status:

Status Health
1st priority 0
2nd priority 25
3rd priority 50
4th priority 75
OK 100
Undefined 100
Maintenance Ignored

# CMDB

The CMDB parameter defines the source of the object added to the Acure Service Model.

If, when adding an object, the value acure is selected as this parameter, then the object is created in the Acure database from scratch and has no connection with external systems.
If any other source is specified as a value, for example, HPSM (or any other CMDB connected to the platform), then the basic information about the object is pulled into the platform database, and the object itself remains connected to the source, which ensures the possibility of synchronization data between primary CMDB and Acure SM.

# Bound objects

In addition to their own attributes, some CIs also have a set of objects associated with it such as Testforge projects, synthetic triggers, Zabbix nodes or Zabbix triggers.

These objects can be bound to CIs to generate and enrich monitoring events.