Child pages
  • opEvents input sources

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


opEvents can process information from a variety of sources, some of which can be extended to suit non-standard deployments. This document briefly documents how to configure opEvents' input sources.


The natively understood formats are:

Format Name
(Parser Type)
nmis_eventlogAn event log file created by NMIS
nmis_slavelogAn NMIS poller event log file
nmis_traplogAn NMIS trap log file
nmis_json_dirA directory of NMIS event logs in JSON format
cisco_syslogA Syslog log file containing logs created by Cisco devices

A Tivoli log file

To enable a particular log file or format, you need to add an entry for the  log file in question to the list of files for the appropriate log format; check the  cisco_syslog entry in the example above for the syntax. The tokens <nmis_something> in the example work like centrally-defined shortcuts or macros; they are replaced by the actual locations given in the directories section at the beginning of conf/opCommon.nmis.


  • set.propertyname(value) sets the named property to the static value.
    No quoting of the value is required or supported.
    The character ")" cannot be part of the value before opEvents 2.2; In 2.2 and above it may only be present if you use the explicit list format for your action statement.
  • capture(propname1,propname2,...) saves the respective captures from the regex in the named properties. The captures are assigned in their order in the regular expression; if you want grouping but not capturing, use (?:....) in your regex. Note that you cannot use multiple capture statements in one THEN.
  • opEvents version 2.0  introduces the new action ignore. This aborts all parsing of this input line altogether and no event is created for it.
    Normally the generic parser is expected to extract suitable information for an event from every single input line, which might not work well if your log data is coming from multiple sources or can't be suitably prefiltered.
  • In opEvents version 2.2 we've added the directives  resolve.fwd(propname) and resolve.rev(propname).
    The resolve.fwd() directive expects the property to be a DNS name and queries the DNS for an IP address associated  with the name; the resolve.rev() directive interprets the property as an IP address and looks for a host name for it. If the resolution is successful, the property value is replaced by the DNS data; otherwise the property is left as-is.
    e.g. to resolve a BGP Peer address which is stored in the element name, add an entry to DNS or /etc/hosts and include resolve.rev(element) as a parser directive.
  • opEvents 2.2 also adds the new directive plugin(PluginName), which invokes an external parser plugin for further enrichment or modification of the event.
    This functionality is described in more detail in the next section.


If a plugin named 'PluginName' is available, its parse_enrich function is executed and if successful, the modifications made by the function replace the event properties. Parsing then continues normally.