Test LAM

In some instances the attribute strings are quoted. Our JSON parser is forgiving, but we recommend that you quote all strings.

To comment out lines, prepend them with a hash.

The monitor section allows you to define all the templates and control the generation of the events . Do not change the name or class properties, these are documentation values that the code requires:

monitor: 
{ 
        name    : "Test File Monitor", 
        class   : "CTestMonitor", 
}

data_rate allows you to instruct the test LAM to generate a given quantity of output in a minute. You define the output as the number of events per minute. The test LAM then compresses time to adjust the period for each template and achieve the rate you supply.

The follow example specifies a data rate of 500 events per minute:

data_rate : 500, 

If you define one template with one source host that sends an event every 20 seconds, your actual rate is three events per minute. But if you want the LAM to send 30 events per minute, the system compresses the period from 20 to two seconds to achieve 30 events per minute.

The system's minimum time between sending events is one millisecond. We do not recommend sending out that many events in a single LAM (for one template and source this equates to 60,000 events per minute), as doing so overloads the relevant systems.

The default value for total_events is -1. Setting a value above 0 causes the LAM to produce that many events and then exit. For example if total_events is set to 100, the LAM will generate 100 events and then complete. Setting a value below 0 causes the LAM to continue indefinitely.

total_events : -1, 

resolution is an internal field that controls the execution of the templates and the number of slices the LAM divides one minute into. The Test LAM attempts to distribute the generation of events evenly across a minute and uses these subdivisions to fill with individual template/source combinations. Internal execution of the LAM effectively evaluates all event templates for execution.

In all normal implementations resolution is set to 1, which causes no time slicing and every template is checked every second.

resolution : 1, 

resolution is effectively the granularity of time to use in the LAM. For example, if you have 20 seconds as a period, resolution controls whether it is 20 seconds exactly (set to 1), or, plus or minus five seconds (set to 12). If you divide time slices into a second, you can have periods that are resolved up to a second. If you divide time slices into 5, if you then have a period of 18, it would either execute on 15 seconds or 20 seconds.

The reason you configure this is that the wider the resolution, the less compute the LAM uses to generate events; the trade-off is the greater the error in the randomness.

resolution determines how closely packed you can put exemplar's for an event template. If you define a template for every 20 seconds and you have 10,000 hosts, what you must avoid is on the 0 second sending 10,000 events, and then, sending nothing until the next 20 seconds before sending 10,000 more. The system spreads out in time the load so that you end up with a consistent event rate (which averages to the value set in data_rate). Therefore avoid overloading the system and returning an unrealistic event rate that exhibits high kurtosis.

sources defines the imaginary sources or hosts that the events will come from. You can define these in one of two ways.

The first way is to define a simple list of source names:

sources: 
{ 
        "switches" : [ "switchA","switchB","switchC","switchD" ], 
}

An event template that use switches will generate an event for Switch A, an event for Switch B, an event for Switch C, and so on. While this generates a number of events from different sources, the methodology is time-consuming.

The second way is to use autohost, which allows the autogeneration of a long list of similar hosts, where you define the template hostname; in the following example it is xldn%dpap . You must also define a range with a start and a count:

"autohost": 
{ 
        "template" : "xldn%dpap", 
        "range": 
        { 
                "start" : 12, 
                "count" : 10 
        } 
} 

This substitutes for %d a number that starts at 12 and produces 10 instances. So you would have 12, 13, 14, 15, 16 all the way up to 21 in this instance. This is a good way to generate a high volume of events from a variety of sources. For example, you can have a start of 1 and have a count of 10,000, which results in 10,000 events from 10,000 different sources.

sources is an object that contains entries that take a list, or, in the case of an autohost, take an object that takes a template and a range, which is an object.

events is a list of event templates, which are JSON objects. Each event template allows you to provide it with a name. This is important because by default, the signature for the generated event is composed of “$name:$source”:

events:[ 
{ 
        "name" : "DBRestart
}]

The template name and source thus enable you to deduplicate alerts from an event template. To do so, you specify which source definition to combine with the template to generate the events. The sources must therefore match a definition of sources:

#"sources"   : "hosts", 
"sources"    : "autohost", 

You can either send the events with a fixed period, or, if you specify a time period (in seconds), you can randomise the period between events.

"timing": 
{ 
        "randomised" : true, 
}

Setting randomised to true randomises the exact period between events. If, for example, the core period you specify is 20 seconds, this sets the average period over time but you will also receive individual events spaced with a random period i.e., 18 seconds, 21 seconds. The way it averages up to the 20 is defined in distribution, which defines a tuned probabilistic distribution for the periods.

You can also specify a distribution class to specify the distribution of periods, which controls the sequence of intervals between events from a given template according to a class, which implements a given probability density function. In this case CUniformDist randomly selects periods (up to max_period) in increments of increment, but ensures that over sample_norm, chunks of max_period that each period (in this case 0 (we actually use 1 second rather than 0),10,20,30,40,50,60) occur equally likely, and the period will average to 30.143 (a period of 0 seconds is not allowable, which is why the answer is not exactly 30!).

"distribution": 
{ 
        class           : "CUniformDist", 
        max_period      : 60, 
        increment       : 10, 
        sample_norm : 2 
} 

The above example specifies:

Moogsoft Onprem currently only supports uniform distribution, which splits max_period into increment chunks and then randomly chooses from amongst that event set with equal probability. The sample_norm is the time over which the engine guarantees that the mean is max_period/2.

In future releases Moogsoft will support normal distribution, and be able to define the kurtosis, the standard deviation and variance.

fields defines all the various components of events that are sent on the events bus. For example in your test environment you can specify: the class, a description, an external identifier etc., as shown below:

"fields": 
{ 
        "agent_location"      : "localhost", 
        "class"                       : "AppMon", 
        "description"                 : "Database instance has restarted",
        "external_id"                 : "12345", 
        "manager"                     : "PATROL", 
        "severity"                    : 2,    
        "type"                                : "DBFail", 
        "entropy"                     : 0.8 
} 

Moogsoft Onprem will fill in the first occurred, the last occurred, the agent time etc. The whole of the file is a sequence of these templates. There are different examples of timing parameters and distribution.

For example in the LinkDown, in timing you have an interval of 60, randomised set to true, and a variance of 20.

"name"               : "LinkDown", 
"sources"     : "switches", 
"timing"      : { 
                                "interval" : 60, 
                                "randomised" : true, 
                                "variance" : 20 
              },

The above example specifies:

The LinkUp template has the precedent field, which references the LinkDown template, which means you can only get a Link Up once there has been a Link Down for the given defined source (switches).

"name"               : "LinkUp", 
"sources"     : "switches", 
"precedent" : "LinkDown", 
"timing"      : { 
                                "interval" : 60, 
                                "randomised" : true, 
                                "variance" : 20 
                          }, 

The above example specifies:

In the Web Server Trap Down, you only have two fields: randomised and variance.

"name"               : "Web Server Down Trap", 
"sources"     : "hosts", 
"timing"      : { 
                                "randomised" : true, 
                                "variance" : 180 
              }, 

The Agent and Process Log sections of the Test LAM configuration file enable you to define the following properties:

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).

filter: 
{ 
        presend: "TestLam.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 LAMs.