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


The Socket LAM is a link access module that:

  • monitors data being written to a network socket
  • parses this data according to the LAM’s configuration file
  • constructs events that are passed to the MooMs bus

You can configure how the Socket LAM processes data. Moogsoft AIOps expects the data to be written to the socket as a series of tokens that are delimited in a predictable, repeatable and regular way. 

The Socket LAM takes its input from a UNIX TCP socket. The details of how the network connection is established is defined in the Socket LAM configuration, socket_lam.conf, in the monitor section, where you can configure three parameters to control how the connection is established. 

Socket LAM conforms to the Java platform standard on Time Conversion. See Data ingestion

Command line attributes

The executable is a command line executable that can be run as a service daemon, and takes four attributes, which can be viewed by typing: 

% socket_lam --help
Points to a pathname to find the configuration file for the LAM. This is where the entire configuration for the LAM is specified
Displays all the command line options
Displays the component’s version number
Specifies the level of debug. By default, you get everything. In common with all executables in MOOG, having it set at that level can result in a lot of output (many messages per event message processed). In all production implementations it is recommended that log level be set to WARN, which only informs you of matters of importance


The configuration that controls the behaviour of the Socket LAM is socket_lam.conf. Remember you must specify -config on the command line, otherwise, the system will look for socket_lam.conf, in the $MOOGSOFT_HOME/config directory

socket_lam.conf contains all the various controls for how events are processed. There is also a LamBot, SocketLam.js. All LAM’s can take a LamBot. 

The config file contains a JSON object. All config in the MOOG system is presented as a JSON object. At the first layer of the object, you have a parameter called config, and the object that follows config has all the necessary information to control the LAM. 


In some instances the attribute strings are quoted. Our JSON parser is forgiving, but the standard requires quoting for all strings, so Moogsoft recommends that you quote all strings. 


You can comment out lines by prepending them with a hash. 

socket_lam.conf walk through

Monitor object

monitor defines the object to be monitored: 

            name : "Socket Monitor",
            class : "CSockMonitor",
            mode : "SERVER",
            address : ""
            port : 8411

The above example specifies: 

  • name and class, which are reserved for future use and should be left as the defaults, Socket Monitor and CSockMonitor
  • mode, can either be CLIENT or SERVER, following that you have an IP address, or hostname, and a TCP socket. In the case of CLIENT mode, the Socket LAM will attempt to connect to the defined address and port. If the Socket LAM cannot make a successful TCP connection to the socket, it will continue to retry within a built in time period. So, you can start up the Socket LAM in the absence of the source being ready, and it will continue to try and connect until it gets a connection. In SERVER mode, the Socket LAM opens the address and port number as a listening socket that can accept inbound connections. It will sit and wait until the source of the data makes a successful attempt to do a TCP connect to the address and port, spawning a standard TCP socket on which to except input 

There is a current limitation with the Socket LAM, in that it can only handle one socket connection. Although it can operate in SERVER mode, you cannot have four or five connections, because you will suffer from interleaving with the data and unpredictable results.

Agent configuration object

agent allows you to define two parameters: agent and  log

            name : "ACME_EVENTS",
            log : "./socket_lam.log"

The above example specifies: 

  • The agent name, in this instance, ACME_EVENTS. When constructing the event that will be sent to MooMs, you can refer to the value that you give for name
  • log, which is a way of logging and capturing a permanent record of what the Socket LAM is receiving. In this instance the Socket LAM will write its ingress contents to ./socket_lam.log

Having a value for log is optional. Moogsoft recommends that log is used if you are collecting data, and you want to process the data later.

Data parsing

Any received data needs to be broken up into tokens. Once you have the tokens, you can start assembling an event. There are a number of parameters that allow you to control how this will work. The first two are a start and end character. The square brackets [] are the JSON notation for a list. You can have multiple start and end characters. The system considers an event as all of the tokens between any start and end character. 

start: [],
end: ["\n"],

The above example specifies: 

  • There is nothing defined in start; however, a carriage return (new line) is defined as the end character

In the example above, the LAM is expecting a whole line to be written followed by a return, and it will process the whole line as one event. 

Carefully set up, you can accept multi-line events. 

For correct parsing of incoming events, the start tokens should not be a subset of any end token and vice versa. For example: 
start : [ "|event|" ],
end  : [ "|event|\n"] 
may result in some unpredictable parsing because the start token "|event|" is a subset of the end token. So if the start token is encountered before the intended end token is met the parser will think that it is the start of a new event and stop the current stream at this point and create an undesirable event. If a configuration like this is in place, and the source cannot be changed, then the recommendation is to use the regular expression parser instead of the start_and_end parser. This does not have the same token subset restriction


Delimiters define how a line is split into tokens – “tokenising”. For example, if you have a line of text data, it needs to be split up into a sequence of sub strings that are referenced by position from the start. So if you were processing a comma-separated file, where a comma separates each value, it would make sense to have the delimiter defined as a comma. Then the system would take all the text between start and end and break it up into tokens between the commas. The tokens could then be referenced by position number in the string starting from one, not zero. 

For example if the input string was “the,cat,sat,on,the,mat” and comma was used as a separator, token 1 would be “the”, token 2 “cat” and so on.

Be aware, there are complications when you come to tokenisation and parsing. For example, if you say comma is the delimiter, and the token contains a comma, you will end up with that token containing a comma to be split into two tokens. To avoid this it is recommended that you quote strings. You must then allow the system to know whether it should strip or ignore quotes, hence the stripQuotes  and ignoreQuotes parameters. 

ignoreQuotes: true,
stripQuotes: false,
ignores: "",
delimiter: [",","\r"]

The above example specifies: 

  • If you have strings that are quoted between delimiters, ignoreQuotes set to true will look for delimiters inside the quote. For example, <delimiter>”hello “inside quote” goodbye”<delimiter> gives a token [hello inside quote goodbye]
  • Setting stripQuotes  to true removes start and end quotes from tokens. For example, “hello world” gives a token [hello world]
  • ignores is a list of characters to ignore. Ignored characters are never included in tokens
  • Delimiter is the list of valid delimiters used to split strings into tokens


For each event in the file, there is a positioned collection of tokens. Moog enables you to name these positions so if you have a large number of tokens in a line, of which you are interested in only five or six, instead of remembering it is token number 32, you can call token 32 something meaningful. 

        { name: "Identifier", position: 1 },
        { name: "Node", position: 4 },
        { name: "Serial", position: 3 },
        { name: "Manager", position: 6 },
        { name: "AlertGroup", position: 7 },
        { name: "Class", position: 8 },
        { name: "Agent", position: 9 },
        { name: "Severity", position: 5 },
        { name: "Summary", position: 10 },
        { name: "LastOccurrence",position: 1 }

The above example specifies: 

  • position 1 is assigned to Identifier; position 4  is assigned to node and so on 
  • Positions start at 1, and go up rather than array index style counting from 0

This is important because at the bottom of the file, socket_lam.conf there is a mapping object that configures how Moog assigns to the attributes of the event that is sent to MooMs, values from the tokens that are parsed. For example, in mapping there is a value called rules, which is a list of assignments. 

        { name: "signature",rule: "$Node:$Serial" },
        { name: "source_id",rule: "$Node" },
        { name: "external_id",rule: "$Serial" },
        { name: "manager",rule: "$Manager" },
        { name: "source",rule: "$Node" },
        { name: "class",rule: "$Class" },
        { name: "agent",rule: "$LamInstanceName" },
        { name: "agent_location",rule: "$Node" },
        { name: "type",rule: "$AlertGroup" },
        { name: "severity",rule: "$Severity", conversion: "sevConverter" },
        { name: "description",rule: "$Summary" },
        { name: "first_occurred",rule: "$LastOccurrence" ,conversion: "stringToInt"},
        { name: "agent_time",rule: "$LastOccurrence",conversion: "stringToInt"}

In the example above, the first assignment name: "signature",rule:"$Node:$Serial" ( "$Node:$Serial is a string with $ syntax) means for signature take the tokens called Node and Serial and form a string with the value of Node followed by a colon followed by the value of Serial and call that signature in the event that is sent up to the system. 

You define a number of these rules covering the base attributes of an event. For reference, the system expects a minimum set of attributes in an event that are shown in this particular section. 

Constants and conversions

There are a number of these rules, such as severity where there is a conversion defined. The following example looks up the value of severity and returns the mapped integer on the other side. 

            lookup: "severity",
            input: "STRING",
            output: "INTEGER"
            "CLEAR" : 0,
            "INDETERMINATE" : 1,
            "WARNING" : 2,
            "MINOR" : 3,
            "MAJOR" : 4,
            "CRITICAL" : 5,
            moog_lookup_default: 3

The above example specifies: 

  • sevConverter, which references a conversion definition in the conversions object 
  • The sevConverter  uses a look up table lookup: "severity" to reference a table named severity defined in the constants section 

In this example the conversion takes as its input a string with a textual value of severity. From this it looks in the severity conversion table for a matching value and then returns the mapped value converted to an integer 

moog_lookup_default can be used to specify a default value when an event is received which does not map to one of the values listed.

If moog_lookup_default setting is not used and an event is received which does not map to one of the other specifically listed values, the event will NOT be processed.

stringToInt is used in a time conversion, which forces the system to turn a string token into an integer value. 

                input: "STRING",
                output: "INTEGER"

The filter defines whether Moog uses a LamBot. If you comment out the presend value, no filter is applied to the events produced and all events are sent unchanged to the MooMs bus. If a LamBot is defined, for every event the system assembles using this configuration, the event is passed to the LamBot (via the presend function defined in the LamBot). 

            presend: "SocketLam.js"

Therefore you must define a presend function in your JavaScript file. 

The return value of the presend function will determine whether the event is sent on to the MooMs bus. The presend function can also define sub-streams that events are sent out on, so events can be sent to different farmd’s.

You can provide an additional parameter to presend called modules that takes a JSON list. The JSON list is a list of optional JavaScript files that are loaded into the context of the LAMBot and executed; thus, you can share modules between LAMs. For example, you can write a generic Syslog processing module that is used in both the Socket LAM and the log file LAM. You therefore do not need to needlessly replicate code in the Moobot for each of the LAM’s. 

JSON events

The other capability of all LAMs is the native ability to consume JSON events. You must have a start and end carriage return as it is expecting a whole JSON object following the carriage return. 

Under parsing you have:

end: ["\n"],

For the delimiter you have: 

delimiter: ["\r"]

JSON is a sequence of attribute/value, and the attribute is used as a name. Under mapping, you must define the following attribute builtInMapper: "CJsonDecoder". It automatically populates, prior to the rules being run, all of the values contained in the JSON object. 

 For example if the JSON object to be parsed was: 

{"Node" : "acmeSvr01","Severity":"Major"...}\n

The attributes available to the rules in the mapping section would be xNode=”acmeSvr01”, $Severity=”Major”  and so on. 


If you have an attribute that is never referenced in a rule, for example “enterprise trap number” which is never mapped into the attribute of an event, they are collected and placed as a JSON object in a variable called defined here and passed as part of the event. 

  • No labels