Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Attributes field type in Logs Data Model #3816

Closed
Closed
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

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

### Logs

- Update types of Resource and Attributes fields in Logs Data Model.
([#3814](https://github.com/open-telemetry/opentelemetry-specification/pull/3814))

### Resource

### OpenTelemetry Protocol
Expand Down
22 changes: 11 additions & 11 deletions specification/logs/data-model.md
Original file line number Diff line number Diff line change
Expand Up @@ -131,11 +131,11 @@ fields:

- Named top-level fields of specific type and meaning.

- Fields stored as `map<string, any>`, which can contain arbitrary values of
different types. The keys and values for well-known fields follow semantic
conventions for key names and possible values that allow all parties that work
with the field to have the same interpretation of the data. See references to
semantic conventions for `Resource` and `Attributes` fields and examples in
- Fields that can contain arbitrary values of different types. The keys and
values for well-known fields follow semantic conventions for key names and
possible values that allow all parties that work with the field to have the
same interpretation of the data. See references to semantic conventions for
`Resource` and `Attributes` fields and examples in
[Appendix A](./data-model-appendix.md#appendix-a-example-mappings).

The reasons for having these 2 kinds of fields are:
Expand All @@ -147,9 +147,9 @@ The reasons for having these 2 kinds of fields are:
- Ability to enforce types of named fields, which is very useful for compiled
languages with type checks.

- Flexibility to represent less frequent data as `map<string, any>`. This
includes well-known data that has standardized semantics as well as arbitrary
custom data that the application may want to include in the logs.
- Flexibility to represent less frequent data. This includes well-known data
that has standardized semantics as well as arbitrary custom data that the
application may want to include in the logs.

When designing this data model we followed the following reasoning to make a
decision about when to use a top-level named field:
Expand Down Expand Up @@ -402,7 +402,7 @@ corresponding short names).

### Field: `Body`

Type: any.
Type: [`any`](#type-any).

Description: A value containing the body of the log record (see the description
of `any` type above). Can be for example a human-readable string message
Expand All @@ -415,7 +415,7 @@ source. This field is optional.

### Field: `Resource`

Type: `map<string, any>`.
Type: [Resource](../resource/sdk.md).
pellared marked this conversation as resolved.
Show resolved Hide resolved

Description: Describes the source of the log, aka
[resource](../overview.md#resources). Multiple occurrences of events coming from
Expand Down Expand Up @@ -444,7 +444,7 @@ is optional.

### Field: `Attributes`

Type: `map<string, any>`.
Type: [Attribute Collection](../common/README.md#attribute-collections).
pellared marked this conversation as resolved.
Show resolved Hide resolved

Description: Additional information about the specific event occurrence. Unlike
the `Resource` field, which is fixed for a particular source, `Attributes` can
Expand Down