CI Resolution

The CI Resolver uses the following strategy to identify the CI that matches an event. The first match from this list of possible matches is used by the CI Resolver to identify the CI to which the event should be paired.

1. Event contains a CI reference. The CI is identified directly from this information and no resolution is necessary. Few events, except for some internal Operations Management events, include a direct reference to the matching CI.

2. CiInfo custom attribute of the event contains a valid RTSM ID, RTSM Global ID, SiteScope monitor ID, or an HPOM Agent ID which identifies the related CI. This match is common for events from HPOM SPIs.

   Note: If CiInfois set, the CI Resolver uses this attribute to identify the CI and then stops the resolution, even if CiInfo does not produce a match.

3. Event Service ID matches a service name that can be mapped by Topology Synchronization into a valid RTSM ID or RTSM Global ID. This match is common for events from HPOM SPIs.

   Topology Synchronization provides a mapping table that enables the CI Resolver to map Service IDs directly to RTSM IDs if the service was synchronized by Topology Synchronization.

4. Split Service ID into keywords and hostedOn information, and identify the best-fit CI.

5. Use application and object fields and host info and identify best-fit CI

   In this context, Service ID is the HPOM message Service ID.

CI hints can be provided in a number of forms.

The custom attribute is evaluated before the Service ID, ensuring that the Service IDs is overridden by the custom attribute values when available.

RTSM IDs

Format: UCMDB:<id>

Example: UCMDB:3bcbb67a6233cfdd0e400e7c1e637db5

RTSM Global IDs

Format: GUCMDB:<id>

Example: GUCMDB:4acdd67a5433cfaa0b600e7c1e667db9

If a UUID prefixed by the string UCMDB: or GUCMDB: is found, it is assumed to be a native RTSM ID or RTSM Global ID. If the CI Resolver can match the ID to a CI in the RTSM, the CI reference is set to this ID. This is the fastest and most accurate method.

SiteScope Monitor IDs

Format: SiteScope:<session_id>:<monitor_id>

SiteScope:12:2

If a SiteScope ID (SiteScope:<session_id>:<monitor_id>) is found, and if the CI Resolver can match the ID to a CI in the RTSM, the CI reference is set to the CI that is monitored by the SiteScope monitor.

HPOM Agent IDs

OmCoreId:<omagentid>

If an HPOM Agent Core ID is found, and if the CI Resolver can match the ID to a CI in the RTSM, the CI reference is set to the agent CI.

Service IDs

OSSPI:svc:fs:/dev/hda@@dbsystem.example.com

A traditional service name as used by HPOM Smart Plug-ins. If this service was synchronized by Topology Synchronization and a corresponding CI was created in the RTSM, the CI Resolver can use this information to directly map the event to the CI. If not, then the service ID is split into keywords.

Natural keys:

CiHint:oracle:database:CMDBDB@@dbsystem.example.com

or

oracle:database:CMDBDB@@dbsystem.example.com

If there is no exact knowledge about the target CI, a list of keywords (usually separated by colons in the message) is extracted from the message. The node name that contains the expected CI is specified after the @@ separator.

In our example, we are trying to find an Oracle Database instance called CMDBDB that is running on the node called dbsystem. The node information is important since there may be many occurrences of the Oracle Database instance called CMDBDB installed on different nodes. This information is used by the CI Resolver to find the best match by comparing these keys with the attribute information of the CIs in the RTSM.

As for a set of natural keys but for an unhosted CI:

mailservice:northamerica

For CIs that are not related to a node, like the email service provided for the northamerica region. To indicate that there is no hosted on information, the @@ separator must be omitted.

If the CI Resolver receives a hint with one or more keywords containing the separation character (default :), the keyword is not assessed as desired because it is divided into two or more incomplete keywords. The separation character is not considered part of the keyword.

IPv6 Hint Resolution

IP addresses can be included as hints. If you are specifying an IPv6 address, enclose it in quotation marks ("..."). For example:

• "<IPv6address>":NETIF@@<hostname>.example.com
• <hint1>:<hint2>@@"<IPv6address>"

RTSM ID Hint Resolution

Some data sources can provide the RTSM ID as a CI hint. However, when forwarding events to another BSM system, this ID might not be known to the second RTSM instance. For such cases, multiple CI hints, including the RTSM Global ID can be sent. If the first hint does not provide a match, the next hint is examined.

When an event is forwarded by Operations Management, the RTSM Global ID is added automatically as an additional hint.

Multiple CI hints are specified using the following format:

<CiHint1>|<CiHint2>|...

where <CiHintX> can be one of the following:

• UCMDB:<RTSM_ID>

• GUCMDB:<RTSM_Global_ID>

• SiteScope:<session_id>:<monitor_id>

• OmCoreId:<omagentid>

• CiHint:<hint1>:<hint2>:...@@<node>

Example:

GUCMDB:4acdd67a5433cfaa0b600e7c1e667db9|c@@dbsystem.example.com

The CI Resolver first checks whether there is a CI with the given RTSM Global ID. This ID usually provides a match as the Global ID should be synchronized across all RTSM instances. If the Global ID is not found, the natural hint (c@@dbsystem.example.com in the example above) is used.

ETI Hint Resolution

The ETI hint field is also used for the matching of a CI by CI resolution. If the ETI hint matches the ETI of a CI, this CI is given a higher match rating.

For example, if the CI hint matches a number of CPU CIs and Node CIs, and it has an ETI hint Memory Load:Critical, CIs with this ETI are given given a higher match rating.

The host CI can usually be identified as long as the host information is available as a normal hint. Ideally, the @@node notation (an @@ separator with a specified node) is used to identify the node on which the CI is hosted. However, it can be difficult to uniquely match a dedicated CI if a hosted and a non-hosted CI have very similar attributes. If the @@node notation is not used, the first match found is accepted and this may not be the correct CI.

For example, only the hint CiHint:sendmail is received. If a sendmail service and a sendmail process exist, the CI Resolver is not able to differentiate between them because it does not differentiate between the hosted-on and not hosted CIs.

To differentiate between them, use:

CiHint:sendmail@@mailserver.example.com — to identify the sendmail process running on the mailserver.example.com node.

StrictCiHint:sendmail — to identify the sendmail service. To match, the sendmail CI must not have a hosted-on CI.

The hostedOn information is very important for correctly identifying a CI, and an attempt is made to resolve the node for each CI from the RTSM. The hostedOn information is derived by traversing all parent compositions of a CI until a node CI is found. The hostname of this node is used as the hostedOn information. When an event is received by Operations Management, the node info value of the CI is compared to the hostedOn information of a CI. If they match, the CI is used as a matching candidate.

The CI Resolver is used to update the node reference of an event.

The hints used to identify the related CI, node, source CI and ETI of an event are displayed in the Resolver Hints tab of the Event browser. See Resolver Hints Tab for details.

The following hints are examined in this order to identify a related Node CI:

• HostInfo event attribute

  HostInfo is an attribute from the HPOM agent to identify a target host. It usually contains the fully qualified domain name or the IP address of a host.

• CiInfo custom attribute

  CiInfo contains node information after the @@ separator in the event text.

• Service ID event attribute

  Service ID node information after the @@ separator in the event text.

  The node reference is retrieved from the RTSM as follows:

  1. Fully qualified domain name (primary_dnsname)

  2. IP address taken from the related ip_address in the RTSM:

     • ip_address.authoritative_dns_name attribute

     • ip_address.ip_address attribute

  3. HPOM core ID. A name attribute taken from the related hp_operationsagent CI in the RTSM.

The HostInfo is an attribute from the HPOM agent to identify a target host. It usually contains the fully qualified domain name or the IP address of a host.

The Service ID event attribute and the CiInfo custom attribute contain node information after the @@ separator in the event text.

The node reference is resolved as follows:

1. Fully qualified domain name (primary_dnsname)

2. IP address taken from RTSM

   1. ip_address.authoritative_dns_name

   2. ip_address.ip_address

3. HPOM core ID taken from the RTSM entry hp.operationsagent.name.

Source CI resolution is used to identify the event source CI and uses the SourceHint attribute of an event. The format of the SourceHint must be the same as that of the normal CI resolution.

The CI Resolver extracts information about potential candidate CIs from the RTSM using a TQL query and maintains this information in a cache. You can either provide a custom TQL query or use the OMiAutoView feature to automatically generate a suitable TQL.

The OMiAutoView feature selects all CIs and all Service Level Agreements, and queries almost all attributes that are potentially useful for resolving CIs.The attributes that are not queried are excluded using the Cache Modification Configuration.

If you are using the TQL query generated by OMiAutoView, to maximize performance, it is also possible to restrict the total number of CIs held in the cache, and restrict the CI types to those most helpful for CI resolution. Configuring the restriction of CIs and CI types is achieved using the following CI Resolver Settings:

• CI Limit — used to limit the number of CIs loaded into the cache, if loaded by the TQL query generated by OMiAutoView.

• Cache Modification Configuration — used to specify which CI types and attribute types to exclude from the cache, and, if there are too many CIs being loaded into the cache, which CI types to use for CI resolution.

For detailed information, see CI Resolver Settings.

There are two cache types, enabling you to decide whether the cache is kept on disk or in main memory:

• Database — It is recommended to use the Database cache type. CI resolution maintains only the most often-used CIs in RAM. All other required CIs are maintained in a cache file. This option requires considerable extra disk space but results in a lower memory footprint. A small impact on CI resolution performance may be noticeable.

• In Memory — It is recommended to select the In Memory cache type when maximizing event throughput is essential. CI resolution maintains all CIs in RAM. Only use this setting when there is sufficient RAM available.

For information about all the CI Resolver Settings, see CI Resolver Settings.

Maintaining very large numbers of CIs in cache requires large amounts of RAM and also has an affect on performance. Controlling the maximum number of CIs held in cache reduces this load and is achieved by ignoring less relevant attributes and CI types normally selected using the OMiAutoView-generated TQL query. The CI types to be ignored are set in the Cache Modification Configuration setting. You can also specify which CI type should be permitted to be used for CI resolution and in which order they are to be evaluated.

The CI Resolver Cache Modification Configuration settings specify three types of information:

• <IgnoreCiType> — Contains a list of CI types to always be ignored.

If a CI type is specified to be ignored, it is always ignored by the CI Resolver. For example, if you know that you don't receive SAP events, but you have SAP CIs in your RTSM, then you can ignore the SAP CI types, reducing the size of the CI Resolver cache.

• <WhiteListCiType> — Contains a list of CI types that are always required.

If there are too many CI Types to be included in the available cache capacity, the CI types specified in the whitelist are included in the order that they are listed. As soon as it is no longer possible to include the CIs of the next CI type in the list, that CI type and all subsequent CI types in the whitelist are also ignored.

• <IgnoreAttribute> — Contains a list of attributes that are always ignored.

If an attribute is specified to be ignored, it is always ignored by the CI Resolver. You should ignore attributes that not suitable for identifying CIs.

The following is an example of the structure of the CI Resolver Cache Modification Configuration settings

<?xml version="1.0" encoding="UTF-8" ?>
<CiResolver>

  <IgnoreCiTypes>
    <IgnoreCiType>service_address</IgnoreCiType>
    <IgnoreCiType>installedsoftware</IgnoreCiType>
    ...
  </IgnoreCiTypes>

  <WhiteListTypes>
    <WhiteListCiType>node</WhiteListCiType>
    <WhiteListCiType>ip_address</WhiteListCiType>
    <WhiteListCiType>business_element</WhiteListCiType>
    ...
  </WhiteListTypes>

  <IgnoreAttributes>
    <IgnoreAttribute>ip_probename</IgnoreAttribute>
    <IgnoreAttribute>ip_isbroadcast</IgnoreAttribute>
    ...
  </IgnoreAttributes>

</CiResolver>


To configure CI resolution to minimize the type and number of CI and attributes held in the cache, see How to Configure CI Resolution Cache Usage.

If the OMiAutoView TQL does not meet your requirements, you can implement a custom TQL query, ensuring that it meets the following requirements:

• CIs that are contained within a node must have a direct or transitive Composition relationship to the node. For the IpAddress CI type, the relationship type must be Composition.

• In the TQL, the node must have one of the following attributes:

  • Primary Node DNS name

  • Association with one or more IP addresses (IpAddress with a Containment relationship)

• At least CI type, data name, and label of the CI must be visible.

• HPOM Agents must have Core ID value.

• Site Scope Monitors or performance measures must have a monitored_by relationship to the monitored CI. The monitor_id and session_id must be visible.

   

You can configure CI resolution enrichment rules to enrich the CI resolution cache with additional keywords for a specific CI. These keywords are provided by another CI in their neighborhood. To enrich a CI, you can use the tuneCache setting in the Settings Manager by adding an XML item <Enrichment> for an enrichment rule.

Rule Syntax

Enrichment is used to mark a CI with keywords that differentiates the CI from other CIs. This enables the use of the enriched keyword as a hint in an event.

An enrichment rule follows the syntax:

[<source ci type>].(from|to:<relationship type>.[<intermediate ci type>].)+[<target ci>].<attribute name>

The direction identifier before each reference indicates the direction of that reference (from = incoming or to = outgoing).

Supported Types & Operators

[Operators] and [Types] are combined to form a valid CI Resolution enrichment rule.

Examples of supported operators:

• containment

• composition

• monitored_by

• dependency

Supported relation directions:

• to

• from

Supported types:

• [<CITypeName>]

Supported types are any CI types contained in the RTSM, specified within squared brackets. The CI Type's name attribute is the value to put into the squared brackets, for example, [host] or [sitescope_monitor].

Keyword	Description	Example
from|to:<reference>	Follow the relationship of a CI to its neighbor CI by a given direction. from = incoming to = outgoing	from:monitored_by
[<Ci type name>]	Set the CI type.	[dbtable]
<CI type property name>	Property of the CI type.	[dbtable].name

Example Rule:

Assume that you have two Oracle databases, DB1 and DB2 on one system. Both databases have a dbtable CI with the name USER.

CI resolution cannot identify from which CI the event originated using the information available within the hint because the two dbtable CIs can only be differentiated by their parent CI relationship (DB1 and DB2). This information must be added by enrichment. Typically, a related CI hint would look like the following:

USER@@dbsystem.example.com

However, this does not work because the database name is not known.

However, if CI resolution is enriched with the database instance name using a CI resolution enrichment rule, it is possible to run a CI resolution successfully when the event also provides the DB instance name.

Enrichment rule:

To enrich a dbtable CI type with additional information about the CI type host name attribute, you can use the following rule.

[dbtable].from:composition.[oracle].name

A CI resolution enrichment rule can be specified to enrich the keywords cache to also include keywords from the parent CI. In this way, it is possible to resolve the correct dbtable CI if the event also provides the database instance name.

USER:DB1@@dbsystem.example.com

For information about CI resolution configurations, see CI Resolver Settings.