Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,6 +33,9 @@ release.

### Profiles

- Remove duplicate information from and extend Profiles documentation (README.md, pprof.md).
([#4932](https://github.com/open-telemetry/opentelemetry-specification/pull/4932))

### Resource

- Clarify that a Resource describes the observed entity, not the component
Expand Down
93 changes: 66 additions & 27 deletions specification/profiles/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,47 +6,74 @@ path_base_for_github_subdir:

# OpenTelemetry Profiles

**Status**: [Alpha](../document-status.md)

<details>
<summary>Table of Contents</summary>

<!-- toc -->

- [Overview](#overview)
- [Design goals](#design-goals)
- [Data Format](#data-format)
- [Known values](#known-values)
- [Specifications](#specifications)
- [References](#references)

<!-- tocstop -->

</details>

## Overview

Profiles are emerging as the fourth essential signal of observability, alongside
Comment thread
christos68k marked this conversation as resolved.
logs, metrics, and traces. They offer unparalleled insights into system and
application behavior, often uncovering performance bottlenecks overlooked by
other signals.

Profiles provide granular, time-based views of resource consumption and
code execution, encompassing:

* **Application-level profiling**: Reveals how software functions consume CPU,
memory, and other resources, highlighting slow or inefficient code.

* **System-level profiling**: Offers a holistic view of the infrastructure,
pinpointing issues in operating system calls, kernel operations, and I/O.

This performance picture can lead to:

* **Faster Root Cause Analysis**: Quickly identifies the exact cause of
performance degradation.
* **Proactive Optimization**: Identifies potential issues before user impact.
* **Improved Resource Utilization**: Optimizes infrastructure for cost savings
and efficiency.
* **Enhanced Developer Productivity**: Helps developers validate code performance
and prevent regressions.

In essence, while logs, metrics, and traces show "what" and "how much/where"
profiles explain "why" and "how efficiently" making them indispensable in modern
observability.
A **profile** is a collection of stack traces with associated values
representing resource consumption and code execution, collected from a
running program. Profiling is the process of collecting such profiles,
typically by sampling program state at regular intervals.

For a general introduction to OpenTelemetry profiling and how it complements other
observability signals, see [Profiles concepts](https://opentelemetry.io/docs/concepts/signals/profiles/).

## Design goals

The profiles signal is designed with the following goals in mind:

- **Low overhead**: Enable profiling agents to operate continuously in production
environments without materially impacting application performance.
- **Efficient representation**: Reduces volume of data stored and transmitted,
by using dictionary tables to deduplicate repeated information across samples.
- **Compatibility with existing formats**: The data format is a superset of
established profiling formats such as [pprof](https://github.com/google/pprof)
and in most cases supports lossless conversions to and from these formats.
If that's not possible (e.g. custom extensions), the `original_payload_format`
field can be used to transmit the original information for future lossless
export or reinterpretation.
- **Correlation with other signals**: Profiles MUST be linkable to logs, metrics
and traces through shared resource context and, where applicable,
direct trace/span references.

## Data Format

The OpenTelemetry profiles data format is [here](./data-format.md).
It builds on the [pprof protobuf format](https://github.com/google/pprof/tree/main/proto)
and extends it with:

- **Resource and scope context**: Each batch of profiles is associated with a
[Resource](../resource/README.md) and an [InstrumentationScope](../common/instrumentation-scope.md),
consistent with logs, metrics and traces.
- **Generalized dictionary**: Deduplicates not only strings but also other messages
that exhibit redundancy.
- **Generalized attributes**: Most messages can carry attributes following the
same conventions as other signals, augmented with Unit information (`KeyValueAndUnit`).
Comment thread
christos68k marked this conversation as resolved.
- **Span context references**: Samples MAY include a `Link` (span ID and trace ID),
enabling direct linking between a profile sample and the trace/span during
which it was captured.

For details on the required attributes for `Mapping` messages and the custom
hashing scheme for build ID generation, see [Mappings](./mappings.md).

For more information on compatibility with [pprof](https://github.com/google/pprof),
see [pprof](./pprof.md).

## Known values

Expand All @@ -61,3 +88,15 @@ tools, known values are utilized.
| Profile field | Known values |
| ------------- | ------------ |
| original_payload_format | [pprof](https://github.com/google/pprof/tree/main/proto), [jfr](https://en.wikipedia.org/wiki/JDK_Flight_Recorder) or [linux_perf](https://perfwiki.github.io/) |

## Specifications

* [Profiles Data Format](./data-format.md)
* [Profiles Mappings Attributes](./mappings.md)
* [Profiles Pprof Compatibility](./pprof.md)

## References

- [Profiles Concepts](https://opentelemetry.io/docs/concepts/signals/profiles/)
- [Profiles Semantic Conventions](https://opentelemetry.io/docs/specs/semconv/general/profiles/)
- [OTEP0212 OpenTelemetry Profiles Vision](../../oteps/profiles/0212-profiling-vision.md)
2 changes: 1 addition & 1 deletion specification/profiles/mappings.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Mappings

**Status**: [Development](../document-status.md)
**Status**: [Alpha](../document-status.md)

This document defines the required attributes of [`Mapping`](../../oteps/profiles/0239-profiles-data-model.md#message-mapping) messages.

Expand Down
15 changes: 8 additions & 7 deletions specification/profiles/pprof.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Pprof

**Status**: [Development](../document-status.md)
**Status**: [Alpha](../document-status.md)

<!-- toc -->

Expand All @@ -10,10 +10,11 @@

## Compatibility

Original [pprof](https://github.com/google/pprof/tree/main/proto) is forward
compatible with OpenTelemetry Profiles in a sense that it can be transformed into
OpenTelemetry Profiles and again into [pprof](https://github.com/google/pprof/tree/main/proto)
without data loss.
Original [pprof](https://github.com/google/pprof/tree/main/proto) is compatible
Comment thread
christos68k marked this conversation as resolved.
with OpenTelemetry Profiles in that it can be transformed into OpenTelemetry Profiles
and back again into [pprof](https://github.com/google/pprof/tree/main/proto) without
data loss (convertibility but not wire compatibility).

To enable this compatibility through explicit conversion, OpenTelemetry provides pprof-specific [guidelines](https://opentelemetry.io/docs/specs/semconv/general/profiles/#compatibility-with-pprof)
in [Semantic Conventions](https://opentelemetry.io/docs/specs/semconv).

For this compatibility OpenTelemetry also provides a `pprof` namespace in
Semantic Conventions.
Loading