Protobuf definitions for the OpenTelemetry protocol (OTLP) (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Tigran Najaryan 4967b51b5c Update CHANGELOG.md after 0.20.0 release 1 year ago
.github Add link checking 2 years ago
.vscode Add release instructions for opentelemetry proto. (#133) 5 years ago
docs [editorial] Drop or adjust Hugo front matter in doc pages (#479) 1 year ago
examples Fix JSON field capitalization in trace.json example (#477) 2 years ago
opentelemetry/proto Clarify uniqueness of Scope attribute keys 1 year ago
.gitattributes Add .gitattributes to avoid mixed line endings. (#85) 5 years ago
.gitignore Add link checking 2 years ago
.markdown_link_check_config.json Add link checking 2 years ago
CHANGELOG.md Update CHANGELOG.md after 0.20.0 release 1 year ago
CONTRIBUTING.md Update links after master -> main branch change (#254) 4 years ago
LICENSE Initial commit 6 years ago
Makefile Add link checking 2 years ago
README.md Remove trace_config from maturity matrix, already removed from repo (#475) 2 years ago
RELEASING.md Eliminate nested "protocol" directory and fix all links 2 years ago
buf.yaml Use buf to detect for wire breaking changes (#415) 2 years ago
package-lock.json Add link checking 2 years ago
package.json Add link checking 2 years ago

README.md

OpenTelemetry Protocol (OTLP) Specification

Build Check

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

Component Maturity
Binary Protobuf Encoding
common/* Stable
metrics/*
collector/metrics/*
Stable
resource/* Stable
trace/*
collector/trace/*
Stable
logs/*
collector/logs/*
Stable
JSON encoding
All messages Stable

(See maturity-matrix.yaml 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 messages and enums 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 messages and enums, i.e. whether they are declared at the top lexical scope or nested inside another message will not change. [from 1.0.0]
  • Package names and directory structure will not change. [from 1.0.0]
  • optional and repeated 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 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.

Experiments

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.