Reporting Plugins


Once an event has been processed, the Manager uses Reporting Plugins to convert alerts from Prelude binary IDMEF format, to various output formats.

There are several Reporting Plugins:
  • db - A database Plugin (MySQL and PostgreSQL).
  • xmlmod - An XML Reporting Plugin.
  • textmod - A text Reporting Plugin.
  • relaying - A plugin relaying alert to another set of manager.
  • smtp - Send textual alert through your SMTP server.
  • (check the prelude-manager --help output for others)

A reporting plugin might be loaded several times, so you could have two db reporting plugin loaded and addressing different database (this is true for most plugin categories).

In order for a plugin to be loaded several times, you need to provide it with the name of each instance. If you don't provide a name, then default is used.

Here is an example:

   prelude-manager --textmod --logfile stderr --textmod [[MyInstanceName]] --logfile /var/log/prelude.log

Or from the configuration file:

logfile = stderr

logfile = /var/log/prelude.log

Will load an instance of the textmod reporting plugin named default, which will log to stderr; and another instance named !MyInstanceName logging to /var/log/prelude.log.

Report Plugins Failover

Under certain conditions, you might want to activate failover for a given reporting plugin (as of the time of writing, only the db reporting plugin supports it). Failover is a prelude-manager feature allowing storage of alerts in case the reporting plugin fails. This is especially useful when the reporting plugin relies on another program (example: database).

If the protected reporting plugin fails for any reason to process the message, the failover subsystem will backup it as well as any future messages. It then will periodically try to re-initialize the plugin, and process any backed up messages.

As an example, if you activate report plugins failover for the db plugin, and then you stop the underlying database. Messages going to the plugin will be saved and processed as soon as the db plugin is successfully reinitialized (in this case, when the database is available again).

--failover db --failover db[MyPluginInstance]

or from the configuration file:

failover = db
failover = db[MyPluginInstance]

Will both activate failover for the default instance of the db plugin, and for the MyPluginInstance instance of this same plugin.

Note: It is not necessary to activate failover for the relaying plugins since the internal subsystem for this plugin will always failover in case of failure.

Additional Notes:

There are two kinds of failover:

  • Global failure: If we get a global failure (example: database disconnect, somethings that is not an internal error), all message(s) are saved and re-submitted later automatically when the software recover from the failure (example: database is back online).

    Path to failover file: $installed_path/var/spool/prelude-manager/failover/db[default]/data0 (or whatever the db instance name is)
    New events are appended to the data0 file, new files are not created for each event.

  • Single failure: If we get a single failure (example: query error), then the message(s) are saved in a separate failover directory - and are not re-submitted automatically. The reason for this not being automatic, is that many times on single failures, there is some error that needs intervention to fix, which is the reason the message is saved for further analysis.

    Path to failover file: *$installed_path/var/spool/prelude-manager/failover/db[default]/invalid/data0_ (or whatever the db instance name is)

    New events are appended to the data0 file, new files are not created for each event.

Processing the files:

You can load the failover file, to insert the events into the database and/or see the reported failure.

preludedb-admin load "type=mysql name=prelude_dbname user=username password=password" data0 <any options>

Any errors will be output to your console. In addtion when the file is done being successfully processed, you will see statistics on your console for the number of events fetched, inserted, and processed.

Global failure files are processed automatically once the database connection exists again, and failover files are cleared of their contents after processing. However, single failure failover files are not cleared after processing automatically - you must remove them yourself manually, then restart prelude-manager (there is no protection for reinserting this failover file's contents multiple times).

In addition, prelude-admin can be used to view or "replay" these events to a particular relay or manager.

prelude-admin print data0
prelude-admin send <analyzer profile> <Prelude Manager/Relay address> data0 

Replaying events with prelude-admin will only update the analyzerTime timestamp with the current time, other timestamps will keep their original values.

Back to Prelude-Manager