Skip to end of metadata
Go to start of metadata

The following examples demonstrate REST LAM configuration options, message formats, cURL commands and sample JSON responses. You can use these example to assist you when configuring REST LAM. See Configure the REST LAM for configuration instructions and REST LAM Reference for a full description of all properties.

REST LAM Authentication

The following examples demonstrate the various authentication options in the REST LAM.

REST LAM configuration without authentication:

monitor:
{
	name                : "Rest Lam Monitor",
	class               : "CRestMonitor",
	port                : 8888,
	address             : "localhost",
	use_ssl             : false,
	authentication_type : "none",
	accept_all_json     : false,
	num_threads         : 5,
	rest_response_mode  : "on_receipt",
	rpc_response_timeout: 20
}

REST LAM configuration with basic authentication:

monitor:
{
	name                : "Rest Lam Monitor",
	class               : "CRestMonitor",
	port                : 8888,
	address             : "localhost",
	use_ssl             : true,
	path_to_ssl_files   : "/root/temp",
	ssl_key_filename    : "server.key",
	ssl_cert_filename   : "server.pem",
	auth_token          : "my_secret",
	authentication_type : "basic",
	authentication_cache: true,
	accept_all_json     : false,
	num_threads         : 5,
	rest_response_mode  : "on_receipt",
	rpc_response_timeout: 20
}

REST LAM configuration with JWT authentication (non-SSL):

monitor:
{
	name                : "Rest Lam Monitor",
	class               : "CRestMonitor",
	port                : 8888,
	address             : "localhost",
	use_ssl             : false,
	authentication_type : "jwt",
	jwt                 : 
						{    
							secretKey : "secret",  
							sub       : "moogsoft",  
							iss       : "moogsoft",  
							aud       : "moogsoft",
							jti       : " "
						}                      
	accept_all_json     : false,
	num_threads         : 5,
	rest_response_mode  : "on_receipt",
	rpc_response_timeout: 20
}

REST LAM configuration with static basic auth authentication:

monitor:
{
	name                : "Rest Lam Monitor",
	class               : "CRestMonitor",
	port                : 8888,
	address             : "localhost",
	use_ssl             : false,
	authentication_type : "basic_auth_static",
	basic_auth_static	:
						{
							username			: "username",
							#password			: "password",
							encrypted_password	: "dfJtTQMGiFHfiq7sCmxguBt6Jv+eytkoiKCquSB/7iWxpgGsG2aez3z2j7SuBtKj"
						},
	accept_all_json     : false,
	num_threads         : 5,
	rest_response_mode  : "on_receipt",
	rpc_response_timeout: 20
}

Moogsoft AIOps Message Format

The Moogsoft AIOps message format and an example message are shown below. You must use this format for incoming messages when accept_all_json is set to false in the REST LAM configuration file. See the REST LAM Reference for more details.

Moogsoft AIOps message format:

{
	auth_token: <string>,
	events: [
		{event1},
		.
		.
		.
		{eventn}
	]
}

Message in Moogsoft AIOps format containing two events:

{
	"auth_token" : "my_secret",
	"events" : [
	{
		"name1" 		: "1",
		"name2" 		: "false",
		"name3" 		: "MINOR",
		"signature" 	: "sig",
		"source_id" 	: "98",
		"external_id" 	: "ext",
		"manager" 		: "man",
		"source" 		: "db",
		"class" 		: "a class"
	},
    {
		"name1" 		: "2",
		"name2" 		: "false",
		"name3" 		: "MINOR",
    }
	]
}

Configuration with cURL Command

The following example demonstrates a REST LAM configuration and the corresponding cURL command to generate events.

REST LAM configuration with no authentication or SSL:

monitor:
{
	name                : "Rest Lam Monitor",
	class               : "CRestMonitor",
	port                : 9876,
	use_ssl             : false,
	accept_all_json     : false,
	#path_to_ssl_files  : "/tmp",
	#ssl_key_filename   : "server.key",
	#ssl_cert_filename  : "server.pem",
	#auth_token         : "abcd1234",
	num_threads         : 5
},
agent:
{
	name 	: "DATA_SOURCE"
	#log 	: "/tmp/rest_lam.log"
},
constants:
{
},
conversions:
{
	stringToInt:
	{
		input	: "STRING",
		output	: "INTEGER"
	}
},
mapping:
{
	catchAll: "overflow",
	rules:
	[
		{ name: "signature",      rule: "$signature" },
        { name: "source_id",      rule: "$source_id" },
        { name: "external_id",    rule: "$external_id" },
        { name: "manager",        rule: "$manager" },
        { name: "source",         rule: "$source" },
        { name: "class",          rule: "$class" },
        { name: "agent",          rule: "$agent" },
        { name: "agent_location", rule: "$agent_location" },
        { name: "type",           rule: "$type" },
        { name: "severity",       rule: "$severity",       conversion: "stringToInt" },
        { name: "description",    rule: "$description" },
        { name: "first_occurred", rule: "$first_occurred", conversion: "stringToInt" },
        { name: "agent_time",     rule: "$agent_time",     conversion: "stringToInt" }
	]
},
filter:
{
	presend: "RestLam.js"
}

The cURL command for the above configuration:

curl http://moogbox2:9876 -H "Content-Type: application/json" --insecure -X POST -v --data '
{  
         "signature":"SIGNATURE1",
         "source_id":"my_source_id",
         "external_id":"my_external_id",
         "manager":"TestMgr1",
         "source":"TestHost1",
         "class":"my_class",
         "agent":"TestAgent1",
         "agent_location":"my_agent_location",
         "type":"TestType1",
         "severity":3,
         "description":"TestDesc1",
         "first_occurred":1411134582,
         "agent_time":1411134582
}'

The cURL command will generate the following event from the REST LAM:

{
   "_MOOTADATA_":{
      "creation_time":1452090420708
   },
   "agent":"TestAgent1",
   "agent_location":"my_agent_location",
   "agent_time":1411134582,
   "class":"my_class",
   "description":"TestDesc1",
   "external_id":"my_external_id",
   "manager":"TestMgr1",
   "overflow":{
      "LamInstanceName":"DATA_SOURCE",
      "first_occurred":1411134582
   },
   "severity":3,
   "signature":"SIGNATURE1",
   "source":"TestHost1",
   "source_id":"my_source_id",
   "type":"TestType1"
}

Expose Request Headers

The following example demonstrates a REST LAM configuration that exposes request headers and contains a mapping to set source as the Origin HTTP header.

REST LAM configuration:

monitor:
{
	name							: "Rest Lam Monitor",
	class							: "CRestMonitor",
	port							: 8888,
	expose_request_headers			: true,
	use_ssl							: false,
	accept_all_json					: false,
	lists_contain_multiple_events 	: true,
	num_threads						: 5
},
agent:
{
	name : "DATA_SOURCE"
},
constants:
{
},
conversions:
{
	stringToInt:
	{
		input  : "STRING",
		output : "INTEGER"
	}
},
mapping:
{
	catchAll: "overflow",
	rules:
	[
		{ name: "signature", rule:      "$signature" },
		{ name: "source_id", rule:      "$source_id" },
		{ name: "external_id", rule:    "$external_id" },
		{ name: "manager", rule:        "$manager" },
		{ name: "source", rule:         "$moog_request_headers.Origin" },
		{ name: "class", rule:          "$class" },
		{ name: "agent", rule:          "$LamInstanceName" },
		{ name: "agent_location", rule: "$agent_location" },
		{ name: "type", rule:           "$type" },
		{ name: "severity", rule:       "$severity",       conversion: "stringToInt" },
		{ name: "description", rule:    "$description" },
		{ name: "first_occurred", rule: "$first_occurred", conversion: "stringToInt" },
		{ name: "agent_time", rule:     "$agent_time",     conversion: "stringToInt" }
	]
},
filter:
{
	presend: "RestLam.js"
}

The cURL command for the above configuration:

curl http://localhost:8888 -H "Content-Type: application/json" --insecure -X POST --header "Origin: http://test.com" -v --data '
{
         "signature":"SIGNATURE4",
         "source_id":"my_source_id",
         "external_id":"my_external_id",
         "manager":"TestMgr4",
         "class":"my_class",
         "agent":"TestAgent4",
         "agent_location":"my_agent_location",
         "type":"TestType4",
         "severity":3,
         "description":"TestDesc4",
         "first_occurred":1411134582,
         "agent_time":1411134582
}'

The cURL command will generate the following event from the REST LAM:

{
    "_MOOTADATA_": {
        "creation_time": 1534951021452
    },
    "agent": "DATA_SOURCE",
    "agent_location": "my_agent_location",
    "agent_time": 1411134582,
    "class": "my_class",
    "description": "TestDesc4",
    "external_id": "my_external_id",
    "manager": "TestMgr4",
    "overflow": {
        "moog_request_headers": {
            "Accept": "*/*",
            "User-Agent": "curl/7.54.0",
            "Host": "localhost:8888",
            "Content-Length": "449",
            "Content-Type": "application/json"
        },
        "agent": "TestAgent4",
        "first_occurred": 1411134582
    },
    "severity": 3,
    "signature": "SIGNATURE4",
    "source": "http://test.com",
    "source_id": "my_source_id",
    "type": "TestType4"
}

Multiple Nested Fields

In the following example the received event has multiple nested fields. The field summary is nested in <env:Envelope> - <env:Body> - <createRequest> - <Summary>. The env: in the field name can produce a mapping error so it is advisable to remove it from the received data in the LAMbot's modifyReponse function.

An event received by REST LAM in XML format:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Header/>
<env:Body>
<createRequest xmlns="http://moogsoft.com"
xmlns:emcf="http://xmlns.oracle.com/sysman/connector">
 
<Summary xmlns="http://moogsoft.com">CPUUtilization for 3 is 6.787%, crossed warning (5) or critical (10)threshold.</Summary>
<Description xmlns="http://moogsoft.com">
Event created in Enterprise Manager:
Target information:
Target Type: host
Target Name: WIN-8U1RA5NAA6I
Target URL: http://win-8u1ra5naa6i:7788/em//em/redirect?pageType=TARGET_HOMEPAGE&amp;targetName=WIN-8U1RA5NAA6I&amp;targetType=host
</Description>
 
<Severity xmlns="http://moogsoft.com">2</Severity>
<Priority xmlns="http://moogsoft.com">Medium</Priority>
</createRequest>
</env:Body>
</env:Envelope>

The corresponding LAMbot configuration to remove env: from the received event fields and send them to REST LAM for tokenizing and mapping:

function modifyResponse(inBoundEventData)
{               
	// if you want to modify response data before injecting the same in LAM for tokenizing                           
	/*inBoundEventData contain below field which can be manipulated as per requirement                                              
	1. responseData - the event data received from the rest server             
	*/               
	var inputString = inBoundEventData.value('responseData');                            
	var obj = JSON.parse(inputString);                            
	var modifiedinput = obj.(env:Envelope).(env:Body).createRequest;                          
	logger.info(JSON.stringify(modifiedinput));               
	inBoundEventData.set('responseData', JSON.stringify(modifiedinput));
	return true;
}

The corresponding mapping in the REST LAM configuration file is shown below. The mapping for class is performed by $Description.content. If the LAMbot is not configured as shown above, the mapping is processed as $env:envelope.env:Body.createRequest.Summary which produces an error.

mapping:
{
	{ name: "signature", rule:      "$signature" },
	{ name: "source_id", rule:      "$source_id" },
	{ name: "external_id", rule:    "$external_id" },
	{ name: "manager", rule:        "$manager" },
	{ name: "source", rule:         "$source" },
	{ name: "class", rule:          "$class" },
	{ name: "agent", rule:          "$LamInstanceName" },
	{ name: "agent_location", rule: "$agent_location" },
	{ name: "type", rule:           "$type" },
	{ name: "severity", rule:       "$severity", conversion: "stringToInt" },
	{ name: "description", rule:    "$description" },
	{ name: "agent_time", rule:     "$agent_time", conversion: "stringToInt" }
}

JSON Responses

The following examples show successful and failed JSON responses.

Successful response without caching:

{ 
   "message":"Processed 1 event(s)",
   "response":{ 
      "cached":0,
      "processed":1,
      "received":1
   },
   "success":true
}

Failed response without caching:

{ 
   "message":"General error. Processed 0 event(s)",
   "response":{ 
      "cached":0,
      "processed":0,
      "received":1
   },
   "statusCode":1000,
   "success":false
}

Failed response with caching:

{ 
   "message":"Content accepted but cached, processing not guaranteed. Processed 0 event(s)",
   "response":{ 
      "cached":1,
      "processed":0,
      "received":1
   },
   "statusCode":5003,
   "success":false
}



  • No labels

3 Comments

  1. user-1ea8e

    Should we refer to then as <env: Envelope> <env:Body>  etc?

  2. user-1ea8e

    I would remove the collapsable sections. I don't think the content is searchable in these nests plus we can't replicate in Xyleme.

  3. Maybe have a contents to link to each example, to make it less unwieldy?