Proto commits in open-telemetry/opentelemetry-proto

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2025-04-24

profiles: Move lookup tables to ProfilesData (#644) Implements https://github.com/open-telemetry/opentelemetry-proto/issues/628#issuecomment-2772566325. Signed-off-by: Florian Lehner <florian.lehner@elastic.co> Co-authored-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com> Co-authored-by: Nayef Ghattas <11560964+Gandem@users.noreply.github.com>

The documentation is generated from this commit.

2025-04-10

Stabilize event_name in LogRecord (#643)

2025-03-28

remove comment on each profile service about keeping the RPC alive (#637) Tigran explained this comment was likely a hold over from the OpenCensus protobufs which did use streaming RPC's. Unary RPC's, which are used by the OpenTelemetry protocol, can not be kept alive making the comment out of place. Co-authored-by: Josh Suereth <Joshua.Suereth@gmail.com>

Add EntityRef and use it in Resource. (#635) * Add EntityRef and use it in Resource. * Update opentelemetry/proto/resource/v1/resource.proto Co-authored-by: Nathan L Smith <nathan.smith@elastic.co> * Update opentelemetry/proto/common/v1/common.proto Co-authored-by: Nathan L Smith <nathan.smith@elastic.co> * Update opentelemetry/proto/common/v1/common.proto Co-authored-by: Nathan L Smith <nathan.smith@elastic.co> --------- Co-authored-by: Nathan L Smith <nathan.smith@elastic.co>

2025-03-26

profiles: clarify use of optional fields in message Line and message Function (#621)

2025-02-24

Update metrics.proto (#632)

2025-02-12

Clarify when bucket_counts array may be empty (#619) The current definition says: "The number of elements in bucket_counts array must be by one greater than the number of elements in explicit_bounds array." However, it also says "bucket_counts is an optional field", which means its length can be 0, which than in turn means the length of explicit_bounds must be -1, which is impossible. We clarify that it is a valid situation to have both bucket_counts and explicit_bounds arrays empty.

2025-02-11

profiles: switch default sample type index from string_table to sample_type array (#620) Signed-off-by: Florian Lehner <florian.lehner@elastic.co> Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

2025-02-04

[editorial] Use canonical URL to OpenMetrics repo (#617)

2025-01-09

Simplify profile stack trace representation - Introduce a first-class Stack message type and lookup table. - Replace location index range based stack trace encoding on Sample with a single stack_index reference. - Remove the location_indices lookup table. The primary motivation is laying the ground work for [timestamp based profiling][timestamp proposal] where the same stack trace needs to be referenced much more frequently compared to aggregation based on low cardinality attributes. Timestamp based profiling is also expected to be used with the the upcoming [Off-CPU profiling][off-cpu pr] feature in the eBPF profiler. Off-CPU stack traces have a different distribution compared to CPU samples. In particular stack traces are much more repetitive because they only occur at call sites such as syscalls. For the same reason it is also uncommon to see a stack trace are a root-prefix of a previously observed stack trace. We might need to revisit the previous [previous benchmarks][benchmarks] to confirm these claims. The secondary motivation is simplicitly. Arguably the proposed change here will make it easier to write exporters, processors as well as receivers. It seems like we had rough consensus around this change in previous SIG meetings, and it seems like a good incremental step to make progress on the timestamp proposal. [timestamp proposal]: https://github.com/open-telemetry/opentelemetry-proto/pull/594 [off-cpu pr]: https://github.com/open-telemetry/opentelemetry-ebpf-profiler/pull/196 [benchmarks]: https://docs.google.com/spreadsheets/d/1Q-6MlegV8xLYdz5WD5iPxQU2tsfodX1-CDV1WeGzyQ0/edit?gid=2069300294#gid=2069300294

2024-12-13

update links to openmetrics to reference the v1.0.0 release (#612)

profile: drop duplicate field in message Profile (#606) * profile: drop duplicate field in message Profile The message Profile contains two fields of type `opentelemetry.proto.common.v1.KeyValue`, `attribute_table` and `attributes`. Both fields are intended for the same use. Therefore drop the later one. * fixup: add attribute_indices to message Profile Signed-off-by: Florian Lehner <florian.lehner@elastic.co> * fixup: move comment Signed-off-by: Florian Lehner <florian.lehner@elastic.co> --------- Signed-off-by: Florian Lehner <florian.lehner@elastic.co> Co-authored-by: Liudmila Molkova <limolkova@microsoft.com>

2024-12-11

Add `event_name` to logs proto (#600) * Add event_name to log proto

2024-12-10

Add note about schema url and schema version (#605)

2024-11-22

Remove unused label from profiles (#602)

2024-11-08

Renovations to experimental profiling schema. (#596) - remove Profile keep_frames and drop_frames due to unclear semantics and use cases - make Sample.link_index and Location.mapping_index optional, consistent with documented intention - remove deprecated fields Sample.location_index, Mapping.id, Location.id, Function.id - renumber fields for improved redability

2024-11-04

Improve lookup table pattern use in profiles. (#592) Based on implementation experience with the draft version of the profiles spec, the use of lookup tables for storing values is space efficient but not particularly user friendly. This change makes improvements by changing field names to clarify their role in the pattern and changing their data types to better accommodate their use in languages limited to 32 bit array indexing e.g. Java.

2024-10-15

Fold the content of pprofextended.proto into profiles.proto, removing ProfileContainer. (#590) This change removes the now unnecessary split of the profiling format between two files, combining them into one as with other protocols. In the process, the likewise unnecessary ProfileContainer message type is removed and its fields merged into Profile, saving one level of indirection. Note this as discussed on slack otel-profiles, this is effectively a minimal subset of the now defunct #587, remaining parts of which will be resubmitted in subsequent PRs. This PR effectively blocks any concurrent changes to pprofextended.proto e.g. #588 as git won't track such changes across the file 'merge'.

2024-10-01

Clarify aggregation temporality for Summary metric type (#591)

2024-09-26

profiles: Make mapping in Profile optional (#556) As commented in [0] and discussed in the OTel Profiling SIG meeting, there are situations where a main binary for a Profile can not be identified. For these cases mark the field optional. FYI: @brancz @petethepig @open-telemetry/profiling-maintainers [0]: https://github.com/open-telemetry/opentelemetry-proto/pull/534#discussion_r1561141336

2024-09-24

Rename profiles v1experimental to v1development (#585) As discussed in https://github.com/open-telemetry/opentelemetry-proto/pull/582#discussion_r1751850589, this renames the `v1experimental` version for profiles to `v1development`. I've also taken this opportunity to update the versioning and stability link.

2024-09-16

profiles: drop BuildIdKind (#584) Drop `BuildIdKind` in favor of its semantic convention as defined in https://github.com/open-telemetry/semantic-conventions/pull/1329. Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

profiles: drop Sample.label (#583) Drop `Sample.label` in favor of `Sample.attributes`. While `label` and `attributes` fulfill the same purpose, it is not defined which one choose for which information. Therefore, drop `label` in favor of `attributes`. FYI: @open-telemetry/profiling-maintainers spec:profiles Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

profiles: drop Location.type_index (#578) With https://github.com/open-telemetry/semantic-conventions/pull/1188 the semantic convention for Profiles that introduces frame types and well known values is about to be merged. Therefore, `Location.type_index` is no longer needed. FYI: @open-telemetry/profiling-maintainers Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

2024-09-04

profiles: drop Sample.stacktrace_id_index (#575) The value for Sample.stacktrace_id_index is hardly defined except for its length. It is also not defined how this value should be generated, interpreted and could be used. Some kind of stacktrace_id can be most efficient in stateful protocols, where transmitting duplicate information should be avoided. As the OTel Profiling protocol is a stateless protocol, this element can be droped.

2024-08-13

profiles: align type of index into string table (#557) With `Mapping.filename`, `Function.name`, `Label.key` and others the type of the index into the string table is always of type `int64`. For consistency align the type of `Location.type_index`, which is also an index into the string table, to `int64`. Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

2024-07-02

Add resource attributes and scope to metrics proto diagram (#519) Fixes https://github.com/open-telemetry/opentelemetry-proto/issues/518.

2024-06-05

Fix typo; According to the definition of message Sample, the relation between Sample and Link should be n-1 (#564)

2024-05-13

profiles: add missing java_package option to pprofextended. (#558) Gah, we put java_package on one file but not the other. Oops. Apparently the opentelementry-proto-java artifact can't be consumed by opentelemetry-java without this.

2024-04-23

Add new profile signal (#534) This is a follow up to [OTEP 239: Introduces Profiling Data Model v2](https://github.com/open-telemetry/oteps/pull/239) The main motivation behind this PR is that this will allow us to start experimenting with the profiles proto in opentelemetry-collector. I marked the profiles part as `Experimental` to indicate that this is not a final version of the data model. I copied the proto from the OTEP, and moved `pprofextended.proto` from `profiles/v1/alternatives/pprofextended.proto` to just `profiles/v1/pprofextended.proto`. I did this because I figured we no longer have alternative representations and this will reduce confusion for people outside of Profiling SIG. The rest of the proto stayed the same. I tested this file with a collector fork and I it compiles properly.

2024-02-02

Add metric.metadata for supporting additional metadata on metrics (#514) * add metric.attributes for supporting additional metadata on metrics

2024-01-30

Clarify formulas for reading span flags (#528) * Add bitshift to comment for reading span flags * Change >> to != 0

2024-01-23

One constant for link and parent is remote mask

Merge parent and link is remote enums into one

Add parent_span_is_remote to Span message

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>

Use enum for ParentSpanIsRemote

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Christian Neumüller <christian+github@neumueller.me>

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>

Remove ParentSpanIsRemote attribute

Include enum for interpreting ParentIsRemote flag and update documentation

Update inconsistency in docs formatting

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>

Update references to isremote masks

Adjust flags documentation ordering

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

Adjust formatting of comments

Remove misleading documentation

Adjust enum name

Add constants and enum for interpreting bits 8 and 9 of a Link's flags

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Joshua MacDonald <jmacd@users.noreply.github.com>

Split isremote into two masks

Remove enum, describe values in comment

Add extra comment about unset value from older clients

Update names

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Johannes Tax <johannes@johannes.tax>

Update opentelemetry/proto/trace/v1/trace.proto Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

Change doc references to updated enum name

Add defintion of 2 bit parent is remote flag

2023-11-07

Remove irrelevant comments from metric name field (#512)

2023-09-14

Add W3C-specified trace flags to v1 Span proto (#503)

2023-08-23

Add comment to explain schema_url fields Resolves https://github.com/open-telemetry/opentelemetry-proto/issues/502

2023-06-06

Clarify uniqueness of Scope attribute keys We use exact same wording as we already have for LogRecord, Span, etc.

2023-05-20

Fix LogRecordFlags and DataPointFlags enum element name inconsistency (#474) Other enum element names in this repo are prefixed by enum name in CAPITAL_CASE. This change makes naming of LogRecordFlags and DataPointFlags elements consistent with the rest of the enums. Resolves https://github.com/open-telemetry/opentelemetry-proto/issues/473 Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>

2023-05-15

Clarify bitfield helper enums Resolves https://github.com/open-telemetry/opentelemetry-proto/issues/433 ## Problem The zero values defined in helper enums encourage incorrect usage of the bitfields. The typical incorrect code looks like this: ```proto enum DataPointFlags { FLAG_NONE = 0; FLAG_NO_RECORDED_VALUE = 1; // Bits 2-31 are reserved for future use. } ``` ```go if datapoint.Flags == FLAG_NONE { // do something when there is no recorded value } ``` This is incorrect because it does not take into account that the Flags field can be extended in the future to use the reserved bits. The `if` statement above will be incorrect if any other bit is set. The correct code looks like this: ```go if (datapoint.Flags & FLAG_NO_RECORDED_VALUE) == 0 { // do something when there is no recorded value } ``` ## Solution To prevent this mistake the following changes are done: - All bitfield mask enums are suffixed with a _MASK to signify their purpose. - Zero value of the enum is prefixed with an underscore to discourage its use. - Some additional comments are added to explain how bitfields and their enums should be used. ## Alternates Tried I also tried to remove the zero values from enums altogether, but it turned out to be impossible. I tried a few possible approaches and none worked. Protobufs [require that enums start with a 0 value](https://protobuf.dev/programming-guides/proto3/#enum). If you try to omit it you get a compilation error: ``` opentelemetry/proto/metrics/v1/metrics.proto:325:28: The first enum value must be zero in proto3. ``` Alternatively, trying to use a dummy name, e.g.: ``` enum DataPointFlags { _ = 0; FLAG_NO_RECORDED_VALUE = 1; } ``` Fails Objective-C generator: ``` error: got empty string for making TextFormat data, input: "", desired: "_". ``` Also tried declaring it reserved as the doc says should be possible: ``` enum DataPointFlags { reserved 0; FLAG_NO_RECORDED_VALUE = 1; } ``` but get an error again: ``` opentelemetry/proto/metrics/v1/metrics.proto:327:28: The first enum value must be zero in proto3. ```

2023-05-11

Update opentelemetry/proto/metrics/v1/metrics.proto Fix field name Co-authored-by: Bogdan Drutu <lazy@splunk.com>

[chore] Change comment on `bucket_counts` to reflect spec. See https://opentelemetry.io/docs/reference/specification/metrics/data-model/#exponential-buckets

2023-05-04

Use "example.com" where an example domain is needed (#465)

2023-03-15

Remove optional part from zero_threshold (#453)

2023-01-27

Clarify behavior for empty/not present/invalid trace_id and span_id fields (#442) Resolves https://github.com/open-telemetry/opentelemetry-specification/issues/3040 This is not a breaking change: - For Span it now defines more precisely the receiver behavior that was previously defined vaguely (e.g. it was unclear what "empty" means for bytes field). - For LogRecord it now defines the receiver behavior that was previously unspecified. This ensures that the wording are consistent with what we have for the Span.

2023-01-23

Introduce an optional `zero_threshold` field to `ExponentialHistogramDataPoint` (#441)

2023-01-20

Delete requirement to generate new trace/span id if an invalid id is received (#444) This is considered an bug in the spec that was uncovered in the discussion here: https://github.com/open-telemetry/opentelemetry-proto/pull/442#discussion_r1061995668 I did some spelunking and the "generate" recommendation comes from the very first commit: https://github.com/open-telemetry/opentelemetry-proto/commit/b5bcfffce09c956b1419b2b56a9aaff384797517#diff-ef5f80fbf835dd57e14cb9264944f03d80cf6b04cc7671b0e7fb33167c67efcc where they were copied from Java repo, to which they were copied from OpenCensus https://github.com/open-telemetry/opentelemetry-java/pull/134 and in OpenCensus the wording first time appeared here https://github.com/census-instrumentation/opencensus-proto/pull/160 (authored by @SergeyKanzhelev, merged by @bogdandrutu). We are deleting the requirement to generate a new trace id or span id if an invalid id is received. The receivers can decide how they want to treat the invalid id (just like upon receiving any other invalid id), e.g. they may drop it, log an error, accept the invalid data, etc. We are not going to prescribe a particular receiver behavior when invalid trace/span id is received.

2022-08-19

Change the exponential histogram boundary condition (#409)

2022-08-08

fix a tiny typo and reflow (#421)

2022-08-03

Make it possible to indicate partial success in an OTLP export response [2] (#414) * Make it possible to indicate partial success in an OTLP export response * Update changelog with PR number * PR suggestions * Improve docs around using rejected as 0 to convey warnings * Adapt comments to match recent spec wording changes * Clarify behavior of partial success not set/empty

2022-07-20

Delete unused experimental TraceConfig (#411) Resolves https://github.com/open-telemetry/opentelemetry-proto/issues/410 I am not aware of any OpenTelemetry or non-OpenTelemetry codebase that uses the experimental TraceConfig. I suggest to remove it. It can be added back if we see the need for it in the future. The SDK configuration may also be achieved by different means, see https://github.com/open-telemetry/opentelemetry-specification/issues/2207 We need to keep this PR open for a while and circulate it widely to make sure we give enough opportunity to object the removal.

2022-06-28

Remove misleading comments for Span in trace.proto (#408)

2022-06-27

Delete deprecated InstrumentationLibrary-related fields and messages (#407) The fields and messages were scheduled to be deleted on June 15, 2022, so now is a good time to do it (especially before we declare OTLP 1.0).

2022-06-16

Fix urls which can not access (#402) - Fix some out-of-date urls which link to [specification](https://github.com/open-telemetry/opentelemetry-specification). - .../metrics/datamodel.md -> .../metrics/data-model.md - .../common/common.md#attributes -> .../common/README.md#attribute

2022-06-12

Introduce Scope Attributes (#395) Implements OTEP 201: https://github.com/open-telemetry/oteps/blob/main/text/0201-scope-attributes.md Corresponding specification PR: https://github.com/open-telemetry/opentelemetry-specification/pull/2579

2022-06-07

Define csharp_namespace option (#399) * Define csharp_namespace option * Update changelog

2022-05-17

Make the exponential histogram sum optional, like its counterpart (#392) * Make the exponential histogram sum optional, like its counterpart * PR Num

2022-04-29

Remove experimental note from logs service definition (#385)

2022-04-01

Add min/max fields to HistogramDataPoint (#279) * Add min/max fields to HistogramDataPoint * Typos * 10 minutes * make min/max optional but strictly refer to (start_time, end_time] * --experimental_allow_proto3_optional * remove gogo * Changelog * revert accidental makefile

2022-03-28

Remove deprecated LogRecord.Name field (#373) The field is already deprecated and was on notice to be removed. I removed all usages of the field from the Collector codebase.

2022-03-13

Add field of present flag to proto build (#366) * Add field presence flag to proto build. * Fix #314 - Cannot distinguish between sum being 0 and undefined. * remove gogo from Makefile Co-authored-by: Josh Suereth <joshuasuereth@google.com>

2022-03-09

Rename InstrumentationLibrary to InstrumentationScope (#362) This applies changes described in spec PR https://github.com/open-telemetry/opentelemetry-specification/pull/2276 This is not a breaking change for OTLP. The wire format does not change. The change is done in a way that the transition can be handled gracefully for OTLP/JSON and for the generated code. See the comments for explanation on how to do it in the senders and receivers.

2022-02-14

Deprecate LogRecord.Name field (#357) The field is removed from the spec: https://github.com/open-telemetry/opentelemetry-specification/pull/2271 I am deprecating it for now, to give some time to existing users to get rid of it (most notably in the Collector). This will be removed March 15, 2022 (after the Collector cleanup).

2022-02-09

Add ObservedTimestamp to LogRecord (#351) This implements the log data model specification change https://github.com/open-telemetry/opentelemetry-specification/pull/2184

Remove experimental metrics config service (#359) As far as I know this is currently not used by anyone. We prefer to delete this code instead of maintaining it. It can be added back when there is sufficient interest and a person who will maintain it.

Fix path to Go packages (#360) The go pacakges now correctly point to https://github.com/open-telemetry/opentelemetry-proto-go repository where we have the generated files for Go. Resolves https://github.com/open-telemetry/opentelemetry-proto/issues/353 Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>

2022-02-08

Remove unused deprecated message StringKeyValue (#358) Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>

2022-02-03

Clarify attribute key uniqueness requirement (#350) Attributes keys must be unique. The key/value pair list in the protocol was always intended to model a map. Contributes to https://github.com/open-telemetry/opentelemetry-specification/issues/2245 Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>

2022-01-18

Rename logs to log_records in InstrumentationLibraryLogs (#352) The renaming is to ensure consistency in how fields are named. We use pluralized name of the message type elsewhere, so let's use it here as well. Resolves https://github.com/open-telemetry/opentelemetry-proto/issues/317

2022-01-03

Remove deprecated messages and fields from metrics (#342) Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>

2021-12-21

Remove deprecated messages and fields from traces (#341) Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>

2021-10-06

Remove outdated comment on empty span name (#328) * Remove outdated comment on span name and replace it with recommendations from specification * Update guidance on empty span name Co-authored-by: Bogdan Drutu <bogdandrutu@gmail.com>

2021-09-29

Add proto messages for signals data independent of OTLP protocol (#332) The main motivation for this is to ensure that other protocols can use it to send/receive OTLP data, as well as for persistent storages such as kafka, disk, etc. Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>