SC4S alternative: a multi-destination log routing without vendor lock-in

Splunk Connect for Syslog (SC4S) is the tool a lot of security teams use to get syslog into Splunk. And for good reason: it does a genuinely hard job well. But if your architecture has outgrown a single destination — or you're tired of paying premium SIEM prices to store data you rarely search — it's worth asking what a modern, vendor-neutral pipeline looks like. This post walks through what SC4S does, where are its limits, and what multi-destination routing unlocks for a cost-aware security team.

What SC4S does well

SC4S sits in front of Splunk and turns the chaos of real-world syslog into something usable. It receives logs from network devices, firewalls, and appliances, then filters and parses those messages, corrects the broken, non-compliant syslog that so many vendors emit, and enriches each event with the Splunk sourcetype and index metadata that Splunk needs to route correctly.

That's real value. Getting sourcetype right at the edge — instead of leaning on Splunk's expensive index-time processing — is exactly the kind of work that belongs in the collection layer.

The catch: SC4S is built for Splunk, and only Splunk

SC4S is, by design, a Splunk connector. Its entire model — setting sourcetype and index, formatting for the HTTP Event Collector — assumes the data is going to Splunk. That assumption is baked deep enough that everything else becomes a workaround.

Other destinations are hard, and the data often arrives wrong

SC4S can send to other destinations, but it's an uphill effort. Configuration is manual and fragile, and because SC4S forwards essentially plain syslog, the data frequently doesn't land in the shape the receiving system expects. One common casualty is the hostname: fields that Splunk interprets correctly can end up misattributed in another SIEM, which quietly breaks host inventory, correlation, and detection downstream.

No normalization for anything but Splunk

Beyond routing, there's the question of format. SC4S doesn't normalize data to each destination's best practices — it sends raw-ish syslog and leaves the transformation, field mapping, and schema work to you. If you want data shaped for a different SIEM, or a modern schema like OCSF, you're building and maintaining that logic by hand.

The vendor database is hard to extend

Much of SC4S's parsing power lives in its device/vendor definitions. Extending that database to cover a product it doesn't already handle requires specific syslog-ng know-how, and every addition is yours to maintain going forward. For a security team that just wants its logs parsed correctly, that's a steep tax.

A shared heritage — and where the paths diverge

Here's a detail worth knowing: SC4S is built on syslog-ng. So is Axoflow. Our CEO, Balázs Scheidler, is the original creator of syslog-ng, and Axoflow actively develops AxoSyslog, a modern syslog-ng fork. Axoflow comes from the same engineering lineage that made SC4S possible — and then takes it several steps further, past the Splunk-only ceiling. As Mark Bonsack, co-author of SC4S, and Director of SE Axoflow (retired) said:

We started SC4S with the hope of it becoming something like Axoflow turned out to be. It realizes everything users want to do when it comes to automatic data classification, curation and routing.