-
Notifications
You must be signed in to change notification settings - Fork 129
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
Add jetty.yaml to JMX scraper #1517
Conversation
…ontrib into jmx-scraper-jetty
…ontrib into jmx-scraper-jetty
@@ -136,4 +153,19 @@ private static void assertAttributedPoints( | |||
KeyValue::getKey, keyValue -> keyValue.getValue().getStringValue()))) | |||
.satisfiesExactlyInAnyOrder(assertions); | |||
} | |||
|
|||
@SuppressWarnings("unchecked") | |||
private static void assertAttributedMultiplePoints( |
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.
[for reviewer] the difference with assertAttributedPoints
is that we check all the provided assertions to all the data points, whereas assertAttributedPoints
expects to have exactly one assertion per point.
...rationTest/java/io/opentelemetry/contrib/jmxscraper/target_systems/JettyIntegrationTest.java
Outdated
Show resolved
Hide resolved
...rationTest/java/io/opentelemetry/contrib/jmxscraper/target_systems/JettyIntegrationTest.java
Outdated
Show resolved
Hide resolved
...rationTest/java/io/opentelemetry/contrib/jmxscraper/target_systems/JettyIntegrationTest.java
Outdated
Show resolved
Hide resolved
@@ -196,4 +198,27 @@ public void export( | |||
sb.http(0); | |||
} | |||
} | |||
|
|||
protected static String genericJmxJvmArguments(int port) { |
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.
Good change! However it is a bit over-complicated in my opinion. Simple StringBuilder and additional private method would be enough, no need for maps and streams. It is just my opinion :-)
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.
Yeah, I think I agree...I would have just hard coded a bunch of string concats...but I don't think it's a huge problem.
.withDockerfileFromBuilder( | ||
builder -> | ||
builder | ||
.from("jetty:11") |
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.
Did you consider upgrade to jetty 12?
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.
No, ideally we should test all those metrics on multiple versions but it's not the case for now, but it would be a nice improvement for later :-).
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.
Looks good to me, but offered a couple discussion points.
+ " -Dcom.sun.management.jmxremote.ssl=false" | ||
+ " -Dcom.sun.management.jmxremote.authenticate=false") | ||
genericJmxJvmArguments(jmxPort) | ||
// making cassandra startup faster for single node, from ~1min to ~15s |
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.
nice 👍🏻
@@ -196,4 +198,27 @@ public void export( | |||
sb.http(0); | |||
} | |||
} | |||
|
|||
protected static String genericJmxJvmArguments(int port) { |
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.
Yeah, I think I agree...I would have just hard coded a bunch of string concats...but I don't think it's a huge problem.
# Unit should not use a plural form, left as-is for compatibility with jetty.groovy | ||
# https://opentelemetry.io/docs/specs/semconv/general/metrics/#instrument-units | ||
unit: "{operations}" |
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.
Is there a reason that we're trying to keep this compatibility instead of fixing it?
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, I think this is better as a first step to stay very close to the original implementation (even if it's buggy).
The unit tests are almost copied as-is which helps us prevent any regressions and to ensure that we have the same behavior between the two implementations.
However, I think that it would be a good idea to remove this (and the other ones) as soon as possible with a separate PR that fixes the two implementations (this one in yaml and groovy) at once. This should not be a breaking change as the units are very unlikely to be relied on beyond documentation, the captured values remain the same.
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.
Giving it a second thought on this, the "we'll never be able to fix this if we perpetuate it" changed my mind and I've fixed that directly in this PR with 187ca89.
I was thinking more about the process of replicating existing tests with some fidelity than fixing small inconsistencies while we are at it when we can do it in a non-breaking way.
Adds support for
jetty
system by providing anjetty.yaml
and related tests.Part of #1362
Tests had to be slightly adapted from their groovy counterparts to make it work as expected, but captured metrics are compatible (some of them only have a few extra attributes).
Adds a
genericJmxJvmArguments
method to generate common JMX JVM arguments to remove some documentation.Bonus: