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


All received data is broken into tokens (tokenised) and then assembled into an Event. There are a number of parameters that allow you to control how tokenising works. 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 entire line to be written followed by a return, and it will process the entire line as one Event. 

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

Regex Parsing

Regular expressions can be used to extract relevant data from the input data. Here's an example definition of how: 

    type: "regexp",
        # See
        # for accepted Regular Expression syntax.
        pattern : "(?m)^START: (.*?)$",
        capture_group: 1,
        tokeniser_type: "delimiters",
                ignoreQuotes: true,
                stripQuotes: true,
                ignores:    "",
                delimiter:  ["||","\r"]

Start & End Parsing


Delimiters define how a line is split into tokens. 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, the consequence is that the 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. Moogsoft AIOps 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 AIOps 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 to the AIOps. 

You define a number of these rules covering the base attributes of an Event. For reference, AIOps 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