Add typed spans working document #14
Conversation
|
@danielkhan thanks for the PR, you need to sign the CLA. |
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td><strong>db.instance</strong> |
There was a problem hiding this comment.
These seems contrary to OpenTracing. The mandatory field should be db.type. Why db.instance?
There was a problem hiding this comment.
Maybe this was a mistake in reading the spec. Looking at https://github.com/opentracing/specification/blob/master/semantic_conventions.md#database-client-calls it seems as if both should be required. Would you agree?
| </td> | ||
| </tr> | ||
| <tr> | ||
| <td><strong>peer.*</strong> |
There was a problem hiding this comment.
If required, all options should be explicitly defined. Why are any of these required?
There was a problem hiding this comment.
They are required to map them to a concrete instance in a model that might be external to OpenTelemetry.
Yes we are waiting for our legal team to take care of that. |
|
Can anyone offer insight as to how we expect this would be implemented? For example, would there be many different sub-classes of Span, each with different sets of fields? Or perhaps a "typed attribute" field inside Span that these would be set on? |
|
@tylerbenson IMHO this work should be split in two parts. 1: Just documentation of what attributes exist and which are supposed to be on certain kinds (more like OT "semantic conventions", but with the canonical type notion). Not technically binding, but rather recommendations. Why? It has value both on implementing instrumentation as well as on interpreting data (analytics backend). 2: Typed spans API. This is a different discussion (we should do separately :)). IMHO we should keep generic span classes, with generic span attributes. But we could add typed "Builder" classes that would help a user to set the correct attributes (via dedicated API's for each attribute). |
- Added motivation - Provided a broader scope and less implementation details, like naming or mandatory fields - Removed tables
|
@danielkhan I think it's a good idea to merge this document in and then start transferring pieces of it to the folder outside the Does this approach make sense for you? |
Absolutely. That sounds like a good approach to get the ball rolling, @SergeyKanzhelev |
|
I'm going to merge it as this is work in progress. Basically an accumulation of many documents. Documents that will require a bigger consensus will be placed outside of this folder. |
@discostu105 perhaps there should be the separate issues for those separate discussions than |
…metry#14) Uses clang-format, cmake-format, and buildifier.
Clarify versioning from experimental to stable
* Add typed spans working document * Restructuring and scoping - Added motivation - Provided a broader scope and less implementation details, like naming or mandatory fields - Removed tables
No description provided.