Propose OpenTelemetry Profiling Vision

[Rperry2174]

This change proposes high-level items that define our long-term vision for
Profiling support in OpenTelemetry project.

A group of open source maintainers, vendors, end-users, and developers excited about profiling / otel have been meeting for ~8 weeks now and this document was created collectively in order to share with the broader community for feedback. We've had ~15 people contribute directly to the document and over 60 people who have attended our meetings over the past couple of months.

This idea of "Adding profiling as a support event type" has also been discussed at length in this issue created in October 2020.

If this proposal is accepted/approved then we will proceed with filling out this project tracking issue and following the other procedures outlined in the project management instructions.

Comments, ideas, feedback, etc. are all very welcome and highly appreciated!

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Rperry2174 / name: Ryan Perry (96cf8da)

[tigrannajaryan]

Mostly LGTM, thank you.

Approving, this is aligned with my vision as well.

[halcyondude]

+1 NB

[SeanHeelan]

lgtm, just a couple of minor wording fixes from the performance section I added in the original doc.

[carlosalberto]

Overall LGTM - I'm a little curious about the initial implementation and its target languages (it seems that it has been informally established the effort will start with Go and Java profiling?)

[yurishkuro]

I am supportive of this vision, but there seems to be a glaring omission in the document - the terms "profile" and "profiling" are never defined. Since this is essentially proposing a new type of telemetry signal to be included in the project, can you provide a clear definition?

[crobert-1]

Just some minor nits, otherwise LGTM!

[halcyondude]

This captures the vision and spirit of the discussions over the past few months, and is a good position from which to start this collaborative effort. I support!

+1

[kittylyst]

Decent statement of high-level intent.

[chadbrewbaker]

If I had to make it more concrete - I might adopt the Rust targets for OS/libc/CPU as a first approximation - especially for embedded CPUs.

On a geospatial level - lat/long would be useful data for network flow modeling. Also network triangulation like pings to three servers - bandwidth might be harder to measure.

[Rperry2174]

I believe all comments have been addressed let me know if anything else needs to be before merging!

[tigrannajaryan]

This vision now has a large number of approvals from existing OpenTelemetry members, from OpenTelemetry Technical Committee and Governance Committee and from the new Profiling Workgroup members.

I believe this shows a clear alignment on the vision from all participants.

Members of @open-telemetry/technical-committee if you haven't had a chance to review this vision, please do.

I will merge the PR and will consider this current vision accepted by OpenTelemetry Profiling if I don't see any further comments.

[tigrannajaryan]

No new comments. Lots of approvals. Merging.