diff --git a/_includes/doc/admin-guide/examples/anon-ip.md b/_includes/doc/admin-guide/examples/anon-ip.md index 11fad74d..4032d75d 100644 --- a/_includes/doc/admin-guide/examples/anon-ip.md +++ b/_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 diff --git a/_includes/doc/admin-guide/options/flags.md b/_includes/doc/admin-guide/options/flags.md index 3c8dc26c..71879550 100644 --- a/_includes/doc/admin-guide/options/flags.md +++ b/_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. diff --git a/_includes/doc/admin-guide/options/host-override.md b/_includes/doc/admin-guide/options/host-override.md index 5cf817c6..210adba7 100644 --- a/_includes/doc/admin-guide/options/host-override.md +++ b/_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. diff --git a/_includes/doc/admin-guide/options/keep-hostname.md b/_includes/doc/admin-guide/options/keep-hostname.md index deb1c0af..9b0813fc 100644 --- a/_includes/doc/admin-guide/options/keep-hostname.md +++ b/_includes/doc/admin-guide/options/keep-hostname.md @@ -6,10 +6,10 @@ *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 @@ -17,7 +17,7 @@ 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} diff --git a/_includes/doc/admin-guide/options/prefix.md b/_includes/doc/admin-guide/options/prefix.md index 7c31b369..f258f2b1 100644 --- a/_includes/doc/admin-guide/options/prefix.md +++ b/_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 diff --git a/_includes/doc/admin-guide/options/source-flags.md b/_includes/doc/admin-guide/options/source-flags.md index 8929241c..5cfd3551 100644 --- a/_includes/doc/admin-guide/options/source-flags.md +++ b/_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. diff --git a/_includes/doc/admin-guide/options/value-pairs.md b/_includes/doc/admin-guide/options/value-pairs.md index 8f2c8317..8be26343 100644 --- a/_includes/doc/admin-guide/options/value-pairs.md +++ b/_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). diff --git a/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/000_BSD_syslog_messages.md b/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/000_BSD_syslog_messages.md index e2c9901c..9aac6e4e 100644 --- a/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/000_BSD_syslog_messages.md +++ b/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 \ = ( \ \* @@ -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*. diff --git a/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/001_IETF_syslog_messages.md b/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/001_IETF_syslog_messages.md index 5accff1e..f4c5cde9 100644 --- a/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/001_IETF_syslog_messages.md +++ b/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: >\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 diff --git a/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/002_EWMM_messages.md b/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/002_EWMM_messages.md index 33e675f2..eb8ecec4 100644 --- a/doc/_admin-guide/020_The_concepts_of_syslog-ng/007_The_structure_of_a_log_message/002_EWMM_messages.md +++ b/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 diff --git a/doc/_admin-guide/020_The_concepts_of_syslog-ng/008_Message_representation.md b/doc/_admin-guide/020_The_concepts_of_syslog-ng/008_Message_representation.md index 4ec9e5f6..609c3818 100644 --- a/doc/_admin-guide/020_The_concepts_of_syslog-ng/008_Message_representation.md +++ b/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. diff --git a/doc/_admin-guide/020_The_concepts_of_syslog-ng/009_Structuring_macros/000_Specifying_data_types.md b/doc/_admin-guide/020_The_concepts_of_syslog-ng/009_Structuring_macros/000_Specifying_data_types.md index c31b854f..bca650b1 100644 --- a/doc/_admin-guide/020_The_concepts_of_syslog-ng/009_Structuring_macros/000_Specifying_data_types.md +++ b/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() diff --git a/doc/_admin-guide/040_Quick-start_guide/002_Configuring_syslog-ng_relays/001_How_relaying_works.md b/doc/_admin-guide/040_Quick-start_guide/002_Configuring_syslog-ng_relays/001_How_relaying_works.md index 64372d00..699e90fb 100644 --- a/doc/_admin-guide/040_Quick-start_guide/002_Configuring_syslog-ng_relays/001_How_relaying_works.md +++ b/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. diff --git a/doc/_admin-guide/060_Sources/140_Python/001_Python_logmessage_API.md b/doc/_admin-guide/060_Sources/140_Python/001_Python_logmessage_API.md index 814a6fd0..1f0ccf85 100644 --- a/doc/_admin-guide/060_Sources/140_Python/001_Python_logmessage_API.md +++ b/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") ``` diff --git a/doc/_admin-guide/060_Sources/150_snmptrap/000_snmptrap_options.md b/doc/_admin-guide/060_Sources/150_snmptrap/000_snmptrap_options.md index b23c4fe9..54582234 100644 --- a/doc/_admin-guide/060_Sources/150_snmptrap/000_snmptrap_options.md +++ b/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. diff --git a/doc/_admin-guide/060_Sources/190_systemd-journal/000_systemd-journal_options.md b/doc/_admin-guide/060_Sources/190_systemd-journal/000_systemd-journal_options.md index b3e97fd6..4ee6801e 100644 --- a/doc/_admin-guide/060_Sources/190_systemd-journal/000_systemd-journal_options.md +++ b/doc/_admin-guide/060_Sources/190_systemd-journal/000_systemd-journal_options.md @@ -17,7 +17,7 @@ The systemd-journal() driver has the following options: |Type: |string| |Default: |notice| -*Description:* The default level value if the PRIORITY entry does not +*Description:* The default level value if the `PRIORITY` entry does not exist. {% include doc/admin-guide/options/hook.md %} diff --git a/doc/_admin-guide/060_Sources/220_unix-stream_unix-dgram/000_Unix_credentials.md b/doc/_admin-guide/060_Sources/220_unix-stream_unix-dgram/000_Unix_credentials.md index cb7a9c52..fe79bc26 100644 --- a/doc/_admin-guide/060_Sources/220_unix-stream_unix-dgram/000_Unix_credentials.md +++ b/doc/_admin-guide/060_Sources/220_unix-stream_unix-dgram/000_Unix_credentials.md @@ -14,8 +14,8 @@ command). Similar information is available for the | Macro | Description | |---|---| -| ${.unix.cmdline} | The name (without the path) and command-line options of the executable belonging to the PID that sent the message. For example, su - myuser | -| ${.unix.exe} | The path of the executable belonging to the PID that sent the message. For example, /usr/bin/su | +| ${.unix.cmdline} | The name (without the path) and command-line options of the executable belonging to the `PID` that sent the message. For example, su - myuser | +| ${.unix.exe} | The path of the executable belonging to the `PID` that sent the message. For example, /usr/bin/su | | ${.unix.gid} | The group ID (GID) corresponding to the UID of the application that sent the log message. Note that this is the ID number of the group, not its human-readable name. For example, 0 | | ${.unix.pid} | The process ID (PID) of the application that sent the log message. For example, 774. | | | Note that on every UNIX platforms, if the system() source uses sockets, it will overwrite the ${PID} macro with the value of ${.unix.pid}, if it is available. | diff --git a/doc/_admin-guide/070_Destinations/130_MongoDB/001_Mongodb_options.md b/doc/_admin-guide/070_Destinations/130_MongoDB/001_Mongodb_options.md index 3a0956af..0f349268 100644 --- a/doc/_admin-guide/070_Destinations/130_MongoDB/001_Mongodb_options.md +++ b/doc/_admin-guide/070_Destinations/130_MongoDB/001_Mongodb_options.md @@ -48,7 +48,7 @@ option supports template functions and macros as well. Using the following example configuration, the mongodb() destination sends incoming messages into separate MongoDB collections (for example, -localhost_messages and anotherhost_messages) based on the HOST field +localhost_messages and anotherhost_messages) based on the `HOST` field of the message : ```config diff --git a/doc/_admin-guide/070_Destinations/130_MongoDB/README.md b/doc/_admin-guide/070_Destinations/130_MongoDB/README.md index 48745055..28d44573 100644 --- a/doc/_admin-guide/070_Destinations/130_MongoDB/README.md +++ b/doc/_admin-guide/070_Destinations/130_MongoDB/README.md @@ -34,7 +34,7 @@ In {{ site.product.short_name }} 4.0 and later versions, each name-value pair is **NOTE:** By default, {{ site.product.short_name }} handles every message field as a string. For details on how to send selected fields as other types of data (for -example, handle the PID as a number), see +example, handle the `PID` as a number), see Specifying data types in value-pairs. {: .notice--info} diff --git a/doc/_admin-guide/070_Destinations/240_SMTP/000_SMTP_options.md b/doc/_admin-guide/070_Destinations/240_SMTP/000_SMTP_options.md index 9d4ceab7..703495f6 100644 --- a/doc/_admin-guide/070_Destinations/240_SMTP/000_SMTP_options.md +++ b/doc/_admin-guide/070_Destinations/240_SMTP/000_SMTP_options.md @@ -103,7 +103,7 @@ When using the header option, note the following points: - If you set the same custom header multiple times, only the first will be added to the email, other occurrences will be ignored. -- It is not possible to set the DATE, Return-Path, Original-Recipient, +- It is not possible to set the `DATE`, Return-Path, Original-Recipient, Content-\*, MIME-\*, Resent-\*, Received headers. {% include doc/admin-guide/options/hook.md %} diff --git a/doc/_admin-guide/070_Destinations/250_snmp/000_Converting_Cisco_messages.md b/doc/_admin-guide/070_Destinations/250_snmp/000_Converting_Cisco_messages.md index 487b47c4..94217b4a 100644 --- a/doc/_admin-guide/070_Destinations/250_snmp/000_Converting_Cisco_messages.md +++ b/doc/_admin-guide/070_Destinations/250_snmp/000_Converting_Cisco_messages.md @@ -34,9 +34,9 @@ the Cisco website. ## Parsing Cisco-specific message fields with patterndb -The PROGRAM part of the syslog messages sent by Cisco devices +The `PROGRAM` part of the syslog messages sent by Cisco devices contain not only the program name, but other important protocol -information part as well. The PROGRAM of these messages contains the +information part as well. The `PROGRAM` of these messages contains the Facility, Severity, and the Mnemonic (the Cisco name) of the message. The following pattern database parses these values and makes them available as the .cisco.Facility, .cisco.Severity, and .cisco.MsgName, diff --git a/doc/_admin-guide/070_Destinations/300_syslog/README.md b/doc/_admin-guide/070_Destinations/300_syslog/README.md index b215f5a5..a7005111 100644 --- a/doc/_admin-guide/070_Destinations/300_syslog/README.md +++ b/doc/_admin-guide/070_Destinations/300_syslog/README.md @@ -70,6 +70,6 @@ destination d_syslog_tls { ``` **NOTE:** If a message uses the IETF-syslog format (RFC-5424), only the text -of the message can be customized (that is, the MESSAGE part of the +of the message can be customized (that is, the `MESSAGE` part of the log), the structure of the header is fixed. {: .notice--info} diff --git a/doc/_admin-guide/080_Log/000_Log_paths/003_Log_path_flags.md b/doc/_admin-guide/080_Log/000_Log_paths/003_Log_path_flags.md index 9cb0019b..9e4d238a 100644 --- a/doc/_admin-guide/080_Log/000_Log_paths/003_Log_path_flags.md +++ b/doc/_admin-guide/080_Log/000_Log_paths/003_Log_path_flags.md @@ -89,7 +89,7 @@ log { ## Example: Using the drop-unmatched flag -In the following example, if a log message arrives whose MSG part does +In the following example, if a log message arrives whose `MSG` part does not contain the string foo, then {{ site.product.short_name }} will discard the message and will not check compliance with the second if condition. diff --git a/doc/_admin-guide/080_Log/030_Filters/002_Comparing_macro_values.md b/doc/_admin-guide/080_Log/030_Filters/002_Comparing_macro_values.md index 0ad338ea..aea372dd 100644 --- a/doc/_admin-guide/080_Log/030_Filters/002_Comparing_macro_values.md +++ b/doc/_admin-guide/080_Log/030_Filters/002_Comparing_macro_values.md @@ -61,14 +61,14 @@ operators for strings as well. ### Example: Comparing macro values in filters -The following expression selects log messages containing a PID (that is, +The following expression selects log messages containing a `PID` (that is, ${PID} macro is not empty): ```config filter f_pid {"${PID}" !=""}; ``` -The following expression selects log messages that do not contain a PID. +The following expression selects log messages that do not contain a `PID`. Also, it uses a template as the left argument of the operator and compares the values as strings: diff --git a/doc/_admin-guide/080_Log/030_Filters/004_Tagging_messages.md b/doc/_admin-guide/080_Log/030_Filters/004_Tagging_messages.md index 63ee3fba..3a2c557d 100644 --- a/doc/_admin-guide/080_Log/030_Filters/004_Tagging_messages.md +++ b/doc/_admin-guide/080_Log/030_Filters/004_Tagging_messages.md @@ -31,7 +31,7 @@ Currently {{ site.product.short_name }} can tag a message at two different place - To include the tags in the message, use the **${TAGS}** macro in a template. Alternatively, if you are using the IETF-syslog message - format, you can include the ${TAGS} macro in the .SDATA.meta part + format, you can include the ${TAGS} macro in the `.SDATA.meta` part of the message. Note that the ${TAGS} macro is available only in {{ site.product.short_name }} 3.1.1 and later. diff --git a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/002_host.md b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/002_host.md index 72a6db0e..1e0108f3 100644 --- a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/002_host.md +++ b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/002_host.md @@ -7,7 +7,7 @@ id: adm-log-filters-host *Description:* Match messages by using a regular expression against the hostname field of log messages. Note that you can filter only on the -actual content of the HOST field of the message (or what it was +actual content of the `HOST` field of the message (or what it was rewritten to). That is, {{ site.product.short_name }} will compare the filter expression to the content of the ${HOST} macro. This means that for the IP address of a host will not match, even if the IP address and the hostname field diff --git a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/003_inlist.md b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/003_inlist.md index 03f4c870..c30840db 100644 --- a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/003_inlist.md +++ b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/003_inlist.md @@ -9,7 +9,7 @@ id: adm-log-filters-inlist in a file, allowing you to do simple, file-based black- and whitelisting. The file must be a plain-text file, containing one entry per line. The {{ site.product.short_name }} application loads the entire file, and -compares the value of the specified field (for example, PROGRAM) to +compares the value of the specified field (for example, `PROGRAM`) to entries in the file. When you use the in-list() filter, note the following points: @@ -25,7 +25,7 @@ Available in {{ site.product.short_name }} 3.5 and later. ## Example: Selecting messages using the in-list() filter -Create a text file that contains the programs (as in the PROGRAM +Create a text file that contains the programs (as in the `PROGRAM` field of their log messages) you want to select. For example, you want to forward only the logs of a few applications from a host: kernel, sshd, and sudo. Create the /etc/syslog-ng/programlist.list file with the diff --git a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/007_netmask.md b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/007_netmask.md index 9abc2f4b..067cb4fa 100644 --- a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/007_netmask.md +++ b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/007_netmask.md @@ -8,7 +8,7 @@ id: adm-log-filters-netmask *Description:* Select only messages sent by a host whose IP address belongs to the specified IPv4 subnet. Note that this filter checks the IP address of the last-hop relay (the host that actually sent the -message to {{ site.product.short_name }}), not the contents of the HOST field of the +message to {{ site.product.short_name }}), not the contents of the `HOST` field of the message. You can use both the dot-decimal and the CIDR notation to specify the netmask. For example, 192.168.5.0/255.255.255.0 or 192.168.5.0/24. To filter IPv6 addresses, see diff --git a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/008_netmask6.md b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/008_netmask6.md index 830abe4a..60d6bcbd 100644 --- a/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/008_netmask6.md +++ b/doc/_admin-guide/080_Log/030_Filters/005_Filter_functions/008_netmask6.md @@ -8,7 +8,7 @@ id: adm-log-filters-netmask6 *Description:* Select only messages sent by a host whose IP address belongs to the specified IPv6 subnet. Note that this filter checks the IP address of the last-hop relay (the host that actually sent the -message to {{ site.product.short_name }}), not the contents of the HOST field of the +message to {{ site.product.short_name }}), not the contents of the `HOST` field of the message. You can use both the regular and the compressed format to specify the IP address, for example, 1080:0:0:0:8:800:200C:417A or 1080::8:800:200C:417A. If you do not specify the address, localhost is diff --git a/doc/_admin-guide/090_Global_options/000_Global_options.md b/doc/_admin-guide/090_Global_options/000_Global_options.md index 8b03e337..a94c14cf 100644 --- a/doc/_admin-guide/090_Global_options/000_Global_options.md +++ b/doc/_admin-guide/090_Global_options/000_Global_options.md @@ -311,7 +311,7 @@ configured to do so. |Default:| yes| *Description:* Enable {{ site.product.short_name }} to collect UNIX credential -information (that is, the PID, user ID, and group of the sender process) +information (that is, the `PID`, user ID, and group of the sender process) for messages received using UNIX domain sockets. Available only in {{ site.product.name }} 3.7 and later. Note that collecting UNIX credential information from sockets in high-traffic environments can be @@ -431,7 +431,7 @@ The following sub-options are available within the stats() option: Available in {{ site.product.short_name }} 4.1 and later versions. -*Description:* Configures the behavior of counting messages based on different syslog fields, like SEVERITY, FACILITY, HOST. +*Description:* Configures the behavior of counting messages based on different syslog fields, like SEVERITY, `FACILITY`, `HOST`. Possible values: @@ -507,15 +507,15 @@ restarts with 1). |Default:| no| *Description:* This option enables generating a globally unique ID. It -is generated from the HOSTID and the RCPTID in the format of +is generated from the `HOSTID` and the `RCPTID` in the format of HOSTID@RCPTID. It has a fixed length: 16+@+8 characters. You can include the unique ID in the message by using the macro. For details, see ${UNIQID}. -Enabling this option automatically generates the HOSTID. The HOSTID is a +Enabling this option automatically generates the `HOSTID`. The `HOSTID` is a persistent, 32-bits-long cryptographically secure pseudo random number, that belongs to the host that the {{ site.product.short_name }} is running on. If the -persist file is damaged, the HOSTID might change. +persist file is damaged, the `HOSTID` might change. Enabling this option automatically enables the ${RCPTID} functionality. For details, see ${RCPTID}. diff --git a/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/000_Formatting_messages.md b/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/000_Formatting_messages.md index 9d5c1cc8..e1f80f4e 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/000_Formatting_messages.md +++ b/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/000_Formatting_messages.md @@ -20,7 +20,7 @@ syslog message, for example, to add elements of the message header to the message text. **NOTE:** If a message uses the IETF-syslog format (RFC-5424), only the text -of the message can be customized (that is, the MESSAGE part of the +of the message can be customized (that is, the `MESSAGE` part of the log), the structure of the header is fixed. {: .notice--info} diff --git a/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/004_Macros_of_syslog-ng.md b/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/004_Macros_of_syslog-ng.md index bfe53a2d..abc6febe 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/004_Macros_of_syslog-ng.md +++ b/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/004_Macros_of_syslog-ng.md @@ -13,7 +13,7 @@ description: >- > > If you are using the flags(no-parse) option, then syslog message parsing is > completely disabled, and the entire incoming message is treated as -> the MESSAGE part of a syslog message. +> the `MESSAGE` part of a syslog message. > In this case, {{ site.product.short_name }} generates a new syslog header > (timestamp, host, and so on) automatically. Note that even > though flags(no-parse) disables message parsing, some flags can @@ -174,7 +174,7 @@ ${MSGHDR} and ${PID} macros. If you are using the flags(no-parse) option, then syslog message parsing is completely disabled, and the entire incoming message is treated as -the MESSAGE part of a syslog message. In this case, {{ site.product.short_name }} +the `MESSAGE` part of a syslog message. In this case, {{ site.product.short_name }} generates a new syslog header (timestamp, host, and so on) automatically. Note that even though flags(no-parse) disables message parsing, some flags can still be used, for example, the no-multi-line @@ -222,13 +222,13 @@ Available in {{ site.product.short_name }} version 3.4 and later. The ${MSG} macro is an alias of the ${MESSAGE} macro, using ${MSG} in {{ site.product.short_name }} is equivalent to ${MESSAGE}. For details on this macro, -see MESSAGE. +see ${MESSAGE}. ## ${MSGHDR} -The name and the PID of the program that sent the log +The name and the `PID` of the program that sent the log message in PROGRAM\[PID\]: format. Includes a trailing whitespace. Note -that the macro returns an empty value if both the PROGRAM and PID fields +that the macro returns an empty value if both the `PROGRAM` and `PID` fields of the message are empty. ## ${MSGID} @@ -246,11 +246,11 @@ relayed without modification. Message contents without the program name or pid. Starting with {{ site.product.short_name }} 3.0, the following macros are equivalent: ${MSGONLY}, ${MSG}, ${MESSAGE}. For consistency, use the ${MESSAGE} -macro. For details, see MESSAGE. +macro. For details, see ${MESSAGE}. ## ${PID} -The PID of the program sending the message. +The `PID` of the program sending the message. ## ${PRI} @@ -303,12 +303,12 @@ restarted, but not when reloaded. ## ${SDATA}, ${.SDATA.SDID.SDNAME} The {{ site.product.short_name }} application automatically parses the -STRUCTURED-DATA part of IETF-syslog messages, which can be referenced in -macros. The ${SDATA} macro references the entire STRUCTURED-DATA part +`STRUCTURED-DATA` part of IETF-syslog messages, which can be referenced in +macros. The ${SDATA} macro references the entire `STRUCTURED-DATA` part of the message, while structured data elements can be referenced using the ${.SDATA.SDID.SDNAME} macro. ->**NOTE:** When using STRUCTURED-DATA macros, consider the following: +>**NOTE:** When using `STRUCTURED-DATA` macros, consider the following: > >- When referencing an element of the structured data, the macro must > begin with the dot (.) character. For example, @@ -346,7 +346,7 @@ one of the following: timestamp format, then {{ site.product.short_name }} stores the sequence number from the message in this macro. If you forward this message the IETF-syslog protocol, {{ site.product.short_name }} includes the sequence number - received from the Cisco device in the ${.SDATA.meta.sequenceId} + received from the Cisco device in the `.SDATA.meta.sequenceId` part of the message. **NOTE:** To enable sequence numbering of log messages on Cisco devices, @@ -458,10 +458,9 @@ following macros are available in {{ site.product.short_name }} version 3.9 and ## ${UNIQID} -A globally unique ID generated from the HOSTID and the -RCPTID in the format of HOSTID@RCPTID. For details, see -use-uniqid() and -RCPTID. +A globally unique ID generated from the `HOSTID` and the +`RCPTID` in the format of HOSTID@RCPTID. For details, see +use-uniqid() and ${RCPTID}. Available in {{ site.product.short_name }} version 3.7 and later. diff --git a/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/007_Template_functions_of_syslog-ng.md b/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/007_Template_functions_of_syslog-ng.md index 409fc5d6..4ddb575e 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/007_Template_functions_of_syslog-ng.md +++ b/doc/_admin-guide/110_Template_and_rewrite/000_Customize_message_format/007_Template_functions_of_syslog-ng.md @@ -105,8 +105,8 @@ prerequisites: 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 (since you will use the template-function in a template, you must escape the double-quotes). @@ -246,8 +246,8 @@ value-pairs(): format-json uses a syntax similar to command lines. 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 (since you will use the template-function in a template, you must escape the double-quotes). @@ -302,8 +302,8 @@ value-pairs(). 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 (since you will use the template-function in a template, you must escape the double-quotes). @@ -815,7 +815,7 @@ template { ### Example: Writing template functions in Python The following example creates a Python template function called -return\_message that returns the MESSAGE part of the log message. +`return_message` that returns the `MESSAGE` part of the log message. ```config @version: 3.38 @@ -831,7 +831,7 @@ destination d_local { ``` The following example creates a Python template function called -resolve\_host that receives an IP address as an argument, and attempts +`resolve_host` that receives an IP address as an argument, and attempts to resolve it into a hostname. ```config diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/001_Setting_fields.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/001_Setting_fields.md index 20160c98..fd412a7a 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/001_Setting_fields.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/001_Setting_fields.md @@ -9,10 +9,10 @@ To set a field of the message to a specific value, you have to: - select the field where it should be included. -You can set the value of available macros, for example, HOST, MESSAGE, -PROGRAM, or any user-defined macros created using parsers (for details, +You can set the value of available macros, for example, ${HOST}, ${MESSAGE}, +${PROGRAM}, or any user-defined macros created using parsers (for details, see [[parser: Parse and segment structured messages]] and -[[db-parser: Process message content with a pattern database (patterndb)]]. +[[db-parser: Process message content with a pattern database (patterndb)]]). Note that the rewrite operation completely replaces any previous value of that field. {% include doc/admin-guide/notes/hard-macros.md %} @@ -29,7 +29,7 @@ rewrite { ### Example: Setting message fields to a particular value -The following example sets the HOST field of the message to myhost. +The following example sets the `HOST` field of the message to myhost. ```config rewrite r_rewrite_set{ @@ -37,7 +37,7 @@ rewrite r_rewrite_set{ }; ``` -The following example appends the \"suffix\" string to the MESSAGE +The following example appends the \"suffix\" string to the `MESSAGE` field: ```config @@ -46,8 +46,8 @@ rewrite r_rewrite_set{ }; ``` -For details on rewriting SDATA fields, see -Creating custom SDATA fields. +For details on rewriting `SDATA` fields, see +Creating custom `SDATA` fields. You can also use the following options in rewrite rules that use the set() operator. diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/003_Setting_facility.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/003_Setting_facility.md index 30c8dd28..70abdb40 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/003_Setting_facility.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/003_Setting_facility.md @@ -5,7 +5,7 @@ id: adm-temp-facility description: >- It is possible to set the facility field with the set-facility() rewrite function. When set, the set-facility() rewrite function will only - rewrite the PRIORITY field in the message to the first parameter value + rewrite the `PRIORITY` field in the message to the first parameter value specified in the function. --- diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/004_Setting_priority.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/004_Setting_priority.md index a525c8f5..dc6705ba 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/004_Setting_priority.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/004_Setting_priority.md @@ -3,14 +3,14 @@ title: Setting the priority of a message with the set-pri() rewrite function short_title: Setting priority id: adm-temp-priority description: >- - You can set the PRI value of a BSD or IETF syslog + You can set the `PRI` value of a BSD or IETF syslog message with the set-pri() rewrite function by specifying a template string. - This is useful, for example, if incoming messages do not have a PRI value - specified by default, but a PRI value is required for filtering + This is useful, for example, if incoming messages do not have a `PRI` value + specified by default, but a `PRI` value is required for filtering purposes. --- -When configured, the set-pri() function will only rewrite the PRI value +When configured, the set-pri() function will only rewrite the `PRI` value of the message field. {% include doc/admin-guide/notes/not-valid-param.md %} diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/006_Unsetting_fields.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/006_Unsetting_fields.md index 2f143a07..214948ce 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/006_Unsetting_fields.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/006_Unsetting_fields.md @@ -24,7 +24,7 @@ rewrite { ### Example: Unsetting a message field -The following example unsets the HOST field of the message. +The following example unsets the `HOST` field of the message. ```config rewrite r_rewrite_unset{ @@ -45,7 +45,7 @@ rewrite { ### Example: Unsetting a group of fields -The following rule clears all SDATA fields: +The following rule clears all `SDATA` fields: ```config rewrite r_rewrite_unset_SDATA{ diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/008_Custom_SDATA_fields.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/008_Custom_SDATA_fields.md index 6438b057..90ac0e15 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/008_Custom_SDATA_fields.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/008_Custom_SDATA_fields.md @@ -3,12 +3,12 @@ title: Creating custom SDATA fields id: adm-temp-sdata description: >- If you use RFC-5424 formatted (IETF-syslog) messages, you can also create - custom fields in the SDATA part of the message (For details on the SDATA + custom fields in the `SDATA` part of the message (For details on the `SDATA` message part, see The STRUCTURED-DATA message part). --- According to RFC-5424, the name of the field (its SD-ID) must not contain -the @ character for reserved SD-IDs. Custom SDATA fields must be in the +the @ character for reserved SD-IDs. Custom `SDATA` fields must be in the following format: .SDATA.group-name@\.field-name, for example, .SDATA.mySDATA-field-group@18372.4.mySDATA-field. (18372.4 is the @@ -19,7 +19,7 @@ private enterprise number of One Identity LLC, the developer of The following example sets the sequence ID field of the RFC-5424 formatted (IETF-syslog) messages to a fixed value. This field is -a predefined SDATA field with a reserved SD-ID, therefore its name does +a predefined `SDATA` field with a reserved SD-ID, therefore its name does not contain the @ character. ```config @@ -36,7 +36,7 @@ use the **${.SDATA.groupID.fieldID@18372.4}** macro in a template or SQL table, its value will be yes for every message that was processed with this rewrite rule, and empty for every other message. -The next example creates a new SDATA field-group and field called custom +The next example creates a new `SDATA` field-group and field called custom and sourceip, respectively: ```config @@ -47,12 +47,12 @@ rewrite r_rewrite_set { If you use the **${.SDATA.custom@18372.4.sourceip}** macro in a template or SQL table, its value will be that of the ${SOURCEIP} macro (as -seen on the machine where the SDATA field was created) for every message +seen on the machine where the `SDATA` field was created) for every message that was processed with this rewrite rule, and empty for every other message. You can verify whether or not the format is correct by looking at the -actual network traffic. The SDATA field-group will be called +actual network traffic. The `SDATA` field-group will be called custom@18372.4, and sourceip will become a field within that group. If you decide to set up several fields, they will be listed in consecutive -order within the field-group\'s SDATA block. +order within the field-group\'s `SDATA` block. diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/009_Setting_multiple_fields.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/009_Setting_multiple_fields.md index c6aa3eab..519e23f2 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/009_Setting_multiple_fields.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/009_Setting_multiple_fields.md @@ -38,19 +38,19 @@ rewrite { The following examples show how to change the values of multiple fields at the same time. -- Change the value of the HOST field to **myhost**. +- Change the value of the `HOST` field to **myhost**. ```config groupset ("myhost" values("HOST")) ``` -- Change the value of the HOST and FULLHOST fields to **myhost**. +- Change the value of the `HOST` and `FULLHOST` fields to **myhost**. ```config groupset ("myhost" values("HOST" "FULLHOST")) ``` -- Change the value of the HOST, FULLHOST and fields to lowercase. +- Change the value of the `HOST` and `FULLHOST` fields to lowercase. ```config groupset ("$(lowercase "$_")" values("HOST" "FULLHOST")) diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/011_Conditional_rewrite.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/011_Conditional_rewrite.md index aa9d9ef1..6b67c162 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/011_Conditional_rewrite.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/011_Conditional_rewrite.md @@ -45,16 +45,16 @@ To configure condtional rewrite 1. The log path receives a message from the source (s1). 2. The rewrite rule (r\_rewrite\_set) evaluates the condition. If the - message matches the condition (the PROGRAM field of the message is + message matches the condition (the `PROGRAM` field of the message is \"myapplication\"), {{ site.product.short_name }} rewrites the log message (sets the - value of the HOST field to \"myhost\"), otherwise it is not + value of the `HOST` field to \"myhost\"), otherwise it is not modified. 3. The next element of the log path processes the message (d1). ### Example: Using conditional rewriting -The following example sets the HOST field of the message to myhost only +The following example sets the `HOST` field of the message to myhost only if the message was sent by the myapplication program. ```config diff --git a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/014_Anonymizing_credit_card_numbers.md b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/014_Anonymizing_credit_card_numbers.md index 194aec80..2edfb50d 100644 --- a/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/014_Anonymizing_credit_card_numbers.md +++ b/doc/_admin-guide/110_Template_and_rewrite/001_Modifying_messages/014_Anonymizing_credit_card_numbers.md @@ -23,7 +23,7 @@ rewrite { }; ``` -By default, these rewrite rules process the MESSAGE part of the log +By default, these rewrite rules process the `MESSAGE` part of the log message. ## credit-card-hash() diff --git a/doc/_admin-guide/120_Parser/000_Parsing_syslog_messages/000_Syslog_parser_options.md b/doc/_admin-guide/120_Parser/000_Parsing_syslog_messages/000_Syslog_parser_options.md index ec30f13f..d49ff81f 100644 --- a/doc/_admin-guide/120_Parser/000_Parsing_syslog_messages/000_Syslog_parser_options.md +++ b/doc/_admin-guide/120_Parser/000_Parsing_syslog_messages/000_Syslog_parser_options.md @@ -24,10 +24,10 @@ If you set drop-invalid() to **no**, the parsing error triggers syslog-parser() to rewrite and extend the original log message with the following additional information: -- It prepends the following message to the contents of the MESSAGE +- It prepends the following message to the contents of the `MESSAGE` field: Error processing log message. -- It sets the contents of the PROGRAM field to syslog-ng. +- It sets the contents of the `PROGRAM` field to syslog-ng. - It sets the contents of the facility field to syslog. diff --git a/doc/_admin-guide/120_Parser/002_Parsing_key-value_pairs/README.md b/doc/_admin-guide/120_Parser/002_Parsing_key-value_pairs/README.md index cc2e4e67..1b121a7e 100644 --- a/doc/_admin-guide/120_Parser/002_Parsing_key-value_pairs/README.md +++ b/doc/_admin-guide/120_Parser/002_Parsing_key-value_pairs/README.md @@ -36,7 +36,7 @@ are not permitted. To parse key=value pairs, define a parser that has the kv-parser() option. Defining the prefix is optional. By default, the parser will -process the MESSAGE part of the log message. You can also define the +process the `MESSAGE` part of the log message. You can also define the parser inline in the log path. **Declaration** diff --git a/doc/_admin-guide/120_Parser/003_JSON_parser/README.md b/doc/_admin-guide/120_Parser/003_JSON_parser/README.md index 1e2819e7..29106e7b 100644 --- a/doc/_admin-guide/120_Parser/003_JSON_parser/README.md +++ b/doc/_admin-guide/120_Parser/003_JSON_parser/README.md @@ -40,7 +40,7 @@ messages, therefore acting as a JSON-filter as well. To create a JSON parser, define a parser that has the json-parser() option. Defining the prefix and the marker are optional. By default, the -parser will process the MESSAGE part of the log message. To process +parser will process the `MESSAGE` part of the log message. To process other parts of a log message with the JSON parser, use the template() option. You can also define the parser inline in the log path. diff --git a/doc/_admin-guide/120_Parser/004_XML_parser/README.md b/doc/_admin-guide/120_Parser/004_XML_parser/README.md index d5673fc5..7d3985d2 100644 --- a/doc/_admin-guide/120_Parser/004_XML_parser/README.md +++ b/doc/_admin-guide/120_Parser/004_XML_parser/README.md @@ -12,7 +12,7 @@ description: >- --- To create an XML parser, define an xml_parser that has the xml() -option. By default, the parser will process the MESSAGE part of the +option. By default, the parser will process the `MESSAGE` part of the log message. To process other parts of a log message using the XML parser, use the template() option. You can also define the parser inline in the log path. diff --git a/doc/_admin-guide/120_Parser/005_Parsing_dates/README.md b/doc/_admin-guide/120_Parser/005_Parsing_dates/README.md index 4605b7cf..0cdde28a 100644 --- a/doc/_admin-guide/120_Parser/005_Parsing_dates/README.md +++ b/doc/_admin-guide/120_Parser/005_Parsing_dates/README.md @@ -11,7 +11,7 @@ description: >- --- **NOTE:** Note that parsing will fail if the format string does not match -the entire template or field. Since by default {{ site.product.short_name }}({{ site.product.short_name }}) uses the MESSAGE part of the log message, +the entire template or field. Since by default {{ site.product.short_name }}({{ site.product.short_name }}) uses the `MESSAGE` part of the log message, parsing will fail, unless the log message contains only a date, but that is unlikely, so practically you will have to segment the message (for example, using a [[csv-parser()|adm-parser-csv]]. @@ -37,7 +37,7 @@ In the following example, {{ site.product.short_name }} parses dates like following format string: format(\"%d/%b/%Y:%H:%M:%S %Z\") (how you create this field from the incoming message is not shown in the example). In the destination template every message will begin with the -timestamp in ISODATE format. Since the syslog parser is disabled, +timestamp in `ISODATE` format. Since the syslog parser is disabled, {{ site.product.short_name }} will include the entire original message (including the original timestamp) in the ${MESSAGE} macro. diff --git a/doc/_admin-guide/120_Parser/006_Python_parser.md b/doc/_admin-guide/120_Parser/006_Python_parser.md index 5c133fa9..62aa864d 100644 --- a/doc/_admin-guide/120_Parser/006_Python_parser.md +++ b/doc/_admin-guide/120_Parser/006_Python_parser.md @@ -73,7 +73,7 @@ False, or raises an exception, {{ site.product.short_name }} will drop the messa - To reference a name-value pair or a macro in the Python code, use the following format. For example, if the first argument in the definition of the function is called log-message, the value of the - HOST macro is log-message\[\'HOST\'\], and so on. (The log-message + `HOST` macro is log-message\[\'HOST\'\], and so on. (The log-message contains the entire log message (not just the text body) in a structure similar to a Python dict, but it is actually an object.) diff --git a/doc/_admin-guide/120_Parser/007_Parsing_tags.md b/doc/_admin-guide/120_Parser/007_Parsing_tags.md index a3865828..ff90231a 100644 --- a/doc/_admin-guide/120_Parser/007_Parsing_tags.md +++ b/doc/_admin-guide/120_Parser/007_Parsing_tags.md @@ -12,7 +12,7 @@ description: >- Available in version 3.23 and later. Specify the macro that contains the list of tags to parse in the -template() option of the parser, for example, the SDATA field that you +template() option of the parser, for example, the `SDATA` field that you used to transfer the tags, or the name of the JSON field that contains the tags after using the json-parser(). diff --git a/doc/_admin-guide/120_Parser/009_Linux_audit_parser/README.md b/doc/_admin-guide/120_Parser/009_Linux_audit_parser/README.md index 6760576c..7eeb603e 100644 --- a/doc/_admin-guide/120_Parser/009_Linux_audit_parser/README.md +++ b/doc/_admin-guide/120_Parser/009_Linux_audit_parser/README.md @@ -45,7 +45,7 @@ pairs. It automatically decodes the following fields: To parse the log messages of the Linux Audit subsystem, define a parser that has the linux-audit-parser() option. By default, the parser will -process the MESSAGE part of the log message. To process other parts +process the `MESSAGE` part of the log message. To process other parts of a log message, use the **template()** option. You can also define the parser inline in the log path. diff --git a/doc/_admin-guide/120_Parser/013_netskope_parser.md b/doc/_admin-guide/120_Parser/013_netskope_parser.md index 753de31d..fca7da1d 100644 --- a/doc/_admin-guide/120_Parser/013_netskope_parser.md +++ b/doc/_admin-guide/120_Parser/013_netskope_parser.md @@ -18,7 +18,7 @@ For example: {% include doc/admin-guide/parser-support.md %} -The {{ site.product.short_name }} application sets the PROGRAM field to Netskope. +The {{ site.product.short_name }} application sets the `PROGRAM` field to Netskope. By default, the Netskope-specific fields are extracted into name-value pairs prefixed with .netskope. For example, the organization_unit in diff --git a/doc/_admin-guide/120_Parser/014_panos_parser/README.md b/doc/_admin-guide/120_Parser/014_panos_parser/README.md index e82d0ca0..5770de9e 100644 --- a/doc/_admin-guide/120_Parser/014_panos_parser/README.md +++ b/doc/_admin-guide/120_Parser/014_panos_parser/README.md @@ -7,7 +7,7 @@ description: >- version of Palo Alto Networks Operating System) parser can parse log messages originating from Palo Alto Networks devices. Even though these messages completely comply to the RFC standards, - their MESSAGE part is not a plain text. Instead, the MESSAGE part contains + their `MESSAGE` part is not a plain text. Instead, the `MESSAGE` part contains a data structure that requires additional parsing. --- diff --git a/doc/_admin-guide/120_Parser/018_websense_parser.md b/doc/_admin-guide/120_Parser/018_websense_parser.md index 22cbb9ce..14dad99b 100644 --- a/doc/_admin-guide/120_Parser/018_websense_parser.md +++ b/doc/_admin-guide/120_Parser/018_websense_parser.md @@ -19,7 +19,7 @@ For example: {% include doc/admin-guide/parser-support.md %} -The {{ site.product.short_name }} application sets the PROGRAM field to Websense. +The {{ site.product.short_name }} application sets the `PROGRAM` field to Websense. By default, the websense-specific fields are extracted into name-value pairs prefixed with .websense. For example, the product_version in the diff --git a/doc/_admin-guide/120_Parser/023_db_parser/000_Classifying_log_messages/000_Structure_of_a_patterndb.md b/doc/_admin-guide/120_Parser/023_db_parser/000_Classifying_log_messages/000_Structure_of_a_patterndb.md index 7fbbe80e..1e65ab04 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/000_Classifying_log_messages/000_Structure_of_a_patterndb.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/000_Classifying_log_messages/000_Structure_of_a_patterndb.md @@ -45,7 +45,7 @@ The pattern database is organized as follows: - Patterns can consist of literals (keywords, or rather, keycharacters) and pattern parsers. - **NOTE:** If the PROGRAM part of a message is empty, rules with an + **NOTE:** If the `PROGRAM` part of a message is empty, rules with an empty Program Pattern are used to classify the message. {: .notice--info} diff --git a/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/001_External_actions.md b/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/001_External_actions.md index 23d7afac..c82b53e1 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/001_External_actions.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/001_External_actions.md @@ -17,7 +17,7 @@ sends them to an external script. ```xml - A log message from HOST matched rule number $.classifier.rule_id + A log message from `HOST` matched rule number $.classifier.rule_id yes ``` diff --git a/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/002_Actions_and_message_correlation.md b/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/002_Actions_and_message_correlation.md index aed1aef5..e1a3af15 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/002_Actions_and_message_correlation.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/002_Actions_and_message_correlation.md @@ -9,7 +9,7 @@ description: >- - The {{ site.product.short_name }} application automatically fills the fields for the generated message based on the scope of the context, for example, - the HOST and PROGRAM fields if the context-scope is program. + the `HOST` and `PROGRAM` fields if the context-scope is program. - When used together with message correlation, you can also refer to fields and values of earlier messages of the context by adding the diff --git a/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/README.md b/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/README.md index 4da806fb..56e55764 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/README.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/002_Triggering_actions/README.md @@ -57,7 +57,7 @@ generates a message when a message matching the rule is received. - A log message from HOST matched rule number $.classifier.rule_id + A log message from `HOST` matched rule number $.classifier.rule_id @@ -73,7 +73,7 @@ they will override the values of the original message. ## Example: Generating messages with inherited values The following action generates a message that is identical to the -original message, but its PROGRAM field is set to +original message, but its `PROGRAM` field is set to overriding-original-program-name ```xml diff --git a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/000_patterns/README.md b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/000_patterns/README.md index b122b8a4..90161fb5 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/000_patterns/README.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/000_patterns/README.md @@ -20,16 +20,16 @@ N/A ## Children - *pattern*: The name of the application --- {{ site.product.short_name }} matches this - value to the PROGRAM header of the syslog message to find the + value to the `PROGRAM` header of the syslog message to find the rulesets applicable to the syslog message. Specifying multiple patterns is useful if two or more applications - have different names (that is, different PROGRAM fields), but + have different names (that is, different `PROGRAM` fields), but otherwise send identical log messages. It is not necessary to use multiple patterns if only the end of the - PROGRAM fields is different, use only the beginning of the - PROGRAM field as the pattern. For example, the Postfix email + `PROGRAM` fields is different, use only the beginning of the + `PROGRAM` field as the pattern. For example, the Postfix email server sends messages using different process names, but all of them begin with the postfix string. @@ -39,8 +39,8 @@ N/A NOTE: If the \ element of a ruleset is not specified, {{ site.product.short_name }} will use this ruleset as a fallback ruleset: it will - apply the ruleset to messages that have an empty PROGRAM header, or - if none of the program patterns matched the PROGRAM header of the + apply the ruleset to messages that have an empty `PROGRAM` header, or + if none of the program patterns matched the `PROGRAM` header of the incoming message. ### Example diff --git a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/001_rules/000_rule/README.md b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/001_rules/000_rule/README.md index 71bb3fd8..9b5dd63f 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/001_rules/000_rule/README.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/001_rules/000_rule/README.md @@ -69,16 +69,16 @@ The *\* element may contain any number of *\* elements. - *process*: Only messages that are generated by the same process of a client belong to the same context, that is, messages that - have identical HOST, PROGRAM and PID values. This is + have identical `HOST`, `PROGRAM` and `PID` values. This is the default behavior of {{ site.product.short_name }} if context-scope is not specified. - *program*: Messages that are generated by the same application of a client belong to the same context, that is, messages that - have identical HOST and PROGRAM values. + have identical `HOST` and `PROGRAM` values. - *host*: Every message generated by a client belongs to the same - context, only the HOST value of the messages must be + context, only the `HOST` value of the messages must be identical. - *global*: Every message belongs to the same context. diff --git a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/000_create_context/README.md b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/000_create_context/README.md index f38495df..d8457e64 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/000_create_context/README.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/000_create_context/README.md @@ -50,16 +50,16 @@ Available in {{ site.product.short_name }} version 3.8 and later. - *process*: Only messages that are generated by the same process of a client belong to the same context, that is, messages that - have identical HOST, PROGRAM and PID values. This is + have identical `HOST`, `PROGRAM` and `PID` values. This is the default behavior of {{ site.product.short_name }} if context-scope is not specified. - *program*: Messages that are generated by the same application of a client belong to the same context, that is, messages that - have identical HOST and PROGRAM values. + have identical `HOST` and `PROGRAM` values. - *host*: Every message generated by a client belongs to the same - context, only the HOST value of the messages must be + context, only the `HOST` value of the messages must be identical. - *global*: Every message belongs to the same context. diff --git a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/README.md b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/README.md index 39c8226e..1074ca03 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/README.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/000_action/README.md @@ -113,14 +113,14 @@ when a message matching the rule is received. A log message matched rule number $.classifier.rule_id ``` - Note that currently it is not possible to add DATE, FACILITY, or + Note that currently it is not possible to add `DATE`, `FACILITY`, or SEVERITY fields to the message. When the action is used together with message correlation, the {{ site.product.short_name }} application automatically adds fields to the message based on the context-scope parameter. For example, using - context-scope=\"process\" automatically fills the HOST, PROGRAM, - and PID fields of the generated message. + context-scope=\"process\" automatically fills the `HOST`, `PROGRAM`, + and `PID` fields of the generated message. - *name*: Name of the message field set by the value element. @@ -134,7 +134,7 @@ generates a message when a message matching the rule is received. - A log message from HOST matched rule number $.classifier.rule_id + A log message from `HOST` matched rule number $.classifier.rule_id @@ -150,7 +150,7 @@ they will override the values of the original message. ### Example: Generating messages with inherited values The following action generates a message that is identical to the -original message, but its PROGRAM field is set to +original message, but its `PROGRAM` field is set to overriding-original-program-name ```xml diff --git a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/README.md b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/README.md index 287081ba..dfae2a63 100644 --- a/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/README.md +++ b/doc/_admin-guide/120_Parser/023_db_parser/004_The_syslog-ng_patterndb_format/000_patterndb/000_ruleset/002_actions/README.md @@ -32,7 +32,7 @@ generates a message when a message matching the rule is received. - A log message from HOST matched rule number $.classifier.rule_id + A log message from `HOST` matched rule number $.classifier.rule_id @@ -48,7 +48,7 @@ they will override the values of the original message. ### Example: Generating messages with inherited values The following action generates a message that is identical to the -original message, but its PROGRAM field is set to +original message, but its `PROGRAM` field is set to overriding-original-program-name ```xml diff --git a/doc/_admin-guide/130_Correlating_log_messages/001_Referencing_previous_messages_grouping-by.md b/doc/_admin-guide/130_Correlating_log_messages/001_Referencing_previous_messages_grouping-by.md index 4777ff73..ad8be8d4 100644 --- a/doc/_admin-guide/130_Correlating_log_messages/001_Referencing_previous_messages_grouping-by.md +++ b/doc/_admin-guide/130_Correlating_log_messages/001_Referencing_previous_messages_grouping-by.md @@ -11,7 +11,7 @@ macro. For example, if there are three log messages in a context, the ${HOST}@1 expression refers to the host field of the current (third) message in the context, the ${HOST}@2 expression refers to the host field of the previous (second) message in the context, ${PID}@3 to the -PID of the first message, and so on. For example, the following message +`PID` of the first message, and so on. For example, the following message can be created from SSH login/logout messages: An SSH session for ${SSH\_USERNAME}@1 from ${SSH\_CLIENT\_ADDRESS}@2 closed. Session lasted from ${DATE}@2 to ${DATE}. diff --git a/doc/_admin-guide/130_Correlating_log_messages/002_grouping-by_options.md b/doc/_admin-guide/130_Correlating_log_messages/002_grouping-by_options.md index 14798db7..d4b84ed1 100644 --- a/doc/_admin-guide/130_Correlating_log_messages/002_grouping-by_options.md +++ b/doc/_admin-guide/130_Correlating_log_messages/002_grouping-by_options.md @@ -112,14 +112,14 @@ following values are available: - *process*: Only messages that are generated by the same process of a client belong to the same context, that is, messages that have - identical HOST, PROGRAM and PID values. + identical `HOST`, `PROGRAM` and `PID` values. - *program*: Messages that are generated by the same application of a client belong to the same context, that is, messages that have - identical HOST and PROGRAM values. + identical `HOST` and `PROGRAM` values. - *host*: Every message generated by a client belongs to the same - context, only the HOST value of the messages must be identical. + context, only the `HOST` value of the messages must be identical. - *global*: Every message belongs to the same context. This is the default value. diff --git a/doc/_admin-guide/140_Enriching_log_messages_with_external_data/001_Looking_up_geoip2_data/001_Using_the_geoip2_parser.md b/doc/_admin-guide/140_Enriching_log_messages_with_external_data/001_Looking_up_geoip2_data/001_Using_the_geoip2_parser.md index f6290133..4ec03bb1 100644 --- a/doc/_admin-guide/140_Enriching_log_messages_with_external_data/001_Looking_up_geoip2_data/001_Using_the_geoip2_parser.md +++ b/doc/_admin-guide/140_Enriching_log_messages_with_external_data/001_Looking_up_geoip2_data/001_Using_the_geoip2_parser.md @@ -16,8 +16,8 @@ parser parser_name { ``` In the following example, {{ site.product.short_name }} retrieves the GeoIP2 data of the -IP address contained in the HOST field of the incoming message -(assuming that in this case the HOST field contains an IP address), +IP address contained in the `HOST` field of the incoming message +(assuming that in this case the `HOST` field contains an IP address), and includes the data (prefixed with the geoip2 string) in the output JSON message. diff --git a/doc/_admin-guide/170_Troubleshooting_syslog-ng/001_Creating_core_files.md b/doc/_admin-guide/170_Troubleshooting_syslog-ng/001_Creating_core_files.md index 779288c6..54e7a10e 100644 --- a/doc/_admin-guide/170_Troubleshooting_syslog-ng/001_Creating_core_files.md +++ b/doc/_admin-guide/170_Troubleshooting_syslog-ng/001_Creating_core_files.md @@ -25,7 +25,7 @@ To enable core files, complete the following procedure: {{ site.product.short_name }} was started from. 4. To test that {{ site.product.short_name }} can create a core file, you can create a - crash manually. For this, determine the PID of {{ site.product.short_name }} (for + crash manually. For this, determine the `PID` of {{ site.product.short_name }} (for example, using the `ps -All | grep syslog-ng` command), then issue the following command: `kill -ABRT ` diff --git a/doc/_admin-guide/170_Troubleshooting_syslog-ng/002_Collecting_debug_info.md b/doc/_admin-guide/170_Troubleshooting_syslog-ng/002_Collecting_debug_info.md index bb56f9a7..a882c7a8 100644 --- a/doc/_admin-guide/170_Troubleshooting_syslog-ng/002_Collecting_debug_info.md +++ b/doc/_admin-guide/170_Troubleshooting_syslog-ng/002_Collecting_debug_info.md @@ -28,7 +28,7 @@ In general, note the following points: The following are examples for tracing system calls of {{ site.product.short_name }} on some platforms. The output is saved into the /tmp/syslog-ng-trace.txt file, -sufficed with the PID of the related {{ site.product.short_name }} process.The path of the +sufficed with the `PID` of the related {{ site.product.short_name }} process.The path of the {{ site.product.short_name }} binary may be different for your installation, as distribution-specific packages may use different paths. diff --git a/doc/_admin-guide/180_Best_practices_and_examples/000_General_recommendations.md b/doc/_admin-guide/180_Best_practices_and_examples/000_General_recommendations.md index a95ec016..a7f6e901 100644 --- a/doc/_admin-guide/180_Best_practices_and_examples/000_General_recommendations.md +++ b/doc/_admin-guide/180_Best_practices_and_examples/000_General_recommendations.md @@ -18,9 +18,9 @@ below: - Standard log messages include the local time of the sending host, without any time zone information. It is recommended to replace this - timestamp with an ISODATE timestamp, because the ISODATE format + timestamp with an `ISODATE` timestamp, because the `ISODATE` format includes the year and timezone as well. To convert all timestamps to - the ISODATE format, include the following line in the syslog-ng + the `ISODATE` format, include the following line in the syslog-ng configuration file: ```config diff --git a/doc/_admin-guide/190_The_syslog-ng_manual_pages/001_loggen.md b/doc/_admin-guide/190_The_syslog-ng_manual_pages/001_loggen.md index dc9bd61e..37df1255 100644 --- a/doc/_admin-guide/190_The_syslog-ng_manual_pages/001_loggen.md +++ b/doc/_admin-guide/190_The_syslog-ng_manual_pages/001_loggen.md @@ -150,7 +150,7 @@ statistics: - \--sdata \ or -p \ - Send the argument of the \--sdata option as the SDATA part of + Send the argument of the \--sdata option as the `SDATA` part of IETF-syslog (RFC-5424 formatted) messages. Use it together with the \--syslog-proto option. For example: **\--sdata \"\[test name=\\\"value\\\"\]** diff --git a/doc/_admin-guide/190_The_syslog-ng_manual_pages/002_pdbtool.md b/doc/_admin-guide/190_The_syslog-ng_manual_pages/002_pdbtool.md index e4ca1979..e54ec00b 100644 --- a/doc/_admin-guide/190_The_syslog-ng_manual_pages/002_pdbtool.md +++ b/doc/_admin-guide/190_The_syslog-ng_manual_pages/002_pdbtool.md @@ -67,7 +67,7 @@ dump \[options\] Display the RADIX tree built from the patterns. This shows how are the patterns represented in {{ site.product.short_name }} and it might also help to track down pattern-matching problems. The dump utility can dump the tree used -for matching the PROGRAM or the MSG parts. +for matching the `PROGRAM` or the `MSG` parts. - \--debug or -d @@ -171,7 +171,7 @@ The match command has the following options: - \--message or -M - The text of the log message to match (only the MESSAGE part + The text of the log message to match (only the `MESSAGE` part without the syslog headers). - \--pdb or -p @@ -180,7 +180,7 @@ The match command has the following options: - \--program or -P - Name of the program to use, as contained in the PROGRAM part of + Name of the program to use, as contained in the `PROGRAM` part of the syslog message. - \--template=\ or -T diff --git a/doc/_admin-guide/190_The_syslog-ng_manual_pages/009_syslog-ng_manual.md b/doc/_admin-guide/190_The_syslog-ng_manual_pages/009_syslog-ng_manual.md index 4570a5f9..68d30846 100644 --- a/doc/_admin-guide/190_The_syslog-ng_manual_pages/009_syslog-ng_manual.md +++ b/doc/_admin-guide/190_The_syslog-ng_manual_pages/009_syslog-ng_manual.md @@ -146,7 +146,7 @@ other sources. The clients send all important log messages to the remote - \--pidfile \ or -p \ - Set path to the PID file where the pid of the main process is + Set path to the `PID` file where the pid of the main process is stored. - \--preprocess-into \ diff --git a/doc/_dev-guide/chapter_8/section_3.md b/doc/_dev-guide/chapter_8/section_3.md index b7495ca4..def07935 100644 --- a/doc/_dev-guide/chapter_8/section_3.md +++ b/doc/_dev-guide/chapter_8/section_3.md @@ -476,7 +476,7 @@ parse_ordered_list_into_log_message_no_check(const gchar *ordered_list) /* First get a copy of our parser */ cloned_parser = (LogParser *) log_pipe_clone(&ordered_parser->super); - /* Set the MESSAGE part of our dummy log message */ + /* Set the `MESSAGE` part of our dummy log message */ msg = log_msg_new_empty(); log_msg_set_value(msg, LM_V_MESSAGE, ordered_list, -1); diff --git a/doc/_dev-guide/chapter_8/section_4.md b/doc/_dev-guide/chapter_8/section_4.md index 06479ffc..349d8ced 100644 --- a/doc/_dev-guide/chapter_8/section_4.md +++ b/doc/_dev-guide/chapter_8/section_4.md @@ -3,7 +3,7 @@ title: Filter Function id: dev-plugin-dev-filter-func --- -This section will guide you through the process of creating a filter function, by going through the files of filter-length, a set of filter functions which filter log messages based on the length of their `${MESSAGE}`. `${MESSAGE}` refers to the {{ site.product.short_name }} macro and not MSG as defined by the syslog protocols. +This section will guide you through the process of creating a filter function, by going through the files of filter-length, a set of filter functions which filter log messages based on the length of their ${MESSAGE}. ${MESSAGE} refers to the {{ site.product.short_name }} macro and not `MSG` as defined by the syslog protocols. Filter functions are written under `lib/filter/`, and so they do not belong to any module and are not technically plugins. To add a filter function we only need to modify the parser and grammar files; there is no plugin file. @@ -226,7 +226,7 @@ First we need to get the message we want from the array. `num_msg` starts counti LogMessage *msg = msgs[num_msg - 1]; ``` -Now that we have our `LogMessage`, we will extract the MESSAGE part from it to evaluate its length. To do so, we call the `log_msg_get_value` function with the appropriate constant. +Now that we have our `LogMessage`, we will extract the `MESSAGE` part from it to evaluate its length. To do so, we call the `log_msg_get_value` function with the appropriate constant. ``` const gchar *message_part = log_msg_get_value(msg, LM_V_MESSAGE, NULL); ``` diff --git a/doc/_doc-guide/02_Tools/01_Self_made_tools/01_Tests/README.md b/doc/_doc-guide/02_Tools/01_Self_made_tools/01_Tests/README.md index 5511ac8b..c09ac5ac 100644 --- a/doc/_doc-guide/02_Tools/01_Self_made_tools/01_Tests/README.md +++ b/doc/_doc-guide/02_Tools/01_Self_made_tools/01_Tests/README.md @@ -33,7 +33,7 @@ text` 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.