That's actually just a snippet of the XML "payload" returned by the probe, but it's the part that's important to this discussion. If you'd like to see the results of any probe, you can drill down into any ECC Queue input record, and then click the orange XML button on the payload field — you'll get a small pop-up window with the XML payload nicely formatted.

Let's look at those results in detail. The tag has an attribute called _probe\_time_ — that's just the time (in milliseconds) that the probe took to run on the MID server. Contained within the tag is a single tag, with several attributes:

* _host_ contains the DNS host name, if DNS at the MID server succeeded with a reverse-lookup, or the NETBIOS name if DNS failed, or nothing at all if both methods failed.
* _source_ the IP address the resolver probe was launched against
* _win\_domain_ contains the Windows domain that the system at the IP address is a member of, if that system is a Windows-based computer in a domain.
The resolver sensor looks at that XML snippet with the results, and then follows the rules for formatting and updating the name of a CMDB item. In our case, it strips the ".service-now.com", forces the result to lower-case, and always updates the name if the DNS name has changed.

That's a very simple example of a sensor. Some sensors are much more complex, but they're still doing the same thing: analyzing data returned by the probe, and updating the CMDB item accordingly. Most likely you'll never have any need to make (or even modify) these complex sensors — the resolver sensor is probably quite similar to one you might want to create for your own purposes...