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.

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

jmx receiver: allow setting system properties #3450

Merged

Conversation

rmfitzpatrick
Copy link
Contributor

Description:
Adding a feature - These changes add a new properties config option to allow specifying desired system properties for the groovy metric gathering script environment.

Link to tracking Issue:
open-telemetry/opentelemetry-java-contrib#33

Testing:
Unit and integration tests added/updated.

Documentation:
Config field documentation added.

@rmfitzpatrick rmfitzpatrick requested a review from a team May 21, 2021 21:08
Copy link
Contributor

@jrcamp jrcamp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

otherwise lgtm

receiver/jmxreceiver/config.go Outdated Show resolved Hide resolved
@@ -59,6 +59,9 @@ type Config struct {
RemoteProfile string `mapstructure:"remote_profile"`
// The SASL/DIGEST-MD5 realm
Realm string `mapstructure:"realm"`
// Array of property=value strings to pass as system properties when running JMX Metric Gatherer
Properties []string `mapstructure:"properties"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason not to use a map[string]string here instead? That way you don't have to parse the configuration yourself

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

viper is destructive in its case insensitivity and this avoid that issue: open-telemetry/opentelemetry-collector#2594

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I don't have enough context to judge here but it feels like the correct solution would be to fix the issue above then instead of working around it (we don't expose Viper explicitly anymore so the issue can be addressed more easily).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds fair and I've updated to a map and will try to address the underlying issue in the core project.

@rmfitzpatrick rmfitzpatrick force-pushed the jmx_receiver_system_properties branch from 52779c6 to 6573b48 Compare May 24, 2021 15:14
@rmfitzpatrick rmfitzpatrick force-pushed the jmx_receiver_system_properties branch from 6573b48 to c20c3b3 Compare May 24, 2021 15:46
@bogdandrutu bogdandrutu merged commit df252ba into open-telemetry:main May 24, 2021
alexperez52 referenced this pull request in open-o11y/opentelemetry-collector-contrib Aug 18, 2021
During receiver shutdown discovery is stopped. However, any previously
discovered targets will continue to be scraped. This calls `Stop` on the scrape
manager to stop the scraping on shutdown as well.

**Issue:** signalfx/splunk-otel-collector#471

**Testing:** 
- added check to Prometheus end to end test that scraping is actually stopped
- tested end to end with receivercreator,  saw that scraping actually stopped after pod was deleted
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants