-
Notifications
You must be signed in to change notification settings - Fork 771
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 JSON export option #4435
Add JSON export option #4435
Conversation
import okhttp3.RequestBody; | ||
import okio.BufferedSink; | ||
|
||
public class JsonRequestBody extends RequestBody { |
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.
Pretty much a copy paste of ProtoResponseBody
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 believe this can be package private, and final. (ProtoResponseBody
can be package private as well.)
Codecov Report
@@ Coverage Diff @@
## main #4435 +/- ##
============================================
- Coverage 90.02% 90.02% -0.01%
- Complexity 4970 4979 +9
============================================
Files 570 571 +1
Lines 15384 15401 +17
Branches 1472 1473 +1
============================================
+ Hits 13850 13864 +14
- Misses 1064 1067 +3
Partials 470 470
Continue to review full report at Codecov.
|
I have signed the CLA, not sure when the PR will update with that fact though. |
|
||
/** Creates a new {@link JsonRequestBody}. */ | ||
public JsonRequestBody(Marshaler marshaler) { | ||
preserializedJson = preserializeJson(marshaler); |
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.
Initially I wanted to save off the marshaler like ProtoResponseBody does and substitute writeBinaryTo() with writeJsonTo() in the overridden writeTo() method below. However there wasn't an equivalent method for getting the contentLength like ProtoResponseBody does in its constructor, so this seemed like the simplest way to do this with the existing code at my disposal.
I copied the implementation from MarshalerUtil.preserializeJsonFields()
but omit the part that trims the beginning and ending brackets.
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.
How about just sticking with -1
for contentLength
without preserializing?
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.
Interesting. I initially didn't think we could leave the contentLength unset because we do some validation on our end to see that it is a positive value. But I don't see anything in the spec that indicates the Content-Length
header must be set and I don't see anything in our code that relies on it other than for monitoring. Asking my team for any context around this choice, but so far I'm inclined to do as you suggest and return -1.
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.
Though, might I ask, is there a downside to leaving this as is? I think it's just a matter of when this serialization logic gets called. It's a bit wasteful to do it this way as there is an extra copy cost to transfer the bytes into the final buffer, but I don't think by very much.
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.
It's not a big deal either way if only for tests - but OkHttp's intended usage is to "do work" on its I/O thread, so it's a bit more correct to do serialization within writeTo
, whereas preserialization in the constructor is serializing on the hot path in principle (not if it's a test, but otherwise it would be).
Using these changes locally I was able to verify that it exports as proper JSON that can be parsed by our consumers. |
/easycla |
\easycla |
easycla |
4d66f31
to
0d2b580
Compare
@@ -117,6 +117,11 @@ public OtlpHttpMetricExporterBuilder setAggregationTemporality( | |||
return this; | |||
} | |||
|
|||
OtlpHttpMetricExporterBuilder exportAsJson() { |
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.
not exposing as a public API. Keeping the one on OkHttpExporterBuilder public though for testing purposes.
@@ -70,4 +70,9 @@ public static ExporterMetrics createGrpcOkHttp(String type, MeterProvider meterP | |||
public static ExporterMetrics createHttpProtobuf(String type, MeterProvider meterProvider) { | |||
return new ExporterMetrics(meterProvider.get("io.opentelemetry.exporters.otlp-http"), type); | |||
} | |||
|
|||
public static ExporterMetrics createHttpJson(String type, MeterProvider meterProvider) { |
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.
Since this is only really for testing anyways, we probably don't need a separate metrics for it
|
||
/** Creates a new {@link JsonRequestBody}. */ | ||
public JsonRequestBody(Marshaler marshaler) { | ||
preserializedJson = preserializeJson(marshaler); |
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.
How about just sticking with -1
for contentLength
without preserializing?
…ontentLength instead of preserializing.
0d2b580
to
4fdbc5c
Compare
README.md
Outdated
| Logs SDK | v<!--VERSION_UNSTABLE-->1.15.0-SNAPSHOT-alpha<!--/VERSION_UNSTABLE--> | | ||
| Prometheus Metrics Exporter | v<!--VERSION_UNSTABLE-->1.15.0-SNAPSHOT-alpha<!--/VERSION_UNSTABLE--> | | ||
| OpenTracing Bridge | v<!--VERSION_UNSTABLE-->1.15.0-SNAPSHOT-alpha<!--/VERSION_UNSTABLE--> | | ||
| OpenCensus Bridge | v<!--VERSION_UNSTABLE-->1.15.0-SNAPSHOT-alpha<!--/VERSION_UNSTABLE--> | |
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.
yikes, idk what's going on with this and all of the apidiffs
updates. This is what the ./gradlew check
did...
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.
Sorry about that @jonahaapala, you got caught in a race condition with our release. I pushed a commit to this branch to pull in HEAD to fix it
…nto jhaapala/add-json-export-option
@anuraaga thanks for the review! What are the next steps now that you've approved? I don't have the ability to merge this. Are we waiting on more approvers? |
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.
Just the minor comment about package privacy.
I am working on adding JSON support for the New Relic OTLP Metrics consumer and while writing functional tests (written in Java) to exercise the new protocol I noticed that there wasn't an OOTB way to configure the OkHttpExporter to send payloads as JSON. For now I've copied the classes I need and changed them like I have in this PR, but figured it would be a nice addition to the opentelemetry-java project as it's not too much code and makes testing more convenient.
I recognize that clients will want to configure themselves to send things as Protobuf, but it might be nice to have the JSON option if only for testing. I wanted to just add the option to the OkHttpExporter (which is what we use directly in our tests) so that it wouldn't need to be exposed in the OtlpHttpMetricExporterBuilder, but the existing tests seem to exercise the OkHttpExporter via the OtlpHttpMetricExporterBuilder so I added the extra wiring to keep testing similar.