# Syslog Accepts syslog messages sent directly over a TLS TCP connection to the Monad platform. ## Requirements There are no prerequisites to start using the Syslog input. Simply create a Syslog input and attach it to a pipeline. ## Details The Syslog input receives messages over a persistent TLS TCP connection. It is well-suited for any system or application that emits syslog output, including Linux hosts, network devices, firewalls, and custom applications. No authentication is required — the pipeline ID is embedded in the destination hostname. ## Sending data Send syslog messages over TLS to: ``` .l4.monad.com:6514 ``` Replace `` with the ID of your pipeline. ### Clients without SNI support If your client can't send Server Name Indication — for example, an older TLS library, an embedded device, or a proxy that strips SNI — you can identify the pipeline with a client certificate instead. Present a certificate whose Subject `serialNumber` field contains the pipeline UUID. Continue to connect to `.l4.monad.com:6514`: the hostname still resolves correctly even when SNI is not sent, and using the same address keeps your configuration consistent with the SNI-based setup. The certificate is **not validated** against any CA. It is used purely as a carrier for the identifier, so a self-signed cert generated locally is sufficient. Generate a client certificate with the pipeline UUID in `Subject.serialNumber`: **RSA:** ```bash openssl req -x509 -newkey rsa:2048 -nodes -days 3650 \ -subj "/serialNumber=" \ -keyout monad-client.key -out monad-client.crt ``` **ECDSA (P-256):** ```bash openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes -days 3650 \ -subj "/serialNumber=" \ -keyout monad-client.key -out monad-client.crt ``` Verify the field is set correctly: ```bash $ openssl x509 -in monad-client.crt -noout -subject subject=serialNumber = ``` Configure your TLS client to present `monad-client.crt` / `monad-client.key` when connecting. If both SNI and a client certificate are sent, SNI takes precedence — the certificate is only consulted when SNI is absent or does not contain a valid pipeline UUID. ### Clients with a fixed certificate Some appliances, firewalls, hardware loggers, etc. present a client certificate that the user cannot control, and SNI isn't available either. For these cases, you can register the certificate's SHA-256 fingerprint against the syslog input; connections presenting that certificate are then routed to the pipeline. Prefer SNI or `Subject.serialNumber` routing when either is available to you. Those need no per-device setup on the Monad side, while fingerprint registration is an extra step you'll repeat for every certificate, and have to remember to redo on any rotation or replacement. Compute the SHA-256 fingerprint over the certificate's DER encoding: ```bash openssl x509 -in device-cert.pem -outform DER | openssl dgst -sha256 -hex # SHA2-256(stdin)= 3caad52e99b4975bfec5f44ebd60e46a656db176234e78ff4011bfa7c2ddf9cc ``` Or, using the `-fingerprint` flag: ```bash openssl x509 -in device-cert.pem -noout -fingerprint -sha256 | tr -d ':' # sha256 Fingerprint=3CAAD52E99B4975BFEC5F44EBD60E46A656DB176234E78FF4011BFA7C2DDF9CC ``` Register the resulting hex string on the syslog input. The device continues to connect to `.l4.monad.com:6514`. SNI and `Subject.serialNumber` remain higher precedence — the fingerprint is consulted only when neither yields a valid pipeline UUID. ### Message framing The input follows [RFC 6587](https://www.rfc-editor.org/rfc/rfc6587) TCP framing and accepts either of the two standard framing methods: - **Octet-counted** — each message is prefixed with its byte length followed by a space: ` ` - **Non-transparent (newline-delimited)** — each message is terminated with a newline (`\n`) character Both formats can be mixed on the same connection; the input automatically detects which framing is in use for each message based on whether it starts with a digit. ### Message parsing After framing is stripped, the raw message is parsed as one of two syslog formats: #### RFC 5424 [RFC 5424](https://www.rfc-editor.org/rfc/rfc5424) is the modern IETF syslog protocol. Messages follow this structure: ``` VERSION TIMESTAMP HOSTNAME APP-NAME PROCID MSGID [STRUCTURED-DATA] MSG ``` Example: ``` <34>1 2024-01-15T10:30:00Z myhost sshd 12345 ID47 [exampleSDID@32473 iut="3" eventSource="Application"] An application event log entry ``` #### RFC 3164 [RFC 3164](https://www.rfc-editor.org/rfc/rfc3164) is the older BSD syslog format. Messages follow this structure: ``` Mmm dd hh:mm:ss HOSTNAME TAG[PID]: MSG ``` Example: ``` <34>Jan 15 10:30:00 myhost sshd[12345]: Accepted publickey for user from 192.0.2.1 ``` Detection is based on message structure: RFC 5424 is identified by a version number following the PRI; RFC 3164 is identified by a PRI or a BSD-format timestamp starting with a month abbreviation. #### Fallback for unrecognized messages If a message cannot be parsed as either RFC 5424 or RFC 3164, it is not dropped. Instead, the entire raw message is placed in the `msg` field and the event is forwarded as-is. ## Output fields Each parsed message produces a JSON object with the following fields. Fields with no value (including RFC 5424 `-` nil values) are omitted. | Field | Type | Source | Description | |---|---|---|---| | `pri` | integer | RFC 5424, RFC 3164 | Priority value encoding facility and severity. Facility = `pri / 8`, severity = `pri % 8`. | | `version` | integer | RFC 5424 only | Syslog protocol version (always `1` for RFC 5424). | | `timestamp` | string | RFC 5424, RFC 3164 | Timestamp of the event. RFC 5424 uses ISO 8601 format; RFC 3164 uses BSD format (`Mmm dd hh:mm:ss`). | | `hostname` | string | RFC 5424, RFC 3164 | Hostname, IP address, or other identifier of the originating device. | | `app-name` | string | RFC 5424, RFC 3164 | Name of the application or process that generated the message. In RFC 3164, this is the TAG field (before any `[PID]`). | | `procid` | string | RFC 5424, RFC 3164 | Process ID of the sending application, if present. | | `msgid` | string | RFC 5424 only | Message type identifier used to distinguish event classes. | | `structured-data` | object | RFC 5424 only | Key-value pairs from the structured data section, grouped by SD-ID. Each SD-ID is a key whose value is an object of parameter name/value pairs. | | `msg` | string | RFC 5424, RFC 3164, fallback | The free-form message text. For unparseable messages, this contains the entire raw message. | ### Structured data example RFC 5424 structured data like: ``` [exampleSDID@32473 iut="3" eventSource="Application"][origin ip="192.0.2.1"] ``` Is represented as: ```json { "structured-data": { "exampleSDID@32473": { "iut": "3", "eventSource": "Application" }, "origin": { "ip": "192.0.2.1" } } } ``` ## Authentication The Syslog input does not currently require authentication. The pipeline is identified either by the destination hostname (`.l4.monad.com` via SNI) or by the `Subject.serialNumber` of a client certificate (see [Clients without SNI support](#clients-without-sni-support)). Ensure that only trusted sources send to your pipeline endpoint. ## Example ### rsyslog To forward messages from rsyslog over TLS to Monad, add a rule like the following to your rsyslog configuration: ``` # /etc/rsyslog.d/99-monad.conf *.* action(type="omfwd" target=".l4.monad.com" port="6514" protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="anon") ``` ### syslog-ng ``` destination d_monad { syslog(".l4.monad.com" port(6514) transport("tls") tls(peer-verify(required-untrusted)) ); }; log { source(s_local); destination(d_monad); }; ``` ### netcat (testing) To send a quick test message using octet-counted framing: ```bash MSG='<34>1 2024-01-15T10:30:00Z myhost testapp 1234 - - Hello from Monad' echo -n "${#MSG} ${MSG}" | openssl s_client -connect .l4.monad.com:6514 -quiet ```