-
Notifications
You must be signed in to change notification settings - Fork 130
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
Reuse JMX Insights in Scraper + Tomcat support #1485
Conversation
jmx-scraper/src/main/java/io/opentelemetry/contrib/jmxscraper/JmxScraper.java
Outdated
Show resolved
Hide resolved
jmx-scraper/src/main/java/io/opentelemetry/contrib/jmxscraper/JmxScraper.java
Outdated
Show resolved
Hide resolved
throw new IllegalStateException("no support for " + system); | ||
} | ||
} catch (Exception e) { | ||
throw new IllegalStateException("error while loading rules for system " + system, e); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other exception would be better here as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll leave this one as-is for now, as we don't have dedicated runtime exceptions, but this could be an improvement later.
private int intervalMilliseconds; | ||
private String metricsExporterType = ""; | ||
private String otlpExporterEndpoint = ""; | ||
private int intervalMilliseconds; // TODO only used to set 'otel.metric.export.interval' from SDK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What this TODO means here? Is there anything aditional to be implemented?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, basically this configuration option is only used to configure the metrics polling interval and there is already a dedicated configuration option in the SDK for this, so if someone is used to configure the SDK using this one we should reuse the existing config option (we'll deal with that when adding auto-configuration here).
…ontrib into scraper-connect
...craper/src/integrationTest/java/io/opentelemetry/contrib/jmxscraper/JmxScraperContainer.java
Show resolved
Hide resolved
...est/java/io/opentelemetry/contrib/jmxscraper/target_systems/TargetSystemIntegrationTest.java
Show resolved
Hide resolved
@robsunday I have just added support for both the JVM metrics and the Tomcat metrics with tests from Gatherer, so we have end-to-end testing now 🎉. If you have some time for another review that would be great ! |
...craper/src/integrationTest/java/io/opentelemetry/contrib/jmxscraper/JmxScraperContainer.java
Show resolved
Hide resolved
...est/java/io/opentelemetry/contrib/jmxscraper/target_systems/TargetSystemIntegrationTest.java
Show resolved
Hide resolved
In the context of integration tests, we always want to send data to otlp as otherwise we don't have a way to validate what it's captured, this is not meant to be a reusable test container outside of those integration tests. For the filtering on the metrics, there was a filter on the metrics that are sent with a specific sdk version, now that we reuse code from instrumentation we do not get the project version as we used to have, but the version of the instrumentation project which is used as dependency. |
sorry @robsunday, I hit the wrong button and re-requested a review from you, which also cleared your approval, can you re-approve? and let me know if there are any outstanding discussions, and if not I'll merge, thanks! |
@SylvainJuge sorry, can you fix up the merge conflicts from #1480? thanks! |
@@ -35,15 +44,25 @@ public class JmxScraper { | |||
*/ | |||
@SuppressWarnings({"SystemOut", "SystemExitOutsideMain"}) | |||
public static void main(String[] args) { | |||
|
|||
// enable SDK auto-configure if not explicitly set by user | |||
// TODO: refactor this to use AutoConfiguredOpenTelemetrySdk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
// TODO: remove snapshot repository once 2.9.0 is released | ||
maven { | ||
setUrl("https://oss.sonatype.org/content/repositories/snapshots") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm merging anyways since
- the
jmx-scraper
artifact isn't published yet so no worries about relying on snapshot repo from maven central - merging will unblock other work
- we expect to update this to 2.9.0 within a week
@@ -76,6 +76,7 @@ public void start() { | |||
// for now only configure through JVM args | |||
List<String> arguments = new ArrayList<>(); | |||
arguments.add("java"); | |||
arguments.add("-Dotel.metrics.exporter=otlp"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes sense to align (long-term) if possible with the autoconfigure SDK defaults
Description:
Part of #1362
Testing:
Integration tests from JMX Gatherer almost copied as-is for
jvm
andtomcat
systems.Manual testing on a local tomcat server started with following JVM options in
bin/setenv.sh
Scraper started with command line (in the
./jmx-scraper
subfolder as working directory).The explicit
otel.exporter.otlp.endpoint
andotel.metrics.exporter
Java system properties are needed due to a check in the configuration parsing (and they aren't yet read from the env variables), but this will later be refactored to use auto-configuration in a later PR to solve this.