REST LAM Examples
The following examples demonstrate REST LAM configuration options, message formats, cURL commands and sample JSON responses. You can use these for reference purposes when you configure the REST LAM. See Configure the REST LAM for configuration instructions and LAM and Integration Reference for a full description of all properties.
REST LAM Authentication
The following examples demonstrate the 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 Enterprise Message Format
These examples demonstrate the Moogsoft Enterprise message format. You must use this format for incoming messages when accept_all_json
is set to false
in the REST LAM configuration file.
Moogsoft Enterprise message format:
{ auth_token: <string>, events: [ {event1}, . . . {eventn} ] }
Message in Moogsoft Enterprise format that contains 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 generates 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 generates 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 modifyResponse
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> <signature>example123</signature> <sourceId>app_id</sourceId> <source>My App</source> <externalId>1234</externalId> <manager>CPU Alerter</manager> <class>Medium</class> <agentLocation>http://moogsoft.com</agentLocation> <type>alert</type> <severity>2</severity> <description> Event created in Enterprise Manager: Target information: CPUUtilization for 3 is 6.787%, crossed warning (5) or critical (10)threshold. Target Type: host Target Name: WIN-8U1RA5NAA6I Target URL: http://win-8u1ra5naa6i:7788/em//em/redirect?pageType=TARGET_HOMEPAGE&targetName=WIN-8U1RA5NAA6I&targetType=host </description> <agentTime>1411134582</agentTime> </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 2. moog_request_headers - the headers received with the request */ 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 : { catchAll : "overflow", rules : [ { name: "signature", rule : "$signature" }, { name: "source_id", rule : "$sourceId" }, { name: "external_id", rule : "$externalId" }, { name: "manager", rule : "$manager" }, { name: "source", rule : "$source" }, { name: "class", rule : "$class" }, { name: "agent", rule : "$LamInstanceName" }, { name: "agent_location", rule : "$agentLocation" }, { name: "type", rule : "$type" }, { name: "severity", rule : "$severity", conversion: "stringToInt" }, { name: "description", rule : "$description" }, { name: "agent_time", rule : "$agentTime", conversion: "stringToInt" } ] }
JSON Responses
The following examples demonstrate successful and unsuccessful 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 }