Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[receiver/splunkenterprise] Add Attributes to track Build & Version Data #36330

Open
michael-burt opened this issue Nov 12, 2024 · 6 comments · May be fixed by #37508
Open

[receiver/splunkenterprise] Add Attributes to track Build & Version Data #36330

michael-burt opened this issue Nov 12, 2024 · 6 comments · May be fixed by #37508
Labels
enhancement New feature or request receiver/splunkenterprise Stale

Comments

@michael-burt
Copy link
Contributor

Component(s)

No response

Is your feature request related to a problem? Please describe.

I would like to attach splunkd_build and splunkd_version attributes to metrics being emitted by the Splunk Enterprise Receiver. I am unsure whether these should be added as "Resource Attributes" or just normal "Attributes". These peices of metadata about the Splunk host are available on the /services/server/info API endpoint.

Describe the solution you'd like

I think these pieces of data should be added as either attributes or resource attributes.

Describe alternatives you've considered

I have implemented a new collector to emit this data as a metric, see here: #36118

Upon reflection, this does not seem like the correct approach. This data is useful when processing all metrics emitted by this receiver, not just the info metric.

Additional context

No response
@michael-burt michael-burt added enhancement New feature or request needs triage New item requiring triage labels Nov 12, 2024
@github-actions GitHub Actions
Copy link
Contributor

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@atoulme atoulme removed the needs triage New item requiring triage label Nov 12, 2024
@shalper2
Copy link
Contributor

I think this will be a good enhancement. A couple notes: I think to begin with we will want to have this set to off by default. This way existing users who don't care about these attributes don't suddenly get flooded with a bunch more data. Second, I don't think it would make sense to have these attributes be updated every time the scrape function is called, however we do have to imagine that version and build info could change during the lifetime of the collector instance so we must update it occasionally. I propose we scrape this information on a hardcoded, relatively lengthy interval. Perhaps every 60m? Thoughts on this? Any other considerations?

@michael-burt
Copy link
Contributor Author

For my use case, 60m may be too long to wait. Could this be a configurable setting perhaps? I don't think it would put too much load on Splunk to fetch this data on every scrape by the receiver, either.

@shalper2
Copy link
Contributor

I think that is definitely possible. Good to know re: load on Splunk

@github-actions github-actions bot mentioned this issue Nov 19, 2024
Closed
@shalper2
Copy link
Contributor

so because of the way the client is designed (i.e. it may contain several endpoints) I think I'm going to have to go back on my word here and just have build and version attached as attributes

@github-actions GitHub Actions
Copy link
Contributor

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 @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

See Adding Labels via Comments if you do not have permissions to add labels yourself.

@github-actions github-actions bot added the Stale label Jan 21, 2025
@shalper2 shalper2 linked a pull request Jan 27, 2025 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request receiver/splunkenterprise Stale
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

36330 bi as attrs shalper2/opentelemetry-collector-contrib
3 participants
@atoulme @michael-burt @shalper2