Docs
...

# CMDB and Service model

This article contains background information about CMDB and Service Model (SM) and its objects. For information on SM configuration, go here.

Service Model (SM) 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 Monq, it is a network graph containing information about model entities and their relationships.

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 Monq 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 (see details),
  • 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),
  • Bound objects (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

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.

From a practical point of view, the Subordination relationship also provides absolute inheritance of access rights from parent objects to child objects.
The Influence relationship, on the other hand, does not affect the access rights to the object in any way.

On the SM graph, connections are indicated by arrows between pairs of objects:

  • Child CI → Parent CI
  • Influencing CI → Dependent CI

Connections are subject to the following restrictions:

  1. An object can only be subordinated to one object.
  2. There cannot be a cyclic connection between objects (A → B → C → A).
  3. A pair of objects cannot have both types of connection at the same time.

One of the main properties of a CI is its Status and Health - these indicators are necessary to ensure tracking and automating of the process of monitoring events.

# Status

Status is a practical indicator used in the process of generating and handling of monitoring events. 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 Monq Service Model.

If, when adding an object, the value MONQ is selected as this parameter, then the object is created in the Monq 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 Monq SM.

# Bound objects

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

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