...
Code Block |
---|
'log' => { 'tmp' => { format => 'text', # a simple textual log file => '/tmp/opevents.log', # last-or-all messages go into this file mode => 'append', # if not given, the log is overwritten, # the default template if none is set: # template => [ "event.time", "\t", "node.name", "\t", "event.event", "\t", "event.element", # "event.state", "\t", "event.details" ], }, 'machinelog' => { format => 'json', # a machine-oriented json log dir => "/tmp/opevents_json", # the directory to log into (created on demand) }, }, |
...
Two log formats are supported, text
and json
.
- Text logs contain by default only the most essential event properties as a tab-delimited list, one event per line. If the
mode
argument is not present, then the log file is overwritten every time the action is executed; the more common mode would beappend
.
In opEvents 3,text
logs support output templates as shown in the example above; see the syslog.XYZ() section below for details about templates. - JSON logs on the other hand contain all event properties, one event per JSON file. You have to give a
dir
option which specifies where those logfiles will be created. The logfiles are named timestamp-number.json, timestamp being the UNIX timestamp and number being a running counter (the UNIX timestamp has a one second granularity, number differentiates between multiple events in a single second).
Configuration for script.XYZ()
...
Please note that before version 2.0.4 email
actions were handled synchronously and thus blocked the events processing until the email delivery concluded. In version 2.0.4 and newer this action is handled asynchronously in a separate process.
Configuration for syslog.XYZ() and nmissyslog.XYZ()
Anchor | ||||
---|---|---|---|---|
|
Actions that involve syslog servers require that conf/EventActions.nmis
contains a matching server definition in its syslog
section, similar to this example:
...