Page tree
Skip to end of metadata
Go to start of metadata

Introduction

rest_lam : is a REST endpoint allowing any tool to "push" events to the LAM.

The REST LAM is a link access module that provides a method of data ingestion through RESTful services, enabling Moogsoft AIOps to accept events via HTTP or HTTPS POST requests in a JSON, an XML and YAML format. In case of XML and YAML format the REST LAM, by default, converts events received in any format into JSON format. The REST LAM provides responses to the data sender in the form of a JSON object.

For the REST LAM to successfully ingest data, the incoming REST messages must conform to HTTP message format standard, which involves correct setting of the header and payload. The REST LAM responds with standard HTTP response codes (see below) and in the case of error, JSON formatted response messages. Multiple events can be sent to the LAM in a single request (see the first configuration example below).

The REST LAM can be configured to listen on a specific port and if authentication is configured, will reject incoming requests that do not contain the expected secret auth_token. Additionally the LAM can be configured to operate in SSL mode and accept requests only via HTTPS (TLS/SSL), which requires SSL certificates.

Configuring the REST LAM

The configuration file rest_lam.conf (default location /usr/share/moogsoft/config/) includes rules (data conversion), LAMBot and LAMBot module configuration. 

Also see example configuration below.

Component
Description
portThe port on the server that listens for REST messages. It is an optional value that defaults to  8888
use_sslAn optional boolean indicating whether the server should use HTTPS ( true ). The default value is  false
ssl_protocols

Only applicable if use_ssl = true

This configuration dictates which SSL protocols are enforced by the REST LAM, the following protocols are allowed to be specified:

  • SSLv3
  • TLSv1
  • TLSv1.1
  • TLSv1.2

If SSL is in use and no value is specified for this configuration then ONLY TLSv1.2 is allowed by default

ssl_key_filename  and  ssl_cert_filename The key and certificate files are both used by HTTPS and must be created with the standard  openssl  command. See the third  configuration example  below
path_to_ssl_filesThe location of the key and certificate files.  If the path begins with ‘.’ or ‘/’ then the path is used as specified (as in the example code above). Otherwise, MOOGSOFT_HOME is prepended to the path
For example: If MOOGSOFT_HOME is /opt/moogsoft/ and
 path_to_ssl  is set to config, the location is defined as /opt/moogsoft/config
auth_tokenA shared secret token in the request body used to authenticate requests. If not defined or empty then authentication via this means is disabled. If defined then all requests must contain this token in the body otherwise the request will be rejected.
encrypted_auth_tokenTo specify the 'shared secret' body token in encrypted form in the configuration file use this option. The 'shared secret' can be encrypted using the $MOOGSOFT_HOME/bin/moog_encryptor utility
header_auth_tokenA shared secret token in the request header used to authenticate requests. If not defined or empty then authentication via this means is disabled. If defined then all requests must contain this token in the header otherwise the request will be rejected.
encrypted_header_auth_tokenTo specify the 'shared secret' header token in encrypted form in the configuration file use this option. The 'shared secret' can be encrypted using the $MOOGSOFT_HOME/bin/moog_encryptor utility
authentication_typeWhen set to basic, authentication uses the graze login.  If set to none (default) or configuration is not specified, then basic  authentication does not occur
authentication_cacheValid only when  authentication_type  is set to  basic
When set to true (default), an encrypted version of a users password is kept in the internal cache for the duration of their session. This speeds request handling, but may be a security issue for some users. If set to false, the basic authentication internal cache is disabled. Users are authenticated with each request, which slows request handling
For example, in tests with 10,000 requests sent as one of 5 graze users, request handling times were over 20x faster
num_threadsThe number of threads that should be used to handle incoming connections.  It is an optional value that defaults to the number of CPUs available (up to a maximum of 8)
accept_all_jsonA boolean indicating whether the REST LAM should expect and process incoming requests using any form of JSON (true), or only incoming requests using the AIOps REST LAM protocol (false)

Incoming requests can be any valid form of JSON. The REST LAM configuration and LAMBot define the structure of the AIOps Event created

When set to true:
 Use true when an event sender does not conform to the AIOps REST LAM protocol

 

Together with list_contains_multiple_events set to true, an event sender (such as a third party commercial off-the-shelf product which defines its own rigid output of events) can be accepted into the REST LAM and be converted into AIOps Events that are sent out on to MooMS


Incoming requests must use the AIOps REST LAM protocol. The default AIOps configuration for the REST LAM and LAMBot can accept, convert and send the incoming requests


When set to false:
 Use false when you can determine how your event sender sends events, and you do not want to change the default rest lam config/lambot

Example valid JSON for an incoming request, if accept_all_json is set to true:


curl http://<hostname>:8888 -H "Content-Type: application/json" -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
    },
    {
        "signature":"SIGNATURE2",
        "source_id":"my_source_id2",
        "external_id":"my_external_id2",
        "manager":"TestMgr2",
        "source":"TestHost2",
        "class":"my_class",
        "agent":"TestAgent2",
        "agent_location":"my_agent_location",
        "type":"TestType2",
        "severity":5,
        "description":"TestDesc2",
        "first_occurred":1411134582,
        "agent_time":1411134582
    }
]'


Example JSON using the AIOps REST LAM protocol, if accept_all_json is set to false:


{
  auth_token: <string>,
  events: [
            {event1},
            .
            .
            .
            {eventn}
          ]
}
rest_response_modeDefines when the REST response is sent during the event ingestion lifecycle. This defines the level of feedback on how far Events are processed in AIOps
on_receipt (default)Instructs the REST LAM to reply to the REST request as soon as the incoming data has been validated as an Event
event_forwardedInstructs the REST LAM to reply to the REST request as soon as it has confirmed that MooMS has received the valid Event
event_processed

Instructs the REST LAM to reply to the REST request as soon as the valid Event has been processed by an AlertBuilder. The REST connection will remain open until a response is received by an AlertBuilder or until the configured timeout has been reached:

    • Use event_forwarded or event_processed to provide more detail as to how far an Event has been processed in AIOps and act accordingly, such as re-sending the event if a failure occurs
    • rpc_response_timeout
    • Defines how long the REST LAM will wait (in seconds) for a response from an AlertBuilder when the rest_response_mode is set to event_processed (see above)

Unlike other LAM configuration files, rest_lam.conf  only uses JSON, so the mapper is set internally and is not configurable. Other source identification components  of the configuration file  such as Regex are not used


LamBot Configuration to extract sub fields from a nested event data structure

In the following example the received event has multiple nested fields. The field summary is to be extracted in the received format, but it is nested in env:envelope> env:Body> createRequest> Summary. The env: in the field name may create problem in the mapping section of the config file. So we are removing it from the received data in the  modifyResponse function of the  LamBot

Example of an event that the REST LAM has received 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 configuration in the LamBot to remove env: form the received event fields and sending it to LAM for tokenizing and mapping :

Lambot:
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 configuration file. The mapping for class is done by $Description.content, if the configuration is LamBot would not have been made, then the mapping would have been $env:envelope.env:Body.createRequest.Summary, which would have thrown an error:

Mapping:

                { name: "signature", rule:      "host1::oem::cpu" },
                { name: "source_id", rule:      "FQDN" },
                { name: "external_id", rule:    "OEM" },
                { name: "manager", rule:        "OEM" },
                { name: "source", rule:         "Hostname" },
                { name: "class", rule:          "$Description.content"},
                { name: "agent", rule:          "$LamInstanceName"},
                { name: "agent_location", rule: "OEM Data Centre" },
                { name: "type", rule:           "$Priority.content" },
                { name: "severity", rule:       "$Severity.content" },
                { name: "description", rule:    "$Summary.content" },
                { name: "agent_time", rule:     "$moog_now"}


Example configuration

  • rest_lam.conf configuration example without authorization enabled:


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.conf configuration example with authorization enabled:


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
  } 


JSON request structure

If possible, the JSON structure of incoming requests should be in standard AIOps format - see the following example - to simplify mapping and other configuration. The payload of the REST message is an array of events in the defined structure, for example:


{"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",
    }
  ]
}


JSON response structure

REST LAM response messages are in the form of a JSON object, and are formatted to facilitate machine interpretation. 
In the response:

  • cached indicates whether the message content was cached (1 = yes, 0 = no)
  • processed indicates whether the message was successfully processed (1 = yes, 0 = no)
  • received indicates whether the message was successfully received (1 = yes, 0 = no)

For example: 

  • A successful response example:


    { 
       "message":"Processed 1 event(s)",
       "response":{ 
          "cached":0,
          "processed":1,
          "received":1
       },
       "success":true
    }
  • A failed response example without caching:


    { 
       "message":"General error. Processed 0 event(s)",
       "response":{ 
          "cached":0,
          "processed":0,
          "received":1
       },
       "statusCode":1000,
       "success":false
    }
  • A failed response example where caching has occurred:


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



Testing and Troubleshootin g

  • Use curl commands to test that the REST LAM is correctly configured and accepting REST messages
  • Ensure that you have network access to both the host machine and the specified port, and that the port is open through the server firewall
     

 REST LAM response codes

The REST LAM provides the following standard HTTP return codes indicating the state of the received message:

HTTP
return
code


Description
200

OK
The REST LAM has received and accepted the payload, which is valid JSON. There is no response message

 

This is not a positive indication that the Event has been properly processed by the LAM or LAMbot
Standard LAM log file response messages are issued for error conditions

400Bad Request
The JSON in the payload is invalid, so the request is rejected. The error could be in any part of the JSON, so the details should be reviewed with a standard JSON parser or lint. The response message is a JSON object containing the statusCode and message
401Unauthorised
The REST LAM configuration file has an auth_token defined but there is no  auth_token  in the header of the message, or the auth_token provided does not match. The request is rejected and will need to be resent with the correct auth_token. The response message is a JSON object containing the  statusCode  and message

405

Method not allowed
The HTTP request used an unsupported method. The only supported method is POST. The response message is a JSON object containing the  statusCode  and message
406Method not acceptable
The HTTP request used a content type that is unsupported. The only supported content type is application/JSON. The response message is a JSON object containing the  statusCode  and message


In the event of an error, the REST LAM provides the following REST response codes indicating the status of the request:

REST
response
code 

Description
1000General error
The request could not proceed and failed in a way that was not expected
3000General Security Error
There was an error with authentication
3001Security Authentication Error
Authentication did not succeed
4000General Method Error
There was an error with the method used
4001Method Not Supported
The HTTP method used is not supported
5000General Content Error
There was an error with the content
5001Content Not Supported
The content type used is not supported
5002Content Decoding Error
The content could not be decoded


 REST LAM configuration examples

The following REST LAM configuration file examples highlight authentication and SSL, along with with example curl commands to generate Events. 

  1. An example rest_lam.conf with no authentication or SSL (auth_token  commented out, use_ssl set to fals and related SSL properties commented out):

    monitor:
    {
          name : "Rest Lam Monitor",
          class : "CRestMonitor",
          port : 9876,
          use_ssl : 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:
        {
          intToInt:
          {
            input: "INTEGER",
            output: "INTEGER"
          },
          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"
    }


 For the above configuration, the following curl command:


curl http://moogbox2:9876 -H "Content-Type: application/json" --insecure -X POST -v --data '
{ 
   "events":[ 
      { 
         "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
      }
   ]
}' 


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"
}



 Also for the same configuration above, the following curl command:


curl http://moogbox2:9876 -H "Content-Type: application/json" --insecure -X POST -v --data '
{ 
   "events":[ 
      { 
         "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
      },
      { 
         "signature":"SIGNATURE2",
         "source_id":"my_source_id",
         "external_id":"my_external_id",
         "manager":"TestMgr2",
         "source":"TestHost2",
         "class":"my_class",
         "agent":"TestAgent2",
         "agent_location":"my_agent_location",
         "type":"TestType2",
         "severity":3,
         "description":"TestDesc2",
         "first_occurred":1411134582,
         "agent_time":1411134582
      },
      { 
         "signature":"SIGNATURE3",
         "source_id":"my_source_id",
         "external_id":"my_external_id",
         "manager":"TestMgr3",
         "source":"TestHost3",
         "class":"my_class",
         "agent":"TestAgent3",
         "agent_location":"my_agent_location",
         "type":"TestType3",
         "severity":3,
         "description":"TestDesc3",
         "first_occurred":1411134582,
         "agent_time":1411134582
      }
   ]
}'



generates the following three separate Events from the REST LAM:
Event 1:


{ 
   "_MOOTADATA_":{ 
      "creation_time":1452090542681
   },
   "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"
}


Event 2:


{ 
   "_MOOTADATA_":{ 
      "creation_time":1452090542681
   },
   "agent":"TestAgent2",
   "agent_location":"my_agent_location",
   "agent_time":1411134582,
   "class":"my_class",
   "description":"TestDesc2",
   "external_id":"my_external_id",
   "manager":"TestMgr2",
   "overflow":{ 
      "LamInstanceName":"DATA_SOURCE",
      "first_occurred":1411134582
   },
   "severity":3,
   "signature":"SIGNATURE2",
   "source":"TestHost2",
   "source_id":"my_source_id",
   "type":"TestType2"
}


Event 3:


{ 
   "_MOOTADATA_":{ 
      "creation_time":1452090542681
   },
   "agent":"TestAgent3",
   "agent_location":"my_agent_location",
   "agent_time":1411134582,
   "class":"my_class",
   "description":"TestDesc3",
   "external_id":"my_external_id",
   "manager":"TestMgr3",
   "overflow":{ 
      "LamInstanceName":"DATA_SOURCE",
      "first_occurred":1411134582
   },
   "severity":3,
   "signature":"SIGNATURE3",
   "source":"TestHost3",
   "source_id":"my_source_id",
   "type":"TestType3"
}



 

The -- insecure  option used in the above two curl commands (and the one in the next example below) uses TSL but will not validate the certificate


  1.  An example rest_lam.conf with authentication, but no SSL (auth_token  uncommented, use_ssl set to fals and related SSL properties commented out):

    monitor:
    {
          name : "Rest Lam Monitor",
          class : "CRestMonitor",
          port : 9876,
          use_ssl : 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:
        {
          intToInt:
          {
            input: "INTEGER",
            output: "INTEGER"
          },
          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"
    }


 For the above configuration, the following curl command:

curl http://moogbox2:9876 -H "Content-Type: application/json" --insecure -X POST -v --data '
{ 
   "auth_token":"abcd1234",
   "events":[ 
      { 
         "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
      }
   ]
}'


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"
}



  1. An example rest_lam.conf with authentication and SSL (auth_token  uncommented and u se_ssl set to true and related SSL properties uncommented):
    A key and certificate file must be generated on the host running the rest_lam; for example with the following command:

    openssl req -new -x509 -days 365 -nodes -subj "/C=''/ST=''/L=''/O='moogsoft'/OU=''/CN=moogbox2" -out /tmp/server.pem -keyout /tmp/server.key
    monitor:
    {
          name : "Rest Lam Monitor",
          class : "CRestMonitor",
          port : 9876,
          use_ssl : true,
          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:
        {
          intToInt:
          {
            input: "INTEGER",
            output: "INTEGER"
          },
          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"
    }


 For the above configuration, the following curl command:


curl https://moogbox2:9876 -H "Content-Type: application/json" -X POST -v --data '
{ 
   "auth_token":"abcd1234",
   "events":[ 
      { 
         "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
      }
   ]
}'


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"
}


The remote host sending the curl command must have a copy of the certificate file in the correct location, for example:


/root/server.pem


Version Information

LAM Version

Tool Version

Tested?

Expected to Work

1.0

Generic

Yes

Yes

1.1GenericYesYes
  • No labels