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.

Sign up for GitHub

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

Jump to bottom

Propose new StructuredBody field for logs #3014

Closed
wants to merge 1 commit into from
Closed

Propose new StructuredBody field for logs #3014

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
11 changes: 10 additions & 1 deletion specification/logs/data-model.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -464,6 +464,15 @@ OpenTelemetry [semantic conventions for Log Attributes](./semantic_conventions/R
[semantic conventions for Span Attributes](../trace/semantic_conventions/README.md).
This field is optional.

### Field: `StructuredBody`

Type: `map<string, any>`.

Description: A structured representation of the log record (see the description
of `any` type above). Can vary for each occurrence of the event coming from the
same source. This field is optional. SHOULD follow OpenTelemetry [semantic conventions
for Log Bodies (TODO)](./semantic_conventions/README.md). This field is optional.

#### Errors and Exceptions

Additional information about errors and/or exceptions that are associated with
Expand Down Expand Up @@ -946,7 +955,7 @@ Field | Type | Description
timestamp | string | The time the event described by the log entry occurred. | Timestamp
resource | MonitoredResource | The monitored resource that produced this log entry. | Resource
log_name | string | The URL-encoded LOG_ID suffix of the log_name field identifies which log stream this entry belongs to. | Attributes["gcp.log_name"]
json_payload | google.protobuf.Struct | The log entry payload, represented as a structure that is expressed as a JSON object. | Body
json_payload | google.protobuf.Struct | The log entry payload, represented as a structure that is expressed as a JSON object. | StructuredBody
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does roughly align but may need some more thought from the Google side to line up properly; if there is a Body with the message, that message should likely go into jsonPayload.message. Not sure what the best way to codify that here would be.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, how does this reconcile with current users who may be parsing structured data to body? If body is structured, that will still go to json_payload too, or do we start flattening anything that's in body? This could be an implementation detail

proto_payload | google.protobuf.Any | The log entry payload, represented as a protocol buffer. | Body
text_payload | string | The log entry payload, represented as a Unicode string (UTF-8). | Body
severity | LogSeverity | The severity of the log entry. | Severity
Expand Down