Alert Builder Reference

Name of the Alert Builder Moolet. Do not change.

Moolet class name. Do not change.

Determines whether the Alert Builder runs when Moogsoft Onprem starts. By default, it is set to true, so that when Moogfarmd starts, it automatically creates an instance of the Alert Builder. In this case you can stop it using farmd_ctrl.

Specifies a JavaScript file found in $MOOGSOFT_HOME/moobots, which defines the Alert Builder Moobot, which creates alerts.

Determines whether or not Moogsoft Onprem includes the Alert Builder in the Event Processing metric for Self Monitoring.

A list of event streams, which the Alert Builder Moolet processes in this instance of Moogfarmd. The LAMs can be configured to send events on different streams. Moogfarmd, as specified in the Alert Builder configuration, then decides whether or not to process them. If Moogsoft Onprem runs multiple Moogfarmds, you can have different event streams being processed by different Alert Builder Moolets.

You can comment out event_streams, or provide an empty list. Then, the Alert Builder processes every event that is published on the default /Events topic on the Message Bus.

You configure the Alert Builder Moolet by giving it a list of strings, for example, [ “App A”, “App B” ]. The result is that the Alert Builder listens for events published on /Events/AppA, and /Events/AppB, and processes that data. Importantly, in this example, events published to /Events or any other stream are ignored. You can have Moogfarmds that process completely separate event streams, or, multiple Moogfarmds that process some different event streams and some common event streams. You would do this when some of the alerts are common to all the applications that are being processed, but some are specific only to a given application. In this way, you can cluster alerts separately for each application by configuring the Sigalisers to only processes alerts from a specific upstream Alert Builder Moolet.

For example, if you have two separate applications that share the same network infrastructure: in Moogfarmd 1, you can have as the event streams, application A and networks, and, in Moogfarmd 2, you can have application B and networks. With this configuration, you can detect alerts and then create Situations that are relevant for just application A and similarly just for application B; however, if there is common networking infrastructure and problems occur with network failures across applications A and B, the Alert Builder can cluster these into Situations.

#
# Configuration for Event Workflows Moolet
#
{    
name            : "Event Workflows",
classname       : "com.moogsoft.farmd.moolet.workflowengine.CWorkflowEngine",    run_on_startup  : true,    
metric_path_moolet : true,    
moobot          : [ "WorkflowEngine.js", "DejaVu.js" ],    # event_handlers : [ "Event"],
message_type: "event",    

# Specify a list of streams for the Workflow Engine to listen to.     
# Reference the streams set in the filter section of the LAM     
# configuration. Defaults to the generic event stream.       

, event_streams : [ "AppA" ]
}

Specifies the number of threads in the Alert Builder. Choose a value to match the event rate experienced by your system that allows time for alert creation.

Allows you to specify a different Events Analyser configuration, for tokenizing and analysis rules, for each Alert Builder Moolet. If no configuration file is specified, the system default events_analyser.conf is used.

Stream name under which the Events Analyser runs in order to calculate token and alert entropies. If set to null, all alerts from all streams are included in the entropy calculations.

If set to true, Moogfarmd extracts the priming stream name from the event's stream. If set to false, Moogfarmd uses the stream configured in priming_stream_name.