Syslogd2 Filters
(Input Filters and Output Filters)
Syslogd2 filters are based on various forms of string-matching.
Syslogd2 filters are stored in external files. Each line of the file fills one of three roles:
Syslogd2 pairs each key-string character with a data-field positionally (the first key-string character uses the 1st field, the 2nd key-string character uses the 2nd field, the Nth character uses the Nth field, etc).
Filter processing (in all cases) occurs from left-to-right based on the key-string. All 'match-fields' are processed first. If any match-field cannot be satisfied by the message, the current filter-element fails and the next filter-element in the file is processed. If all match-fields of a filter-element are satisfied and no transformation-fields, throttle-fields or extraction-fields are present, processing immediately stops and some action is taken.
f^ (*(sudo(extra25(
In the example above, there are 2 key-string symbols and 3 fields. The field-delimiter is set to '('.
Any msg whose msg-string component starts with 'sudo' and whose facility matches the wildcard '*' will have its facility transformed to 'extra25'.
Note that in this example the 'f' must come before the '^' in the keystring in order to insure that the field 'extra25' refers to the facility instead of to the string 'sudo'.
The throttle key ('t') is one of two 'special' (out-of-band) keys.
This key requires a data-field to specify the interval and the comparison string as well as the optional 'h' flag that creates separate throttle instances for each remote host.
Because the throttle data-field is not considered to be a 'match-field, the use of this key requires at least one (additional) key with a match-field in order to be valid.
t^ /i2h:audit /audit /
t^ /i2h,h:audit /audit /
The example above limits the occurrance of msgs beginning with 'audit ' to one msg every 2 hours. The number of msgs that were discarded will be added to the msg sdstring as '[RepeatCount=N]'.
This key is positionally matched in the field-list as if it were a match-field, but it neither accepts nor looks for a transform-field.
The implementation of throttle will produce one throttle instance for each input-connection or output-connection on which a throttle is declared. A throttle instance is defined to have:
The 'extraction-operator' extracts a string from the free-form text of the msg-string, creating a static-data field in the sdstring. This new field will be formatted as '[name=value]' and is always inserted at the front of the sdstring. The name is taken from the string specified between the square brackets in the filter-element key-string. If a NULL string is specified, the resulting sdstring parameter will contain the value without an identifying name.
The 'extraction-operator' ('[name]') is the second of two 'special' out-of-band keys.
This 'key' is a multi-character value that requires two data-fields.
Extraction-fields do not accept or look for transformation-fields.
Because the extraction-operator data-fields are not considered to be a 'match-fields, the use of this key requires at least one (additional) key with a match-field in order to be valid.
As with the throttle operator, the extraction-operator is best located at the start of the key-string for readability purposes. This also places its two data-fields at the start of the data-field-list where it is less likely to confuse maintainers at a later date.
The extraction-operator is processed only if all match-field requirements have been met. It is processed AFTER all transformations have been accomplished so they take advantage of any transformations that are requested.
[facility][ConnFd][username]c /[/]/^/[/user: '/' host:/[Note]/[notice]/
[facility][ConnFd][username]c /[/]/^/[/user: '/' host:/[Warning]/[warn]/
[facility][ConnFd][username]c /[/]/^/[/user: '/' host:/[Error]/[error]/
With an input msg like:
2022-07-05 12:24:30 37 [Warning] Aborted connection 37 to db: 'dbd' user: 'ed' host: 'localhost' (Got an error reading communic
Adds or modifies the sdstring field of this msg to contain:
[username=ed][ConnFd=37][facility=warn]...
The three example filter-elements above are from an input-filter for the MariaDb application's default error-log files. They are complex but are valid and working filters.
The implementation of filters in Syslogd2 is divided into two components (input filters and output filters), but there is almost a 100%
overlap in the implementation of input and output filters.
This overlap is intentional.
The difference between an input filter and an output filter is not format or content, but when (during processing) the filter is applied,
whether the filter is configured by an input specification or an output specification, and the
scope of the data that is affected by each type of filter.
Input filters are executed after the message is fully parsed and the (source) hostname has been resolved, but before the search for output-destinations
is begun.
Input filters affect only the traffic that enters Syslogd2 via the input specification on which the input filter was declared.
-->The reason the scope of input-filters is connection-specific instead of global is to accomodate different input text-files with different
filter requirements as well as to recognize that each traditional input-source (kernel, IP socket or linux socket) has different requirements for filtering
traffic.
Trying to force a one-size-fits-all approach to any data-management problem is almost always a non-starter.
--> Syslogd2 still routes messages to files and other destinations on the basis of facilities and priorities, but in Syslogd2 input-filters
may be used to modify the message faciltiy and/or priority upon which that routing is based.
-->The implementation of extra facilities in Syslogd2 is intended specifically to
provide clean facilities to 'move' messages into as they are identified and re-routed by input filters.
Output filters are executed after a facility+priority match has been found against a selector-string component. Each output-filter will only affect the data from the selector-string component(s) specified on the output-line on which the filter was declared.
-->Output filters were originally intended to 'reduce' the traffic being transmitted over network links. However, they have recently found a
secondary role: supplementing message content by adding one or more parameters to the message's 'sdstring' field.
-->Because each output-filter is unique to a specific output-line destination and selector-string-component, and because of its 'location' in the
message-processing stream (almost the last step), it is (and was always intended to be) ideally suited to act as the 'front-line' for congestion-prevention of network-links.
-->Whatever changes to a message or its attributes may be made by an output-filter, only the one selector-string-component is affected.
Each application of an output-filter always starts with a clean copy of the original message - to prevent unexpected data-contamination between locations
due to filter modificaitons.
Syslogd2 implements each (input or output) filter as a separate file (usually stored in ConfigDir). This is done
for several reasons:
For the most part, Syslogd2 filters are based on string-matching and string-replacement or on manipulation of the facility and/or priority integers.
In Syslogd2 the term 'filter' refers to either an entire file (containing zero or more filter-elements) or to the concept or effect of the filter depending on context.
--> Each line of a filter (file) is referred to as a 'filter-element'
Each filter maintains a 'sense' during parsing. The 'sense' of a filter can be either 'default pass' or 'default discard'.
The 'sense' of a filter specifies what happens to the message when no filter-elements are matched.
Each filter execution starts with a sense of 'default pass'.
Each filter file contains 3 types (too often 4 types) of lines:
To change the 'sense' of a filter, enter either 'dd' to set the 'default discard' sense or 'dp' to set 'default pass' on a line by itself. The sense of a filter (-file) may be changed as many times as desired during the processing of a filter.
A filter-element consists of a key-string followed by one or more delimited fields on the same line.
-->Each filter-element must fit on one line.
-->The field-delimiter is re-calculated for each filter-element-line of each filter.
-->The field-delimiter for a filter-element-line is the first non-whitespace character following
the key-string.
The field-delimiter chosen for a filter-element-line must not be found within any delimited field on that line.
The filter-element-keystring is a string comprised of (possibly repeated) filter-key-characters followed by whitespace.
The current list of filter-key-characters and their meanings is:
Following the filter-element-keystring is a list of delimited fields. There must be at least as many delimited fields as there are characters in the keystring. 3 scenarios are possible:
-->There are fewer delimited fields than keystring characters: This is an error and the filter-element will be rejected during the filter-parse
process - either at startup or during a dynamic 'filter-update'.
-->There are exactly as many delimited fields as there are keystring characters: This is a 'match' element. If all tests are passed, the filter
immediately returns an action that is the opposite of the CURRENT 'sense' of the filter ('discard' for 'default pass' or 'pass' for 'default discard').
-->There are more delimited fields than keystring characters: This is a 'transformation' element.
The key-string parsing will be restarted and the remaining fields will be considered to be 'replacement' values for those that were tested for the 'match'.
Transformation fields are matched against key-string-characters left-to-right until the end of the field-list.
Filter-processing is terminated immediately after all transformation fields have been processed.
All matching transformation elements result in an action of 'pass'.
if a filter-element fails to match the message, Syslogd2 tests the next filter-element in the file until end-of-file is reached.
If no filter-element matches the message, the filter returns the value of the final 'sense' of the filter (pass or discard).
If a filter returns 'discard', Syslogd2 immediately dicards that message (or if an output-filter, that copy of the message).
After a message has been shown to 'match' a specific filter-element (for all keystring characters in a filter-element), if there are any
delimited fields left over, the keystring will be 're-wound' and transformation processing will start from left-to-right until the
'transformation-fields' are exhausted.
NOTE: The implied requirement that all filter-fields that will be modified be grouped at the start of the keystring is the only restriction to the number,
repeat-count or order of keystring elements (provided that the one-to-one (positional) relationship between key-string characters and delimited-fields is
otherwise maintained).
For each string-match, the contents of the 'transformation-field' will replace the contents of the 'match-field' in the message-string or host-name field.
It is possible to add text to the beginning or end of a message (perhaps to add a missing 'tag' field) by specifying an empty match-field and a non-empty
transformation-field as the example below shows.
In this example, the system looks for any message that matches a null-string at the front (which all messages do) (the '^' test)
and that does not contain the string 'kernel: ' (the 'n' test). Upon finding that a message meets these conditions, the empty-field at the front of the message is replaced
with the string 'kernel: ', effecting pre-pending this tag field onto the message. Once this has been done, the filter processing is complete and the newly-modified message
passed on for further processing.
^n //kernel: /kernel: /
For facilities and priority values, the asterisk may be used as a match-string wild-card, but the transform field must be a single value. Both match and transform fields may be expressed in either numeric or string form. (String form is by far easier). Here is a sample input-filter that I use on my laptop to sort message traffic by 'tag field'. The hard part in setting this up was remembering which facilities contained which application data when creating the output-lines to write the log files. This filter is assigned to my (customized) input-specification for the default Linux input socket.
# to wireless.log
f^ /*/wpa_supplicant[/extra14/
f^ /*/NetworkManager[/extra14/
# f^ /*/wlp2s0: /extra14/
#to gnome-shell.log
f^ /*/gnome-shell[/extra1/
#to whoopsie.log
f^ /*/whoopsie[/extra2/
#to dbus-daemon.log
f^ /*/systemd[/extra3/
f^ /*/dbus-daemon[/extra3/
#to brave.log
f^ /*/brave/extra11/
#to named.log
f^ /*/named[/extra15/
# to dhcpd.log
f^ /*/avahi-daemon[/extra13/
f^ /*/dhcpd[/extra13/
f^c /*/sh[/dhcpd/extra13/
# to shellcmds.log
f^n /*/sh[/dhcpd/extra12/
# to udisk.log
f^ /*/udisk/extra16/
It should be noted that the above filter does not duplicate any portion of any message stream.
It merely 'diverts' selected messages from their originally-specified 'destination' to new destinations.
Many of these diversions will be out of the 'daemon' facility, but there may also be isolated instances of diversions from the 'user' or other facilities as well.
On the 'plus' side, sending any of these 'sub-streams' to a remote host (preferably after passing through a 'traffic-reduction' output-filter) will result in a more accurate,
easier-to-understand datastream being received.
The SD-String is intended to
allow syslog-based systems to manipulate fixed-field data elements in
addition to free-form text -- especially in the context of
syslog-based network-management.
When using SD-Strings, you should also consider using CAP_VARBUFFERS and
LossLess queueing
The '+' keystring character in Syslogd2
filters is used to manipulate the SD-String. The exact type of
manipulation is defined by the format and content of the datafields
as outlined in the following table.
|
When the Field-Delimiter is '/' and the Match Field Contains: |
Transform Field is Missing |
Transform Field is Empty |
Transform Field is Non-Empty |
|---|---|---|---|
|
<empty match field> // |
This situation makes no real sense but is implemented as an automatic-match (a No-Op) |
All sd-fields for this message will be removed. |
A new field is added at the beginning of the current list containing the contents of the transform-field. |
|
/^/ |
Auto-Match (a No-Op) |
The first field (if any) is deleted. |
A new field is added at the beginning of the current list containing the contents of the transform-field. |
|
/^<text>/ |
The string <text> must exist at the start of any field or the match fails for the given filter-line. This search is case-sensitive. |
The sub-string '<text>' if found at the start of any field, is deleted - leaving the remainder of the field (if any). |
The sub-string '<text>' (if found at the start of any
field) is replaced with the contents of the transform-field. |
|
/$/ |
Auto-match (a No-Op) |
The last field (if any) is deleted. |
A new field is added to the end of the list containing the contents of the transform-field. |
|
/$<text>/ |
The string <text> must occur at the end of any field or the match fails for the given filter-line. This search is case-sensitive. |
The sub-string '<text>' if found at the end of any field, is deleted - leaving the remainder of the field (if any). |
The sub-string '<text>' (if found at the end of any
field) is replaced with the contents of the transform-field. |
|
/<text>/ |
All fields are searched for the 1st field containing the string '<text>'. The first field that matches will be the one that is acted upon. This search is case-sensitive. |
The sub-string '<text>' is deleted - leaving the remainder of the field (if any). |
The sub-string '<text>'
is replaced with the contents of the transform-field. |
|
/<n>/, where <n> is numeric |
If the 'nth' field does not exist in the list, the match fails for the given filter-line. (Counting starts at '1' (one).) |
The <n>th field is deleted. |
The <n>th field is replaced with the contents of the transform-field. |
|
/<n><text>/ |
If the 'nth' field does not contain '<text>' as a case-sensitive sub-string of the field, the match fails for the given filter-line. |
The sub-string '<text>' (if found in the <n>th field) is removed. |
The sub-string '<text>' (if found in the <n>th field) is replaced with the contents of the transform-field. |
In addition to creating and deleting SD fields (components of the SD-String), Syslogd2 provides several variables that can be used to set values into SD Fields. I would like to stress that the following are just a 'first-cut' 'swing' at what may be useful. I hope for feedback over time to be able to improve the overall usefulness of the '+' keystring filter identifier in Syslogd2.
Within the 'transform' fields of a '+' keyString symbol, the following special character sequences are recognized (all characters follow either a leading '%' or '#' escape-character):
The '%' escape-character is used to display string values. Use '#' to display numeric values.
'%' : Displays a '%' (percent-sign). ('%%' or '#%' -> '%')
'#' : Displays a '#' (hashtag). ('%#' or '##' -> '#')
Lowercase 'f' : (active facility) Like the 'f' option in the key-string, this designates the current (active routing) facility. 'Current' is defined as: 'The facility in effect as of when the filter is applied').
Use '#f' for a numeric result, '%f' for a string.
Uppercase 'F' : (original facility) Like the 'f' option in the key-string, but containing the original (unmodified) facility taken from the incoming message or (if the msg contained no incoming facility) the global system-default value (as defined by compiled-in or user-default settings. This value may differ from the 'f' value if input options ('facility' or 'ignore=facility') have modified the 'working facility' value.
Use '#F' for a numeric result, '%F' for a string.
Wildcards and substitutions apply to this value as for the 'f' option above.
Lowercase 'p' : (active priority) Like the 'p' option in the key-string, this designates the current (active routing) priority. 'Current' uses the same definition as for the 'f' option.).
Use '#p' for a numeric result, '%p' for a string.
Uppercase 'P' : (original priority) like the 'F' option above, but for the original (incoming, pre-modified) priority value.
Use '#P' for a numeric result, '%P' for a string.
Lowercase 'c' : (combined (active) facility+priority value)
Use '#c' for a numeric result, '%c' for a string.
Numeric value is expressed as a single decimal value, this is calculated as [(facility * 8) + priority]. Example: '13' for 'user.notice' ((1 * 8) + 5).
String value is expressed as 'user.notice'.
Uppercase 'C' : (combined (original) facility+priority value)
Use '#C' for a numeric result, '%C' for a string.
Numeric value is expressed as a single decimal value, this is calculated as [(facility * 8) + priority]. Example: '13' for 'user.notice' ((1 * 8) + 5).
String value is expressed as 'user.notice'.
't' : The time-field of the message.
Use '#t' to express as an integer in the UTC time-zone.
Use '%t' to express in string format as “yyyy-mm-ddTHH:MM:SSZ”.
The throttle operator provides a means to throttle incoming events.
Many syslog events are reported for every instance of an occurance.
This means that events like disk errors, kernel audit msgs or network-interface errors (especially
'switch-port flapping' events) will be reported potentially hundreds of times per hour PER HOST).
The throttle operator allows Syslogd2 to suppress (discard) most of these msgs, allowing 1 message
to be delivered per time-period with a counter ('RepeatCount=<N>) indicatng the number of messages
that were discarded.
Once per time-period, Syslogd2 will 'accept' a throttled message and will insert a field into the
SD-String field that looks like [RepeatCount=<N>].
The throttle operator ('t') (like the data-extraction operator below) is an out-of-band operator.
This means it is not counted when counting fields for match->transform alignment.
Nor is it processed until after all other match-criteria have been found to 'match'.
The throttle operator does not support a transform field definition.
It is not considered to be a 'match' during operation, because it is only processed after all (other) defined
match-criteria have succeeded.
The field contents for the throttle ('t') key consists of a comma-separated list of options followed by a
colong then a string (the 'throttle-string') containing the text to be stored as a template. Whenever an incoming msg
matches all match criteria and contains the throttle-string, the message will be throttled.
This design allows additional selection criteria to be used to select which hosts or which (of similar msg texts) will
be selected for throttling.
Throttles may be defined globally (a singled global throttle-count across all hosts) or on a per-host basis
(individual throttle counts (and reports) for each host).
The options for the throttle-operator data-field are:
Format:
t /i<timestirng>[,h]:<throttle-string>/
Examples:
t^h /i4h,h:audit: /audit: /-desktop/
tcf /i1d:exe=/exe=/kern/
The 'Extraction-Operator' allows for the extraction of arbitrary data strings from the free-form
'msg-string' component of a message and the creation of a new sdstring field containing that data.
These 'extracted' fields can then be used by follow-on programs such as DBD2 as if they were any
other name=value pair contained in the sdstring field.
The 'Extraction-Operator' is a compound operator (a compound key-string element) comprised of thee
elements: '[', <name-for-the-extracted-value>, and a closing ']'.
All elements of the extraction operator are found in the key-string and the set of 'match' fields.
There is no 'transform' component for the 'extraction-operator'.
However, like the 'transform' operators, if the message is modified by an extraction
(whether or not a transform is involved, the message is kept - even though the basic 'match' criteria
might otherwise indicate it should be discarded.
When parsing filters, Syslogd2 does not consider the extraction-operator elements or associated
fields to be part of the actual key-string or data-fields (even though the '[' and ']' elements
are still positionally related to their associated 'match' strings).
Effectively, each extraction-operator appears as '[text]' in the keystring and requires two 'match-fields'
for supporting text, but because the execution is AFTER all match and transform operations, the normal
left-to-right order of transformation executions is unaffected.
This means that the extraction fields can appear anywhere in the key-string/match-field-list as long as at
least one match criteria is specified to select a set of messages to 'work' on. (I recommend placing all
extraction operators at the end of the keystring and match-lists.)
When executing an extraction, all match and transform operations are done before any
extraction efforts are attempted.
All white-space is trimmed from both beginning and end of the data after extraction.
Extractions are attempted left-to-right and each field is inserted at the beginning of any pre-exising
sdstring.
c[FullName] /My name is/name is/$/
The line above results in selecting all messages containing the string "My name is", then
extracting the characters following 'name is' 'to end-of-msg'. this data is then used to
create a new field [FullName=....].
Upon receipt of a syslog event "<12>My name is Ed Freesmeyer", the above filter line would produce:
<12>Sep 3 16:31:15 ubuntudesktop.localdomain [FullName=Ed Freesmeyer] My name is Ed Freesmeyer
Multiple extractions can be specified on the same line, but care must be taken to insure that each extraction is surrounded by non-volatile (boiler-plat) text since there is no way to specify non-changing, non-white-space text "anchors" in the middle of volatile text.
After compiling Syslogd2, this tool will be found in the './tools' directory.
Run the 'testFilter' tool without parameters to get usage instructions.
This tool is specifically designed to emulate the results of Syslogd2's handling of messages
given various (selected) input options and all filter modifications. In addition, testFilter
will parse the designated filter-file each time it is run and will display any parsing errors it detects
to the user. Additionally, testFilter can display the content of each filter, showing the
field-alignments, extractions and transformations specified by the user.
testFilter uses the exact same code to parse and execute filters as does Syslogd2 itself.
When run without a 'configfile' specification, testFilter shows the result of applying the
specified filter-file to each message read from the inputFile assuming no other factors are
involved.
testFilter is (intentionally) limited in that it displays the message transformations of
each message in the input file after applying only the single designated filter-file each time it
is run.
Though Syslogd2 can apply up to two filters + input options to any given message,
testFilter's aim is to provide clarity and simplicity.
In reality, various default values may have been modified in the Syslogd2 configuration that
are not strictly part of the filter operation.
Various input options may also affect the message the filter 'starts with' (and therefore the results
of filter application). The configfile option provides a method to emulate these settings.
The configFile is an extremely limited subset of the Syslogd2 configuration file that
supports only a (massively reduced) --defaults line and an --input specification that
retains the general format of the Syslogd2 input lines (--kernel, --tailfile,
--input, --journal, etc).
TestFilter actually parses and implements only a few of the (generic) input options -- those
that could interact with Syslogd2 filters and cause confusion and those that implement any
special processing required by the input data.
If a 'filter' option is not present in the '--input' command option-list, no filter will be applied.
If a 'filter' option is specified it will over-ride any '--filter' option provided on the command-line.
A testFilter.conf sample file is provided as a starting point
for writing your own testFilter configuration files.
Here is a sample output of 'testFilter' run against a simple filter with no config-file specificaton:
Host: ubuntudesktop.localdomain ConfigDir: '/etc/syslog.d' KernelFacility: kern.notice <5> UserFacility: user.notice <13> Filter filename: '/opt2/build/syslog/tools/test.filter', Input filename: '/opt2/build/syslog/tools/test.input' --------------------------------------------------------------------------------------------------------------------------------------- Raw Input: '<12>My name is Ed Freesmeyer' ------------------------------------------------------------------- Original facility/priority (OldFacPri): 12 (user.warn), Current Facility: 12 (user.warn) Processed (Pre-Filter) Input: '<12>Sep 3 18:59:29 ubuntudesktop.localdomain My name is Ed Freesmeyer' ------------------------------------------------------------------- Filter-Execution Errors: Output facpri: 12 (user.warn): '<12>Sep 3 18:59:29 ubuntudesktop.localdomain [FullName=Ed Freesmeyer] My name is Ed Freesmeyer' ---------------------------------------------------------------------------------------------------------------------------------------
Compare the above output to that below where a configuration file is set with various options. Specifically note the differences in the 'output' line due to the additional '--input' options set outside of the filter's operation. For those interested, the 'configfile' being used contains:
defaults hostname = let, domainname=freedom.ring input = /tmp/junker.socket, port=abc, hostname=sallyhost, facility = extra14, filter=/opt2/build/syslog/tools/test.filter, \ ignore=facility, noforceprintable # , noheader, nohost
Note that the 'noheader' and 'nohost' options have been commented out. Also note that the "Processed (Pre-Filter) Input" line below changes due to the input options. This line of output displays what an input filter would 'see' as it begins execution:
Host: let.freedom.ring ConfigDir: '/etc/syslog.d' KernelFacility: kern.notice <5> UserFacility: user.notice <13> Filter filename: '/opt2/build/syslog/tools/test.filter', Input filename: '/opt2/build/syslog/tools/test.input' --------------------------------------------------------------------------------------------------------------------------------------- Raw Input: '<12>My name is Ed Freesmeyer' ------------------------------------------------------------------- Original facility/priority (OldFacPri): 12 (user.warn), Current Facility: 308 (extra14.warn) Processed (Pre-Filter) Input: '<308>Sep 3 19:11:12 sallyhost My name is Ed Freesmeyer' ------------------------------------------------------------------- Filter-Execution Errors: Output facpri: 308 (extra14.warn): '<308>Sep 3 19:11:12 sallyhost [FullName=Ed Freesmeyer] My name is Ed Freesmeyer' ---------------------------------------------------------------------------------------------------------------------------------------
The two examples above illustrate (in a small way) how filters and input options interact to control the
flow and content of syslog traffic through the Syslogd2 processing steps.
(Bear in mind that just before releasing data to an output destination, Syslogd2 will run another
filter (an 'output filter') that acts in the exact same way as an input filter except that any message
modifications made by the output filter are made to copies of the content so the same original
(pre-output-filter) message may be used with multiple filters without the original being modified.
When testFilter is called with the '-d' option, an output similar to the one below is
generated where each line of the filter-file is displayed in its own 'section'. (Remember that
an extraction is considered to be a form of 'transformation', so the first section line below
(containing a match and transformation) will be kept, over-riding the 2nd line (that is never
processed) that is a 'match-only'.
--------------------------------------------------------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------------------------------------------------------- Filter filename: '/opt2/build/syslog/tools/test.filter' Number of active filter lines: 2 ------------------------------------------------------------------------------------------- This line is a 'match' line. (matching lines will be accepted) Original String: 'c[FullName] /My name is Ed Freesmeyer/name is/$/', Key String: 'c' (Key-String Length: 1) key match value --> transform value --- ----------- --> --------------- c 'My name is Ed Freesmeyer' Extraction fields: 'before' string --> field name --> 'after' string '-------------- --> ---------- --> '------------- 'name is' --> 'FullName' --> '$' ------------------------------------------------------------------------------------------- This line is a 'match' line. (matching lines will be discarded) Original String: 'c /name is/', Key String: 'c' (Key-String Length: 1) key match value --> transform value --- ----------- --> --------------- c 'name is'[Top of page]