Discovery Probes and Sensors

Note: This article applies to Fuji and earlier releases. For more current information, see Discovery Probes and Sensors at http://docs.servicenow.com The ServiceNow Wiki is no longer being updated. Visit http://docs.servicenow.com for the latest product documentation.

Overview

Discovery probes and sensors perform data collection and processing tasks. Both get their instructions from the ECC queue. There is a worker job on the MID Server that monitors the queue for work. The monitor checks for any entries where the Queue is output and the State is ready.

Error creating thumbnail: Unable to save thumbnail to destination

The MID Server then processes all the output ECC messages, runs the necessary probes, and returns the probes results to the ECC queue. These results are put in the ECC Queue as input entries.

Error creating thumbnail: Unable to save thumbnail to destination

After an entry is inserted in the ECC Queue table, a business rule fires (on insert) that takes that information and runs it through a sensor processor. The sensor processor's job is to take the input data, find any sensors interested in that data, and pass it along to be processed. Those sensors ultimately update the CMDB.

For tips and instructions for creating your own custom probes and sensors, visit the ServiceNow community.

Probes

Probes are launched by the MID Server to collect all the information that you want returned from a device. For example, the base ServiceNow system has probes to get the names of Windows and Linux devices, and separate exploration probes that return disk information for devices with those operating systems. Some probes run a post-processing script to filter the data that is sent back to the ServiceNow instance. The data is sent back in JSON format.

View each probe's results in the ECC queue, which displays specifics such as the time the probe ran and its payload. For each probe, you must also create a sensor to process the data that the probe returns. To view existing probes, navigate to Discovery > Discovery Definition > Probes.

The Probe form provides the following unique fields.

Field	Description
Probe type	Select the probe for the operating system of the device it will query. CIM Probe: Select this probe type to query a CIM server using WBEM protocols. Multiprobe: Select this probe type to run one or more simple probes of any type or mix probes of different types. This type of probe can make several queries simultaneously that return all the results at the same time. You cannot add multiprobes to other multiprobes. Probe: Select this generic probe type to define a probe class. Specify the name of the probe class in the ECC queue topic field. SNMP Probe: Select this probe type for network devices, such as routers. WMIRunner Probe: Select this probe type for Windows devices.
ECC queue topic	Enter a descriptive term for the function of the probe. The probe uses this label as the Topic field for incoming ECC queue messages. The term does not have to be unique. For example, all the UNIX probes might have an ECC queue topic value of SSHCommand. By default, ServiceNow probes use the following ECC queue topics: CimProbe Multiprobe Powershell SCPRelay SSHCommand SNMP WMIRunner
ECC queue name	Enter either a descriptive name for human use, or the actual command the probe is to run. For example, if the value in the ECC queue topic field is SSHCommand, then enter the actual shell command to run in this field.
Classic Mode	Starting in Fuji, select this option to debug the post-processing script on the ServiceNow instance instead of the MID Server. This mode is only valid if a post-processor script exists. Use the Classic mode to debug post-processing scripts in the test environment. ServiceNow does not recommend use of the Classic mode in the production environment.
Post processor script	Starting in Fuji, defines a post-processing script that runs on the MID Server. The script accepts probe results as an input and outputs a JSON string that is sent back to the ServiceNow instance for a sensor to use as input.

Setting Probe Parameters

Use probe parameters to control the behavior of a particular probe every time it is triggered.

1. Create or select the probe you want to set parameters for.
2. From the Probe Parameters' related list, click New.
3. Fill in the fields, as appropriate (see table).

The Probe parameter form has the following fields.

Field	Description
Name	Enter the parameter name. Each probe type has its own list of available parameters.
Value	Enter the parameter value or script as required by the parameter.
Value script	[Optional] Enter the script you want the parameter to run if you have not already specified a script in the Value field.
Probe	Displays the probe this parameter relates to.

Global Parameters

Each probe type has its own list of available parameters, but the following parameters are available for all probe types.

Parameter	Description
mid.discovery.max_payload_size	Specifies the maximum string length of Discovery probe results that the MID Server sends to the instance. The MID Server verifies the size of the Discovery probe results before sending them to the instance. If the Discovery probe results exceed the limit, the MID Server discards them and returns a warning message. This applies only to probes where the Used by Discovery field is true. Set the value to any negative number to disable the payload limit and allow payloads of any size to be sent to the instance. For example, -1. This parameter is available starting with the Eureka release. Type: integer (bytes) Default value: 5000000
mid.eccq.max_payload_size	Specifies the maximum string length of a payload that the MID Server sends to the instance. The MID Server verifies the size of the payload before sending it to the instance. If the payload size exceeds the limit, the MID Server discards it and returns an error message in the payload. This parameter is available starting with the Eureka release. Type: integer (bytes) Default value: 20000000
source	[Required] The initial host to connect to. Type: string (URL) Default value: None

Probe Results Cache

The probe results cache improves overall discovery performance by caching probe results on the instance and only processing results that have changed. Probe results that have not changed do not need sensor processing and therefore the sensor does not run. The cache can be enabled or disabled for individual probes. The probe results cache is available starting with the Eureka release.

Enabling and Disabling the Cache for Specific Probes

If you have created probes, you can turn on the cache individually by enabling the Cache Results option for that probe. The probe results cache should be enabled only for those probes and sensors whose output is unlikely to change. For example, the Linux – CPU sensor is cached because CPU information seldom changes. The cache is turned on by default for base system probes and sensors whose output is unlikely to change.

Warning: Do not turn on the cache for classification and identification probes. Furthermore, do not turn on the cache for probes that trigger additional probes because this may prevent them from being triggered.

Sensors

If the probe has a post-processing script defined, that script processes the information collected on the MID Server. Otherwise the sensor performs this post processing. The sensor updates the CMDB.

Every probe in Discovery must have a corresponding sensor. For example, if incoming data is the result of a WMI probe, then the WMI sensor is triggered to process the payload.

Note: If you create a multiprobe, you must create a multisensor to process the data returned from this probe. For details, see Multiprobes and Multisensors.

Navigate to Discovery > Discovery Definition > Sensors and edit or create a sensor.

Field	Description
Name	Enter a unique probe name.
Reacts to probe	Select the probe whose payload this sensor must process.
Sensor Type [sys_class_name]	Select the type of sensor to create: Import Export Map: This option is not currently used. MultiSensor: Multisensors process the data returned from multiprobes. Select this type to create a multisensor that responds to the simple probes used in a multiprobe. Sensor: Select this type if this sensor is a simple sensor that responds to a simple probe.
Description	Enter an optional description of the sensors function.
Sensor type [sensor_type]	Specify how the results from the probe are processed. Classifier: This field is not currently used. Java: This field is not currently used. Javascript: Returned data from the probe is processed in the sensor itself, outside the application, and is visible to the user. This is the most common sensor type. Multiline Text: This field is not currently used. XML: The XML data from the probe is broken into pieces. Some pieces can be used to launch other probes that the original sensor needs to complete all the necessary information about a device.
Active	Select this option to enable or disable the sensor.
Script	Enter a script to run when processing the probe. You can use the g_probe_parameters hashmap in a sensor script to set probe parameters for any configured, triggered probes. For example, this code sets a 'node_port' parameter to 16001 for all triggered probes. <source lang="javascript">g_probe_parameters['node_port'] = 16001;</source>
Responds to probes	Use this related list to specify the simple probe within a multiprobe whose payload this multisensor must process. This list is available for multisensors only.
Triggers probes	Use this related list to specify which probes this sensor can start for additional exploration.
These fields can be added by configuring the form
Field	Description
Agent	Enter the ECC queue type to match this sensor with.
Apply Defaults	Select this option to apply default sensor values.
Classification type	Select the classification type associated with this sensor.
Coalesce	Enter the field to match against when determining whether to coalesce.
Condition script	Create a predetermined requirement for this sensor to run.
Data option	Select how to treat imported sensor data. Options include: Insert and Update Insert Only Update Only
External names	Enter a name to tag the sensor data.

Multiprobes and Multisensors

Multiprobes contain one or more simple probes configured to extract specific information from manageable devices by executing multiple queries with a single authentication. You can schedule multiprobes to run any time in the discovery process to make exploration more efficient. One common use for multiprobes is as identity probes. Identity probes ask a device for information such as its name and serial number, and then use the results of those queries to update existing CIs in the CMDB.

To process the data returned from a multiprobe, you must create multisensors, which run scripts that process the data returned by the multiprobes. Multisensors typically use the same name as their corresponding multiprobes.

Creating Multiprobes

1. Navigate to Discovery > Discovery Definition > Probes.
2. Click New.
3. Complete the form using the following settings:
   • Probe type: Multiprobe.
   • ECC queue topic: MultiProbe.
4. In the Includes probes related list, add the probes you want to include in the multiprobe.
5. Click Save.

Adding Simple Probes

Add simple probes to your multiprobe in the Includes Probes related list. You can add simple probes of any type to a multiprobe and mix probe types if necessary.

Warning: Do not add a multiprobe to the Includes Probes related list.

MultiProbe record

To add simple probes, do one of the following:

• Click Edit to add existing simple probes to the multiprobe. Move the appropriate simple probes into the Includes probes list.
• Click New to create a new simple probe for the multiprobe. This is an advanced procedure and requires a strong knowledge of JavaScript.

Editing the list of included probes

Multiprobes Included with ServiceNow

The following multiprobes are included with the base ServiceNow system. The corresponding multisensors have the same names.

Multiprobe	Includes These Probes
AIX - ADM	AIX - Active Processes: Gets active running processes Unix - Active Connections: Gets active connections information
AIX - Identify	AIX - Network: Determines network interfaces, IPs, and MACs AIX - Serial Number: Gets AIX serial numbers
CIM - SMI-S - Identity	CIM - SMI-S - Computer System: Gets CIM Computer Systems per SMI-S
HP-UX - ADM	HP-UX - Active Processes: Gets active running processes Unix - Active Connections: Gets active connections information
HP-UX - Identify	HP-UX - Hardware Serial Number: Gets HP-UX serial numbers HP-UX - Network: Determines network interfaces, IPs, and MACs
Linux - Identify	Linux - Hardware Information: Gets DMI (BIOS) information Linux - Network: Determines network interfaces, IPs, and MACs
Mac OS X - Identify	Mac OS X - Network: Determines network interfaces, IPs, and MACs Mac OS X - CPU/Memory: Gets CPU and memory information
SNMP - Identify	SNMP - Identity Info: Identifies printer CIs
SNMP - Load Balancer - Identity	SNMP - F5 BIG-IP - Identity - Serial: Gets BIG-IP chassis serial numbers, which are globally unique for this vendor SNMP - Identity Info: Identifies SNMP devices
Solaris - ADM	Solaris - Active Processes: Gets active running processes Unix - Active Connections: Gets active connections information
Solaris - Identify	Solaris - Network: Determines network interfaces, IPs, and MACs Solaris - Serial Number: Gets serial numbers for Solaris devices †
Unix - ADM	Unix - Active Processes: Gets active running processes Unix - Active Connections: Gets active connections information
UNIX - Classify	ESX - OS: Identifies ESX machines UNIX - OS: Runs after the ESX - OS probe to determine the operating system for SSH devices not identified as ESX
Windows - ADM	Windows - Active Processes: Gets active running processes Windows - Active Connections: Retrieves active connections information
Windows - Identify	Windows - Network: Determines network interfaces, IPs, and MACs Windows - OS/Hardware Information: Probes a Windows machine for WMI information

† Note: This probe requires the installation of a command line tool from Oracle called SNEEP. To download and install this tool, log in to the Oracle website. After this tool is installed, the Solaris - Serial Number probe runs automatically when Discovery detects a Solaris device. For Fujitsu PRIMEPOWER devices, you must run this probe with root credentials. More Info.

Creating Multisensors

Error creating thumbnail: Unable to save thumbnail to destination

1. Navigate to Discovery > Discovery Definition > Sensors.
2. Click New.
3. Complete the form using the following settings:
   • Sensor type: MultiSensor.
   • ECC queue topic: MultiSensor.
   • Reacts to probe: Select the probe whose payload this sensor must process.
   • Sensor type: Select one of these options.
     • Javascript: Returned data from the probe is processed in the sensor itself, outside the application, and is visible to the user. This is the most common sensor type.
     • XML: The XML data from the probe is broken into pieces. Some pieces can be used to launch other probes that the original sensor needs to complete all the necessary information about a device.
4. Right-click the form header, and click Save.
5. In the Responds to Probes related list, click New.
6. Complete the form using the following settings:
   • Reacts to probe: Select the probe within the multiprobe that this sensor reacts to. The sensor must be linked to the probe by function, such as network identification or serial number.
   • Script: Enter a script to run before the script in the multisensor. This script defines how the data returned from each probe should be processed.
7. Click Save.

Enhancements

Fuji

• Moved some data processing that was done by the sensor on the ServiceNow instance to a probe post-processing script that is run on the MID Server.

Eureka

• Provides improved probe performance by caching probe results on the instance and only processing results that have changed.
• Provides a global probe parameter to set the maximum probe payload size.