Create OPNsense plugin to export to Splunk using HTTP Event Collector

[pvols79]

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

• [x ] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [x ] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [ x] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
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 solution you'd like
I would like to see a plugin to support exporting logs over HTTP to a Splunk instance.

Describe alternatives you've considered
I have developed the plugin and I am interested in sharing it with the community.

Additional context

[AdSchellevis]

I'm not a Splunk user myself, but isn't syslog-ng offering the hec format natively?

https://syslog-ng.github.io/admin-guide/070_Destinations/260_Splunk/000_Splunk-hec-event.html

[pvols79]

I did not realize that syslog-ng had added this capability. That seems to be something that would work quite well, however, the plugin provides the necessary configuration from the GUI. The whole point for me is to make enabling log shipping to Splunk super easy. I don't want admins to have to modify config files for syslog-ng through the CLI. I also do not think it is any easier or better to expose configuration in the GUI for syslog-ng than to allow users to choose this export plugin.

The plugin scans the system for available logs so users can easily choose logs that actually exist on their system.

[AdSchellevis]

You can always host the plugin yourself, but from a maintenance perspective it's just not very likely to meet the bar to be included in our repository as my colleague also noted.

Offering a target type in the already existing syslog remote configuration might be a more feasible option.