-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Problem Statement
Right now, the Logs API has similar abstractions to ones in attribute
package. For instance, log.KeyValue
is almost an equivalent of attribute.KeyValue
.
Because of the different types, Logs API provides log.KeyValueFromAttribute
which also shows that the intention when the types are used is similar.
What is more with OTEP: Extending attributes to support complex values #4485 we have an agreement that attribute
is going to be eventually extended with new types that are now available only in logs signals (ones the addition of new attributes types is stabilized in the specification). Prototype of the new attribute value types: #6809.
Proposed Solution
Remove log.KeyValue
(and all related definitions) and use attribute
package instead.
The bridges would marshal the values to JSON and use the attribute.String
in places where log.MapValue
, log.SliceValue
and log.BytesValue
are currently used: https://github.com/open-telemetry/opentelemetry-go-contrib/blob/main/internal/shared/logutil/convert.go.tmpl.
Alternatives
Keep the log.[Key]Value
types to allow usage of the additional value types that are not yet stable for places other than log record attributes and body. However, long-term this would cause unnecessary duplication of types and cause user-confusion why we have different types in the logs API. It would also increase the amount of code that we would have to maintain.
Additional Context
This issue and OTEP: Extending attributes to support complex values #4485 is the main reason why Logs API has not been stabilized yet.
The OTel Go SIG wants very much to simplify the design and prefer to remove the log.[Key]Value
types.
We should also update: https://github.com/open-telemetry/opentelemetry-go/blob/main/log/DESIGN.md
Metadata
Metadata
Assignees
Labels
Type
Projects
Status