Why is Alert CI binding randomly selecting a DNS entry instead of the desired File System or Server entry?

Katherine Lewis
Tera Contributor

 

The Node contains an FQDN, and all data formats/values are consistent in the event payload.

The event rule will bind to the desired File System CI record with fallback to the Server CI record, but will sometimes bind to the DNS record instead..

The content and format of the desired Server CI records is also consistent.

Also, to answer/preempt some questions:
 - version is Kingston Patch 4
 - and I can confirm we don't have duplicate CI records

Given we have servers that were created by discovery with the following records:

Server A
- Windows server [cmdb_ci_win_server]
 - Name [name] is server-a
 - FQDN [fqdn] is server-a.domain.net
 - SysId is eb9a49cedb225b08d153745bbf96195c

- File System [cmdb_ci_file_system]
 - Name [name] is C:\
 - Mount point [mount_point] is C:\
 - Computer is server-a
 - SysId is 25fc2477dbcfdfc44eb473e9bf961997

- VMware VM Instance [cmdb_ci_vmware_instance]
 - Name [name] is SERVER-A
 - FQDN [fqdn] is empty
 - SysId is c5a4dfe9dbb52200868a7c841f9619ba

- DNS Name [cmdb_ci_dns_name]
 - Name [name] is server-a.domain.net
 - FQDN [fqdn] is server-a.domain.net
 - SysId is 76e05ba9dbb52200868a7c841f961928


Server B
- Windows server [cmdb_ci_win_server]
 - Name [name] is server-b
 - FQDN [fqdn] is server-b.domain.net
 - SysId is 0e926b1dc3100200d8d4bea192d3ae12

- File System [cmdb_ci_file_system]
 - Name [name] is C:\
 - Mount point [mount_point] is C:\
 - Computer is server-b
 - SysId is a72c5181930122005c15d905e67ffbf8


- VMware VM Instance [cmdb_ci_vmware_instance]
 - Name [name] is SERVER-B
 - FQDN [fqdn] is empty
 - SysId is c9edec9c0fc7e200a621fa6ce1050eec


- DNS Name [cmdb_ci_dns_name]
 - Name [name] is server-b.domain.net
 - FQDN [fqdn] is server-b.domain.net
 - SysId is 1dd376fddba21708d153745bbf96199e

 

And the event rule is configured as follows:

Event Rule Info
- Name is "EventRule01"
 - Source is "EventSource01"
- Order is "100"

And Event Filter
- Ignore is Unchecked
- The following conditions must be met:
 - Type is "EventTypeName01"
 - Metric name is "EventMetricName01"

And Transform and Compose Alert Output
- Configure as follows:
 - Description is ${description}
 - Node is ${node}
 - Type is ${type}
 - Resource is ${resource}
 - Message Key is left blank
 - Severity is ${severity}
 - Metric Name is ${metric_name}
 - Source Instance is ${event_class}
 - Source is ${source}
 - Classification is ${classification}

 - Manual attributes is Checked
  - mount_point = ${resource}\

And Threshold
- Active is Unchecked

And Binding
- Override default binding is Checked
- Binding Type is "CI field matching"
- CI Type is "File System"

When an Event record is created with the following values:
 - Node is "server-a.domain.net"
 - Resource is "c:"
Then the Alert will correctly bind to the File System CI record related to with server-a
 And the Processing Notes are as follows:
  - Binding alert CI process flow:
  - Node is FQDN
  - Node was not found, checking by name
  - Node will be resolved to CI id: eb9a49cedb225b08d153745bbf96195c : found by node name
  - Event CI type is cmdb_ci_file_system
  - Query with fields:
  - mount_point : c:\
  - The event CI type is device, trying to check for matching device
  - Found matching device (using type: cmdb_ci_file_system defined in em_binding_device_map table)
  - Bounding will be done with a matching device (id): 25fc2477dbcfdfc44eb473e9bf961997
  - Bind to 25fc2477dbcfdfc44eb473e9bf961997

  - Event rule applied: EventRule01

When an Event record is created with the following values:
 - Node is "server-b.domain.net"
 - Resource is "c:"
Then the Alert will incorrectly bind to the DNS Name CI record for server-b
 And the Processing Notes are as follows:
  - Binding alert CI process flow:
  - Node is FQDN
  - Event CI type is cmdb_ci_file_system
  - Query with fields:
  - mount_point : c:\
  - The event CI type is device, trying to check for matching device
  - No matching CI found
  - No related CI found for binding, alert CI will be bound to node (id): 1dd376fddba21708d153745bbf96199e
  - Bind to 1dd376fddba21708d153745bbf96199e

  - Event rule applied: EventRule01

1 ACCEPTED SOLUTION

Just received confirmation from ServiceNow Support that the DNS Name binding issue should also be resolved in Kingston Patch 13 (as well as London Patch 1)

View solution in original post

15 REPLIES 15

Marc54
Mega Guru

Hi Katherine,

we are seeing the same issue where the event sometimes binds with the DNS name entry and sometimes with the Server record, when the FQDN is supplied. I have not yet found the pattern, but it happens regularly as you can see from the following report.

 

find_real_file.png

 

The processing notes from an example event that should match with a windows server, but is matched with a DNS name instead:

Binding alert CI process flow:
Node is FQDN
Event CI type is empty
No matching CI found
No related CI found for binding, alert CI will be bound to node (id): 03bc98874f702340043a8c401310c7c6
Bind to 03bc98874f702340043a8c401310c7c6

This is on Kingston patch 9

When the event is properly matched to the windows server we see this in the processing notes:

 

Binding alert CI process flow:
No need to run Identification Engine for hardware with no attributes.
Node is FQDN
Bind to 0ec407474f060748e49381d88310c737

Event rule applied: SCOM Operating Systems all

Just received confirmation from ServiceNow Support that the DNS Name binding issue should also be resolved in Kingston Patch 13 (as well as London Patch 1)

manivk
Giga Expert

As per documentation,by default binding can be done only by name, FQDN, IP or MAC Address for any CI that extends the ‘cmdb_ci_hardware’ table.  In my environment node does not bind to DNS name . Please check in cmdb_ci how many  records are displayed for that node, check CI identification rules, processing notes, any customization done in the EvtMgmtCustom_PostTransformHandler scripting hook. It can be found under Event Management->Advanced Scripts.

Katherine Lewis
Tera Contributor

As per an update from development team. It has been accepted as a problem (PRB1293941) and it is in progress.