package opentelemetry.proto.logs.v1

Get desktop application:
View/edit binary Protocol Buffers messages

A collection of Logs produced by an InstrumentationLibrary. InstrumentationLibraryLogs is wire-compatible with ScopeLogs for binary Protobuf format. This message is deprecated and will be removed on June 15, 2022.

Used in: ResourceLogs

• optional common.v1.InstrumentationLibrary instrumentation_library = 1

  The instrumentation library information for the logs in this message. Semantically when InstrumentationLibrary isn't set, it is equivalent with an empty instrumentation library name (unknown).

• repeated LogRecord log_records = 2

  A list of logs that originate from an instrumentation library.

• string schema_url = 3

  This schema_url applies to all logs in the "logs" field.

A log record according to OpenTelemetry Log Data Model: https://github.com/open-telemetry/oteps/blob/main/text/logs/0097-log-data-model.md

Used in: InstrumentationLibraryLogs, ScopeLogs

• fixed64 time_unix_nano = 1

  time_unix_nano is the time when the event occurred. Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970. Value of 0 indicates unknown or missing timestamp.

• fixed64 observed_time_unix_nano = 11

  Time when the event was observed by the collection system. For events that originate in OpenTelemetry (e.g. using OpenTelemetry Logging SDK) this timestamp is typically set at the generation time and is equal to Timestamp. For events originating externally and collected by OpenTelemetry (e.g. using Collector) this is the time when OpenTelemetry's code observed the event measured by the clock of the OpenTelemetry code. This field MUST be set once the event is observed by OpenTelemetry. For converting OpenTelemetry log data to formats that support only one timestamp or when receiving OpenTelemetry log data by recipients that support only one timestamp internally the following logic is recommended: - Use time_unix_nano if it is present, otherwise use observed_time_unix_nano. Value is UNIX Epoch time in nanoseconds since 00:00:00 UTC on 1 January 1970. Value of 0 indicates unknown or missing timestamp.

• SeverityNumber severity_number = 2

  Numerical value of the severity, normalized to values described in Log Data Model. [Optional].

• string severity_text = 3

  The severity text (also known as log level). The original string representation as it is known at the source. [Optional].

• optional common.v1.AnyValue body = 5

  A value containing the body of the log record. Can be for example a human-readable string message (including multi-line) describing the event in a free form or it can be a structured data composed of arrays and maps of other values. [Optional].

• repeated common.v1.KeyValue attributes = 6

  Additional attributes that describe the specific event occurrence. [Optional]. Attribute keys MUST be unique (it is not allowed to have more than one attribute with the same key).

• uint32 dropped_attributes_count = 7

• fixed32 flags = 8

  Flags, a bit field. 8 least significant bits are the trace flags as defined in W3C Trace Context specification. 24 most significant bits are reserved and must be set to 0. Readers must not assume that 24 most significant bits will be zero and must correctly mask the bits when reading 8-bit trace flag (use flags & TRACE_FLAGS_MASK). [Optional].

• bytes trace_id = 9

  A unique identifier for a trace. All logs from the same trace share the same `trace_id`. The ID is a 16-byte array. An ID with all zeroes is considered invalid. Can be set for logs that are part of request processing and have an assigned trace id. [Optional].

• bytes span_id = 10

  A unique identifier for a span within a trace, assigned when the span is created. The ID is an 8-byte array. An ID with all zeroes is considered invalid. Can be set for logs that are part of a particular processing span. If span_id is present trace_id SHOULD be also present. [Optional].

Masks for LogRecord.flags field.

• LOG_RECORD_FLAG_UNSPECIFIED = 0

• LOG_RECORD_FLAG_TRACE_FLAGS_MASK = 255

LogsData represents the logs data that can be stored in a persistent storage, OR can be embedded by other protocols that transfer OTLP logs 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.

• repeated ResourceLogs resource_logs = 1

  An array of ResourceLogs. For data coming from a single resource this array will typically contain one element. Intermediary nodes that receive data from multiple origins typically batch the data before forwarding further and in that case this array will contain multiple elements.

A collection of ScopeLogs from a Resource.

Used in: collector.logs.v1.ExportLogsServiceRequest, LogsData

• optional resource.v1.Resource resource = 1

  The resource for the logs in this message. If this field is not set then resource info is unknown.

• repeated ScopeLogs scope_logs = 2

  A list of ScopeLogs that originate from a resource.

• repeated InstrumentationLibraryLogs instrumentation_library_logs = 1000

  A list of InstrumentationLibraryLogs that originate from a resource. This field is deprecated and will be removed after grace period expires on June 15, 2022. During the grace period the following rules SHOULD be followed: For Binary Protobufs ==================== Binary Protobuf senders SHOULD NOT set instrumentation_library_logs. Instead scope_logs SHOULD be set. Binary Protobuf receivers SHOULD check if instrumentation_library_logs is set and scope_logs is not set then the value in instrumentation_library_logs SHOULD be used instead by converting InstrumentationLibraryLogs into ScopeLogs. If scope_logs is set then instrumentation_library_logs SHOULD be ignored. For JSON ======== JSON senders that set instrumentation_library_logs field MAY also set scope_logs to carry the same logs, essentially double-publishing the same data. Such double-publishing MAY be controlled by a user-settable option. If double-publishing is not used then the senders SHOULD set scope_logs and SHOULD NOT set instrumentation_library_logs. JSON receivers SHOULD check if instrumentation_library_logs is set and scope_logs is not set then the value in instrumentation_library_logs SHOULD be used instead by converting InstrumentationLibraryLogs into ScopeLogs. If scope_logs is set then instrumentation_library_logs field SHOULD be ignored.

• string schema_url = 3

  This schema_url applies to the data in the "resource" field. It does not apply to the data in the "scope_logs" field which have their own schema_url field.

A collection of Logs produced by a Scope.

Used in: ResourceLogs

• optional common.v1.InstrumentationScope scope = 1

  The instrumentation scope information for the logs in this message. Semantically when InstrumentationScope isn't set, it is equivalent with an empty instrumentation scope name (unknown).

• repeated LogRecord log_records = 2

  A list of log records.

• string schema_url = 3

  This schema_url applies to all logs in the "logs" field.

Possible values for LogRecord.SeverityNumber.

Used in: LogRecord

• SEVERITY_NUMBER_UNSPECIFIED = 0

  UNSPECIFIED is the default SeverityNumber, it MUST NOT be used.

• SEVERITY_NUMBER_TRACE = 1

• SEVERITY_NUMBER_TRACE2 = 2

• SEVERITY_NUMBER_TRACE3 = 3

• SEVERITY_NUMBER_TRACE4 = 4

• SEVERITY_NUMBER_DEBUG = 5

• SEVERITY_NUMBER_DEBUG2 = 6

• SEVERITY_NUMBER_DEBUG3 = 7

• SEVERITY_NUMBER_DEBUG4 = 8

• SEVERITY_NUMBER_INFO = 9

• SEVERITY_NUMBER_INFO2 = 10

• SEVERITY_NUMBER_INFO3 = 11

• SEVERITY_NUMBER_INFO4 = 12

• SEVERITY_NUMBER_WARN = 13

• SEVERITY_NUMBER_WARN2 = 14

• SEVERITY_NUMBER_WARN3 = 15

• SEVERITY_NUMBER_WARN4 = 16

• SEVERITY_NUMBER_ERROR = 17

• SEVERITY_NUMBER_ERROR2 = 18

• SEVERITY_NUMBER_ERROR3 = 19

• SEVERITY_NUMBER_ERROR4 = 20

• SEVERITY_NUMBER_FATAL = 21

• SEVERITY_NUMBER_FATAL2 = 22

• SEVERITY_NUMBER_FATAL3 = 23

• SEVERITY_NUMBER_FATAL4 = 24