-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build Splunk sink #19
Comments
Decided to build a raw TCP sink first, since that's simpler for the time being and their initial sampling use case won't need to add any structured data. |
Reopening this now that we have structured data support and it's clear that their ideal sampling implementation will rely on it. Building a HEC sink will also provide a much better overall experience than relying on raw TCP (e.g. support for parsed fields, original host forwarding, etc). |
Signed-off-by: Stuart Broad <[email protected]>
Signed-off-by: Stuart Broad <[email protected]>
SENS-812 Adding optional flatten arg to map function Approved-by: Danny Browning
<!-- **Your PR title must conform to the conventional commit spec!** <type>(<scope>)!: <description> * `type` = chore, enhancement, feat, fix, docs * `!` = OPTIONAL: signals a breaking change * `scope` = Optional when `type` is "chore" or "docs", available scopes https://github.com/vectordotdev/vector/blob/master/.github/semantic.yml#L20 * `description` = short description of the change Examples: * enhancement(file source): Add `sort` option to sort discovered files * feat(new source): Initial `statsd` source * fix(file source): Fix a bug discovering new files * chore(external docs): Clarify `batch_size` option -->
Merge custom changes into v0.39
The first sink we need to build is for Splunk. At this stage, we only provide value to them by being in front of Splunk itself.
From our perspective, by far the most desirable Splunk integration would be with the HTTP Event Collector (HEC). There are multiple open source examples of integrations with this collector that we could work from, and it's relatively simple HTTP requests.
Based on our meeting, it sounds like they're in the process of testing the HEC and it is not yet supported in production. It seems unlikely that supporting something else would be a better decision than simply making their rollout of the HEC a dependency of their rollout of the router, but we should verify that point with them before committing to it completely.
The text was updated successfully, but these errors were encountered: