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.
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'.
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>
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>
#576 excluded the profiles definition from breaking changes.
But the entire profiles protocol is in development and can have breaking changes, including the gRPC service.
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.
The Profiles protocol is still experimental. Exclude it from the
breaking-changes check as such changes are expected at this stage.
Signed-off-by: Florian Lehner <florian.lehner@elastic.co>
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>
In the `Protocol Details` section the spec states that it defines how OTLP is implemented over grpc and **http 1.1**, but later in the document in section `OTLP/HTTP` it states "Implementations MAY use HTTP/1.1 or HTTP/2 transports."
This may confuse end readers and I suggest that it is easier to drop the 1.1 in the Protocol Details section.
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.
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.