package opentelemetry.proto.profiles.v1development

Mouse Melon logoGet desktop application:
View/edit binary Protocol Buffers messages

message Function

profiles.proto:476

Describes a function, including its human-readable name, system name, source file, and starting line number in the source.

Used in: ProfilesDictionary

message KeyValueAndUnit

profiles.proto:491

A custom 'dictionary native' style of encoding attributes which is more convenient for profiles than opentelemetry.proto.common.v1.KeyValue Specifically, uses the string table for keys and allows optional unit information.

Used in: ProfilesDictionary

message Line

profiles.proto:465

Details a specific line in a source code, linked to a function.

Used in: Location

A pointer from a profile Sample to a trace Span. Connects a profile sample to a trace span, identified by unique trace and span IDs.

Used in: ProfilesDictionary

message Location

profiles.proto:441

Describes function and line table debug information.

Used in: ProfilesDictionary

message Mapping

profiles.proto:418

Describes the mapping of a binary in memory, including its address range, file offset, and metadata like build ID

Used in: ProfilesDictionary

message Profile

profiles.proto:274

Represents a complete profile, including sample types, samples, mappings to binaries, stacks, locations, functions, string table, and additional metadata. It modifies and annotates pprof Profile with OpenTelemetry specific fields. Note that whilst fields in this message retain the name and field id from pprof in most cases for ease of understanding data migration, it is not intended that pprof:Profile and OpenTelemetry:Profile encoding be wire compatible.

Used in: ScopeProfiles

message ProfilesData

profiles.proto:188

ProfilesData represents the profiles data that can be stored in persistent storage, OR can be embedded by other protocols that transfer OTLP profiles data but do not implement the OTLP protocol. The main difference between this message and collector protocol is that in this message there will not be any "control" or "metadata" specific to OTLP protocol. When new fields are added into this message, the OTLP request MUST be updated as well.

message ProfilesDictionary

profiles.proto:123

ProfilesDictionary represents the profiles data shared across the entire message being sent. The following applies to all fields in this message: - A dictionary is an array of dictionary items. Users of the dictionary compactly reference the items using the index within the array. - A dictionary MUST have a zero value encoded as the first element. This allows for _index fields pointing into the dictionary to use a 0 pointer value to indicate 'null' / 'not set'. Unless otherwise defined, a 'zero value' message value is one with all default field values, so as to minimize wire encoded size. - There SHOULD NOT be dupes in a dictionary. The identity of dictionary items is based on their value, recursively as needed. If a particular implementation does emit duplicated items, it MUST NOT attempt to give them meaning based on the index or order. A profile processor may remove duplicate items and this MUST NOT have any observable effects for consumers. - There SHOULD NOT be orphaned (unreferenced) items in a dictionary. A profile processor may remove ("garbage-collect") orphaned items and this MUST NOT have any observable effects for consumers.

Used in: collector.profiles.v1development.ExportProfilesServiceRequest, ProfilesData

message ResourceProfiles

profiles.proto:206

A collection of ScopeProfiles from a Resource.

Used in: collector.profiles.v1development.ExportProfilesServiceRequest, ProfilesData

message Sample

profiles.proto:393

Each Sample records values encountered in some program context. The program context is typically a stack trace, perhaps augmented with auxiliary information like the thread-id, some indicator of a higher level request being handled etc. A Sample MUST have have at least one values or timestamps_unix_nano entry. If both fields are populated, they MUST contain the same number of elements, and the elements at the same index MUST refer to the same event. For the purposes of efficiently representing aggregated data observations, a Sample is regarded as having a shared identity and an associated collection of per-observation data points. Samples having the same identity SHOULD be combined by inserting timestamps and values to the data arrays. Examples of different ways ('shapes') of representing a sample with the total value of 10: Report of a stacktrace at 10 timestamps (consumers must assume the value is 1 for each point): values: [] timestamps_unix_nano: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] Report of a stacktrace with an aggregated value without timestamps: values: [10] timestamps_unix_nano: [] Report of a stacktrace at 4 timestamps where each point records a specific value: values: [2, 2, 3, 3] timestamps_unix_nano: [1, 2, 3, 4] All Samples for a Profile SHOULD have the same shape, i.e. all data observation series should consistently adopt the same data recording style.

Used in: Profile

message ScopeProfiles

profiles.proto:226

A collection of Profiles produced by an InstrumentationScope.

Used in: ResourceProfiles

message Stack

profiles.proto:434

A Stack represents a stack trace as a list of locations.

Used in: ProfilesDictionary

message ValueType

profiles.proto:355

ValueType describes the type and units of a value.

Used in: Profile