Product documentation Docs
    • English
    • Deutsch
    • 日本語
    • 한국어
    • Français
  • More Sites
    • Now Community
    • Developer Site
    • Knowledge Base
    • Product Information
    • ServiceNow.com
    • Training
    • Customer Success Center
    • ServiceNow Support Videos
  • Log in

Product documentation

  • Home
How search works:
  • Punctuation and capital letters are ignored
  • Special characters like underscores (_) are removed
  • Known synonyms are applied
  • The most relevant topics (based on weighting and matching to search terms) are listed first in search results
Topics are ranked in search results by how closely they match your search terms
  • A match on the entire phrase you typed
  • A match on part of the phrase you typed
  • A match on ALL of the terms in the phrase you typed
  • A match on ANY of the terms in the phrase you typed

Note: Matches in titles are always highly ranked.

  • Release version
    Table of Contents
    • IT Operations Management
Table of Contents
Choose your release version
    Home Paris IT Operations Management IT Operations Management ITOM Health Event Management Administer events Event rules Alert binding to CIs with event rules

    Alert binding to CIs with event rules

    • Save as PDF Selected topic Topic & subtopics All topics in contents
    • Unsubscribe Log in to subscribe to topics and get notified when content changes.
    • Share this page

    Alert binding to CIs with event rules

    When alerts are associated with CIs, the task of remediation is simplified. During alert generation, Event Management uses event rules and other mechanisms to automatically bind alerts to CI information from the CMDB. For tracking purposes and remediation, the alert shows information about the CI that caused the event.

    Alert binding process flow

    Alerts bind to CIs based on the following process flow:
    1. When an event arrives, Event Management checks the node or CI identifiers.
    2. If no node exists, the generated alert can bind to the CI using the alert Type, Additional information, or Configuration item identifier fields.
    3. If the event has a node value, search for a valid host.
    4. If the event has a host and a CI type, try to bind to a device CI.
    5. If the event has a host, try to bind to the application CI.
    Figure 1. How alerts bind to CIs

    The event can contain the binding process flow in its Processing Notes field.

    By default, events do not bind to CIs with a specified status, such as Retired. To enable binding events to these CIs, set the evt_mgmt.ignore_retired_cis_in_binding property to false.

    To specify the CI statuses to be included in the evt_mgmt.ignore_retired_cis_in_binding property, add the relevant status numbers to the evt_mgmt.install_status_list_to_ignore_in_binding property, as per the following table:

    Table 1. CI Statuses
    Status Number Status
    1 Installed
    2 OnOrder
    3 InMaintenance
    4 PendingInstall
    5 PendingRepair
    6 InStock
    7 Retired
    8 Stolen
    100 Absent
    Note: When adding more than one status, separate each status number with a comma.

    Tracking and remediation

    Alerts can be bound to CIs from the CMDB for tracking purposes and remediation. Event Management uses event rules and various mechanisms to automatically bind CIs to alerts. When information from an event populates a field with a value, the value either originates from the event source or from event rules. This enhances remediation, functionality, and integration with other ITOM products.

    Binding to an application running on a specific host

    If the event is specific to an application type, use the following steps to bind alerts to a specific application:
    1. Use the procedures in the Bind alerts to a host CI topic.
    2. Create an event rule with a filter that captures events on the application type you want.
    3. In the event rule, select Binding. Event Management binding
    4. Click Override default binding.
    5. In the Binding Type field, select either CI's Identification or CI field matching.
      1. For CI's Identification, specify the Class. Event Management binding
      2. In the Criterion attributes field, specify name and sys_class_name.

        Event Management binding

      3. In the Name Add Value field, specify the required name.
      4. In the Container level 1 area, specify the required values.
      5. If further container level fields appear, specify the required values.
    • For CI field matching, specify the required CI Type.
    • In the binding process, after the host is found, the algorithm matches all additional_info attributes that have the same name as CI fields for that CI type. If the match is successful, the event is bound to the CI.
    • If more than one matching application is found on the host, the alert is bound to the host and not to the application.
    Where there is no CI Type, for example, when binding alerts to an SQL server application when the CPU on sqlServer.exe is over 90%, do the following:
    • Populate the Node field in the event with the CI name, FQDN, IP, or MAC address value. The bind is successful even if the host has more than one IP address or MAC address.
    • If you want to use a unique identifier that is not one of those previously mentioned, populate the event rule CI Identifier (ci_identifier) field with one or more unique identifiers of the CI. This field should be in JSON format. For example, to use a unique identifier that is not one of those previously mentioned, add a CI Identifier (ci_identifier) filter field with one or more unique identifiers of the CI. If the host CI is VMWare VM, and it has a field called MOID, use the JSON format and specify: {"moid":"<CI moid>"}
    • Create an event rule with an event match field which maps the process name to the mapping variable sa_process_name. In this case, do not use the CI type.

    Binding procedures

    Use the procedures in these topics to bind alerts.
    • Bind alerts to a host CI

      You can create an event rule to bind alerts to host CIs.

    • Bind alerts to a specific host CI

      You can create an event rule to bind alerts to the correct device CI. An incoming event from a device CI can bind to an alert based on event rule transform information. However, first identify the host CI that the device is running on.

    • Bind alerts for non-host CIs

      An incoming event from a discovered application service or alert group can bind to an alert based on an event rule and the corresponding event field mapping. The event field mapping requires a URL or the port number and corresponding IP address for each service or alert group.

    • Bind alerts for application CIs

      An incoming event from an application CI can bind to an alert based on event rule transform information. Create an event rule to bind alerts to the host CI and also to the application CI.

    • Bind alerts to CIs using event field mapping

      Instead of creating separate event rules for each CI you want to bind to an alert, you can use event field mapping to bind an alert to multiple event CIs.

    • Trigger alerting bind to a CI

      You can manually bind an alert to a CI by triggering a new alert.

    Related concepts
    • Event field format for event collection

    Tags:

    Feedback
    On this page

    Previous topic

    Next topic

    • Contact Us
    • Careers
    • Terms of Use
    • Privacy Statement
    • Sitemap
    • © ServiceNow. All rights reserved.

    Release version
    Choose your release version

      Alert binding to CIs with event rules

      • Save as PDF Selected topic Topic & subtopics All topics in contents
      • Unsubscribe Log in to subscribe to topics and get notified when content changes.
      • Share this page

      Alert binding to CIs with event rules

      When alerts are associated with CIs, the task of remediation is simplified. During alert generation, Event Management uses event rules and other mechanisms to automatically bind alerts to CI information from the CMDB. For tracking purposes and remediation, the alert shows information about the CI that caused the event.

      Alert binding process flow

      Alerts bind to CIs based on the following process flow:
      1. When an event arrives, Event Management checks the node or CI identifiers.
      2. If no node exists, the generated alert can bind to the CI using the alert Type, Additional information, or Configuration item identifier fields.
      3. If the event has a node value, search for a valid host.
      4. If the event has a host and a CI type, try to bind to a device CI.
      5. If the event has a host, try to bind to the application CI.
      Figure 1. How alerts bind to CIs

      The event can contain the binding process flow in its Processing Notes field.

      By default, events do not bind to CIs with a specified status, such as Retired. To enable binding events to these CIs, set the evt_mgmt.ignore_retired_cis_in_binding property to false.

      To specify the CI statuses to be included in the evt_mgmt.ignore_retired_cis_in_binding property, add the relevant status numbers to the evt_mgmt.install_status_list_to_ignore_in_binding property, as per the following table:

      Table 1. CI Statuses
      Status Number Status
      1 Installed
      2 OnOrder
      3 InMaintenance
      4 PendingInstall
      5 PendingRepair
      6 InStock
      7 Retired
      8 Stolen
      100 Absent
      Note: When adding more than one status, separate each status number with a comma.

      Tracking and remediation

      Alerts can be bound to CIs from the CMDB for tracking purposes and remediation. Event Management uses event rules and various mechanisms to automatically bind CIs to alerts. When information from an event populates a field with a value, the value either originates from the event source or from event rules. This enhances remediation, functionality, and integration with other ITOM products.

      Binding to an application running on a specific host

      If the event is specific to an application type, use the following steps to bind alerts to a specific application:
      1. Use the procedures in the Bind alerts to a host CI topic.
      2. Create an event rule with a filter that captures events on the application type you want.
      3. In the event rule, select Binding. Event Management binding
      4. Click Override default binding.
      5. In the Binding Type field, select either CI's Identification or CI field matching.
        1. For CI's Identification, specify the Class. Event Management binding
        2. In the Criterion attributes field, specify name and sys_class_name.

          Event Management binding

        3. In the Name Add Value field, specify the required name.
        4. In the Container level 1 area, specify the required values.
        5. If further container level fields appear, specify the required values.
      • For CI field matching, specify the required CI Type.
      • In the binding process, after the host is found, the algorithm matches all additional_info attributes that have the same name as CI fields for that CI type. If the match is successful, the event is bound to the CI.
      • If more than one matching application is found on the host, the alert is bound to the host and not to the application.
      Where there is no CI Type, for example, when binding alerts to an SQL server application when the CPU on sqlServer.exe is over 90%, do the following:
      • Populate the Node field in the event with the CI name, FQDN, IP, or MAC address value. The bind is successful even if the host has more than one IP address or MAC address.
      • If you want to use a unique identifier that is not one of those previously mentioned, populate the event rule CI Identifier (ci_identifier) field with one or more unique identifiers of the CI. This field should be in JSON format. For example, to use a unique identifier that is not one of those previously mentioned, add a CI Identifier (ci_identifier) filter field with one or more unique identifiers of the CI. If the host CI is VMWare VM, and it has a field called MOID, use the JSON format and specify: {"moid":"<CI moid>"}
      • Create an event rule with an event match field which maps the process name to the mapping variable sa_process_name. In this case, do not use the CI type.

      Binding procedures

      Use the procedures in these topics to bind alerts.
      • Bind alerts to a host CI

        You can create an event rule to bind alerts to host CIs.

      • Bind alerts to a specific host CI

        You can create an event rule to bind alerts to the correct device CI. An incoming event from a device CI can bind to an alert based on event rule transform information. However, first identify the host CI that the device is running on.

      • Bind alerts for non-host CIs

        An incoming event from a discovered application service or alert group can bind to an alert based on an event rule and the corresponding event field mapping. The event field mapping requires a URL or the port number and corresponding IP address for each service or alert group.

      • Bind alerts for application CIs

        An incoming event from an application CI can bind to an alert based on event rule transform information. Create an event rule to bind alerts to the host CI and also to the application CI.

      • Bind alerts to CIs using event field mapping

        Instead of creating separate event rules for each CI you want to bind to an alert, you can use event field mapping to bind an alert to multiple event CIs.

      • Trigger alerting bind to a CI

        You can manually bind an alert to a CI by triggering a new alert.

      Related concepts
      • Event field format for event collection

      Tags:

      Feedback

          Share this page

          Got it! Feel free to add a comment
          To share your product suggestions, visit the Idea Portal.
          Please let us know how to improve this content

          Check any that apply

          To share your product suggestions, visit the Idea Portal.
          Confirm

          We were unable to find "Coaching" in Jakarta. Would you like to search instead?

          No Yes
          • Contact Us
          • Careers
          • Terms of Use
          • Privacy Statement
          • Sitemap
          • © ServiceNow. All rights reserved.

          Subscribe Subscribed Unsubscribe Last updated: Tags: January February March April May June July August September October November December No Results Found Versions Search preferences successfully updated My release version successfully updated My release version successfully deleted An error has occurred. Please try again later. You have been unsubscribed from all topics. You are now subscribed to and will receive notifications if any changes are made to this page. You have been unsubscribed from this content Thank you for your feedback. Form temporarily unavailable. Please try again or contact  docfeedback@servicenow.com  to submit your comments. The topic you requested does not exist in the release. You were redirected to a related topic instead. The available release versions for this topic are listed There is no specific version for this documentation. Explore products Click to go to the page. Release notes and upgrades Click to open the dropdown menu. Delete Remove No selected version Reset This field is required You are already subscribed to this topic Attach screenshot The file you uploaded exceeds the allowed file size of 20MB. Please try again with a smaller file. Please complete the reCAPTCHA step to attach a screenshot
          Log in to personalize your search results and subscribe to topics
          No, thanks Login