-
Notifications
You must be signed in to change notification settings - Fork 164
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
Typed Spans: Create RFC from current WIP proposal. #25
Closed
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,155 @@ | ||
# Typed Spans | ||
|
||
**Status:** `proposed` | ||
|
||
In OpenCensus and OpenTracing spans can be created freely and it’s up to the | ||
implementor to annotate them with attributes specific to the represented operation. | ||
This document proposes to add type information to spans and to define and reserve | ||
mandatory and optional attributes depending on the span type. | ||
|
||
## Motivation | ||
|
||
Spans represent specific operations in and between systems. | ||
|
||
Examples for such operations are | ||
|
||
- Local operations like method invocations | ||
- HTTP requests (inbound and outbound) | ||
- Database operations | ||
- Queue/Message publish and consume | ||
- gRPC calls | ||
- Generic RPC operations | ||
|
||
Depending on the type of an operation, additional information is needed to | ||
represent and analyze a span correctly in monitoring systems. | ||
|
||
While both OpenCensus and OpenTracing define conventions that define some reserved | ||
attributes that can be used to add operation-specific information, there is no | ||
mechanism to specify the type of an operation and to ensure that all needed | ||
attributes are set. | ||
|
||
### Proposed types | ||
|
||
Below is a list of types and attributes per type. | ||
This document does not include the final naming of attributes and types. | ||
It is assumed that there will be naming conventions that will be applied eventually. | ||
|
||
There is also no distinction between mandatory and optional attributes as it is assumed | ||
that there will be a dedicated discussion and document for each type linked in this document. | ||
|
||
See [this document by @discostu105](https://docs.google.com/spreadsheets/d/1H0S0BROOgX7zndWF_WL8jb9IW1PN7j3IeryekhX5sKU/edit#gid=0) for type and attribute mappings that exist in OpenCensus and OpenTracing today. | ||
|
||
#### HTTP Client | ||
Represents an outbound HTTP request. | ||
|
||
##### Attributes | ||
These attributes are not covered in the [main spec](../../specification/data-semantic-conventions.md): | ||
|
||
- Route | ||
- User Agent | ||
- Parameters | ||
- Request Headers | ||
- Response Headers | ||
|
||
#### HTTP Server | ||
Represents an inbound HTTP request. | ||
|
||
##### Attributes | ||
|
||
These attributes are not covered in the [main spec](../../specification/data-semantic-conventions.md): | ||
|
||
- User Agent | ||
- Webserver Name | ||
- Remote Address | ||
- Parameters | ||
- Request Headers | ||
- Response Headers | ||
|
||
#### Database Client | ||
Represents a database call. | ||
|
||
##### Attributes | ||
|
||
These attributes are not covered in the [main spec](../../specification/data-semantic-conventions.md): | ||
|
||
- Channel Type (e.g. TCP) | ||
|
||
#### gRPC Client | ||
Represents an outbound gRPC request. | ||
|
||
##### Attributes | ||
|
||
These attributes are not covered in the [main spec](../../specification/data-semantic-conventions.md): | ||
|
||
- Channel Type (e.g. TCP) | ||
|
||
#### gRPC Server | ||
Represents an inbound gRPC request. | ||
|
||
##### Attributes | ||
|
||
These attributes are not covered in the [main spec](../../specification/data-semantic-conventions.md): | ||
|
||
- Channel Type (e.g. TCP) | ||
|
||
#### Remoting Client | ||
Represents an outbound RPC request. | ||
|
||
##### Attributes | ||
- Service Endpoint | ||
- Channel Type (e.g. TCP) | ||
- Channel Endpoint | ||
- Service Name | ||
- Service Method | ||
|
||
|
||
#### Remoting Server | ||
Represents an inbound RPC request. | ||
|
||
##### Attributes | ||
- Service Method | ||
- Service Name | ||
- Service Endpoint | ||
- Protocol Name | ||
|
||
|
||
#### Messaging Consumer | ||
Represents an inbound message. | ||
|
||
##### Attributes | ||
- Vendor Name | ||
- Destination Name | ||
- Destination Type | ||
- Channel Type | ||
- Channel Endpoint | ||
- Operation Type | ||
- Message Id | ||
- Correlation Id | ||
|
||
#### Messaging Producer | ||
Represents an outbound message. | ||
|
||
##### Attributes | ||
- Vendor Name | ||
- Destination Name | ||
- Channel Type | ||
- Channel Endpoint | ||
- Message Id | ||
- Correlation Id | ||
|
||
## Proposal | ||
* Add a field `CanonicalType` that contains the type of span | ||
* Define mandatory and optional attributes per span type | ||
* Provide an API that supports creating typed spans and ensures that at least all | ||
mandatory attributes for this `CanonicalType` are present | ||
|
||
## Challenges and Objections | ||
- Some mandatory attributes for a given type may not be available at the time of creation | ||
|
||
### POC | ||
Here is [a POC for HTTP Client Spans for Node.js and OpenCensus](https://github.com/danielkhan/opencensus-node-typed-span-sample) | ||
|
||
## Action Items | ||
- Define all types | ||
- Agree on type and attribute naming conventions | ||
- Specify each type and agree on mandatory and optional attributes per type |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 would really like to see an actual proposal of the API for doing this. Especially if it was already POCed in Node, what's preventing it from becoming a part of this RFC? Without the API proposal this current document provides little value, since it's not directly usable.
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.
Should we make language-specific RFCs? Not all languages support the same capabilities which makes writing specs for APIs a challenge. We can, however, link to the language spec files or should we rather use same pseudo code?