Advanced service modeling

This section presents some more advanced service modeling topics that you can use to refine your service models further.

Setting CI access control

Access to configuration items (CIs) and related objects is controlled by read and write access control lists in the CIs of the user groups that have either read or write access. These access control lists also control access to the devices, monitor instances, and instance thresholds associated with the CIs.

By default, a user does not have access to a CI, or its associated objects, unless the user is a member of one of the groups in the access control lists. A user that is only a member of a group in the read list can only view the CIs and the associated object. A user that is a member of a group in the write list can perform various management actions on the CIs and associated objects. The actual views the user can see and operations or actions the user can perform are controlled by the permissions in the role(s) assigned to the groups that the user is a member of.

Consider the following points when setting access controls:

If access is granted to a higher level CI in a service model but not to some of the provider CIs in the same model, then the user will not be able to see the cause of any problems propagated up from the provider CIs.This can be useful if a set of users must be able to only see the status of the high level services that they use.
If a user has access to set thresholds on monitor instances associated with a subset of CIs, grant only the group of which the the user is a member, write access to that subset of CIs.
Access control is not hierarchical (for example, a user that can access a higher CI in the model does not automatically have access to the provider CIs).

Note:

The events in event collectors are currently not controlled by CI access controls. Event collectors have their own access control lists that are defined in the KB of the cell.

Service schedules

You may have services where their availability is only high priority part of the time, such as during business hours. At other times, they may be expected to be available, but an outage does not require an action as urgently as another service that does not have reduced priority. To handle this, you can set up service schedules.

A service schedule specifies the time frames during which the service has high priority. Any period of time not in the schedule is considered “out of schedule” and may have a lower priority set.

Service schedules can be composed of multiple recurring, and non-recurring time frames.
If no service schedule is set for a CI, it is considered to always be in schedule.
Besides having a separate out of schedule priority, you can also set a separate cost of down time for out of schedule.

Modeling network infrastructure

Network infrastructure can be modeled in several ways for impact, depending on the monitoring and events you have in the network.

Network aggregate collection

If you only have general network related events or monitoring, or you only need a simple representation of the network in the model, you can represent the network as a single connectivity collection CI as shown in the figure below:

Network Topology based

If you have monitoring and events for specific individual network devices and you want a more detailed representation of the network in your service models, you can add the network as distinct CIs representing components of the network (such as subnets, switches, routers, and so on) based on the network topology as shown in the figure below:

Configuring how impact is computed or propagated in the model

The propagation of impact statuses up the model is controlled by the impact computation model set on the CIs and by the impact propagation model set on the relationships between the CIs.

Impact computation models

When you have CIs that may be impacted by several provider CIs, you may want to adjust the way in which the impact status is computed. You can do this by using the computation model of the CI.

The table below lists the available computation models:

Computation model	Description
STANDARD	Computes the status of the CI as the highest status of the provider CIs (or itself) Use when the CI has its own status or when the CI is directly impacted by its providers.
CLUSTER	Computes the status as the highest status propagated by the quorum percentage (>=51%) of the provider CIs Use when the CI has a group of provider CIs that are all of the same type.
WEIGHTED CLUSTER	Computes the status based on the status weight set for each impact relationship from the provider CIs. This allows you to give some providers a higher weight in computing the impact status than other providers. Use when the CI has differing types of provider CIs that have different impacts of the status.
SELF-PREFERRED	Uses the CI’s own status if open events are associated with the CI. Otherwise, uses the standard highest status of the provider CIs. Use when a CI has providers, but also its own monitors and events that set its status.

Impact propagation models

In rare cases, you may want to adjust the status that is propagated from a provider CI to its consumer CIs. You can do this by setting the propagation model on the impact relationship between the CIs.

The table below lists the available propagation models:

Propagation model	Description
DIRECT	Propagates the status as is (the default) Use in most cases.
INCREASING	Propagates the status increased by one level Use when the provider CI’s status impacts the consumer CI more than itself.
DECREASING	Propagates the status decreased by one level Use when the provider CI’s status impacts the consumer CI less than itself.
JUST_WARNING	Propagates the Warning status for any statuses greater than OK Use if the provider CI does not really impact the status of the consumer, but requires a warning status if it has a problem.
JUST_INFO	Propagates the Info status for any statuses greater then, or equal to Info. The None status is propagated for any status less than Info. Use if the provider CI does not really impact the status of the consumer, but requires an Info status if it has a problem.