Troubleshooting ServiceNow Object Connections
When successful the Task Output will provide you with a number of details about your connection to ServiceNow and what happened in the run.
You can use this information to get an idea of whether or not this behaved as expected and how long this took to complete. If you find that your monitoring objects are increasing you might wish to keep an eye on the timings to ensure that this remains within your configured timeout.
ServiceNowTargetClass - The main target of the payload
Can be misleading in more complicated payloads
ScomSourceClassName - The main source of the information from SCOM
Can pick up other details from hosting relationships so can be misleading
UniqueClasses - The number of different classes used in this payload
EA Sync may cause this to be a class or two higher than you might normally expect
TotalItems - The total number of distinct objects posted in this discovery
Parents that host multiple children are only counted once
NoChangeItems - The number of objects that resulted in no change to the ServiceNow CMDB
InsertItems - The number of objects that resulted in a new item being created in ServiceNow
UpdateItems - The number of objects that already existed but required a change in ServiceNow
DeleteItems - The number of objects that were actively deleted in ServiceNow
UpdateWithItems - A combination of rarer update types:
Update with Downgrade - An existing CI in the target table is updated and its class is changed to a more generic class (ancestor class)
Update with Switch - An existing CI in the target table is updated and its class is changed to another class which is not an ancestor or descendant class
Update with Upgrade - An existing CI in the target table is updated and its class is changed to a more specialized class (descendant class)
FailedObjectPayloads - The number of payloads that produced exceptions
TotalRelationships - The number of relationships related to this payload
TotalErrors - The total number of errors encountered across all payloads
NoChangeRelationships - The number of relationships that resulted in no change to the ServiceNow CMDB
InsertRelationships - The number of new relationships created in ServiceNow
UpdateRelationships - The number of relationships that already existed but required a change in ServiceNow
AveragePostTime - The average time it took to transmit each payload to ServiceNow in milliseconds
MinPostTime - The fastest time it took to transmit a payload to ServiceNow in milliseconds
MaxPostTime - The longest time it took to transmit a payload to ServiceNow in milliseconds
AverageLookupTime - The average time it took to look up each SCOM object property in milliseconds
MinLookupTime - The quickest time it took to look up a SCOM object property in milliseconds
MaxLookupTime - The longest time it took to look up a SCOM object property in milliseconds
IdentificationPostCount - The number of attempts it took to complete this discovery
ContainFailures - Whether this discovery task contained any failures of any kind
Discovery payload is inaccurate for memory
When pushing a discovery payload to SCOM the memory is slightly out.
SCOM and ServiceNow by default discover memory in different orders of magnitude. There is not currently any direct way of doing the math required to convert from one to the other.
There are a number of different workaround depending on the accuracy requirements and your appetite for complexity.
The simplest option has already been implemented in our example payloads. Use regular expressions to perform a basic, but inaccurate change to the order of magnitude. In this case slicing off the last four digits.
The next option is only really viable in predictable environments and in reality is probably the least desirable of the three. However you can use dynamic groups to sort servers by their memory, use these groups to filter your payloads using group filters, and statically set the memory capacity to the desired level.
The final option is to create an extension class to discover the memory attribute in the correct magnitude. This requires some SCOM authoring knowledge, but there are blogs out there on similar enough topics.