-
Notifications
You must be signed in to change notification settings - Fork 850
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
Proposal for modeling nested CLIENT instrumentation #1822
Comments
Should we formalise these events on spec level? |
This "layering" or "nesting" views of protocols occurs quite a bit and will occur more and more as we add more instrumentation. A few thoughts that will probably only serve to confuse matters more:
Finally, I'll say that any form of modeling/representation that isn't "let's pretend this lower level of visibility never happened" would be an improvement, and so I'll support any movement in that direction. |
I don't think that events are going to solve this problem completely, as I think @johnbley is also suggesting. Events will absolutely be the appropriate way to tackle some issues (like looking up connections from a connection pool), but not everything. I think we'll need to tackle this at the spec level to truly solve the issue. Options I see:
|
Linking in a good and relevant comment from @agoallikmaa #2923 (comment) |
Note, the spec has now been updated to allow nested CLIENT instrumentation, so this issue probably needs some re-thought. |
@open-telemetry/java-approvers I propose to close this issue as solved by https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/suppressing-instrumentation.md#enable-instrumentation-suppression-by-type |
👍 additional proposals/discussions can be opened as new issues |
Since CLIENT spans cannot have nested CLIENT spans, we suppress the nested http client instrumentation, which seems reasonable, as user is interacting with the higher level library, and is probably most interested in seeing things at that level.
But sometimes the nested instrumentation can provide interesting telemetry.
For example, Elasticsearch CLIENT spans are modeled as database spans, but makes HTTP calls under the covers using an instrumented http client, and it may be interesting to see the lower level HTTP telemetry.
I'm not sure if Elasticsearch CLIENT spans are always 1-1 with HTTP calls, but it would be reasonable for some database CLIENT spans to make multiple HTTP calls under the covers.
As we discussed in SIG meeting yesterday, if we want to capture the lower level telemetry, a nice option would be to use events to represent the lower level HTTP calls.
The text was updated successfully, but these errors were encountered: