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

Guidance for instrumentation authors of libraries built upon other instrumented libraries #5417

Open
alanwest opened this issue Mar 6, 2024 · 1 comment
Labels
question Further information is requested

Comments

@alanwest
Copy link
Member

alanwest commented Mar 6, 2024

Often libraries are built on top of other libraries. We currently have a few examples that, when both libraries are instrumented, different design decisions have been made.

Examples

Grpc.Net.Client & HttpClient

We have instrumentation for both. When both are configured they each individually create a client span.

AspNetCore & Grpc.AspNetCore.Server

Currently, our instrumentation for Grpc.AspNetCore.Server piggybacks on our standard instrumentation for AspNetCore. It does so by adding additional RPC attributes to the activity created by the AspNetCore instrumentation. It does not create an additional span.

AspNetCore & HotChocolate.AspNetCore

Hot Chocolate is a graphql framework. Similar to our Grpc.AspNetCore.Server instrumentation, it contains native instrumentation which piggybacks on the activity created by AspNetCore instrumentation and alters its name. There exist graphql semantic conventions for spans, but the conventions do not currently specify the span kind for a graphql server span. See #5402 for more details.

Things to discuss

  • Do the differences in design decisions make sense? Or should we converge on one pattern over the other?
    • One of the problems with the "piggybacking" design is that instrumentation can be brittle as there is an implied contract between the instrumentation of the two libraries.
  • Depending on what we decide, we should offer guidance to library authors.
  • The examples above are primarily focused on span data. How (if at all) would our guidance affect metrics? (e.g. if we added support for the rpc.server.duration metric or if graphql eventually defined metrics).
    • Should both metrics be emitted? Or should we prefer one over the other?
  • Is there a precedence in any other languages?
  • Should this be a language/framework specific conversation, or should this be a topic be elevated to the semantic conventions SIG?
@alanwest alanwest added the question Further information is requested label Mar 6, 2024
Copy link
Contributor

This issue was marked stale due to lack of activity and will be closed in 7 days. Commenting will instruct the bot to automatically remove the label. This bot runs once per day.

@github-actions github-actions bot added the Stale Issues and pull requests which have been flagged for closing due to inactivity label Dec 31, 2024
@TimothyMothra TimothyMothra removed the Stale Issues and pull requests which have been flagged for closing due to inactivity label Dec 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants