4.6 destination flags

content/chapter-destinations/configuring-destinations-redis/reference-destination-redis/_index.md

@@ -17,8 +17,9 @@ The `redis()` destination has the following options:
 
 *Description:* The password used for authentication on a password-protected Redis server. Available in {{% param "product.abbrev" %}} version 3.10 and later.
 
-{{% include-headless "chunk/option-destination-threaded-batching.md" %}}
+{{% include-headless "chunk/option-destination-batch-bytes.md" %}}
 
+{{% include-headless "chunk/option-destination-threaded-batching.md" %}}
 
 ## command() {#redis-option-command}
 
@@ -31,17 +32,15 @@ The `redis()` destination has the following options:
 
 Note the following points when using the `redis()` destination:
 
-  - You can use macros and templates in the parameters of the Redis command.
+- You can use macros and templates in the parameters of the Redis command.
 
-  - Currently you can use only one command in a redis() destination.
+- Currently you can use only one command in a redis() destination.
 
-  - The {{% param "product.abbrev" %}} application ignores the return value of the command. If the Redis server returns an error, {{% param "product.abbrev" %}} closes the connection.
+- The {{% param "product.abbrev" %}} application ignores the return value of the command. If the Redis server returns an error, {{% param "product.abbrev" %}} closes the connection.
 
 {{< include-headless "chunk/option-destination-diskbuffer.md" >}}
 
-{{% include-headless "chunk/option-destination-batch-bytes.md" %}}
-
-{{% include-headless "chunk/option-destination-threaded-batching.md" %}}
+{{< include-headless "chunk/option-destination-flags.md" >}}
 
 {{< include-headless "chunk/option-destination-hook.md" >}}
 

content/chapter-destinations/configuring-destinations-riemann/reference-destination-riemann/_index.md

@@ -57,7 +57,7 @@ In case the parameter is omitted, {{% param "product.abbrev" %}} defaults to the
 
 Note that the time format parameter requires:
 
-  - riemann-c-client 1.10.0 or newer
+- riemann-c-client 1.10.0 or newer
 
     In older versions of riemann-c-client, the microseconds option is not available.
 
@@ -74,13 +74,13 @@ Note that the time format parameter requires:
 
     ```
 
-  - Riemann 2.13 or newer
+- Riemann 2.13 or newer
 
     Older versions of Riemann cannot handle microseconds. No error will be indicated, however, the time of the event will be set to the timestamp when the message arrived to Riemann.
 
 
 
-## Example: Example event-time() option
+### Example: Example event-time() option
 
 ```shell
    destination d_riemann {
@@ -101,6 +101,7 @@ Note that the time format parameter requires:
 
 If an error occurs while sending the messages to the server, {{% param "product.abbrev" %}} will try to resend every message from the batch. If it does not succeed (you can set the number of retry attempts in the `retries()` option), {{% param "product.abbrev" %}} drops every message in the batch.
 
+{{< include-headless "chunk/option-destination-flags.md" >}}
 
 {{< include-headless "chunk/option-destination-hook.md" >}}
 

content/chapter-destinations/configuring-destinations-smtp/reference-destination-smtp/_index.md

@@ -6,17 +6,17 @@ weight:  100
 
 The `smtp()` sends email messages using SMTP, without needing external applications. The `smtp()` destination has the following options:
 
-{{% include-headless "chunk/smtp-option-body.md" %}}
+{{% include-headless "chunk/option-destination-batch-bytes.md" %}}
 
-{{% include-headless "chunk/smtp-option-bcc.md" %}}
+{{% include-headless "chunk/option-destination-threaded-batching.md" %}}
 
-{{% include-headless "chunk/smtp-option-cc.md" %}}
+{{% include-headless "chunk/smtp-option-bcc.md" %}}
 
-{{< include-headless "chunk/option-destination-diskbuffer.md" >}}
+{{% include-headless "chunk/smtp-option-body.md" %}}
 
-{{% include-headless "chunk/option-destination-batch-bytes.md" %}}
+{{% include-headless "chunk/smtp-option-cc.md" %}}
 
-{{% include-headless "chunk/option-destination-threaded-batching.md" %}}
+{{< include-headless "chunk/option-destination-flags.md" >}}
 
 {{% include-headless "chunk/smtp-option-from.md" %}}
 

content/chapter-destinations/configuring-destinations-stomp/reference-destination-stomp/_index.md

@@ -35,12 +35,14 @@ The `stomp()` destination has the following options:
 
 *Description:* The name of the destination (message queue) on the STOMP server. It can include macros and templates.
 
-{{< include-headless "chunk/option-destination-diskbuffer.md" >}}
-
 {{% include-headless "chunk/option-destination-batch-bytes.md" %}}
 
 {{% include-headless "chunk/option-destination-threaded-batching.md" %}}
 
+{{< include-headless "chunk/option-destination-diskbuffer.md" >}}
+
+{{% include-headless "chunk/option-destination-flags.md" %}}
+
 {{< include-headless "chunk/option-destination-hook.md" >}}
 
 ## host() {#stomp-option-host}

content/chapter-destinations/destination-loki/_index.md

@@ -43,6 +43,8 @@ The `loki()` destination has the following options.
 
 {{% include-headless "chunk/option-destination-batch-timeout.md" %}}
 
+{{% include-headless "chunk/option-destination-flags.md" %}}
+
 {{< include-headless "chunk/option-destination-grpc-keep-alive.md" >}}
 
 ## labels()

content/chapter-destinations/destination-mqtt-intro/destination-mqtt-options/_index.md

@@ -42,6 +42,7 @@ Occasionally, the reason why {{% param "product.abbrev" %}} cannot post messages
 
 {{% /alert %}}
 
+{{% include-headless "chunk/option-destination-flags.md" %}}
 
 {{% include-headless "chunk/option-mqtt-http-proxy.md" %}}
 

content/chapter-destinations/destination-slack/reference-destination-slack/_index.md

@@ -107,7 +107,7 @@ For details on how this option influences batch mode, see [http: Posting message
 |          |                                                                                |
 | -------- | ------------------------------------------------------------------------------ |
 | Type:    | string or template                                                             |
-| Default: | '${MSG} - host: ${HOST} | program: ${PROGRAM}(${PID}) | severity: ${PRIORITY}' |
+| Default: | `${MSG} - host: ${HOST} | program: ${PROGRAM}(${PID}) | severity: ${PRIORITY}` |
 
 *Description:* The plain-text summary of the Slack attachment. For details, see the [fallback option in the Slack documentation](https://api.slack.com/message-attachments).
 

content/chapter-destinations/destination-syslog-ng-otlp/_index.md

@@ -37,6 +37,8 @@ The `syslog-ng-otlp()` destination has the following options.
 
 {{< include-headless "chunk/option-destination-diskbuffer.md" >}}
 
+{{% include-headless "chunk/option-destination-flags.md" %}}
+
 {{< include-headless "chunk/option-destination-hook.md" >}}
 
 {{% include-headless "chunk/option-destination-log-fifo-size.md" %}}

content/chapter-destinations/opentelemetry/_index.md

@@ -66,6 +66,8 @@ log non_otel_to_otel_tls {
 
 {{< include-headless "chunk/option-destination-grpc-compression.md" >}}
 
+{{% include-headless "chunk/option-destination-flags.md" %}}
+
 {{< include-headless "chunk/option-destination-threaded-workers.md" >}}
 
 <!-- FIXME xinclude other common options

content/chapter-destinations/python-destination/reference-destination-python/_index.md

@@ -60,6 +60,8 @@ For details, see {{% xref "/chapter-configuration-file/python-code-external-file
 
 {{< include-headless "chunk/option-destination-diskbuffer.md" >}}
 
+{{% include-headless "chunk/option-destination-flags.md" %}}
+
 {{< include-headless "chunk/option-destination-frac-digits.md" >}}
 
 {{% include-headless "chunk/option-python-loaders.md" %}}

content/headless/chunk/option-destination-flags.md

@@ -6,14 +6,31 @@
 
 |          |                                |
 | -------- | ------------------------------ |
-| Type:    | no-multi-line, syslog-protocol |
+| Type:    | `ignore-errors`, `no-multi-line`, `no-seqnum-all`, `seqnum-all`, `syslog-protocol`, `threaded` |
 | Default: | empty set                      |
 
+*Description:* Flags influence the behavior of the destination driver.
 
+- `ignore-errors`: Silently drop messages which haven't been successfully delivered because of an unrecoverable low-level error (for example, I/O errors).
+- `no-multi-line`: The `no-multi-line` flag disables line-breaking in the messages: the entire message is converted to a single line.
+- `no-seqnum-all`: <!-- FIXME -->
+- `seqnum-all`: Available in {{% param "product.abbrev" %}} version 4.6 and later. By default, {{% param "product.abbrev" %}} follows the logic of the RFC5424 `meta.sequenceId` structured data element: it adds a sequence number to local messages, forwarded messages retain their original sequenceId.
 
-*Description:* Flags influence the behavior of the destination driver.
+    The `seqnum-all` flag adds a sequence number to every message sent to the destination, not just local messages. This also changes the behavior of the `${SEQNUM}` macro. For example:
+
+    ```shell
+    destination { syslog("127.0.0.1" port(2001) flags(seqnum-all)); };
+    ```
 
-  - *no-multi-line*: The `no-multi-line` flag disables line-breaking in the messages: the entire message is converted to a single line.
+    The output messages have increasing sequence numbers:
 
-  - *syslog-protocol*: The `syslog-protocol` flag instructs the driver to format the messages according to the new IETF syslog protocol standard (RFC5424), but without the frame header. If this flag is enabled, macros used for the message have effect only for the text of the message, the message header is formatted to the new standard. Note that this flag is not needed for the `syslog` driver, and that the `syslog` driver automatically adds the frame header to the messages.
+    ```shell
+    <13>1 2023-12-09T21:51:30+00:00 localhost sdff - - [meta sequenceId="1"] f sdf fsd
+    <13>1 2023-12-09T21:51:32+00:00 localhost sdff - - [meta sequenceId="2"] f sdf fsd
+    <13>1 2023-12-09T21:51:32+00:00 localhost sdff - - [meta sequenceId="3"] f sdf fsd
+    <13>1 2023-12-09T21:51:32+00:00 localhost sdff - - [meta sequenceId="4"] f sdf fsd
+    <13>1 2023-12-09T21:51:32+00:00 localhost sdff - - [meta sequenceId="5"] f sdf fsd
+    ```
 
+- `syslog-protocol`: The `syslog-protocol` flag instructs the driver to format the messages according to the new IETF syslog protocol standard (RFC5424), but without the frame header. If this flag is enabled, macros used for the message have effect only for the text of the message, the message header is formatted to the new standard. Note that this flag is not needed for the `syslog` driver, and that the `syslog` driver automatically adds the frame header to the messages.
+- `threaded`: The `threaded` flag enables multithreading for the current destination, even if the global `threaded()` option is set to `no`. Applies only to destinations that support multithreaded processing. For more information on multithreading, see {{% xref "/chapter-multithreading/configuring-multithreading/_index.md#example-enabling-multithreading" %}}.

content/headless/chunk/option-source-flags.md

@@ -4,32 +4,26 @@
 
 ## flags()
 
-|          |                                                                                                                                                                                |
-| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+|          |       |
+| -------- | ----- |
 | Type:    | assume-utf8, empty-lines, expect-hostname, kernel, no-hostname, no-multi-line, no-parse, sanitize-utf8, store-legacy-msghdr, store-raw-message, syslog-protocol, validate-utf8 |
-| Default: | empty set                                                                                                                                                                      |
+| Default: | empty set |
 
 *Description:* Specifies the log parsing options of the source.
 
-  - *assume-utf8*: The `assume-utf8` flag assumes that the incoming messages are UTF-8 encoded, but does not verify the encoding. If you explicitly want to validate the UTF-8 encoding of the incoming message, use the `validate-utf8` flag.
+- *assume-utf8*: The `assume-utf8` flag assumes that the incoming messages are UTF-8 encoded, but does not verify the encoding. If you explicitly want to validate the UTF-8 encoding of the incoming message, use the `validate-utf8` flag.
+- *empty-lines*: Use the `empty-lines` flag to keep the empty lines of the messages. By default, {{% param "product.abbrev" %}} removes empty lines automatically.
+- *expect-hostname*: If the `expect-hostname` flag is enabled, {{% param "product.abbrev" %}} will assume that the log message contains a hostname and parse the message accordingly. This is the default behavior for TCP sources. Note that pipe sources use the `no-hostname` flag by default.
+- *guess-timezone*: 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*: The `kernel` flag makes the source default to the `LOG_KERN | LOG_NOTICE` priority if not specified otherwise.
+- *no-header*: The `no-header` flag triggers {{% param "product.abbrev" %}} to parse only the `PRI` field of incoming messages, and put the rest of the message contents into `$MSG`.
 
-  - *empty-lines*: Use the `empty-lines` flag to keep the empty lines of the messages. By default, {{% param "product.abbrev" %}} removes empty lines automatically.
-
-  - *expect-hostname*: If the `expect-hostname` flag is enabled, {{% param "product.abbrev" %}} will assume that the log message contains a hostname and parse the message accordingly. This is the default behavior for TCP sources. Note that pipe sources use the `no-hostname` flag by default.
-
-  - *guess-timezone*: 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*: The `kernel` flag makes the source default to the `LOG_KERN | LOG_NOTICE` priority if not specified otherwise.
-
-  - *no-header*: The `no-header` flag triggers {{% param "product.abbrev" %}} to parse only 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.
-    
+
     {{% alert title="Note" color="info" %}}
 Essentially, the `no-header` flag signals {{% param "product.abbrev" %}} 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`.
     {{% /alert %}}
-
-
+
     ### Example: using the no-header flag with the syslog-parser() parser
 
     The following example illustrates using the `no-header` flag with the `syslog-parser()` parser:
@@ -41,9 +35,8 @@ Essentially, the `no-header` flag signals {{% param "product.abbrev" %}} that th
           );
         };
     ```
-
 
-  - *no-hostname*: Enable the `no-hostname` flag if the log message does not include the hostname of the sender host. That way {{% param "product.abbrev" %}} assumes that the first part of the message header is ${PROGRAM} instead of ${HOST}. For example:
+- *no-hostname*: Enable the `no-hostname` flag if the log message does not include the hostname of the sender host. That way {{% param "product.abbrev" %}} assumes that the first part of the message header is ${PROGRAM} instead of ${HOST}. For example:
 
     ```shell
         source s_dell {
@@ -54,21 +47,17 @@ Essentially, the `no-header` flag signals {{% param "product.abbrev" %}} that th
         };
     ```
 
-  - *no-multi-line*: The `no-multi-line` flag disables line-breaking in the messages: the entire message is converted to a single line. Note that this happens only if the underlying transport method actually supports multi-line messages. Currently the `file()` and `pipe()` drivers support multi-line messages.
+- *no-multi-line*: The `no-multi-line` flag disables line-breaking in the messages: the entire message is converted to a single line. Note that this happens only if the underlying transport method actually supports multi-line messages. Currently the `file()` and `pipe()` drivers support multi-line messages.
+- *no-parse*: By default, {{% param "product.abbrev" %}} parses incoming messages as syslog messages. The `no-parse` flag completely disables syslog message parsing and processes the complete line as the message part of a syslog message. The {{% param "product.abbrev" %}} 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 message (available using the `${MESSAGE}` macro). This flag is useful for parsing messages not complying to the syslog format.
 
-  - *no-parse*: By default, {{% param "product.abbrev" %}} parses incoming messages as syslog messages. The `no-parse` flag completely disables syslog message parsing and processes the complete line as the message part of a syslog message. The {{% param "product.abbrev" %}} 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 message (available using the `${MESSAGE}` macro). This flag is useful for parsing messages not complying to the syslog format.
-
     {{% include-headless "chunk/para-flags-no-parse.md" %}}
 
-  - *dont-store-legacy-msghdr*: By default, AxoSyslog 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 (AxoSyslog automatically corrects minor header errors, for example, adds a whitespace before `msg` in the following message: `Jan 22 10:06:11 host program:msg`). If you do not want to store the original header of the message, enable the `dont-store-legacy-msghdr` flag.
+- *dont-store-legacy-msghdr*: By default, AxoSyslog 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 (AxoSyslog automatically corrects minor header errors, for example, adds a whitespace before `msg` in the following message: `Jan 22 10:06:11 host program:msg`). If you do not want to store the original header of the message, enable the `dont-store-legacy-msghdr` flag.
 
-  - *sanitize-utf8*: When using the `sanitize-utf8` flag, {{% param "product.abbrev" %}} converts non-UTF-8 input to an escaped form, which is valid UTF-8.
+- *sanitize-utf8*: When using the `sanitize-utf8` flag, {{% param "product.abbrev" %}} converts non-UTF-8 input to an escaped form, which is valid UTF-8.
+- *store-raw-message*: Save the original message as received from the client in the `${RAWMSG}` macro. You can forward this raw message in its original form to another AxoSyslog node using the [`syslog-ng()` destination]({{< relref "/chapter-destinations/destination-syslog-ng/_index.md" >}}), or to a SIEM system, ensuring that the SIEM can process it. Available only in 3.16 and later.
+- *syslog-protocol*: The `syslog-protocol` flag specifies that incoming messages are expected to be formatted according to the new IETF syslog protocol standard (RFC5424), but without the frame header. Note that this flag is not needed for the `syslog` driver, which handles only messages that have a frame header.
 
-  - *store-raw-message*: Save the original message as received from the client in the `${RAWMSG}` macro. You can forward this raw message in its original form to another AxoSyslog node using the [`syslog-ng()` destination]({{< relref "/chapter-destinations/destination-syslog-ng/_index.md" >}}), or to a SIEM system, ensuring that the SIEM can process it. Available only in 3.16 and later.
+- *validate-utf8*: The `validate-utf8` flag enables encoding-verification for messages formatted according to the new IETF syslog standard (for details, see {{% xref "/chapter-concepts/concepts-message-structure/concepts-message-ietfsyslog/_index.md" %}}). If the BOM character is missing, but the message is otherwise UTF-8 compliant, {{% param "product_name" %}} automatically adds the BOM character to the message.
 
-  - *syslog-protocol*: The `syslog-protocol` flag specifies that incoming messages are expected to be formatted according to the new IETF syslog protocol standard (RFC5424), but without the frame header. Note that this flag is not needed for the `syslog` driver, which handles only messages that have a frame header.
-
-  - *validate-utf8*: The `validate-utf8` flag enables encoding-verification for messages formatted according to the new IETF syslog standard (for details, see {{% xref "/chapter-concepts/concepts-message-structure/concepts-message-ietfsyslog/_index.md" %}}). If the BOM character is missing, but the message is otherwise UTF-8 compliant, AxoSyslog automatically adds the BOM character to the message.
-
     {{% include-headless "chunk/para-bom-definition.md" %}}
-