Binding alerts to a specific host CI (default binding)
Summarize
Summary of Binding alerts to a specific host CI (default binding)
Binding alerts to Configuration Items (CIs) using the Node field or the CI Identifier field in event records ensures accurate association of alerts with the correct host CIs. This precise binding enhances incident response, root cause analysis, and impact assessment by clearly identifying affected assets.
Show less
How Default Binding Works
The system primarily uses the Node field from the event record to associate alerts with host CIs. Since the CI itself does not have a Node field, the Node value from the event is compared against host CI attributes such as Name, Fully Qualified Domain Name (FQDN), IP address, or MAC address. If a match is found, the alert is linked to that host CI.
The binding process applies only to host CIs, which include Computers, Operating Systems, Switches, Routers, or any hardware component extending the cmdbcihardware table.
The system respects the sa.activeoperationalstatus property during binding, which controls which host operational statuses are considered valid. By default, only hosts with status "Operational" (value 1) are eligible. This property can be customized to include additional statuses, such as Non-operational or Repair in Progress.
If no match is found using the Node field, the system attempts binding using the CI Identifier field, which is a JSON structure specifying key CI attributes (e.g., serialnumber, name). Successful matching here also results in alert binding.
Difference Between Node and CI Identifier Binding
- Node binding: Matches values in the event’s Node field against multiple host CI attributes.
- CI Identifier binding: Uses a structured JSON to specify specific fields for matching, allowing more precise identification even if those fields are not in Additional Information.
Both methods only apply to host CIs and ensure alerts are linked based on relevant hardware components.
Event Rules and Override Binding
After successful binding via Node or CI Identifier, event rules may override default binding behavior using the “Override default binding” checkbox. This allows binding adjustments based on business logic rather than direct field matches. For example, an event from a specific server may be bound to its parent cluster CI instead of the individual server CI.
Practical Example
If an event contains a Node field with “Server-123.example.com,” the system compares this value with host CI attributes (FQDN, IP, MAC, Name) in the CMDB. On finding a match, the alert binds to that CI. Event rules may further redirect the binding to a related CI like a cluster as needed.
Additional Tools
Service Operations Workspace can also be used to bind alerts, supporting automation and enrichment of alert handling.
Binding alerts to Configuration Items (CIs) using the Node field or the CI Identifier field ensures accurate event association. By comparing an event record’s Node or CI Identifier value, alerts are linked to the right system. This improves response, root cause analysis, and impact assessment by providing clear visibility into affected assets.
How default binding works
The system can perform default binding using the Node field or the CI Identifier field from the event record.
When an event enters the system, a key field like Node is available in the event record. However, there is no Node field in the CI. Instead, the node value from the event is compared with various attributes in the host CI, such as Name, Fully Qualified Domain Name (FQDN), IP, or MAC address. If a match is found, the alert is linked to the corresponding CI. This is the default method for binding alerts to CIs.
The property sa.active_operation_status is used by the default binding mechanism, specifically when binding via IP/MAC using the node field in the event. When an event attempts to bind to a host through the node field (using IP/MAC), the system ignores hosts whose operational status is not included in this property and the operational status of the host must also not be null. By default, the property value is "1", which corresponds to Operational. You can extend the list to include additional statuses, and any status in the list is not ignored during binding.
- 1 – Operational
- 2 – Non-operational
- 3 – Repair in Progress
- 4 – DR Standby
- 6 – Retired
If no match is found using node, the system looks at the CI Identifier field on the event record. The CI Identifier is a JSON structure containing column names and values for comparison (e.g., Name, Fully qualified domain name, IP, or MAC Address). The JSON is: {"column_name":"<column_value>"}. For example, if we want to bind to a CI identified by serial_number whose value is Dell Latitude 7420 Laptop, the JSON is: {"serial_number":"Dell Latitude 7420 Laptop"}. If a match is found, the alert is linked to the corresponding CI.
Difference between binding with Node vs. CI Identifier
In default binding, the system considers all fields in the Additional Information field and attempts to match their values with the CI table. The CI Identifier field allows specifying particular fields for matching, even if they are not present in Additional Information. This process uses a predefined JSON structure and applies only when the CI is a host.
Example: Resolving a CI Using Node and Event Rules
- Matching with CI Attributes:
- The system checks the Node value against the CMDB.
- It compares "Server-123.example.com" with the FQDN, IP, MAC address, or Name of existing host CIs.
- If a match is found (e.g., FQDN in the CMDB is also "Server-123.example.com"), the alert is linked to that CI.
- Applying Event Rules: Even if the Node resolves to Server-123, additional event rules might determine if the alert should be linked differently. For example, an event rule may specify that alerts from Server-123 should be linked to a parent CI (like a cluster) instead of the individual server.