From cc06312d91b85ecba46090d888da5a0153a7742a Mon Sep 17 00:00:00 2001 From: Abhijeet Prasad Date: Tue, 4 Mar 2025 16:19:10 -0500 Subject: [PATCH 1/6] feat(logs): intial work on develop docs for sdk logging api --- .../sdk/data-model/envelope-items.mdx | 5 + develop-docs/sdk/telemetry/logs.mdx | 262 ++++++++++++++++++ 2 files changed, 267 insertions(+) create mode 100644 develop-docs/sdk/telemetry/logs.mdx diff --git a/develop-docs/sdk/data-model/envelope-items.mdx b/develop-docs/sdk/data-model/envelope-items.mdx index 31171a50a4fcb..32b7d041955c0 100644 --- a/develop-docs/sdk/data-model/envelope-items.mdx +++ b/develop-docs/sdk/data-model/envelope-items.mdx @@ -427,6 +427,11 @@ details. *None* +### Logs + +Item type `"logs"` contains a check-in payload encoded as JSON. + + ### Reserved Types Reserved types may not be written by any implementation. They are reserved for diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx new file mode 100644 index 0000000000000..26f3be39f873d --- /dev/null +++ b/develop-docs/sdk/telemetry/logs.mdx @@ -0,0 +1,262 @@ +--- +title: Logs +sidebar_order: 3 +--- + + + +The Sentry Logs feature is under active development. The information in this document is subject to change. + + + +This document defines the format used by Sentry to ingest logs, as well as the SDK API and behavior that creates and sends logs to Sentry. + +## Logs Protocol + +Logs can be sent in two ways to Sentry, via the `logs` envelope and Sentry Log Schema, or the `otel_log` envelope and OpenTelemetry Log Schema. The `logs` envelope is the preferred way to send logs to Sentry, but the `otel_log` envelope is also supported. + +### `logs` Envelope + +### Log Severity Level + +The log severity level is a string that represents the severity of the log. The Sentry's default log severity level maps exactly to [OpenTelemetry's Severity text field](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitytext) on the OpenTelemetry Logs Spec.. + +- `trace` +- `debug` +- `info` +- `warn` +- `error` +- `fatal` + +Optionally the SDK can define a `log` log severity level, which maps to the `info` log severity level in Sentry. + +## Public API + +API wise the SDKs are required to expose logging methods which are to be defined in a `logger` module or namespace. The SDKs should also include some initialization options to configure the behavior of logs in the SDK. + +### Initialization Options + +The SDKs need to expose the following two configuration options: + +- `enableSentryLogs`/`enable_sentry_logs`: A boolean flag to control if log envelopes will be generated and sent to Sentry via the Sentry SDK's Logging APIs. If this flag is set to `false`, the SDK should not send logs to Sentry. Defaults to `false`. + +- `beforeSendLog`/`before_send_log`: A function that takes a log object and returns a log object. This function is called before sending the log to Sentry. It can be used to modify the log object or to prevent the log from being sent to Sentry. Defaults to `null`/`unset`. + +```js +Sentry.init({ + enableSentryLogs: true, + + beforeSendLog(log) { + // Prevent logs from being sent to Sentry if the plan type is enterprise + if (log.attributes["plan.type"] === "enterprise") { + return null; + } + + return log; + }, +}); +``` + +At the current moment, logs are not sampled so no sampling configuration needs to be exposed. This may change in the future. + +### Logger Module + +At minimum the SDK needs to implement the following two items to be considered to have a complete logging public API: + +1. `Sentry.logger.X` (where `X` is the log level): The log levels are `trace`, `debug`, `info`, `warn`, `error`, and `fatal`, which is specced out by the [protocol below](#log-severity-level). These methods accepts a string template and the parameters to that string template so the SDK can perform structured logging. Optionally these methods take arbitrary attributes, but not all languages can support both passing a parameterized template and attributes in an easy way. + +- `Sentry.logger.trace` +- `Sentry.logger.debug` +- `Sentry.logger.info` +- `Sentry.logger.warn` +- `Sentry.logger.error` +- `Sentry.logger.fatal` + +```js +Sentry.logger.info`Adding item ${itemId} for user ${userId}`; + +Sentry.logger.warn("User %s performed action %s", [userId, actionName], { + extra: "123", +}); +``` + +2. `Sentry.logger.emit`: A more verbose version of the `Sentry.logger.X` methods that accepts a log object/dictionary for maximum customizability. This is only meant to be used by power users, who want full control over what exactly is being set. Note that this API aligns with [OTEL's default logging API](https://opentelemetry.io/docs/specs/otel/logs/api/#emit-a-logrecord) as well, which gives us flexibility to align on those in the future. + +Emit should take the following parameters: + +- `level`: The log severity level of the log. One of `trace`, `debug`, `info`, `warn`, `error`, `fatal`. +- `message`: The log body +- `attributes`: An object/dictionary of key-value pairs of arbitrary data attached to the log. This should not be a nested data structure. If a object or dictionary is passed in, SDKs can choose to either disregard the attribute, or serialize the object into a string. +- `severityNumber`: An optional integer that represents the severity of the log. See [Log Severity Number](#log-severity-number) for more information. + +```js +Sentry.logger.emit({ + level: "info", + message: "Adding item for user", + attributes: { + itemId, + userId, + }, + severityNumber: 11, +}); +``` + +Beyond the two specified sets of methods, SDKs are free to add any extra helpers as they feel is necessary. For example, they could choose to add specialized decorators or helpers for string template creation. + +Below are some example SDK implementations to get you started. These are not finalized versions of the API and individual SDK authors should ensure the logging APIs best fit their platforms. When an SDK implements the logging API, this section should be updated with the SDK's specific implementation. + +#### JavaScript + +```jsx +// Browser JavaScript - need to rely on tagged template literals for string templating +Sentry.logger.info(Sentry.logger.fmt`Adding item ${itemId} for user ${userId}`); + +// Server-side (Node.js, Bun, Deno) with printf-like syntax +Sentry.logger.info("Adding item %s for user %s", [itemId, userId], { + extra: 123, +}); + +Sentry.logger.emit({ + level: "info", + message: "Adding item for user", + attributes: { + itemId, + userId, + extra: 123, + }, +}); +``` + +#### Python + +```python +# With f-string like syntax +Sentry.logger.info('Adding item {item} for user {user}', item=item_id, user=user_id, attributes={ 'extra': 123 }); + +Sentry.logger.emit( + level='info', + message='Adding item for user', + attributes={ + 'item_id': item_id, + 'user_id': user_id, + extra: 123 + }, +) +``` + +#### PHP + +```php +use function Sentry\logger; + +logger()->info('Adding item %s for user %s', [$item_id, $user_id], ['extra' => 123]); + +logger()->emit( + level: LogLevel::info(), + message: 'Adding item for user', + attributes: [ + 'item_id': item_id, + 'user_id': user_id, + 'extra': 123 + ], +); +``` + +#### Java + +```java +import io.sentry.Sentry; + +// example with MessageFormat based string template +Sentry.logger().info("Adding item {0,string} for user {1,string}", item_id, user_id); + +Sentry.logger().emit(log -> { + log.setLevel("info"); + log.setMessage("Adding item for user"); + log.setAttribute("item_id", item_id); + log.setAttribute("user_id", user_id); + log.setAttribute("extra", 123); +}); + +// Java - Builder Pattern, where setters return builder for method chaining +Sentry.Logger.emit(log -> { + log.setLevel("info") + .setMessage("Adding item for user") + .setAttribute("item_id", item_id) + .setAttribute("user_id", user_id) + .setAttribute("extra", 123) +}); + +// Kotlin +Sentry.Logger.emit("Adding item for user") { // fun emit(block: LogItem.() -> Unit) + setLevel("info") + setAttribute("item_id", item_id) + setAttribute("user_id", user_id) + setAttribute("extra", 123) +} +``` + +#### Apple + +```swift +// Swift +SentrySDK.logger + .info(message: "Adding item %s for user %s", + params: [itemId, userId], + attributes: ["extra": @"123"] + ) + +// Objective-C +[SentrySDK.logger + emit :@"Adding item for user" + level: @"info" + attributes: @{ @"extra" : @"123", @"item_id" : item_id, @"user_id" : user_id } +]; +``` + +#### Threading and Concurrency Considerations + +Both the `Sentry.logger.X` and `Sentry.logger.emit` methods are fire-and-forget (have no return value). This means that the SDK can choose to run these methods on a separate thread or queue them up for processing later. This includes evaluating the string template, and running any internal hooks (like `beforeSendLog`). The SDK should ensure that the logs are sent in the order they are received. + +## SDK behavior + +### Implementation + +If `debug` is set to `true` in SDK init, calls to the Sentry logger API should also print to the console with the appropriate log level. This will help debugging logging setups. + +Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. A recommended condition is if the buffer length exceeds 25 items, or if 5 seconds have passed. In the future we can use a [weight-tracking based approach](https://github.com/getsentry/rfcs/blob/main/text/0126-sdk-spans-aggregator.md#weight) to determine when to flush logs. + +We recommend exposing + +The internal SDK implementation is kept purposefully broad as we are still in early stages. As we figure more out about the logs product and payload characteristics, we'll be able to define a more rigorous spec for logging internals in the SDK. SDKs should take care to not expose logging internals as much as possible to userland so that they can be refactored in the future. + +### Default Attributes + +By default the SDK should set the following attributes: + +1. `sentry.message.template`: The parameterized template string +2. `sentry.message.parameters.X`: The parameters to the template string, where X is the number that represent the parameters position in the template string +3. `sentry.environment`: The environment set in the SDK +4. `sentry.release`: The release set in the SDK + +Example: + +```json +{ + "sentry.message.template": "Adding item %s for user %s", + "sentry.message.parameters.0": "item_id", + "sentry.message.parameters.1": "user_id", + "sentry.environment": "production", + "sentry.release": "1.0.0" +} +``` + +Beyond these attributes, we are exploring if the SDK should also send OS, user, and device information automatically (via reading the appropriate contexts from the scope). Given this behaviour can easily be added as a new feature to the SDK, it does not have to be part of the initial SDK implementation until we make a finalized decision. + +### SDK Integrations + +SDKs should aim to have it so that console/logger integrations create logs as per the appropriate log level if `enableSentryLogs` is set to true. Examples of this include JavaScript's `console` methods and Pythons `logging` standard library. + +If SDK authors feel the need, they can also introduce additional options to beyond `enableSentryLogs` to gate this functionality. For example an option to control log appenders added via external config like with `Log4j` in the Java SDK. + +### Default Attributes From a6a809137d62bf7a38cf1cbe1b12b63408f51143 Mon Sep 17 00:00:00 2001 From: Abhijeet Prasad Date: Wed, 5 Mar 2025 15:00:03 -0500 Subject: [PATCH 2/6] feat: Document otel_log envelope --- .../sdk/data-model/envelope-items.mdx | 35 +++++- develop-docs/sdk/telemetry/logs.mdx | 116 +++++++++++++++++- 2 files changed, 146 insertions(+), 5 deletions(-) diff --git a/develop-docs/sdk/data-model/envelope-items.mdx b/develop-docs/sdk/data-model/envelope-items.mdx index 32b7d041955c0..29ef867d9757c 100644 --- a/develop-docs/sdk/data-model/envelope-items.mdx +++ b/develop-docs/sdk/data-model/envelope-items.mdx @@ -429,8 +429,41 @@ details. ### Logs -Item type `"logs"` contains a check-in payload encoded as JSON. +Item type `"logs"` contains a logs payload encoded as JSON. Multiple log envelope items can be sent in a single envelope. +See the Logs documentation for the payload +details. + +**Constraints:** + +*None* + +**Envelope Headers:** + +*None* + +**Additional Item Headers:** + +*None* + +### Otel Logs + +Item type `"otel_logs"` contains a OpenTelemetry Logs payload encoded as JSON. Multiple Otel log envelope items can be sent in a single envelope. + +See the Logs documentation for the payload +details. + +**Constraints:** + +*None* + +**Envelope Headers:** + +*None* + +**Additional Item Headers:** + +*None* ### Reserved Types diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx index 26f3be39f873d..bbd924da17902 100644 --- a/develop-docs/sdk/telemetry/logs.mdx +++ b/develop-docs/sdk/telemetry/logs.mdx @@ -13,9 +13,102 @@ This document defines the format used by Sentry to ingest logs, as well as the S ## Logs Protocol -Logs can be sent in two ways to Sentry, via the `logs` envelope and Sentry Log Schema, or the `otel_log` envelope and OpenTelemetry Log Schema. The `logs` envelope is the preferred way to send logs to Sentry, but the `otel_log` envelope is also supported. +Logs can be sent in two ways to Sentry, via the `log` envelope and Sentry Log protocol, or the `otel_log` envelope and OpenTelemetry Log protocol. The `log` envelope and protocol is the preferred way to send logs to Sentry, but the `otel_log` envelope and protocol is also supported. -### `logs` Envelope +### `otel_log` Envelope Item Payload + +The `otel_log` envelope item payload is a JSON object that represents a OpenTelemetry Log. Multiple `otel_log` envelope items can be sent in a single envelope. + +```json +{ + "severity_text": "info", + "body": { + "string_value": "User John has logged in!" + }, + "attributes": [ + { + "key": "sentry.message.template", + "value": { "string_value": "User %s has logged in!" } + }, + { + "key": "sentry.message.parameters.0", + "value": { "string_value": "John" } + } + ], + "time_unix_nano": "1741191250694000000", + "trace_id": "edec519707974fc8bfccb5a017e17394", + "severity_number": 9 +} +``` + +It consists of the following fields: + +`severity_text` + +: **String, required**. The severity level of the log. One of `trace`, `debug`, `info`, `warn`, `error`, `fatal` (in order of lowest to highest). + +`severity_number` + +: **Integer, optional**. The severity number of the log. See [Log Severity Number](#log-severity-number) for more information. + +`trace_id` + +: **Integer, optional**. [HEAVILY RECOMMENDED] The trace id of the log. SDKs should attempt to set this if possible. This is used to link logs to traces and errors in Sentry. + +`body` + +: **Object, required**. The log body/message. + +Example: + +```json +{ + "string_value": "Added item to shopping cart" +} +``` + +`attributes` + +: **Array\, optional**. A dictionary of key-value pairs of arbitrary data attached to the log. Attributes must also declare the type of the value. The following types are supported: `string`, `number`, `boolean`, `integer`, `double`. + +Example: + +```json +{ + "attributes": [ + { + "key": "string_item", + "value": { + "stringValue": "value" + } + }, + { + "key": "integer_item", + "value": { + "intValue": 123 + } + }, + { + "key": "boolean_value", + "value": { + "boolValue": false + } + }, + { + "key": "double_item", + "value": { + "stringValue": "value" + } + } + ] +} +``` + +### `log` Envelope Item Payload + +The `log` envelope item payload is a JSON object that represents a log. + +TODO: Document `log` Envelope Item Payload once finalized. ### Log Severity Level @@ -30,6 +123,23 @@ The log severity level is a string that represents the severity of the log. The Optionally the SDK can define a `log` log severity level, which maps to the `info` log severity level in Sentry. +### Log Severity Number + +The log severity number is an integer that represents the severity of the log. The Sentry's default log severity number maps exactly to [OpenTelemetry's Severity number field](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber) on the OpenTelemetry Logs Spec. + +| SeverityNumer range | Range name | Meaning | +| ------------------- | ---------- | --------------------------------------------------------------------------------------- | +| 1-4 | Trace | A fine-grained debugging event. Typically disabled in default configurations. | +| 5-8 | Debug | A debugging event. | +| 9-12 | Info | An informational event. Indicates that an event happened. | +| 13-16 | Warn | A warning event. Not an error but is likely more important than an informational event. | +| 17-20 | Error | An error event. Something went wrong. | +| 21-24 | Fatal | A fatal error such as application or system crash. | + +Default SDK public API should set the lowest severity number for a given severity level. For example, `warn` severity level logs collected by the SDK should use the severity number `13`. + +If an SDK collects `log` severity level, it should map to `info` severity level and `9` severity number. + ## Public API API wise the SDKs are required to expose logging methods which are to be defined in a `logger` module or namespace. The SDKs should also include some initialization options to configure the behavior of logs in the SDK. @@ -226,8 +336,6 @@ If `debug` is set to `true` in SDK init, calls to the Sentry logger API should a Logs should be buffered before being sent. SDKs should keep a buffer of logs on the client (so you can have logs from multiple traces in the buffer) that flushes out based on some kind of condition. A recommended condition is if the buffer length exceeds 25 items, or if 5 seconds have passed. In the future we can use a [weight-tracking based approach](https://github.com/getsentry/rfcs/blob/main/text/0126-sdk-spans-aggregator.md#weight) to determine when to flush logs. -We recommend exposing - The internal SDK implementation is kept purposefully broad as we are still in early stages. As we figure more out about the logs product and payload characteristics, we'll be able to define a more rigorous spec for logging internals in the SDK. SDKs should take care to not expose logging internals as much as possible to userland so that they can be refactored in the future. ### Default Attributes From 20cfb449f6ecb162e2d3b050be089f00ac43c98b Mon Sep 17 00:00:00 2001 From: Abhijeet Prasad Date: Wed, 5 Mar 2025 15:05:31 -0500 Subject: [PATCH 3/6] ref: Clean up logs spec --- develop-docs/sdk/telemetry/logs.mdx | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx index bbd924da17902..77818aee93a13 100644 --- a/develop-docs/sdk/telemetry/logs.mdx +++ b/develop-docs/sdk/telemetry/logs.mdx @@ -104,6 +104,10 @@ Example: } ``` +`time_unix_nano` + +: **String, optional**. The time the log was created in Unix nanoseconds. If not set, the SDK should set this to the current time. + ### `log` Envelope Item Payload The `log` envelope item payload is a JSON object that represents a log. @@ -121,8 +125,6 @@ The log severity level is a string that represents the severity of the log. The - `error` - `fatal` -Optionally the SDK can define a `log` log severity level, which maps to the `info` log severity level in Sentry. - ### Log Severity Number The log severity number is an integer that represents the severity of the log. The Sentry's default log severity number maps exactly to [OpenTelemetry's Severity number field](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber) on the OpenTelemetry Logs Spec. @@ -136,9 +138,7 @@ The log severity number is an integer that represents the severity of the log. T | 17-20 | Error | An error event. Something went wrong. | | 21-24 | Fatal | A fatal error such as application or system crash. | -Default SDK public API should set the lowest severity number for a given severity level. For example, `warn` severity level logs collected by the SDK should use the severity number `13`. - -If an SDK collects `log` severity level, it should map to `info` severity level and `9` severity number. +Default SDK public API should set the lowest severity number for a given severity level. For example, `warn` severity level logs collected by the SDK API should use the severity number `13`. ## Public API @@ -150,7 +150,7 @@ The SDKs need to expose the following two configuration options: - `enableSentryLogs`/`enable_sentry_logs`: A boolean flag to control if log envelopes will be generated and sent to Sentry via the Sentry SDK's Logging APIs. If this flag is set to `false`, the SDK should not send logs to Sentry. Defaults to `false`. -- `beforeSendLog`/`before_send_log`: A function that takes a log object and returns a log object. This function is called before sending the log to Sentry. It can be used to modify the log object or to prevent the log from being sent to Sentry. Defaults to `null`/`unset`. +- `beforeSendLog`/`before_send_log`: A function that takes a log object and returns a log object. This function is called before sending the log to Sentry. It can be used to modify the log object or to prevent the log from being sent to Sentry. ```js Sentry.init({ @@ -173,7 +173,7 @@ At the current moment, logs are not sampled so no sampling configuration needs t At minimum the SDK needs to implement the following two items to be considered to have a complete logging public API: -1. `Sentry.logger.X` (where `X` is the log level): The log levels are `trace`, `debug`, `info`, `warn`, `error`, and `fatal`, which is specced out by the [protocol below](#log-severity-level). These methods accepts a string template and the parameters to that string template so the SDK can perform structured logging. Optionally these methods take arbitrary attributes, but not all languages can support both passing a parameterized template and attributes in an easy way. +1. `Sentry.logger.X` (where `X` is the log level): The log levels are `trace`, `debug`, `info`, `warn`, `error`, and `fatal`, which is specced out by the [protocol below](#log-severity-level). - `Sentry.logger.trace` - `Sentry.logger.debug` @@ -182,14 +182,23 @@ At minimum the SDK needs to implement the following two items to be considered t - `Sentry.logger.error` - `Sentry.logger.fatal` +These methods accepts a string template and the parameters to that string template so the SDK can perform structured logging. Optionally these methods take arbitrary attributes, but not all languages can support both passing a parameterized template and attributes in an easy way. + ```js -Sentry.logger.info`Adding item ${itemId} for user ${userId}`; +// Need to use `fmt` helper function in JavaScript for structured logging. +Sentry.logger.info(Sentry.logger.fmt`Adding item ${itemId} for user ${userId}`); Sentry.logger.warn("User %s performed action %s", [userId, actionName], { extra: "123", }); ``` +Optionally the SDK can define a `log` log severity level, which maps to the `info` log severity level in Sentry. If an SDK collects `log` severity level, it should map to `info` severity level and `9` severity number. + +```js +Sentry.logger.log("Added item to shopping cart"); +``` + 2. `Sentry.logger.emit`: A more verbose version of the `Sentry.logger.X` methods that accepts a log object/dictionary for maximum customizability. This is only meant to be used by power users, who want full control over what exactly is being set. Note that this API aligns with [OTEL's default logging API](https://opentelemetry.io/docs/specs/otel/logs/api/#emit-a-logrecord) as well, which gives us flexibility to align on those in the future. Emit should take the following parameters: @@ -328,7 +337,7 @@ SentrySDK.logger Both the `Sentry.logger.X` and `Sentry.logger.emit` methods are fire-and-forget (have no return value). This means that the SDK can choose to run these methods on a separate thread or queue them up for processing later. This includes evaluating the string template, and running any internal hooks (like `beforeSendLog`). The SDK should ensure that the logs are sent in the order they are received. -## SDK behavior +## SDK Behavior ### Implementation @@ -366,5 +375,3 @@ Beyond these attributes, we are exploring if the SDK should also send OS, user, SDKs should aim to have it so that console/logger integrations create logs as per the appropriate log level if `enableSentryLogs` is set to true. Examples of this include JavaScript's `console` methods and Pythons `logging` standard library. If SDK authors feel the need, they can also introduce additional options to beyond `enableSentryLogs` to gate this functionality. For example an option to control log appenders added via external config like with `Log4j` in the Java SDK. - -### Default Attributes From ba6d2ddac01b2fc52e10463bb2d391d3451bf7d4 Mon Sep 17 00:00:00 2001 From: Abhijeet Prasad Date: Wed, 5 Mar 2025 15:15:14 -0500 Subject: [PATCH 4/6] fix link to logs pages --- develop-docs/sdk/data-model/envelope-items.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/develop-docs/sdk/data-model/envelope-items.mdx b/develop-docs/sdk/data-model/envelope-items.mdx index 29ef867d9757c..0c2a8ce3816ff 100644 --- a/develop-docs/sdk/data-model/envelope-items.mdx +++ b/develop-docs/sdk/data-model/envelope-items.mdx @@ -431,7 +431,7 @@ details. Item type `"logs"` contains a logs payload encoded as JSON. Multiple log envelope items can be sent in a single envelope. -See the Logs documentation for the payload +See the Logs documentation for the payload details. **Constraints:** @@ -450,7 +450,7 @@ details. Item type `"otel_logs"` contains a OpenTelemetry Logs payload encoded as JSON. Multiple Otel log envelope items can be sent in a single envelope. -See the Logs documentation for the payload +See the Logs documentation for the payload details. **Constraints:** From 7e4a0cb604daee58a3e10b821543cde9d10561eb Mon Sep 17 00:00:00 2001 From: Abhijeet Prasad Date: Thu, 6 Mar 2025 09:47:58 -0500 Subject: [PATCH 5/6] Apply suggestions from code review Co-authored-by: Alex Krawiec --- develop-docs/sdk/data-model/envelope-items.mdx | 2 +- develop-docs/sdk/telemetry/logs.mdx | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/develop-docs/sdk/data-model/envelope-items.mdx b/develop-docs/sdk/data-model/envelope-items.mdx index 0c2a8ce3816ff..8d4074353b2fb 100644 --- a/develop-docs/sdk/data-model/envelope-items.mdx +++ b/develop-docs/sdk/data-model/envelope-items.mdx @@ -448,7 +448,7 @@ details. ### Otel Logs -Item type `"otel_logs"` contains a OpenTelemetry Logs payload encoded as JSON. Multiple Otel log envelope items can be sent in a single envelope. +Item type `"otel_logs"` contains an OpenTelemetry Logs payload encoded as JSON. Multiple Otel log envelope items can be sent in a single envelope. See the Logs documentation for the payload details. diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx index 77818aee93a13..8f0392fa8bdce 100644 --- a/develop-docs/sdk/telemetry/logs.mdx +++ b/develop-docs/sdk/telemetry/logs.mdx @@ -9,15 +9,15 @@ The Sentry Logs feature is under active development. The information in this doc -This document defines the format used by Sentry to ingest logs, as well as the SDK API and behavior that creates and sends logs to Sentry. +This document defines the format used by Sentry to ingest logs, as well as the SDK API and behavior that create and send logs to Sentry. ## Logs Protocol -Logs can be sent in two ways to Sentry, via the `log` envelope and Sentry Log protocol, or the `otel_log` envelope and OpenTelemetry Log protocol. The `log` envelope and protocol is the preferred way to send logs to Sentry, but the `otel_log` envelope and protocol is also supported. +There are two ways to send logs to Sentry: via the `log` envelope and Sentry Log protocol (preferred), or the `otel_log` envelope and OpenTelemetry Log protocol. ### `otel_log` Envelope Item Payload -The `otel_log` envelope item payload is a JSON object that represents a OpenTelemetry Log. Multiple `otel_log` envelope items can be sent in a single envelope. +The `otel_log` envelope item payload is a JSON object that represents an OpenTelemetry Log. Multiple `otel_log` envelope items can be sent in a single envelope. ```json { From e5f87ea7ba14ffc8700e56c41938a6fcde89bd4d Mon Sep 17 00:00:00 2001 From: Abhijeet Prasad Date: Thu, 6 Mar 2025 10:14:14 -0500 Subject: [PATCH 6/6] Update develop-docs/sdk/telemetry/logs.mdx Co-authored-by: Lorenzo Cian --- develop-docs/sdk/telemetry/logs.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/develop-docs/sdk/telemetry/logs.mdx b/develop-docs/sdk/telemetry/logs.mdx index 8f0392fa8bdce..21e5b871751f4 100644 --- a/develop-docs/sdk/telemetry/logs.mdx +++ b/develop-docs/sdk/telemetry/logs.mdx @@ -129,7 +129,7 @@ The log severity level is a string that represents the severity of the log. The The log severity number is an integer that represents the severity of the log. The Sentry's default log severity number maps exactly to [OpenTelemetry's Severity number field](https://opentelemetry.io/docs/specs/otel/logs/data-model/#field-severitynumber) on the OpenTelemetry Logs Spec. -| SeverityNumer range | Range name | Meaning | +| SeverityNumber range | Range name | Meaning | | ------------------- | ---------- | --------------------------------------------------------------------------------------- | | 1-4 | Trace | A fine-grained debugging event. Typically disabled in default configurations. | | 5-8 | Debug | A debugging event. |