sysutils/os-splunk-hec: Add Splunk HEC Exporter plugin

[pvols79]

Introduces the os-splunk-hec plugin for forwarding native OPNsense logs to Splunk via HTTP Event Collector (HEC).

Features:

• Native GUI configuration for Splunk endpoint and token
• Multiplexing round-robin stream architecture to handle backlog recovery
• Supports system, filter, routing, dhcp, openvpn, suricata, unbound, etc.
• Native system telemetry polling (CPU, RAM, Disk, PF states)
• Native parsing of Zenarmor elasticsearch IPDR spool files
• Zero external dependencies

Important notices

Before you submit a pull request, we ask you kindly to acknowledge the following:

• [ x] I have read the contributing guidelines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [ x] I opened an issue first for non-trivial changes and linked it below.
• [x ] AI tools were used to create at least part of the code submitted herewith.

If AI was used, please disclose:

• Model used: Gemini 3.1 Pro
• Extent of AI involvement: Complete

---

Describe the problem

Splunk is used by many. Syslog is good, but I think the HTTP event collector is a far easier method for shipping logs to Splunk. I have been using syslog and I have installed the Splunk forwarder on the firewall. The HEC exporter I developed seems to be more performant.

Describe the proposed solution

I would like to see a plugin to support exporting logs over HTTP to a Splunk instance. I have developed the plugin and I am interested in sharing it with the community. It allows the admin to ship various logs over compressed HTTP to a Splunk instance.

---

Related issue

#5658

[Monviech]

(Response generated via ChatGPT 5.5, but audited by me)

I’m not really convinced by the premise here. If such an exporter is needed at all, I would have expected it to consume syslog directly rather than individually tailing and interpreting log files from a growing list of unrelated services and plugins.

The current approach couples this plugin to implementation details of Kea, Unbound, Suricata, WireGuard, Zenarmor, CrowdSec, etc. Every change to any of those can potentially require changes here as well. Realistically, I don’t see who is going to maintain all of this over time.

More fundamentally, OPNsense plugins generally rely on a FreeBSD port for their core functionality rather than implementing and carrying an entire custom daemon inside the plugin itself. I don’t think introducing a bespoke log shipping daemon maintained as part of the plugin is a good direction.

Before discussing implementation details, I think the architecture and long-term maintenance story need a much stronger justification.