Describe the feature
A standalone, remotely-configurable external collector that listens for logs pushed by on-prem sources, tags each event with its dataType, and forwards the raw payload to the SIEM. Listeners are defined by config pushed from the backend — no static allowlist, no recompile to add a source. This is what enables user-defined custom integrations: a new integration becomes a pushed listener definition instead of a code change.
Listeners:
- Syslog — UDP / TCP / TLS
- Raw TCP/UDP — arbitrary port
- NetFlow / IPFIX — UDP
- HTTP(S) — webhook / HEC-style
Use Case
Today syslog listening is baked into the agent with a hardcoded allowlist (ValidateModuleType + ProtoPorts). Adding any new listener — even a plain syslog source on a custom port — requires editing that switch and recompiling and redeploying the agent. There is no way to stand up a new source from the panel, so custom integrations are effectively impossible for users. A config-driven external collector removes that limitation.
Proposed Solution
A dedicated collector process that owns no static source list. The backend pushes listener definitions; the collector reconciles them at runtime (bind/unbind, port change, enable/disable) and forwards raw events upstream over the existing ProcessLog channel.
The HTTP listener generalizes the existing GitHub-webhook handler (plugins/inputs/handlers.go): accept a raw external body, wrap it into a Log tagged with the listener's dataType, and forward — rather than expecting a pre-formed Log proto like /v1/logs does.
Other Information
No response
Acknowledgements
Describe the feature
A standalone, remotely-configurable external collector that listens for logs pushed by on-prem sources, tags each event with its
dataType, and forwards the raw payload to the SIEM. Listeners are defined by config pushed from the backend — no static allowlist, no recompile to add a source. This is what enables user-defined custom integrations: a new integration becomes a pushed listener definition instead of a code change.Listeners:
Use Case
Today syslog listening is baked into the agent with a hardcoded allowlist (
ValidateModuleType+ProtoPorts). Adding any new listener — even a plain syslog source on a custom port — requires editing that switch and recompiling and redeploying the agent. There is no way to stand up a new source from the panel, so custom integrations are effectively impossible for users. A config-driven external collector removes that limitation.Proposed Solution
A dedicated collector process that owns no static source list. The backend pushes listener definitions; the collector reconciles them at runtime (bind/unbind, port change, enable/disable) and forwards raw events upstream over the existing
ProcessLogchannel.{ "kind": "syslog", "dataType": "firewall-sonicwall", "bind": { "proto": "tcp", "port": 7009, "tls": true }, "enabled": true }The HTTP listener generalizes the existing GitHub-webhook handler (
plugins/inputs/handlers.go): accept a raw external body, wrap it into aLogtagged with the listener'sdataType, and forward — rather than expecting a pre-formedLogproto like/v1/logsdoes.Other Information
No response
Acknowledgements