Types of LAM
LAM and LAMbot
In Moogsoft Enterprise, event ingestion settings are configured in two places.
LAM (lam.conf configuration file) - handles data acquisition, tokenization, and mapping. In some cases, it can also perform some normalization.
LAMbot - optional JavaScript to handle additional normalization processes.
First, we will take a look at the LAMs.
Which Type of LAM Should I Use?
In some cases, you could ingest the same data using separate mechanisms. In such cases, typically receiving LAMs are the preferred option over polling type.
Also, when given a choice of multiple options you should consider the following list in the following order of preference:
REST LAM or webhook
Implemented as a direct forward from the underlying monitoring tool or via a messaging bus such as RabbitMQ, Kafka, JMS.
Provide a more reliable delivery mechanism, as well as has no dependency on a polling cycle in case of a polling LAM in Moogsoft Enterprise.
REST Client LAM
SNMP LAM if MIB conversion already exists.
Socket LAM if event raw payload is structured to allow tokenization.
Syslog LAM if messages are structured and invariable and require little or no ongoing maintenance via email
UDP Socket and SNMP protocols do not offer guaranteed delivery of forwarded events as opposed to webhook or messaging bus mechanisms.
Tip
If you decide to swap the ingestion mechanisms - for example, swap webhook with a RabbitMQ LAM - for a monitoring system, make sure to use a consistent approach to the data parsing in the lambot so that there is no impact to the downstream processing in Moogsoft Enterprise.
LAM Types - Generic, Aggregation, and Vendor-Specific
There are three types of LAMs shipped with Moogsoft Enterprise and each requires a different degree of configuration:
Generic LAMs
The generic adapters have no specific default configuration - i.e. they can be customized to any suitable single data source that sends events on the supported protocol. The associated config and lambot files provide only a framework for acquiring, tokenizing, and mapping the raw data, and require that you configure the logic for the normalization part including deriving an appropriate signature.
There are three types of generic LAMs:
Socket: accepts data over TCP or UDP network socket, and lets you specify how to parse the incoming data stream.
Rest/webhook: listens for data in JSON format over a REST protocol.
Rest client: polls a REST server and accepts JSON data.
Aggregation LAMs
The aggregation LAMs are specific to a protocol or vendor platform and have a configuration and a lambot for generically consuming events from these sources, but do little or no processing of the event contents themselves. Same as generic LAMs you will be required to configure the normalization part.
Since these are often aggregated event sources, there may be multiple event formats within the single ingestion source. For example, a customer may send all of their event data - events from both Netcool and Nagios - to a Kafka bus. When we consume these using the Kafka LAM they still remain Netcool and Nagios events, containing the different attributes and lifecycle behavior associated with those underlying event sources. They will need the appropriate mapping, routing, processing, and normalization associated with these event sources. Without normalization at the aggregation layer, this work has to be done in the LAMbot.
Another example of aggregated ingestion is consuming the syslog data arriving from the Splunk platform. In this case the out of the box Splunk LAM would have to be enhanced to construct an appropriate signature and syslog string parsing into attributes such as hostname and severity unless this has already been done at the aggregation layer.
The biggest effort of setting up an aggregation LAM lies in identifying the number of separate event formats arriving via the adapter and assessing the normalization workload needed for each. You may be required to add routing logic for separate format handling. Use centrally administered modules to overcome and compensate for complexity within the LAMbot.
The aggregation LAMs are:
Logfile
Email
Kafka
JDBC
Splunk
Syslog (UDP or TCP socket)
Trapd (UDP)
RabbitMQ
WebSphere MQ
Vendor-Specific LAMs
Vendor-specific LAMs are the most complete, because they are product specific with the data in a known format, and can be handled in a consistent manner regardless of customer. We would expect only light customization to the configuration and - only needed if the customer has any specifics - to the LAMbot.
Consult the Integrations section of the documentation for the complete list of vendor-specific LAMs.