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

Restlet instrumentation #3946

Merged
merged 8 commits into from
Sep 14, 2021

Conversation

anosek-an
Copy link
Contributor

Beginning of Restlet instrumentation - issue #3661.

  • server instrumentation - creation of server span
  • works with versions 1.0.x and 1.1.x, 1.2 will be checked in future PRs

@anosek-an anosek-an force-pushed the restlet-server-instrumentation branch from cf73b9c to 3e095a5 Compare September 6, 2021 10:12
Copy link
Member

@mateuszrzeszutek mateuszrzeszutek left a comment

Choose a reason for hiding this comment

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

Looks nice! I left just a few (mostly minor) comments.

Copy link
Member

@mateuszrzeszutek mateuszrzeszutek left a comment

Choose a reason for hiding this comment

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

LGTM 👍
Thanks!

return;
}

// Restlet suppresses exceptions and sets the throwable in status
Copy link
Member

Choose a reason for hiding this comment

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

👍

Comment on lines 14 to 21
public Iterable<String> keys(Request carrier) {
return HeadersAdapter.getHeaders(carrier).getNames();
}

@Override
public String get(Request carrier, String key) {
return HeadersAdapter.getValue(carrier, key);
}
Copy link
Member

Choose a reason for hiding this comment

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

I'd suggest inlining the HeadersAdapter methods and deleting the HeadersAdapter class

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sure, I think it's not necessary to keep them separate

Comment on lines +44 to +46
public Instrumenter<Request, Response> getServerInstrumenter() {
return serverInstrumenter;
}
Copy link
Member

Choose a reason for hiding this comment

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

maybe just getInstrumenter() if we don't need to distinguish between client and server instrumenter

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm planning on adding client instrumentation in the future, so I'd prefer to leave the current naming

Copy link
Member

Choose a reason for hiding this comment

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

make sense 👍

Comment on lines 8 to 12
/*
* Copyright The OpenTelemetry Authors
* SPDX-License-Identifier: Apache-2.0
*/

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/*
* Copyright The OpenTelemetry Authors
* SPDX-License-Identifier: Apache-2.0
*/


@Override
boolean testException() {
false //Filter's afterHandle does not execute if exception was thrown in the next restlet
Copy link
Member

Choose a reason for hiding this comment

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

if afterHandle is not executed, will the Scope that was started in beforeHandle be left open (and the Context left bound to the thread)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

after some investigation and looking into Restlet's StatusFilter I found a way to make afterHandle execute even if an exception was thrown, so the Scope will be safely closed in every case now

import static io.opentelemetry.instrumentation.test.base.HttpServerTest.ServerEndpoint.REDIRECT
import static io.opentelemetry.instrumentation.test.base.HttpServerTest.ServerEndpoint.SUCCESS

abstract class AbstractRestletServerTest extends HttpServerTest<Server> {
Copy link
Member

Choose a reason for hiding this comment

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

👍

try {
super.doHandle(request, response);
} catch (Throwable t) {
response.setStatus(new Status(Status.SERVER_ERROR_INTERNAL, t));
Copy link
Member

Choose a reason for hiding this comment

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

You could implement the whole instrumentation inside doHandle to avoid modifying the response object

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Without setting status this way, the throwable is not propagated and we get a response with status of 200, not 500. My approach based on StatusFilter.
I can move instrumentation code to doHandle, leaving this line as it is.

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. How about you move the instrumentation code to doHandle and use the StatusFilter in library instrumentation tests? We generally want an instrumentation to be as transparent as possible - I agree that returning 200 for unhandled exceptions is a bit weird and unintuitive, but as instrumentation authors we should avoid changing this default behavior on our whim. If a user wants to return 500s instead then they're going to use StatusFilter anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure, thanks for the explanation!

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

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

thx @Enkelian!

@trask trask merged commit 473f16f into open-telemetry:main Sep 14, 2021
@anosek-an anosek-an deleted the restlet-server-instrumentation branch November 15, 2021 10:03
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.

3 participants