Highlighted field keywords #71 (#74)

Fixes: #71 

Added backtick highlight to field names which have macro counterpart.

Author: HofiOne

_includes/doc/admin-guide/examples/anon-ip.md

@@ -1,6 +1,6 @@
 ### Example: Anonymizing IP addresses
 
-The following example replaces every IPv4 address in the MESSAGE part
+The following example replaces every IPv4 address in the `MESSAGE` part
 with its SHA-1 hash:
 
 ```config

_includes/doc/admin-guide/options/flags.md

@@ -9,8 +9,9 @@
 * `expect-hostname`: When this flag is used syslog-ng OSE expects a log message that contains a hostname and parses the message accordingly. This is the default behavior for TCP sources. Note that pipe sources use the `no-hostname` flag by default.
 * `guess-timezone`: This flag allows the source to attempt to guess the timezone of the message if this information is not available in the message. Works when the incoming message stream is close to real time, and the timezone information is missing from the timestamp.
 * `kernel`: This flag sets the source default to the `LOG_KERN | LOG_NOTICE` priority if not specified otherwise.
-* `no-header`: This flag triggers syslog-ng OSE to parse only the PRI field of incoming messages, and put the rest of the message contents into `$MSG`.
-The functionality of `no-header` is similar to the `no-parse` flag, but the `no-header` flag does not skip the `PRI` field. The `no-header` flag signals syslog-ng OSE that the syslog header is not present (or does not adhere to the conventions / RFCs), so the entire message (except from the PRI field) is put into `$MSG`.
+* `no-header`: This flag triggers syslog-ng OSE to parse only the `PRI` field of incoming messages, and put the rest of the message contents into `MSG`.
+The functionality of `no-header` is similar to the `no-parse` flag, but the `no-header` flag does not skip the `PRI` field. The `no-header` flag signals syslog-ng OSE that the syslog header is not present (or does not adhere to the conventions / RFCs), so the entire message (except from the `PRI` field) is put into `MSG`.
+
 ```config
     parser p_syslog {
       syslog-parser(
@@ -19,7 +20,7 @@ The functionality of `no-header` is similar to the `no-parse` flag, but the `no-
     };
 ```
 
-* `no-hostname`: Enable this flag if the log message does not include the hostname of the sender host. This results in syslog-ng OSE assuming that the first part of the message header is `${PROGRAM}` instead of `${HOST}`.
+* `no-hostname`: Enable this flag if the log message does not include the hostname of the sender host. This results in syslog-ng OSE assuming that the first part of the message header is `PROGRAM` instead of `HOST`.
 ```config
     source s_dell {
         network(
@@ -30,7 +31,7 @@ The functionality of `no-header` is similar to the `no-parse` flag, but the `no-
 ```
 
 * `no-multi-line`: This flag disables line-breaking in the messages and converts the entire message into a single line. Note that this happens only if the underlying transport method supports multi-line messages. Currently only the `file()` and `pipe()` drivers support multi-line messages.
-* `no-parse`: By default, syslog-ng OSE parses incoming messages as syslog messages. The `no-parse` flag disables syslog message parsing and processes the complete line as the message part of a syslog message. The syslog-ng OSE application generates a new syslog header (timestamp, host, and so on) automatically and puts the entire incoming message into the `MESSAGE` part of the syslog message (available using the `${MESSAGE}` macro). This flag is useful for parsing messages that do not complying to the syslog format.
+* `no-parse`: By default, syslog-ng OSE parses incoming messages as syslog messages. The `no-parse` flag disables syslog message parsing and processes the complete line as the message part of a syslog message. The syslog-ng OSE application generates a new syslog header (timestamp, host, and so on) automatically and puts the entire incoming message into the `MESSAGE` part of the syslog message (available using the ${MESSAGE} macro). This flag is useful for parsing messages that do not complying to the syslog format.
 * `dont-store-legacy-msghdr`: During default operation, syslog-ng OSE stores the original incoming header of the log message. This is useful if the original format of a non-syslog-compliant message must be retained. The syslog-ng OSE application automatically corrects minor header errors, for example, it adds a whitespace before "msg" in the following message: `Jan 22 10:06:11 host program:msg`. If storage of the original header of the message is not needed, enable the `dont-store-legacy-msghdr` flag.
 * `sanitize-utf8`: When this flag is used, syslog-ng OSE converts non-UTF-8 input to an escaped format, adhering to UTF-8.
 Prior to version 4.6, this only worked with parsing RFC3164 messages. In syslog-ng OSE 4.6 and later versions, RFC5424 and raw messages can also be parsed using this flag.

_includes/doc/admin-guide/options/host-override.md

@@ -3,5 +3,5 @@
 |  Type: |     string|
 | Default: ||
 
-*Description:* Replaces the HOST part of the message with the
+*Description:* Replaces the `HOST` part of the message with the
 parameter string.

_includes/doc/admin-guide/options/keep-hostname.md

@@ -6,18 +6,18 @@
 *Description:* Enable or disable hostname rewriting.
 
 - If enabled (**keep-hostname(yes)**), {{ site.product.short_name }} assumes that the
-    incoming log message was sent by the host specified in the HOST
+    incoming log message was sent by the host specified in the `HOST`
     field of the message.
 
-- If disabled (**keep-hostname(no)**), {{ site.product.short_name }} rewrites the HOST
+- If disabled (**keep-hostname(no)**), {{ site.product.short_name }} rewrites the `HOST`
     field of the message, either to the IP address (if the use-dns()
     parameter is set to **no**), or to the hostname (if the use-dns()
     parameter is set to **yes** and the IP address can be resolved to a
     hostname) of the host sending the message to {{ site.product.short_name }}. For
     details on using name resolution in {{ site.product.short_name }}, see
     Using name resolution in syslog-ng.
 
-**NOTE:** If the log message does not contain a hostname in its HOST field,
+**NOTE:** If the log message does not contain a hostname in its `HOST` field,
 {{ site.product.short_name }} automatically adds a hostname to the message.
 {: .notice--info}
 

_includes/doc/admin-guide/options/prefix.md

@@ -12,7 +12,7 @@ name-value pairs to help further processing. For example:
     the name of the macro, for example, **${my-parsed-data.name}**.
 
 - If you forward the parsed messages using the IETF-syslog protocol,
-    you can insert all the parsed data into the SDATA part of the
+    you can insert all the parsed data into the `SDATA` part of the
     message using the **prefix(.SDATA.my-parsed-data.)** option.
 
 Names starting with a dot (for example, .example) are reserved for use

_includes/doc/admin-guide/options/source-flags.md

@@ -28,15 +28,15 @@
     | LOG_NOTICE priority if not specified otherwise.
 
 - *no-header*: The no-header flag triggers {{ site.product.short_name }} to parse only
-    the PRI field of incoming messages, and put the rest of the message
+    the `PRI` field of incoming messages, and put the rest of the message
     contents into ${MSG}.
 
     Its functionality is similar to that of the no-parse flag, except
-    the no-header flag does not skip the PRI field.
+    the no-header flag does not skip the `PRI` field.
 
     **NOTE:** Essentially, the no-header flag signals {{ site.product.short_name }} that the
     syslog header is not present (or does not adhere to the conventions
-    / RFCs), so the entire message (except from the PRI field) is put
+    / RFCs), so the entire message (except from the `PRI` field) is put
     into ${MSG}.
     {: .notice--info}
 
@@ -55,8 +55,8 @@
 
 - *no-hostname*: Enable the no-hostname flag if the log message does
     not include the hostname of the sender host. That way {{ site.product.short_name }}
-    assumes that the first part of the message header is PROGRAM
-    instead of HOST. For example:
+    assumes that the first part of the message header is `PROGRAM`
+    instead of `HOST`. For example:
 
     ```config
     source s_dell {
@@ -78,7 +78,7 @@
     message parsing and processes the complete line as the message part
     of a syslog message. The {{ site.product.short_name }} application will generate a
     new syslog header (timestamp, host, and so on) automatically and put
-    the entire incoming message into the MESSAGE part of the syslog
+    the entire incoming message into the `MESSAGE` part of the syslog
     message (available using the ${MESSAGE} macro). This flag is useful
     for parsing messages not complying to the syslog format.
 

_includes/doc/admin-guide/options/value-pairs.md

@@ -12,8 +12,8 @@ formatted to JSON format, or directly used in a mongodb() destination.
 
 The following example selects every available information about the log
 message, except for the date-related macros (R\_\* and S\_\*), selects
-the .SDATA.meta.sequenceId macro, and defines a new value-pair called
-MSGHDR that contains the program name and PID of the application that
+the ${.SDATA.meta.sequenceId} macro, and defines a new value-pair called
+`MSGHDR` that contains the program name and `PID` of the application that
 sent the log message.
 
 ```config
@@ -55,7 +55,7 @@ are evaluated in the following order:
 
 *Description:* This option removes the specified macros from the selection. Use it to remove unneeded macros selected using the scope() parameter.  
 
-For example, the following example removes the SDATA macros from the selection.
+For example, the following example removes the `SDATA` macros from the selection.
 
 ```config
 value-pairs(
@@ -200,7 +200,7 @@ The rekey() option can be used with the format-json template-function as well, u
 
 - *rfc5424*: The macros that correspond to the RFC-5424 (IETF-syslog) message format: ${FACILITY}, ${PRIORITY}, ${HOST}, ${PROGRAM}, ${PID}, ${MESSAGE},   ${MSGID}, ${R_DATE}, and the metadata from the structured-data (SDATA) part of RFC-5424 formatted messages, that is, every macro that starts with .SDATA..
 
-  The rfc5424 group also has the following alias: syslog-proto. Note that the value of ${R_DATE} will be listed under the DATE key. The rfc5424 group does not contain any metadata about the message, only information that was present in the original message. To include the most commonly used metadata (for example, the ${SOURCEIP} macro), use the selected-macros group instead.
+  The rfc5424 group also has the following alias: syslog-proto. Note that the value of ${R_DATE} will be listed under the `DATE` key. The rfc5424 group does not contain any metadata about the message, only information that was present in the original message. To include the most commonly used metadata (for example, the ${SOURCEIP} macro), use the selected-macros group instead.
 
 - *all-macros*: Include every hard macro. This group is mainly useful for debugging, as it contains redundant information (for example, the date-related macros include the date-related information several times in various formats).
 

doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/000_BSD_syslog_messages.md

@@ -34,10 +34,10 @@ size when using UDP destinations.
 
 ## The PRI message part
 
-This section describes the PRI message part of a syslog message, according to the
+This section describes the `PRI` message part of a syslog message, according to the
 legacy syslog (BSD-syslog) protocol.
 
-The PRI part of the syslog message (known as Priority value) represents
+The `PRI` part of the syslog message (known as Priority value) represents
 the Facility and Severity of the message. Facility represents the part
 of the system sending the message, while Severity marks its importance.
 
@@ -57,7 +57,7 @@ PRI field (that is, Priority value):
 
 >\<133\> Feb 25 14:09:07 webserver syslogd: restart
 
-In this example, \<133\> represents the PRI field (Priority value). The
+In this example, \<133\> represents the `PRI` field (Priority value). The
 syslog message\'s Facility value is 16, and the Severity value is 5.
 
 Substituting the numerical values into the \<PRI\> = ( \<facility\> \*
@@ -96,9 +96,9 @@ format. For details, see the ts-format() option in Global options.
 
 ## The MSG message part
 
-This section describes the MSG message part of a syslog message, according to
+This section describes the `MSG` message part of a syslog message, according to
 the legacy syslog (BSD-syslog) protocol.
 
-The MSG part contains the name of the program or process that generated
-the message, and the text of the message itself. The MSG part is usually
+The `MSG` part contains the name of the program or process that generated
+the message, and the text of the message itself. The `MSG` part is usually
 in the following format: *program\[pid\]: message text*.

doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/001_IETF_syslog_messages.md

@@ -20,7 +20,7 @@ The message corresponds to the following format:
 
 >\<priority\>VERSION ISOTIMESTAMP HOSTNAME APPLICATION PID MESSAGEID STRUCTURED-DATA MSG
 
-- Facility is 4, severity is 2, so PRI is 34.
+- Facility is 4, severity is 2, so `PRI` is 34.
 
 - The VERSION is 1.
 
@@ -32,9 +32,9 @@ The message corresponds to the following format:
 
 - The APP-NAME is \"su\" and the PROCID is unknown.
 
-- The MSGID is \"ID47\".
+- The `MSGID` is \"ID47\".
 
-- The MSG is \"\'su root\' failed for lonvick\...\", encoded in UTF-8.
+- The `MSG` is \"\'su root\' failed for lonvick\...\", encoded in UTF-8.
 
 - In this example, the encoding is defined by the BOM:
 
@@ -44,14 +44,14 @@ The message corresponds to the following format:
 - There is no STRUCTURED-DATA present in the message, this is
     indicated by \"-\" in the STRUCTURED-DATA field.
 
-The HEADER part of the message must be in plain ASCII format, the
+The `HEADER` part of the message must be in plain ASCII format, the
 parameter values of the STRUCTURED-DATA part must be in UTF-8, while the
 MSG part should be in UTF-8. The different parts of the message are
 explained in the following sections.
 
 ## The PRI message part
 
-The PRI part of the syslog message (known as Priority value) represents
+The `PRI` part of the syslog message (known as Priority value) represents
 the Facility and Severity of the message. Facility represents the part
 of the system sending the message, while severity marks its importance.
 The Priority value is calculated by first multiplying the Facility
@@ -61,7 +61,7 @@ number by 8 and then adding the numerical value of the Severity.
 
 ## The HEADER message part
 
-The HEADER part contains the following elements:
+The `HEADER` part contains the following elements:
 
 - *VERSION*: Version number of the syslog protocol standard. Currently
     this can only be 1.
@@ -117,7 +117,7 @@ An example STRUCTURED-DATA block looks like:
 
 ## The MSG message part
 
-The MSG part contains the text of the message itself. The encoding of
+The `MSG` part contains the text of the message itself. The encoding of
 the text must be UTF-8 if the BOM1 character is present in the message.
 If the message does not contain the BOM character, the encoding is
 treated as unknown. Usually messages arriving from legacy sources do not

doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/002_EWMM_messages.md

@@ -29,9 +29,9 @@ The message has the following parts:
 
 - The header of the complies with the
     IETF-syslog messages RFC-5424 message format,
-    where the PROGRAM field is set to @syslog-ng, and the SDATA field is empty.
+    where the `PROGRAM` field is set to @syslog-ng, and the `SDATA` field is empty.
 
-- The MESSAGE part is in JSON format, and contains the actual message,
+- The `MESSAGE` part is in JSON format, and contains the actual message,
     as well as any name-value pairs that {{ site.product.short_name }} has attached to
     or extracted from the message. The ${.\_TAGS} field contains the
     identifier of the {{ site.product.short_name }} source that has originally received the

doc/_admin-guide/020_The_concepts_of_syslog-ng/008_Message_representation.md

@@ -66,7 +66,7 @@ rules or other means.
 Soft macros (sometimes also called name-value pairs) are either
 built-in macros automatically generated from the log message (for
 example, ${HOST}), or custom user-created macros generated by using
-the {{ site.product.short_name }} pattern database or a CSV-parser. The SDATA fields of
+the {{ site.product.short_name }} pattern database or a CSV-parser. The `SDATA` fields of
 RFC-5424 formatted log messages become soft macros as well. In
 contrast with hard macros, soft macros are writable and can be
 modified within {{ site.product.short_name }}, for example, using rewrite rules.

doc/_admin-guide/020_The_concepts_of_syslog-ng/009_Structuring_macros/000_Specifying_data_types.md

@@ -33,8 +33,8 @@ function supports data types.
 
 ## Example: Using type-hinting
 
-The following example stores the MESSAGE, PID, DATE, and PROGRAM fields
-of a log message in a MongoDB database. The DATE and PID parts are
+The following example stores the `MESSAGE`, `PID`, `DATE`, and `PROGRAM` fields
+of a log message in a MongoDB database. The `DATE` and `PID` parts are
 stored as numbers instead of strings.  
 
 ```config
@@ -52,7 +52,7 @@ Use the following example to format the same fields into JSON.
 
 `$(format-json date=datetime("${UNIXTIME}") pid=int64("${PID}") program="${PROGRAM}" message="${MESSAGE}")`
 
-Use the following example to format the MESSAGE field as a JSON list.
+Use the following example to format the `MESSAGE` field as a JSON list.
 
 `$$(format-json message=list(${MESSAGE}))`
 
@@ -118,7 +118,7 @@ The type of the field can be set. Type-casting can be executed using
 the set() and groupset() template functions, to properly promote the
 type information.
 
-For more information, see Creating custom SDATA fields and
+For more information, see Creating custom `SDATA` fields and
 Setting multiple message fields to specific values.  
 
 ### db-parser()

doc/_admin-guide/040_Quick-start_guide/002_Configuring_syslog-ng_relays/001_How_relaying_works.md

@@ -16,20 +16,20 @@ Depending on the settings of syslog-ng-relay, the following can happen.
 
 - By default, the keep-hostname() option is disabled, so
     syslog-ng-relay writes the IP address of the sender host (in this
-    case, 192.168.1.2) to the HOST field of the syslog message,
+    case, 192.168.1.2) to the `HOST` field of the syslog message,
     discarding any IP address or hostname that was originally in the
     message.
 
 - If the keep-hostname() option is enabled on syslog-ng-relay, but
     name resolution is disabled (the use-dns() option is set to **no**),
-    syslog-ng-relay uses the HOST field of the message as-is, which is
+    syslog-ng-relay uses the `HOST` field of the message as-is, which is
     probably 192.168.1.2.
 
 - To resolve the 192.168.1.2 IP address to a hostname on
     syslog-ng-relay using a DNS server, use the **keep-hostname(no)**
     and **use-dns(yes)** options. If the DNS server is properly
     configured and reverse DNS lookup is available for the 192.168.1.2
-    address, {{ site.product.short_name }} will rewrite the HOST field of the log
+    address, {{ site.product.short_name }} will rewrite the `HOST` field of the log
     message to client-host.
 
     **NOTE:** It is also possible to resolve IP addresses locally, without
@@ -40,8 +40,8 @@ Depending on the settings of syslog-ng-relay, the following can happen.
 - The above points apply to the {{ site.product.short_name }} server
     (syslog-ng-server) as well, so if syslog-ng-relay is configured
     properly, use the **keep-hostname(yes)** option on syslog-ng-server
-    to retain the proper HOST field. Setting **keep-hostname(no)** on
-    syslog-ng-server would result in {{ site.product.short_name }} rewriting the HOST
+    to retain the proper `HOST` field. Setting **keep-hostname(no)** on
+    syslog-ng-server would result in {{ site.product.short_name }} rewriting the `HOST`
     field to the address of the host that sent the message to
     syslog-ng-server, which is syslog-ng-relay in this case.
 

doc/_admin-guide/060_Sources/140_Python/001_Python_logmessage_API.md

@@ -18,7 +18,7 @@ from syslogng import LogMessage
 # Initialize an empty message with default values (recvd timestamp, rcptid, hostid, ...)
 msg = LogMessage()
 
-# Initialize a message and set its MESSAGE field to the specified argument
+# Initialize a message and set its `MESSAGE` field to the specified argument
 msg = LogMessage("string or bytes-like object") 
 ```
 

doc/_admin-guide/060_Sources/150_snmptrap/000_snmptrap_options.md

@@ -30,7 +30,7 @@ Default value: .snmp. option.
 *Description:* The snmptrap() source automatically parses the traps into
 name-value pairs, so you can handle the content of the trap as a
 structured message. Consequently, you might not even need the
-MESSAGE part of the log message. If set-message-macro() is set to
-**no**, {{ site.product.short_name }} leaves the MESSAGE part empty. If
+`MESSAGE` part of the log message. If set-message-macro() is set to
+**no**, {{ site.product.short_name }} leaves the `MESSAGE` part empty. If
 set-message-macro() is set to **yes**, {{ site.product.short_name }} generates a regular
 log message from the trap.