AlexSm 6d3e410c45 Remove CMakeLists from main (#2032) | 9 months ago | |
---|---|---|
.. | ||
opentelemetry | 9 months ago | |
CHANGELOG.md | 9 months ago | |
CONTRIBUTING.md | 1 year ago | |
LICENSE | 1 year ago | |
README.md | 1 year ago | |
RELEASING.md | 1 year ago | |
ya.make | 9 months ago |
This repository contains the OTLP protocol specification and the corresponding Language Independent Interface Types (.proto files).
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.
See additional requirements for OTLP/JSON wire representation here.
To generate the raw gRPC client libraries, use make gen-${LANGUAGE}
. Currently supported languages are:
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 |
(See maturity-matrix.yaml for definition of maturity levels).
Components marked Stable
provide the following guarantees:
optional
and repeated
declarators of existing fields will not change. [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:
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.
In some cases we are trying to experiment with different features. In this case, we recommend using an "experimental" 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 experimental protocols to join the main project.