Next steps in service modeling

This section discusses the modeling steps that must be undertaken after a basic service model has been implemented.

Associating monitor instances with CIs

By default, monitor instances are associated with the computer system configuration item (CI) that corresponds to the device on which the monitor is defined. When you create CIs to represent the higher-level infrastructure that is running on the computer system and/or is supporting different applications, you might want to associate monitor instances related to those higher level entities with the new CIs.

• This will associate any problems detected (and events generated) by those monitor instances with the new higher-level CI instead of the computer system CI.
• The impact of those problems is propagated only up to the application that the new-higher level CI supports instead of all of the applications that the underlying computer system may support.

You can associate monitor instances with CIs in the Services Editor tab of the Administration Console. You can search for the CI you want to associate the monitor instances with, right-click that CI, and select Associate Monitors. For more information, see the Associate monitors with CIs through the administrator console.

Associating external events with CIs

Associating events to CIs is what causes the status of a CI to be updated. The highest severity of the events associated with the infrastructure CI is used to set the status of the CI. That status is propagated up through impact relationships to the higher-level CIs to update their status.

Only events generated for monitor instance threshold alarms and abnormalities are automatically associated with the CI with which the monitor instance is associated.

Events from external sources, including directly from BMC PATROL Agents, are associated with CIs through the use of unique aliases that are specified for each CI. If no CI with matching aliases is found, default rules are used to associate the events with the computer system from which the events are sent.

Events can either include the component alias for associating with a CI or the alias can be generated by alias formulas that format the alias from other information in the events.

When events that require alias processing enter the cell (event processor), if the event does not contain an alias set by the event source, then the cell uses the values in the event’s slots to construct an alias. The cell then searches for this alias in the CIs in the service model. When a match is found, the event is associated with the CI and the instance’s impact status is updated based on the configuration in the service model.

Component Aliases

A component alias is a unique value that identifies a CI and is used to map events to the CI. A CI may have multiple aliases, but each alias must be unique across all CIs.

Consider the following requirements when creating aliases:

• The aliases used for a CI depend on the event sources for that CI because a CI alias has to match the alias in an event for the event to get associated with the CI.
• Aliases must be unique values that can be automatically constructed from event sources (either directly or generated from other event slot values). This makes it possible to create aliases for dynamic CIs (for example, in VMs) that vary with different host names.
• Aliases can either be set directly in the events by the event source or be generated by an alias formula that formats the alias from other information in the events.
• Keep the number of aliases per CI to a minimum.
• Use generic values for the aliases that can be used regardless of the event source.
• Aliases are case-sensitive, so use a standard convention for setting the case of the aliases.

Aliases can be automatically generated by specifying custom Normalization Engine rules in BMC Atrium CMDB. For more information on this see, Configuring Custom normalization rules.

The following table lists some recommended naming conventions for aliases.

Alias formulas

Events that do not have the alias set at the event source must have the alias generated by an alias formula that formats the alias from other information in the events. At present, this includes all events external to Infrastructure Management, unless:

• The mapping in the event adapters includes setting of the mc_sm_alias slot
• There is some MRL code that generates the alias

Alias formulas define the criteria for matching an event and a format pattern that can substitute values from the event to generate an alias. The criteria for matching an event is based on comparisons with the event class, host class, host name, host address, object class, object, and parameter slots. The cell (event processor) evaluates the alias formulas for events that do not have an alias set prior to attempting to associate the event with a CI. Because multiple alias formulas may match an event, the criteria in the formula is evaluated to find the most specific match against each event.

For example, if you have a PATROL_EV class event with mc_object_class=“Oracle”, mc_object set with the database instance name, and mc_host set with the host name:

• Define an alias formula with matching criteria for the PATROL_EV event class and mc_object_class=“Oracle”
• Set the formula format string to 'sprintf("%s::ORA_DB::%s",[PN90BPDRAFT:$1.mc_host,$1.mc_object])’ (<mc_host>::ORA_DB::<mc_object>)

Consider the following when defining alias formulas:

• An alias formula is needed for any event that needs to be associated with CIs that do not have the alias set by the event source.
• Alias formulas for a parent event class must match against any event classes that inherit from the parent class.
• Alias formulas must be defined for the parent event class level where the slots in the descendent classes provide the same information needed to format the alias.
• Alias formulas must be defined with criteria specific enough to match all events for which the specific alias format pattern must be used.
• Alias formulas must be defined with more generic criteria to catch events that do not match the more specific criteria.

Alias formulas are defined in the administration console. For more information, see the Associating events to devices with the administrator console, Alias formulae, and Associate monitors with CIs through the administrator console.

Expanding the model

Modeling to higher levels

Modeling only up to the application level is good if you are only ready for, or are only interested in, managing the IT infrastructure at the application level, or as a first step when planning to model to higher levels. If (or when) you want to manage your IT infrastructure from the perspective of higher level business services that the infrastructure supports or the organizations and users that use those services, then you must add the CI levels for those entities.

The CIs that are commonly used to represent these higher level constructs are:

• Technical Service (BMC_BusinessService class, ServiceType=TechnicalService)
  • Used to represent a technical service, which may be composed of several applications
  • May have nested Technical Services, as needed
• Business Service (BMC_BusinessService class, ServiceType=BusinessService)
  • Used to represent the high level business service that is being utilized by customers (other organizations, end users, and so on)
  • May have nested Business Services as needed to represent other business services that may be utilized independently but support the higher level service
• Organization (BMC_Organizationclass)
  • Used to represent any type of organization, internal or external (companies, business units, departments, and so on)
  • For multitenancy, setting the isTenant attribute to true indicates that the organization is a tenant
• User Community (BMC_UserCommunityclass)
  • Used to represent a set of users, usually external, that use the service (customers, users in New York, users in Europe, and so on)
• Location (BMC_PhysicalLocationclass)
  • Used to represent locations (sites, states, regions, countries, and so on)

Increasing the granularity of the model

Apart from dealing with shared resources and clustered resources, you may want to insert more CIs to represent the application servers, database servers, and other servers that support the applications being modeled.

Some general guidelines for increasing the granularity of the model are:

• Use the CI classes that are necessary to model the real environment.
• Do not make the service model too granular or detailed.
  For example, do not include NICs and other hardware components (such as hard drives, CPUs, or memory), or the operating system in the service model as separate CIs from the Computer System CI.
• Limit maximum depths to 10-12 levels.

It is best to use BMC Atrium Discovery and Dependency Mapping, or another discovery tool, as much as possible to generate and maintain the infrastructure levels of the impact models so that changes in the environment are automatically reflected in the models.

The following table lists some of the recommended CI classes (and subtype settings) used to represent the IT infrastructure components in your environment:

Priority & Priority Propagation

The figure below is an example of a priority being propagated from the service down to the impacting CI.

Priority

The services and applications in your environment may not all have the same importance. Set the priority of top or higher level CIs to indicate the relative importance of that entity in your environment. The lower the priority number, the higher the importance. 1 is the highest priority, 5 is the lowest and the default priority.

Priority propagation

When a problem on a low-level component impacts a high priority service, you want that problem to be fixed before a problem that only affects a low priority service. Priority propagation aids this by propagating the priority of the service down to the CI that is causing the impact and on to the events reporting the problem.

You can set a CI to propagate its priority by setting the Propagates Priority attribute to Yes.