# Options of db-parser() parsers

The `db-parser()` parser has the following options.

## drop-unmatched()

|   
---|---  
Accepted values: | `yes`, `no`  
Default: | `no`  
  
_Description:_ If set to `yes`, AxoSyslog discards every message that does not match any pattern in the database. For details and examples, see [Using pattern databases](../../../docs/axosyslog-core/chapter-parsers/chapter-patterndb/configuring-pattern-databases/index.md).

## file()

|   
---|---  
Synopsis: | `file(<path-to-pattern-database>)`  
Default: | `/opt/syslog-ng/var/run/patterndb.xml`  
  
_Description:_ Path to the pattern database XML file to use. Different `db-parser()` statements can reference different pattern databases by setting different `file()` paths.

## inject-mode()

|   
---|---  
Accepted values: | `internal`, `pass-through`, `aggregate-only`  
Default: | `pass-through`  
  
_Description:_ Controls how AxoSyslog routes messages generated by the parser (for example, by `create-context` actions or trigger-action rules). The following values are available:

  * _internal_ : Inject generated messages into the internal source of AxoSyslog, so they appear in every log path that uses `source(s_internal)`.
  * _pass-through_ : Pass generated messages into the same log path as the original message that triggered them. This is the default.
  * _aggregate-only_ : Only emit the generated messages and drop the triggering original messages.



## internal()

|   
---|---  
Accepted values: | `yes`, `no`  
Default: | `no`  
  
_Description:_ Marks this pipeline element as internal. Elements marked as `internal()` are treated as an implementation detail, so for example statistics of the given pipe are available only on higher stats level. This option is mainly useful for developers or when writing SCL blocks and integrations.

## message-template()

|   
---|---  
Synopsis: | `message-template("<template>")`  
Default: | `${MESSAGE}`  
  
_Description:_ The template or macro that AxoSyslog evaluates and uses as input for pattern matching. By default, patterns are matched against the body of the message (`${MESSAGE}`). Use this option to apply patterns against a different field or against an expression built from the log message. The `template()` option is a generic alias for `message-template()`.

## persist-name()

|   
---|---  
Synopsis: | `persist-name("<name>")`  
  
_Description:_ Sets a unique name for the parser instance, used to identify its state in the persist file across restarts. Set `persist-name()` if you have multiple `db-parser()` instances and want to ensure that state restoration works correctly after a configuration change.

## prefix()

|   
---|---  
Synopsis: | `prefix("<prefix>")`  
  
_Description:_ Inserts a prefix before the name part of the name-value pairs that the parser sets, so that downstream processing can address them uniquely. For example, with `prefix(".patterndb.")` the parsed value `username` becomes `${.patterndb.username}`.

## program-template()

|   
---|---  
Synopsis: | `program-template("<template>")`  
Default: | `${PROGRAM}`  
  
_Description:_ The template that AxoSyslog evaluates to select which pattern database ruleset to apply. By default, the application name from the `${PROGRAM}` macro is used. Set this option if the program name is stored in a different macro or needs to be constructed from other fields.

Available in AxoSyslog version 3.21 and later.

## template()

|   
---|---  
Synopsis: | `template("<template>")`  
Default: | `${MESSAGE}`  
  
_Description:_ The generic parser-level alias for `message-template()`. The template or macro that AxoSyslog evaluates and uses as input for pattern matching. If both `template()` and `message-template()` are set, the last value wins.

Last modified August 6, 2026: [Sync db-parser with source code (56c4ca71)](<https://github.com/axoflow/axosyslog-core-docs/commit/56c4ca71a8645c309b48d25d3ef6c5d3d5af77f5>)