NOTE
This is a modified version of the Go OpenTelemtry protobuf files to re-add deprecated/removed Metric types (IntSum, IntGuage, IntHistogram) and label type (StringKeyValue).
You should not depend on these protobuf files directly, instead use the Honeycomb fork of the opentelemetry-proto-go package which includes these changes.
This repo is currently pinned to v0.19.0 of the upstream repository.
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:
- cpp
- csharp
- go
- java
- objc
- openapi (swagger)
- php
- python
- ruby
Component | Maturity |
---|---|
Binary Protobuf Encoding | |
common/* | Stable |
metrics/* collector/metrics/* |
Stable |
resource/* | Stable |
trace/trace.proto collector/trace/* |
Stable |
trace/trace_config.proto | Alpha |
logs/* collector/logs/* |
Stable |
JSON encoding | |
All messages | Stable |
(See maturity-matrix.yaml for definition of maturity levels).
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.
- Service method parameter names will not change.
- Service method parameter types and return types will not change.
- Service method kind (unary vs streaming) will not change.
- Names of messages and enums will not change.
- Names of enum choices and numbers assigned to enum choices will not change.
- The location of messages and enums, i.e. whether they are declared at the top lexical scope or nested inside another message will not change.
- Package names and directory structure will not change.
optional
andrepeated
declarators of existing fields will not change.- No existing symbol will be deleted.
The following additive changes are allowed:
- Adding new fields to existing messages.
- Adding new messages or enums.
- Adding new choices to existing enums.
- Adding new choices to existing oneof fields.
- Adding new services.
- Adding new methods to existing services.
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.