In previous Discovery 101 posts, we’ve described how to set up a MID Server, how to manage and normalize the data with BDNA and answered a number of common questions.
Today, I’d like to dig a bit deeper into how Discovery actually works. Often times when I lead a Discovery training, businesses are overwhelmed by the sheer volume of module links under the Application Menu, so hopefully I’ll be able to de-mystify all of those links for you today.
Throughout this example, we’ll be following a Linux server where Port 22 (SSH protocol) and Port 135 (WMI protocol) are both open. This detail will come up later.
Basic Discovery Overview
First, it’s important to understand the four phases of Discovery:
- Port Scan
- Classify
- Identify
- Explore
Know them, love them. The reason these phases are so important to understand is that when you go to read device logs or need to troubleshoot why a particular device is not being discovered, you need to know what the last successful phase was.
Port Scan
As Dan Fraser explained in his blog post on Behaviors, there are only a limited number of ports that are evaluated, and they’re all customizable. You can set up a Behavior to limit what you look for, and you can further customize these Behaviors with port probes if you are using a non-standard port (e.g. 8080 for a web server). While this is not an exhaustive list, the common ports scanned include:
- SSH: Port 22. This is the protocol that all *nix based servers use.
- WMI: Port 135. PowerShell operates on the Windows Management Interface, which is the rough equivalent of SSH on *nix devices.
- SNMP: Port 161. This is used to get information from any “dumb” network devices, such as Printers and Switches.
Classification
Classification is where we get to the fun stuff and determine the Configuration Item class of the device.
When the Port Scan (“Shazzam” probe) results are returned from our MID Server, we look to see what ports were open. In our example, we have a Linux server with both Port 22 and Port 135 open, so what happens next?
Tony Fugere alluded to this in his Discovery Q&A post — there is an order of precedence set by the Classification priority field in Port Probe list.
Note: The Classification priority field is not shown by default, so you may have to personalize the list to see it.
In the image above, you can see that we are going to prefer WMI over SSH, so the WMI Classification probe will be sent out first. Since we are discovering a Linux server, this will hit its specified timeout and ServiceNow will fall back to SSH.
Servers (WMI, SSH capable devices) are classified based on their Operating System and network devices are classified by their Capability (prints, routes, switches, etc). Network devices that do multiple things, like the next-gen Cisco N7000 devices, are classified by their “highest level” capability, Routing.
Identification
After determining the correct Classification entry, ServiceNow looks to the “triggers probes” list on that entry. Following our Linux server example, 13 probes are triggered, but one is marked (and there can only be one!) as belonging to the Identification phase (highlighted in the image below).
The Identification entry listed is noted as a MultiProbe, which I’ll talk about in a different post, but the important thing to know is that the Identification sensor processes multiple pieces of data and determines, or identifies, the specific record in ServiceNow to update. If you’ve ever done a data import in ServiceNow, this is akin to the coalesce value.
Just as there is a priority for Port Probes (preferred protocols), there is also a priority list for Identification. Since the software, network and naming information of a given device can change, ServiceNow looks up an ordered list of details, starting with the most specific.
Note: If there are ever multiple matches found for a given device, ServiceNow will not proceed further with Discovery of the device. This is to prevent confusion and incorrect data.
Exploration
Finally, once the correct Configuration Item is found (or if no matches found were found), ServiceNow moves on to the Exploration probes and fills in the remainder of the data for the device — installed programs, disks attached, memory information, system uptime and other details.
Inside the Discovery Process
Hopefully this gives you a bit more of an idea about what each of the major phases of Discovery entails. In the coming weeks, we’ll expand on each phase with additional technical details.
Just to review:
Port Scan takes an IP address and determines which of the common service ports are available, enabling us to narrow down not only which devices are active, but also the category into which they fall — Windows, Linux or Network device. Classification is where we start to need credentials. This is where we gather basic details as to what specific type (Configuration Item class) of device is sitting on the other end of the wire. For example: Solaris, Linux or Router. Identification of a device requires getting specific hardware information, such as serial number, to pick out an existing record in the CMDB to update. Exploration then completes the remainder of the details — CPU, Memory, Disk drives for a computer or server and supply status or routing information for a Printer and Router, respectively.
As always, sound off in the comments if you have questions, want to know more, or to give a suggestion about what topics you’d like to see covered next time!
Learn More
Interested in learning more? Check out our Top 10 Best Practices for ServiceNow Discovery.
The post ServiceNow Discovery 101: How Discovery Works appeared first on Cloud Sherpas.