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

Add jetty.yaml to JMX scraper #1517

Merged
merged 18 commits into from
Nov 4, 2024
Merged

Conversation

SylvainJuge
Copy link
Contributor

@SylvainJuge SylvainJuge commented Oct 24, 2024

Adds support for jetty system by providing an jetty.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:

@@ -136,4 +153,19 @@ private static void assertAttributedPoints(
KeyValue::getKey, keyValue -> keyValue.getValue().getStringValue())))
.satisfiesExactlyInAnyOrder(assertions);
}

@SuppressWarnings("unchecked")
private static void assertAttributedMultiplePoints(
Copy link
Contributor Author

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.

@SylvainJuge SylvainJuge marked this pull request as ready for review October 24, 2024 14:34
@SylvainJuge SylvainJuge requested a review from a team as a code owner October 24, 2024 14:34
@@ -196,4 +198,27 @@ public void export(
sb.http(0);
}
}

protected static String genericJmxJvmArguments(int port) {
Copy link
Contributor

@robsunday robsunday Oct 28, 2024

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 :-)

Copy link
Contributor

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")
Copy link
Contributor

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?

Copy link
Contributor Author

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 :-).

Copy link
Contributor

@breedx-splk breedx-splk left a 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
Copy link
Contributor

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) {
Copy link
Contributor

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.

Comment on lines 10 to 12
# 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}"
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@trask trask merged commit df4960b into open-telemetry:main Nov 4, 2024
14 checks passed
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