How to extend ACC-V Discovery ?
As a reminder, ACC-V is capable to provide an inventory of the server.
There are different possible approaches to implement extensions of ACC-V :
- Choice 1 : create a new custom plugin
- Choice 2 : create a flow to trigger the ACC Spoke
- Choice 3 : create a check definition (if applicable)
- (bad) choice 4 : modify an existing plugin
Choice 1 : create a new custom plugin
It is possible by creating new custom ruby scripts, and then some processing in the platform. It will involve plugin signature, which is possible but with some complexity. I think it is complex overall.
This article describes how to create a new ACC plugin : Adding a Custom Plugin to ACC-M
Choice 2 : create a flow to trigger the ACC Spoke
It is possible to trigger the ACC Spoke to execute commands on every agent
This solution is interesting, but to me is more relevant for unitary actions. Technically it is possible to create daily flows that will wake up every agent for execution, but I think it is not the best for discovery purposes.
Example of Flow using Agent Run Command Spoke :
Choice 3 : create a check definition (if applicable)
If the function already exist in the agent, it is one easy way to implement. Please note that not every action can be done with already existing scripts. You can check what already exist in the "Check Definitions".
I think check defintion are very efficient to gather information, and require little modifications.
For the use case described in this article, we created a new check definition, using the read-file.rb script already deployed on agents. The check definition will trigger the read of the file, and send the content to ServiceNow. Once in ServiceNow, the "check type" script will parse it and update the CMDB.
(bad) Choice 4 : modify an existing plugin
I would not recommend this approach, as you could face a lot of issues in the future and for upgrades.
Conclusion : for my Use Case, "Choice 3 : create a check definition" seems to be the most adapted.
How to implement the parsing of a signature file to populate Tags on servers
Principle
- The policy will trigger the Check Definition
- The Check Definition will read the file at a specific location and will send the content to ServiceNow using the ECC Queue table
- The Check Type script will parse the file and enrich the CMDB with tags
Limitation of this example
- As of now, this implementation doesn't remove obsolete data. So if the file is removed, or if some values are deleted in the file, it will stay in the CMDB. To handle this, it would be necessary to enrich the "check type" script to remove old values from the CMDB.
- The example describes only Windows OS, but it is very simple to do the same for other Operating Systems
Format of the json file
The file is in JSON format, at a predefined location. In this article it will be C:\signatures\signature.json . The file contains keys and values, that the script will parse to create records in the cmdb_key_value table.
Example of signature file :
{
"application" : "MyApplication",
"environment" : "test",
"owner" : "Owner Team"
}
Check Type Creation
This record will contain the processing script
Content of the script :
// This script search for tag and values in the discovered signature file
// input is checkResults
// this script creates a payload and update the CMDB records
//gs.info('BCR result ' + index + ': requestId: ' + check.requestId + ' agent_name: ' + checkResults[index].agent_id + ' ci_id: ' + check.ci_id + ' status: ' + check.status + ' output: ' + check.output);
// parse the result of the check Instance and build relatedObj
var payload = {
items: []
};
/for (var index = 0; index < checkResults.length; index++) {
var relatedObj = [];
var check = checkResults[index].check;
if (check.status == "0") {
try {
str = check.output.replaceAll("SensuSnReadFile OK: ", "");
jsonStr = JSON.parse(str);
// For each key mapped
for (key in jsonStr) {
relatedObj.push({"className" : "cmdb_key_value", "values" : {"key" : key, "value" : jsonStr[key]}});
}
if (relatedObj.length > 0) {
payload.items.push(
{
"className" : "cmdb_ci_server",
"values" : {
"sys_id": check.ci_id
},
"related": relatedObj
}
);
}
} catch (e) {
gs.warning('Signature parsing failed for server : ' + checkResults[index].client);
}
}
}
// Update only is data was discovered
if (payload.items.length > 0) {
var input = JSON.stringify(payload);
sn_cmdb.IdentificationEngine.createOrUpdateCI('ACC-Visibility', input);
}
Basically this script will parse the file, for each ley/value it will put data in relatedObj variable.
Then if the variable is not empty, we create a new payload that we sent to to Identification Engine.
The attribute check.ci_id contains the Sys ID of the compter to update
Check Definition Creation
The check Definition will trigger the reaf of the file using the command "read-file.rb -f "C:\signatures\signature.json"
Policy Creation
The policy will trigger the Check Definitions.
You can select some filters, here that we want to run on Widnows OS only.
It is required to configure the Check Definition to run
Scheduling parameters
Add tags related lists on computer/servers forms
If you want to display tags, it is necessary to add the related list on the forms
Check the results
The tag values should be created in the CMDB
How to troubleshoot if not working
- Manually trigger the check definition
- Check in the ECC Queue
- Check in platform logs
- Change Check Type Script to add log lines
