-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[SplunkHECExporter] Add ability to heartbeating destination #19220
Comments
I am picking up this work and hoping to get some guidance. I am thinking of two approaches for the part to emit observability data for the heartbeat:
@atoulme @dmitryax do you have any advices on the approaches? |
The target audience of the contrib components is the end users. Let's keep it that way end expose only user-configurable options, not programmatic. So let's add the observability data right in the exporter. The exporter already has cc @wojtekzyla who introduced that option |
The Agree on starting from the user config first. I would recommend we look at two additional config entries under a heartbeat key with the following defaults:
We generate the log message to send based off |
Is that the case? IFAIU, the goal is still to validate the destination, according to @splunkericl, no?
I'd like to reuse the configuration field for something serving the same purpose. It's better to avoid adding new fields if they are not strictly necessary to reduce the mental load on the end user |
Yeah the destination still needs to be validated. So if I understand correctly, we can:
|
You're using interchangeably healthcheck and heartbeat. This is creating confusion. These are not the same thing.
|
There are some similarities between
So if it makes sense, we can put the |
These are distinct concepts, and we'd want to toggle them on and off separately in my opinion. It doesn't look like heartbeat data is dummy data to me. It looks like diagnostic data sent to upstream so that operations can check that the collector is reporting in properly, even when no data is being sent. With that, my definition of
|
That is fair. I think this definition makes sense and we should separate the configuration between |
This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping Pinging code owners: See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Closing as done |
Is your feature request related to a problem? Please describe.
In Edge Processor(EP), it is possible the EP of a customer would have very low traffic for some periods of time. EP adds the ability to heartbeat the destination periodically to check the validity of the destination. For example, the S3 exporter in EP periodically calls listObjects to validate the credentials are still valid.
One of the requirement to incorporate SplunkHECExporter into Edge Processor(EP) is to adds this heart-beating ability to SplunkHECExporter and adds observability data on top of it.
Describe the solution you'd like
Add an configuration option to allow heartbeating in
SplunkHECExporter
. If enabled the exporter would spawn a go routine that periodically sends dummy info to the destination. The dummy info can be similar to how a splunk forwarder is sending:_internal
index so it would work out of the box.Describe alternatives you've considered
We can leverage the heartbeat information by checking how many events were sent successfully. However, this doesn't address the users that won't have data sent for a while.
The text was updated successfully, but these errors were encountered: