IT Service Management

Using quantitative/numerical data to evaluate efficiency of business processes and practices is a very valuable management practice. Though there are many things that cannot be measured and still must be managed, correct quantification makes management tasks more clear, improvements are more visible and the whole management process more steady. Measurements lay a solid foundation to select an appropriate action.

Basically, metric is a systematized measurement. With the Metrics Package, Iotellect provides a simple yet powerful measurement model as described below.

Hereafter, we distinguish between terms 'measure' and 'metric'. Measure is data obtained by Iotellect Network Manager from devices, software components and other resources. Metric is an interpretation of one or more measures collected in purposes of IT management.

Consider the following example: Let's introduce a 'Health' metric. For a server, Health can be defined as a metric that indicates the current performance of the hardware server. The 'Server Health' metric can be calculated using the 'CPU Load' and 'Memory Utilization' measures, for example, evaluating them against predefined threshold to detect possible performance issues. Further on, assume that the server is used to run an application. Then the server Health value can be used (likely, along with metrics of some other components required by application) to evaluate the application Health. Suppose then, the application is running to provide an IT service. To function correctly, the application needs to store and fetch data. There is a high-availability database cluster for that purpose. The application and the high-availability database cluster are connected with a local network. Then the application Health along with the high-availability database cluster Health and the network Health values would comprise the IT service Health metric. The Metrics Package represents metrics as instances of the Metric instantiable model. This model encapsulates all the information and behavior needed to define and measure a metric.

In the example above, the server health, application health, network health,  and the IT service health values can be modeled as a single Health metric. Then, there will be an instance of the Metric model that describes the concept of 'Health' and defines everything needed to apply this metric to various objects within the IT management domain.

Obviously, metrics exist to be measured. To calculate metric's value you can invoke the measure rule set within the desired Metric model instance.

One important detail here is that you can't measure a metric itself. To get a value, you have to refer to an entity the metric is applied to.

Taking into account the example we discussed earlier, we can't measure the Health metric itself. To be measurable, the Health should refer to a certain object: a server, an application, a service, etc.

As the Measurement Package depends on and extends the Iotellect Configuration Management Database (CMDB), we use the term Configuration Items (CIs) for the entities that metrics can be associated with.

This correlates with ITIL terminology, where a CI can represent any object, real or 'virtual', that plays some role in IT management: hardware, software, buildings, people, documentation, IT Service, etc. CMDB is basically a storage of CIs, that is supposed to comprise information about every element of IT management system. This allows us to assign metrics to virtually any asset in our IT management domain.

Thus, to measure a metric, we have to specify a CI it is calculated for. Every CI has a unique identifier (ID).

So, to calculate a metric on a CI, you have to invoke the measure rule set in the metric context providing the CI ID as a parameter.

Example: To calculate the Health of a CI with ID = 3, evaluate the following expression: cell( {measure.health:measure(3)} )

Getting back to the Health metric example, it is necessary to declare that server health, application health, and service health value represent essentially the same characteristic of different objects. If we define all these indicators to have the same meaning for all CIs they are applied to, measure them within the same scale using the same units, we can say that they all refer to one metric named Health.

For example, the Health can be defined as discrete four-values metric: 0 means the CI is 'OK', i.e. it functions properly and no problems detected. 1 means the CI 'Degraded', i.e. it is functional but some problems are detected, that may affect its functionality in the nearest future. 2 means the CI is 'Failed', i.e. it does not work as expected. 3 means the CI's state is 'Unknown', i.e. there is no information about the CI health available.

Although the Health metric has the same meaning for different CIs, the way we calculate its value may vary significantly.

Actually, this is already illustrated by the example above: server Health is evaluated using CPU load and memory utilization measures. while IT service health is evaluated using the health of its components: application, high-availability database cluster, network, etc.

Generally speaking, the evaluation procedure usually depends on the CI's characteristics, the data it provides, and the role the entity plays within business processes. The evaluation may differ even for the same 'type' of CIs if they provide different sets of measures. For example, a network device Health evaluation may depend on protocols the device supports and differ for an SNMP-enabled device vs. simple device that provides be only ping responses.

Thus, there can be several metric evaluation methods, each applied to a subset of CIs the metric is defined for.

Within the Metrics Package, an evaluation method is a named expression specified within the context of a metric.

This is supported by introducing the methods variable within the Metric model context. The methods variable is defined the with the following format:

The Metric model instances store their evaluation methods as rows in this variable.

The Evaluation method's expression takes the targeted CI ID as a single value (field '0' ) in the default data table. How to define an evaluation method and its expression is described below.

When we associate a metric with a CI, we have to specify a metric model and an evaluation method to be used.

The conventional way to associate an existing metric with a CI is via the CI Details dashboard. Locate the targeted CI, say via the CMDB dashboard, and open the CI Details dashboard.

Metrics are defined in the Metrics field. Open the Metrics table and add a new record for the metric. Fill in the metric's name and description, and select a model that the defines the desired metric. Then the Method field will be automatically filled with names of available methods, so you'll have just to select an appropriate method in the drop-down list.

To be calculated, every metric needs some source data. The source data can be a set of measures, or one or more other metrics.

For example: the Health of a network device can be evaluated using it's measures that are obtained via ping, SNMP, or any other protocol supported by the device the Health of an IT service is evaluated over the Health values of CIs it depends on: an application, a database cluster, network, etc.

The latter is an example of a so-called 'compound metric'.

Compound metric is a metric that is calculated over an explicitly-defined set of CIs.

This is an important aspect of the Metrics Package, so let's consider the compound metrics in more detail with the following to examples.

As assumed in our example above, the IT Service depends on several major components: an application a high-availability database cluster a network segment that connects them together. To evaluate the IT Service Health, we have to aggregate the Health metrics assigned to these components. We have to take into account that to function properly IT Service needs all the components: i.e., if any of them fails, the service is malfunctioned. Following the definition of the Health metric, the IT Service Health can be evaluated simply as maximum of component's Health values.

Let's consider another item of our example IT system, the High-Availability Database Cluster. A high-availability cluster is also a compound system comprising several components: database instances. But the Health of this compound system is evaluated differently. The high-availability cluster is supposed to build a redundancy to eliminate failures. Thus, it must have a working database instance and one or more duplicating nodes. Therefore, the High-Availability Cluster Health value can be defined according to the following rules: The cluster state is 'Unknown' (3), if any component's state is 'Unknown'. We can't confidently deduce the cluster health in this case. The cluster state is 'OK' (0), if all the components are 'OK'. The cluster state is 'Failed' (2), if all the components are 'Failed'. otherwise, cluster state is 'Degraded' (1).

The common part of these two examples is that the resulting metric value is evaluated as an aggregation over several component's metrics. This can be described as a dependency.

In our example: the Health value of an IT service depends on the Health values of an application, a high-availability database cluster, and a network segment the Health value of a high-availability database cluster depends on the Health of its nodes.

We refer to the objects that a CI's metric depends on as impactors.

In both cases, we have an 'accumulator' where we accumulate the aggregated value (the Health). The aggregation is performed as a function that takes the incoming value of the next impactor's metric value and the current accumulator value. The result the function produces is taken as a new accumulator value to be used on the next iteration step, or as the final result if all impactors have been aggregated.

The difference between the two examples is hidden in the aggregation function:

• for an IT service, the Health can be accumulated as maximum of the incoming impactor value and the current accumulator
• for a high-availability cluster, it is a little bit more complex function defined by the rules above.

Thus, the way a metric is aggregated can vary for different CIs. This is very similar to methods as described earlier. As well as methods, aggregators are named expression specified in contexts of the Metrics model instances. As well as for methods, this is supported by introducing a variable that stores aggregators in metrics. The variable is named aggregators and has a format that is similar to the methods variable format:

The current accumulator and the incoming metric values are passed to the aggregation expression in the single-row default table within the currentValue and the newValue fields respectively.

Initially, at the first invocation the currentValue will be nil.

You can find examples and some more details on defining aggregators below.

The Metrics Package implements the described metric aggregation model out of the box, as it covers most practical cases being quite simple. At the same time, the model does not force to use the engine being described only, allowing to implement any other approach.

To configure metric dependencies for a CI, locate the targeted CI, e.g. using the CMDB dashboard, and open the CI Details dashboard on it. The Dependencies table contains impactors for all metrics defined for the CI.

To add an impactor, create a new row in the Dependencies table and specify the Metric, Impactor CI, and Aggregation Expression by clicking on the corresponding field and selecting a required entity from the list.

To create a new metric, we have to:

1. Create a new instance of the Metric model and set its name and description.

2. Define metric evaluation methods to be used to calculate the metric value in different circumstances.

3. If the metric has compound values, specify the aggregation functions.

The first point here is quite trivial. Refer to the Instantiable Models section for details.

Several examples and practices for defining the evaluation methods and aggregation functions are provided below.

Metric evaluation method is a named expression defined by a row of the methods variable in an instance of the Metric model. The expression accepts the targeted CI ID as a single value (field '0') in the default data table. The straightforward way to refer the CI ID is to through {0} reference, for example:

cell(   getVariable(     cell(       cell({users.admin.models.cmdb:get({0})}, "data")       , "source_context"     )     , "measure"   ) )

The evaluation method here simply takes a value from a variable (named measure in this example) within a context the targeted CI is associated with. The CI ID is passed to the get function (rule set) in the CMDB model. The get extracts and returns CI table from a storage. The CI data is stored in the data field of the table. We extract it and get a path to the context associated with the CI from the source_context.

A common practice is to extract complex evaluation methods to other Iotellect components.

For example, this a method that evaluates the Health as a compound metric:

{metric.availability:compoundHealth(dt())}

Here, we simply refer to an evaluation procedure that is predefined out-of-box by Metrics Package in the compoundHealth rule set in the Metric model.

Metric aggregator is a named expression defined by a row of the aggregators variable in an instance of Metric model. It is used to accumulate a compound metric value while iterating over its impactors. The expression accepts two parameters as fields of the single-row default table:

• {currentValue} refers to the current accumulator value
• {newValue} refers to the next impactor's metric value to be accumulated.

To illustrate this procedure, we'll use the IT Service Health and the High-Availability Database Cluster Health examples discussed earlier.

Remind that the Health is defined as a four-value discreet metric:

• OK (0)
• Degraded (1)
• Failed (2)
• Unknown (3)

In our example, an IT service depends on an application, a high-availability database cluster, and a network segment that connects them together. All these components are mandatory in the sense that malfunction of any of these assets immediately brings the service down.

Having these specified, we can evaluate the IT Service Health as maximum of its impactors health values. We also should take into account, that initially the accumulator is nil. Thus, the aggregator expression can be this: {currentValue} == nil ? {newValue} : max({currentValue}, {newValue})

The High-Availability Database Cluster Health evaluation is a bit trickier.

The propose of a high-availability cluster is to provide continued service when some components fail. Therefore, the Health of a high-availability cluster can be evaluated according to the following rules:

• 'Unknown' (3), if any component's state is 'Unknown'.
• 'OK' (0), if all the components are 'OK'.
• 'Failed' (2), if all the components are 'Failed'.
• 'Degraded' (1), otherwise.

The expression that implements these rules would be quite long and unreadable. A good practice within Iotellect environment is to extract lengthy and complex expression to models as rule sets. In our case, this could be implemented as a rule set in the Metric model.

The expression then will be:

{ metric.availability:aggregateOptionalHealth( {currentValue}, {newValue} ) }

where the aggregateOptionalHealth rule set can be defined as follows:

Was this page helpful?

Tell us more

Send

Thank you!