Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions devdocs/features.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Contributor

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:

## Go
...

### Context Propagation
...

### Supported Libraries
...

### SDK Integration
...

## Java
...

### Context Propagation
...

Structuring the currently proposed way severly limits the ability to eplain things by having it in a table and without other languge context. Addtionally, this is not how users will use this documentation, they will first ask about a specific Language and then look for its supported features.

Copy link
Contributor Author

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?


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
Copy link
Contributor

Choose a reason for hiding this comment

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

What about C++ and Rust?

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 can write them in Not supported status
we have plans to implement Rust tokio support in the future, im not familiar with common C++ asynchronies frameworks

|:--------------------|:---------:|---------------:|:--------------------------------------------------|:-------------
| 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
Copy link
Contributor

Choose a reason for hiding this comment

The 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 webrick?

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 remember thats what i saw from @grcevski PR, maybe he can correct me

| Java Thread pool | Java | N/A | N/A | Stable
Copy link
Contributor

Choose a reason for hiding this comment

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

Why N/As here? There definitely should be limitations on versions at least.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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