Man am I liking this HTTP Classifier

[doug_schulze]

Just had the opportunity to give the HTTP Classifier (London build+) a test drive with some friends that needed to discover some specific devices.

For years I've had challenges with requests for iLO Discovery because of the nature of the device passing through (SNMP) request to the server it was on rather than answering for itself. But now I had the opportunity to actually build a "catch" based on an HTTP(S) response and trigger a pattern to do the rest of the work and it couldn't have been easier.

You can match on any bit on the return, very similar to the OOB F5 classifier (value) does.

In my case, I used other values (obviously) but now that I had the power to trigger a pattern that could then query other directories that the API had to offer and the process takes it from there. If I had this available back when IP Phone discovery was all the rage we wouldn't have needed this excellent update set from our friend Valor Poland, because back then I could see the phone's status (web) page but we didn't have a way to do anything with it. Let alone having to authenticate through it...Now that we have this, life is much easier...

One important thing I learned was that the HTTP Classifier probe requires at least one 'Basic auth' credential loaded, even if you are only using HTTP and not HTTPS. I'm not sure if this is a bug or an undocumented "feature" (I've notified the responsible parties, so this might change (either in code or documentation) but if you are going down this route and aren't getting a response from the HTTP Classifier probe then double check that.

DO know I got this idea from a coworker who used this to trigger storage systems patterns so his friends didn't have to enable SNMP to trigger the same pattern. In his case, he used an alternate port (!= 80,443) so like him, know you can set up another port in Discovery Definition > IP Services. Include it on the HTTP port probe (triggered by services) the new port check in your Discovery Definition > port probes for your Configuration Item Discoveries. Include it in the Discovery Definition > Functionality Definition > ALL so when you do quick discoveries you're checking that port. Then add it of course, to your new HTTP classifier...

Bottom line, if you have a device that you need to discover and only have HTTP(S) as an available protocol whos 'GET' can provide quality information then this is a great way to go! Overall I saved my friends from having to configure credentials for other available protocols (SSH) on thousands of systems when their base HTTP call gave us everything we needed to create, identify and relate the records.  I am liking this HTTP Classifier....

[Michael Fry1]

Do tell more? Would love to see the whole solution, pattern, etc!

[RGreene]

I am with Michael, I would love to see more on iLO classidication.  I have read about many people trying to figure out how to Classify iLOs,  with the HTTP classifier it seems it might be possibly.

[doug_schulze]

Overall it was pretty easy.  Using the HTTP classifier I was able to do a GET against the iLo address where It contained a bunch of information about the card, its name, the server it was plugged into ect.. Enough for me to trigger the HTTP classification with a simple contains <some value in the return> match, that triggered my pattern.

Created an iLo table off the Hardware class and in the pattern, I did another GET to pull in the same return and shoved that into a temp value where through the steps I parsed out the different values that were in the same. Then it got a little tricky.

I needed to build a reference to the server so you could see the card record on the iLo class, not too hard we do it a million times a day in Probes and sensors but in this case, I couldn't  'shove' the name of the server into the reference field, don't work that way in patterns.  So I built a pre post processing script (pre sensor) that when the name was returned in the pattern it did the glide query to find its sysID and filled the table with that value. Script below...

/*
 * 1. Pre sensor: You can change payload before it will be proccesed by Identification Engine.
 * Use IEJsonUtility in order to add relevant information to the payload
 * Input parameters in Pre sensor mode: payload, patternId
 * 2. Post sensor: You can update/add missing info to the DB based on result (Json) from
 * Identification Engine
 * Output parameters in Post sensor mode: payload
 *
 */
var rtrn = {};
	
	//parsing the json string to a json object
	var payloadObj = JSON.parse(payload);
	
	//put your business logic here.
	var itemsDiscovered = payloadObj.items;
	var mainCi = null;
	
	//Find the main CI from the installed_on value in the payload of the pattern
	
	for(var index in itemsDiscovered){
		if(Ci.extendsFromTable(itemsDiscovered[index].className,'cmdb_ci_hardware')){
			mainCi = itemsDiscovered[index];
			break;
		}
	}
	
	// lookup and match the sysID from main CI record. Set that sysID to the variable 'host'
	if (mainCi && mainCi.values.installed_on) {
		//gs.log('===== mainCi.values.installed_on before conversion: ' + mainCi.values.installed_on);
		var host = '';
		var gr = new GlideRecord('cmdb_ci_server');
		gr.addQuery('name', mainCi.values.installed_on);
		gr.query();
		
		if (gr.next()){
			host = gr.sys_id;
		}
		//now re-defined the value of installed_on to the sysID (String) that matched above, the system will do the rest
		
		mainCi.values.installed_on = host.toString();
		
		//gs.log('===== mainCi.values.installed_on converted: ' + mainCi.values.installed_on);
	}
	
	//you can return a message and a status, on top of the input variables that you MUST return.
	//returning the payload as a Json String is mandatory in case of a pre sensor script, and optional in case of post sensor script.
	//if you want to terminate the payload processing due to your business logic - you can set isSucess to false.
	rtrn = {'status':{
		'message':'Enter your message here',
		'isSuccess':true
	},
	'patternId':patternId,
	'payload':JSON.stringify(payloadObj)
};

[Nik Amy]

Hi Doug,

I really couldnt understand how to make use of HTTP classifier to discover a device.

Could you please explain step by step.

another question: Can AS400 be discovered using this.

[doug_schulze]

Nik,

Basically I created a classifier that triggered on a return from the HTTP payload.

I created an ilo Class off hardware and added a reference table to cmdb_ci_computer and attributes I wanted to populate

I then created the pattern that just did another get from the same classification and parsed out the variables and attributes.

I then added the above-mentioned pre/post-processing script so I could build the reference through the Identification Engine

I didn't need to add an extra identifier because I leveraged the OOB hardware identifier, but could have if I needed something specific...

Hope this helps.

[doug_schulze]

Here's an update set with the three key pieces.  Please KNOW, the pattern in the update set just drops it into the hardware table and not reflective of the actual use, so you have to modify your table structure. Specifically where you will need to (if you want) to create a specific table off hardware for the iLo's and its specific attributes.  

This is NOT plug and play, again, this is NOT, NOT plug and play....you have to do some tweaking with the class and adding attributes (that you can read in the pattern) but hope it gets my friends out there a structure to implement the same solution.

[RGreene]

This worked great as a base.  We added the discovered iLOs to the existing Out-Of-Band Devices.  Before this Out-of-Devices had things similar to iLOs such as Dell DRACs.  There were a couple of attributes we added to flesh it out.  The other gotcha is this only discovers the newer iLOs for ProLiant Gen8 and above servers.  The Gen 8 iLOs and newer servers support redfish which a Restful api.  The older ones use XML queries to get anything meaningful.

[CJ22]

Hello.  I'm trying to reproduce this on a test instance and I'm having issues.  I'm sure I'm missing something simple.  I'm getting three errors. "Could not find a table sa_pattern this update requires" along with the same error for sa_pattern_prepost_script and discovery_classy_http.  Any suggestions?

[doug_schulze]

Not sure Chris... It seems like a lot of unrelated errors from the update that I provided. If you would like to open a case with support and PM me the number I can take a look at some point.

[User367757]

I'm excited to see this implementation, since I've only ever noticed the HTTPClassifierProbe when it is logging timeouts all over the place.

Next time I see that, I shall give this a go.

[SN Arch Guy]

@doug_schulze i didn't see the update set you mentioned in this post. it seems like the http classifier method might be the new approach. but i don't believe all iLOs support http, some look like they only support IPMI / Redfish. and the response format isn't clear to me. as IPMI has been around for quite some time, i'm a bit surprised that ServiceNow does not have OOB capabilities for the many devices that use it. is there anything planned? is there another way to discover those devices with IPMI only?

[RGreene]

Redfish is an API based on HTTP/HTTPS.  Depending on what you are wanting you can discover much via Readfish without using credentials.  I used Doug's base and then added Redfish based  commands to pull back the information for discovery.

[S Ram]

Update set is not available. And neither is it available on the share. 

[doug_schulze]

Sorry about that, I'll see if I can find it and send it over.

[Nathan Underwoo]

I also need to get discovery working so we can track HP iLO devices - can I get the update set @doug_schulze ?

Also, there's an entry on the Idea portal to make it an officially supported pattern and I recommend that anyone interested in that add their support at the link here:
https://support.servicenow.com/ideas?id=view_idea&sysparm_idea_id=7758ed43dbf91010a08a1ea6689619d7

[mihai1107]

Hello!

I recently did the classifier and the pattern and I am able to discover ILO devices. I currently store the data in Out-of-Band Devices[cmdb_ci_outofband_device] and I am able only to use the "Host" field to create a reference to the server.

Is there any possible way to properly create a relationship(in cmdb_rel_ci) using discovery (not by scripting) between the ILO device and the server where it is installed if I have a standalone discovery pattern for ILO Devices? 

Thank you in advance!