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

Openkit for Server Side Tracing #204

Open
luckyabhishek opened this issue Oct 25, 2019 · 6 comments
Open

Openkit for Server Side Tracing #204

luckyabhishek opened this issue Oct 25, 2019 · 6 comments
Assignees

Comments

@luckyabhishek
Copy link

Hey,

Can this library be used to do the server side tracing. I know the tracer which exists is for outgoing web request equivalent, however if we extend the library we might be able to write an incoming web request tracer.
The reason I ask is because oneagent SDK is not behaving well with vertx due to the way thread models work in vertx. The oneagent jumbles up the purepath.

Will we be able to extend this kit to construct the same by extending this SDK.

Abhishek

@stefaneberl
Copy link
Contributor

Hi Abhishek,

thanks for the question. Unfortunately, OpenKit was not designed for this use case, to trace incoming web requests. It's also not trivial to get this in, as we would need to extend the protocol that is used.

The appropriate way would be the OneAgent SDK or the OneAgent itself. I will forward this ticket to the appropriate stakeholders. They will be able to give more details about Vert.X support.

Best regards
Stefan

@stefaneberl stefaneberl self-assigned this Oct 25, 2019
@z1c0
Copy link

z1c0 commented Oct 25, 2019

Hi,

I'm not familiar with Vert.X to be honest, but from the way it's described on the website (event driven, non-blocking) it is most likely not a good fit for the OneAgent SDK tracers and their thread-affinity.

from https://github.com/Dynatrace/OneAgent-SDK-for-java:

A Tracer instance can only be used from the thread on which it was created. See in process linking for tracing across thread boundaries.

You could ask on Dynatrace Answers about Vert.X and see if others have that requirement as well, though.

Best regards
Wolfgang

@luckyabhishek
Copy link
Author

Hi Wolfganf, Stefen

I understand tha One Agent SDK has some kind of thread-affinity, and hence wanted to fall back upon OpenKit. The challenge I have in my hand is that we have a microservices based application where all services are good and dynatrace abiding citizens.
Because of the usage of vertx we are losing the end to end traces and people are contemplating to move to other options like Jaeger. We need to find a way out to ensure that we don't lose all our knowledhe and investments in dynatrace and start learning the new tool.
I have 2 questions

  1. What would it take if we were to extend openkit for incoming tracer. Is it a question of building new APIs in the server or a question of adapting the SDK. If it's about SDK then can you point to some helpful documentation on how one can go about it.
  2. I understand that tracer instance can't be used cross thread. In vertx, we are using the instance in a single thread (A single thread runs multiple requests). My belief is that it gets messed up because One Agent SDK also assumes that the tracer which is opened last will close first. And hence we get warnings which speak about nodes and depth in the system log. Does One Agent SDK do a stack walk to maintain the states ?

I know One Agent has already mentioned that this is not even in the roadmap. Is there a way this can come in the roadmap ? vertx seems to be working well with Jaeger and hence there's a definite affinity of the team to switch
"

@SonjaChevre
Copy link

Hi Abhishek,

can you share a very simple code snippet of how your web request looks like? We just took a very quick look at Vert.X sample codes:

Looking at those two examples, you should be able to use OneAgent SDK for tracing the incoming and outgoing web requests if the SDK tracer is started and ended into the handler methods.

You should also make sure that no other out-of-the-box sensor is already starting the outgoing web request. In that case, you would need to deactivate this out-of-the-box sensor.

Sonja

@luckyabhishek
Copy link
Author

luckyabhishek commented Oct 31, 2019 via email

@luckyabhishek
Copy link
Author

Hi Sonja,
I created a quick sample which reproduces the issue to some extent. The sample is now uploaded on https://github.com/luckyabhishek/vertx-sample
And
git checkout pathdrops
to checkout the first repro.
If you build and deploy this sample on cloudfoundry and bind it to the dynatrace service. You would see the following message in the logs.
info [native] PATH-DROPPING: 1 of 4 SubPath(s) have been dropped
This basically means that path information is getting dropped. We then went on to create a http request tracer to do the custom logging using the oneagent sdk. I will do that next to show the jumbled purepaths.

openkitdt pushed a commit that referenced this issue Apr 22, 2021
Merge in OP/openkit-java from feature/ONE-54799-pump-version-to-2.3.0-SNAPSHOT to main

* commit 'd090fd59b8ee9d4aa8912d868fc29623dac3a4d4':
  Pump version to 2.3.0-SNAPSHOT

GitOrigin-RevId: a7cc215f447a5d0bb5945fe05eb24045157068bb
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

No branches or pull requests

4 participants