Moving from Splunk.

Sondar implements Splunk's HTTP Event Collector API. Anything that sends to HEC (Fluent Bit's splunk output, Vector's splunk_hec_logs sink, the OpenTelemetry Collector's splunkhec exporter, your own code) sends to Sondar once its URL and token change. We ran all three of those shippers against the product, each configured with nothing but the new URL and a Sondar collect token, and counted every event back by search.

# Fluent Bit: the splunk output, unchanged but for host and token
[OUTPUT]
    Name          splunk
    Match         *
    Host          sondar.internal
    Port          9200
    Splunk_Token  collect_<id>

Universal forwarders are the exception. A universal forwarder's [httpout] speaks Splunk's internal forwarder protocol, not the HEC event API. Send those files with the Sondar agent, or route them through one of the shippers above.

SonQL is Splunk-inspired, not Splunk-compatible. Most of a search is the same words; the rest is a known list of differences. The converter applies them and says which it applied. These five are where most of the work is:

• The count column. stats count by host becomes stats count() as count by host. Without the alias, SonQL names the column count(), and a later sort by count returns no rows and no error.
• Sort direction. SonQL sorts descending by default and Splunk ascends, so sort -x is sort by x desc. Write the direction every time.
• Renamed commands. head is limit, table is fields (comma-separated), spath is jsonpath.
• Quoted option values. Spans, durations and join types are quoted: timechart span="1h", transaction maxspan="1m", join type="inner".
• Two engines. A handful of commands (lookup, streamstats, accum, makemv) run on the other engine, which a leading search selects.

The full table, each row measured against a running instance: Splunk → SonQL.

What props.conf and transforms.conf extract becomes an extraction rule on a source type. Regex and JSON rules apply at search time on both engines, so a rule you add today also extracts the field from data indexed last month. On the default engine, CSV, key-value and XML rules do not apply at search time: the field comes back empty, with a warning that names it, rather than silently.

Indexes and field extraction

There is no importer. Nothing reads Splunk dashboard XML or savedsearches.conf, so each one is rebuilt: translate its search, save it as a report, and add it to a dashboard or an alert rule. That is the longest part of most migrations, and a good moment to retire the half nobody opens.

Dashboards · Alerts and notifications

Upload each CSV as a lookup file (Configure → External Data → Lookup File). inputlookup "hosts.csv" reads it on the default engine, and lookup joins it on search1, naming the file in full, quoted, with output in lower case. outputlookup replaces a table's contents, as Splunk's does, but does not create one, so upload before you write.