Metric-to-CI binding

  • Release version: Australia
  • Updated July 20, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Metric-to-CI binding

    Metric-to-CI binding associates metrics collected by pull connectors with configuration items (CIs) in the Configuration Management Database (CMDB). This association enables you to link performance and operational metric data directly to the corresponding CIs, improving visibility and management of your IT environment. The platform uses default binding logic for supported connectors, which you can customize if needed.

    Show full answer Show less

    How Metric-to-CI Binding Works

    • The pull connector gathers metric data from external vendors and stores it in the metric base (Clotho).
    • If a metric has not been bound to a CI, the system generates an event to request binding.
    • An event field mapping rule triggers on this event and calls a scripted extension to resolve the appropriate CI.
    • The resolved CI is updated on the event’s cmdbci field, and the binding is recorded in the Metric to CI mappings table.
    • Subsequent metrics for the same source-resource pair are directly associated with the bound CI without creating new events.
    • If no CI is resolved, the metric remains unbound in the metric base.

    Default Behavior for MPN Metrics

    No additional configuration is needed for CI binding with MPN metrics. The built-in NokiaMPNMetricCIMapper scripted extension resolves CIs by checking event fields in a specific order, using values like additionalinfo.name, distinguished names, serial numbers, hardware IDs, and aliases. The lookup searches the CMDB tables accordingly and stops at the first successful match.

    This mechanism ensures accurate binding to CIs based on various identifiers present in the metric events.

    Customizing Metric-to-CI Binding

    If the default binding logic does not fit your CMDB data model or connector source, you can override it by implementing your own EventFieldMapping extension. This allows you to provide custom resolution logic without altering the product code. The platform dynamically resolves your custom implementation at runtime by source and rule name, enabling flexible and tailored metric-to-CI associations.

    Practical Benefits for ServiceNow Customers

    • Automates the association of metric data with CMDB CIs, improving data accuracy and operational insight.
    • Supports out-of-the-box binding for common connectors like MPN, reducing setup effort.
    • Offers extensibility to adapt to your unique CMDB structure and data sources.
    • Enables enhanced monitoring, reporting, and troubleshooting by linking performance metrics directly to infrastructure components.

    Metric-to-CI binding associates metrics collected by a pull connector with configuration items (CIs) in the Configuration Management Database (CMDB). Default binding logic is used for each supported connector, which you can override with a custom implementation.

    How metric-to-CI binding works

    When a metric is collected, the platform runs the following sequence to associate each metric with a CMDB CI:

    1. The connector pulls metric data from the vendor and stores it in the metric base (Clotho).
    2. If the metric is not yet bound to a CI, the metric base framework automatically creates an event to record the request for a binding.
    3. An event field mapping rule fires on the new event. Telecommunications Service Operations Management ships pre-configured event field mapping rules for each supported connector source.
    4. The rule delegates to a scripted extension that resolves the appropriate CI for the event. The script updates the cmdb_ci field on the event with the resolved CI.
    5. The binding appears in the Metric to CI mappings table. From that point on, all subsequent metric data for that source-resource pair is associated with the bound CI directly, without creating another event.

    If the scripted extension can't resolve a CI, the event's cmdb_ci field is left empty and the metric data is stored in the metric base unbound.

    Default behavior for MPN metrics

    No additional configuration is required for CI binding. A scripted extension named NokiaMPNMetricCIMapper handles metric-to-CI binding for the MPN pull connector by firing on matching events through an event field mapping rule.

    The extension tries the following event fields in order, stopping at the first match. The first lookup uses the CMDB table named in additional_info.ciClass on the event (defaulting to cmdb_ci); the remaining lookups always run against cmdb_ci:

    Table 1. MPN metric event CI lookup order
    Order Event field Lookup behavior
    1 additional_info.name Matched against name on the class specified by additional_info.ciClass
    2 additional_info.pmDataSource.dn Distinguished name traversal in cmdb_ci. The deepest matching component wins
    3 additional_info.pmDataSource.serial_no Matched against serial_number in cmdb_ci
    4 additional_info.pmDataSource.hw_id Matched against name in cmdb_ci
    5 additional_info.pmDataSource.nhg_alias Matched against name in cmdb_ci

    The additional_info.name and additional_info.pmDataSource.dn fields can each hold a comma-separated list of values. The extension tries the values from right to left, and the first value that resolves to a CI wins.

    On a match, the extension sets the cmdb_ci and ci_type fields on the event.

    Override the default binding behavior

    If the shipped lookup logic does not match how your CMDB models the source data, you can override it by providing your own implementation of the EventFieldMapping extension point. The platform resolves the implementation at runtime by source name and rule name, so you can substitute your own logic without modifying product code.

    For the procedure, see Override default metric-to-CI binding.