Jonathan Halliday
d77c317b47
|
1 week ago | |
---|---|---|
.github | 3 months ago | |
.vscode | 5 years ago | |
docs | 2 months ago | |
examples | 2 months ago | |
opentelemetry/proto | 1 week ago | |
.gitattributes | 5 years ago | |
.gitignore | 2 years ago | |
.markdown_link_check_config.json | 1 year ago | |
.markdownlint.yaml | 1 year ago | |
CHANGELOG.md | 4 months ago | |
CONTRIBUTING.md | 3 months ago | |
LICENSE | 6 years ago | |
Makefile | 2 months ago | |
README.md | 2 months ago | |
RELEASING.md | 6 months ago | |
buf.yaml | 2 years ago | |
package-lock.json | 1 year ago | |
package.json | 1 year ago |
README.md
OpenTelemetry Protocol (OTLP) Specification
This repository contains the OTLP protocol specification and the corresponding Language Independent Interface Types (.proto files).
Language Independent Interface Types
The proto files can be consumed as GIT submodules or copied and built directly in the consumer project.
The compiled files are published to central repositories (Maven, ...) from OpenTelemetry client libraries.
See contribution guidelines if you would like to make any changes.
OTLP/JSON
See additional requirements for OTLP/JSON wire representation here.
Generate gRPC Client Libraries
To generate the raw gRPC client libraries, use make gen-${LANGUAGE}
. Currently supported languages are:
- cpp
- csharp
- go
- java
- objc
- openapi (swagger)
- php
- python
- ruby
Maturity Level
1.0.0 and newer releases from this repository may contain unstable (alpha or beta) components as indicated by the Maturity table below.
Component | Binary Protobuf Maturity | JSON Maturity |
---|---|---|
common/* | Stable | Stable |
resource/* | Stable | Stable |
metrics/* collector/metrics/* |
Stable | Stable |
trace/* collector/trace/* |
Stable | Stable |
logs/* collector/logs/* |
Stable | Stable |
profiles/* collector/profiles/* |
Development | Development |
(See Versioning and Stability for definition of maturity levels).
Stability Definition
Components marked Stable
provide the following guarantees:
- Field types, numbers and names will not change.
- Service names and
service
package names will not change. - Service method names will not change. [from 1.0.0]
- Service method parameter names will not change. [from 1.0.0]
- Service method parameter types and return types will not change. [from 1.0.0]
- Service method kind (unary vs streaming) will not change.
- Names of
message
s andenum
s will not change. [from 1.0.0] - Numbers assigned to
enum
choices will not change. - Names of
enum
choices will not change. [from 1.0.0] - The location of
message
s andenum
s, i.e. whether they are declared at the top lexical scope or nested inside anothermessage
will not change. [from 1.0.0] - Package names and directory structure will not change. [from 1.0.0]
optional
andrepeated
declarators of existing fields will not change. [from 1.0.0]- No existing symbol will be deleted. [from 1.0.0]
Note: guarantees marked [from 1.0.0] will go into effect when this repository is tagged with version number 1.0.0.
The following additive changes are allowed:
- Adding new fields to existing
message
s. - Adding new
message
s orenum
s. - Adding new choices to existing
enum
s. - Adding new choices to existing
oneof
fields. - Adding new
service
s. - Adding new
method
s to existingservice
s.
All the additive changes above must be accompanied by an explanation about how new and old senders and receivers that implement the version of the protocol before and after the change interoperate.
No guarantees are provided whatsoever about the stability of the code that is generated from the .proto files by any particular code generator.
Experiments
In some cases we are trying to experiment with different features. In this case, we recommend using a "development" sub-directory instead of adding them to any protocol version. These protocols should not be used, except for development/testing purposes.
Another review must be conducted for in-development protocols to join the main project.