-
Notifications
You must be signed in to change notification settings - Fork 65
inter service context propagation docs #1082
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -39,3 +39,19 @@ To turn this off and fallback to the normal network based instrumentation for Go | |
| | github.com/segmentio/kafka-go | Kafka | >= v0.4.11 | All | Yes | No | N/A | ||
| | github.com/IBM/sarama | Kafka | >= 1.37 | All | Yes | No | N/A | ||
| | go.mongodb.org/mongo-driver | MongoDB | >= v1.10.1, >= v2.0.1 | All | Yes | No | N/A | ||
|
|
||
| # Supported Context propagation frameworks | ||
|
|
||
| For Inter-process context propagation, OBI by default assumes actions happening the same thread are part of the same | ||
| trace. | ||
| but in many cases, especially in asynchronous programming models, the context might be propagated across threads or even | ||
| processes. | ||
| OBI has support for several asynchronous frameworks that allow it to propagate context in these scenarios. | ||
|
|
||
| | Framework | Languages | Versions | Limitations | Status | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about C++ and Rust?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i can write them in |
||
| |:--------------------|:---------:|---------------:|:--------------------------------------------------|:------------- | ||
| | Go Routines | Go | Go >= 1.18 | up to 3 nested levels of goroutines | Stable | ||
| | Node.js Async Hooks | Node.js | Node.js >= 8.0 | Custom handling of SIGUSR1 signal might interfere | Stable | ||
| | Ruby Puma Server | Ruby | N/A | Only works with Puma server | Stable | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this limited to a Puma server? I've seen this work with
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
| | Java Thread pool | Java | N/A | N/A | Stable | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. for java and ruby i couldn't find if we have any limitations, maybe @grcevski can chime in |
||
| | Python asyncio | Python | Python >= 3.7 | N/A | In Progress | ||
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 think this grouping is going to be overwhelming.
I would recommend we group our documentation by language:
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.
still leaving the top table for protocols? and after grouping by language and write custom probes under that?