logger is the command, here is a nice overview (with CLI options shown at the bottom).

Syslog has two widespread formats, RFC 3164 (DMS prior to v14), and RFC 5424 (DMS v14 onwards default), where most should be using the proper standard RFC 5424. The priority value represents the combined facility (most services in DMS should be using mail IIRC) and the severity (your log levels).

Here is some stripped down reference from my Vector PR:

enum Severity {
    Emergency = 0,
    Alert = 1,
    Critical = 2,
    Error = 3,
    Warning = 4,
    Notice = 5,
    #[default]
    Informational = 6,
    Debug = 7,
}

enum Facility {
    Kern = 0,
    #[default]
    User = 1,
    Mail = 2,
    Daemon = 3,
    Auth = 4,
    Syslog = 5,
    LPR = 6,
    News = 7,
    UUCP = 8,
    Cron = 9,
    AuthPriv = 10,
    FTP = 11,
    NTP = 12,
    Security = 13,
    Console = 14,
    SolarisCron = 15,
    Local0 = 16,
    Local1 = 17,
    Local2 = 18,
    Local3 = 19,
    Local4 = 20,
    Local5 = 21,
    Local6 = 22,
    Local7 = 23,
}

// Example (Priority value for `Facility::Mail` + `Severity::Error` is `19`):
// `(2 * 8) + 3` or `(2 << 3) + 3` (bitwise shift instead of multiplication)
let priority = (self.facility as u8 * 8) + self.severity as u8;

Nevermind that, logger --priority mail.error is supported as a more friendly way for you to use, no math needed 😅 (use the relevant supported log levels from the collapsed snippet though)

Examples:

# RFC 5424 format (notq omits the structured data regarding time, msgid is rfc5424 only):
logger --rfc5424=notq --priority mail.error --id=1337 --msgid=hello --tag dms-changedetector "This is an example error message!"
<19>1 2024-05-26T11:45:28.305480+00:00 mail.example.test dms-changedetector 1337 hello - This is an example error message!

# Old RFC 3164 format (lacks a year, assumes present year):
logger --rfc3164 --priority mail.error --id=1337 --tag dms-changedetector "This is an example error message!"
<19>May 26 11:45:27 mail dms-changedetector[1337]: This is an example error message!

• Use --stderr with the above logger command examples to get the output to stderr.
• If you don't use notq, you'll get some metadata for a log ingester to have about quality of the timestamps ([timeQuality tzKnown="1" isSynced="1" syncAccuracy="157"]), this is Structured Data from RFC5424, doesn't really exist for prior RFC 3164.
• --tag is the service name like amavis or postfix. Despite the linked resource examples, do not use spaces, that makes the log ambiguous to parse. The RFC document has a breakdown for supported tokens and expected sequence format.
• --id isn't really needed, it's the PID by default logger omits it, PID of the logger command as default requires --id. Note that --id 42 is not valid, that's --id then 42 as part of the message rather than as part of --id, make sure assignments for the option have = 😑 (-i seems to be equivalent to --id too?)
• --rfc5424 is not being parsed properly by rsyslog in :edge, stick to --rfc3164

UPDATE: Nevermind. I thought logger would be appropriate, but regardless of syslog format used, rsyslog is not stripping away some of the data like expected:

# RFC 3164 followed by RFC 5424

# v13.3:
May 26 11:51:14 mail mail dms-changedetector[1337]: This is an example error message!
May 26 11:55:07 mail 1 2024-05-26T11:55:07.509942+00:00 mail.example.test dms-changedetector 1337 - - This is an example error message!

# v14
2024-05-26T12:05:58.700336+00:00 mail mail dms-changedetector[1337]: This is an example error message!
2024-05-26T12:17:07.824094+00:00 mail 1 2024-05-26T12:17:07.824035+00:00 mail.example.test dms-changedetector 1337 hello - This is an example error message!

Pretty sure on a related PR I discussed this and documented the rsyslog config. Perhaps we should address that before pushing out v14 to use the syslog format? (I was under the impression it was effectively the same as the two but omitted the priority value, and for RFC 5424 the syslog version, eg <19>1)

Seems like I made a note of this on the rsyslog changelog entry actually 🤔

So just to clarify, your change here won't exactly line up to rsyslog format

• You are using a two space delimiter.
• You skip the host.
• Your timestamp won't match.
• You add your own log level (but so do other services with their message, so.._ 🤷‍♂️ )

Personally I prefer the current DMS log output which is more easier to distinguish if it's not going to align with rsyslog for log parsing (_at least with the current log output, you know that if the line starts with [ it's probably emitted by DMS, otherwise if a valid timestamp is the starting portion it's more than likely from rsyslog from one of the services we run. Anything else is usually stderr or similar and could be filtered separately.

Approving this change if you still feel you want to go through with it as-is, but you should wait for @casperklein to provide input too.

I actually never tried to be rsyslog-compatible, but if you and @casperklein think it'd be a good idea, I can make that happen.

I think it could be nice, but proper approach is to use logger as described above, which will require messing with rsyslog config to properly ingest.

As I want to replace rsyslog with Vector in future I don't know if it's worth your time to integrate with rsyslog, but if you can make it work that'd be cool 👍