Feedback on profiles protobuf format

[airbnb-gps]

I was instructed to file a GitHub issue with comments on the profiles protobuf format.

Undesirable gzip Requirement

opentelemetry-proto/opentelemetry/proto/profiles/v1development/profiles.proto

Line 163 in b41217b

// - On-disk, the serialized proto must be gzip-compressed.

On-disk, the serialized proto must be gzip-compressed.

Pretty sure this was initially copied from the pprof proto file.

Gzip/zlib/deflate should not be required exclusively in 2025 for performance reasons. It's fine to mandate support for that compression format given its popularity. But mandating exclusive use is ill-advised since there are more modern compression formats (e.g. zstd) that yield better compression ratios and require less CPU per byte being compressed and decompressed. (On the decompression side zstd is often 5x faster than gzip.)

Mandating a 30 year old and inferior compression format is wasteful. Please don't.

(For the record I operate processes that are CPU bottlenecked on gzip in pprof. I hope this artificial bottleneck doesn't get propagated to Otel.)

Better Annotation of Source Code

pprof and Otel profiling today lack the ability to richly represent source code. They can describe a location in source code (Location, Line, Function, Mapping). But the profile format doesn't have a way to store the actual source code or provide a defined way to link back to it.

I think a killer feature of profile visualizers is the turnkey ability to integrate with source code. When you do this right, you are able to get a line-by-line breakdown of profile samples and explore the call chain leading to hot code.

One idea is a unified, self-describing profile that contains its source code. This would entail new protobuf messages for storing source code.

One feature Otel profiling has that pprof doesn't is arbitrary attributes on Location. These attributes can be used to express e.g. where the source code lives in VCS or the URL to access it at. This functionality may be sufficient to enable Otel profiles to convey source code information. It may be useful to also allow arbitrary attributes on Function and/or Line since these are closer to source code and attributes to describe source code may be more appropriate on these versus Location.

[tigrannajaryan]

@open-telemetry/profiling-maintainers