Forwarder is failing to accept raw messages

[canoas]

We have been trying to update a older forwarder (https://github.com/datalust/seq-forwarder) to the new seqcli recomendation (datalust/seq-forwarder#54 (comment)) but all the raw messages are not working.
"seqcli forwarder" only works with "--pre". But the "--pre" also disables raw messages.
Older serilog clients will keep sending messages as raw.

2026-02-02T16:21:38.8534132Z [16:21:38 ERR] Client supplied a legacy raw-format (non-CLEF) payload

[nblumhardt]

Hi Jose, thanks for reaching out.

We're on board with adding some level of raw support to the new Forwarder commands 👍

It's currently missing because it's been a very long time since the most popular client libraries produced that format; even if you're stuck not being able to update to the very latest client versions, even moving to Serilog.Sinks.Seq version 3.0.0 would enable the compact: true configuration flag to produce the newer format. (Though newer versions are better :-)).

Otherwise, we can investigate adding basic raw format support in the 2026.1 version of this app, which won't be RTM for a while, but should be shipping in early previews soon. The timeline isn't super solid, but if this is the only option open to you, let us know, we'll do our best to make it happen.

[canoas]

It's almost impossible to change deployed apps at customers. We will try to implement some sort of backward mapping anyway. Don't want to change (or maintain multiple) endpoints. started already here https://github.com/DevScope/seqcli

Our ingestion strategy:
cloudflare revproxy -> sql-forwarder on azure app service -> fw/haproxy onprem -> sql-forwarder at onprem (SERILOG00) -> seq on windows (SERILOG02)
this way our instrumentation gets buffered and we have much better availability in case of network, power, maintenance downtimes at our office.

Tip:
think it would be very useful to have some sort of property injected in messages regarding de ingestion format/version to enable some sort dashboard of phasing out old sinks. E.g. raw vs glef vs otlp, ...

[nblumhardt]

@canoas I checked out your fork, it looks like it's coming together nicely. When you're happy with it, if you're interested in sending a PR I'd be happy to review/help land it.

RE your tip, I think this would be interesting to consider on the client side (e.g. an opt-in in the Seq sink, GELF input app, etc.). OpenTelemetry has already standardised some of this via the telemetry.sdk... family of resource attributes, which OTLP clients should (but seemingly don't always) send. I'll give all of this some more thought - thanks!