feat(logs): Expand attributes section for logs spec and specify defaults for every platform (#13832)

resolves https://linear.app/getsentry/issue/LOGS-28

After testing with some SDKs and getting feedback, we've decided on a
list of default attributes the SDKs should try to attach to logs.

This includes
1. user attributes from
https://develop.sentry.dev/sdk/data-model/event-payloads/user/
2. browser attributes, parsed from user agents
(getsentry/relay#4757)
3. os and device attributes attached to mobile, desktop, and native
sdks, based on
https://develop.sentry.dev/sdk/data-model/event-payloads/contexts/

I also re-organized this section to make things a bit more clear.

---------

Co-authored-by: Philipp Hofmann <[email protected]>

Author: AbhiPrasad

develop-docs/sdk/telemetry/logs.mdx

@@ -268,33 +268,39 @@ An SDK should implement [Tracing without Performance](/sdk/telemetry/traces/trac
 
 ### Default Attributes
 
-By default the SDK should set the following attributes:
+By default the SDK should attach the following attributes to a log:
 
-1. `sentry.message.template`: The parameterized template string
-2. `sentry.message.parameter.X`: The parameters to the template string. X can either be the number that represent the parameter's position in the template string (`sentry.message.parameter.0`, `sentry.message.parameter.1`, etc) or the parameter's name (`sentry.message.parameter.item_id`, `sentry.message.parameter.user_id`, etc)
-3. `sentry.environment`: The environment set in the SDK
-4. `sentry.release`: The release set in the SDK
-5. `sentry.trace.parent_span_id`: The span id of the span that was active when the log was collected. This should not be set if there was no active span.
-6. `sentry.sdk.name`: The name of the SDK that sent the log
-7. `sentry.sdk.version`: The version of the SDK that sent the log
-8. [BACKEND SDKS ONLY] `server.address`: The address of the server that sent the log. Equivalent to `server_name` we attach to errors and transactions.
-
-Example:
+1. `sentry.environment`: The environment set in the SDK if defined.
+2. `sentry.release`: The release set in the SDK if defined.
+3. `sentry.trace.parent_span_id`: The span id of the span that was active when the log was collected. This should not be set if there was no active span.
+4. `sentry.sdk.name`: The name of the SDK that sent the log
+5. `sentry.sdk.version`: The version of the SDK that sent the log
 
 ```json
 {
-  "sentry.message.template": "Adding item %s for user %s",
-  "sentry.message.parameter.0": "item_id",
-  "sentry.message.parameter.1": "user_id",
   "sentry.environment": "production",
   "sentry.release": "1.0.0",
   "sentry.trace.parent_span_id": "b0e6f15b45c36b12",
   "sentry.sdk.name": "sentry.javascript.node",
-  "sentry.sdk.version": "9.11.0",
-  "server.address": "foo.example.com"
+  "sentry.sdk.version": "9.11.0"
 }
 ```
 
+If the log was paramaterized the SDK should attach the following
+
+1. `sentry.message.template`: The parameterized template string
+2. `sentry.message.parameter.X`: The parameters to the template string. X can either be the number that represent the parameter's position in the template string (`sentry.message.parameter.0`, `sentry.message.parameter.1`, etc) or the parameter's name (`sentry.message.parameter.item_id`, `sentry.message.parameter.user_id`, etc)
+
+```json
+{
+  "sentry.message.template": "Adding item %s for user %s",
+  "sentry.message.parameter.0": "item_id",
+  "sentry.message.parameter.1": "user_id"
+}
+```
+
+#### SDK Integration Attributes
+
 If a log is generated by an SDK integration, the SDK should also set the `sentry.origin` attribute, as per the [Trace Origin](/sdk/telemetry/traces/trace-origin/) documentation. It is assumed that logs without a `sentry.origin` attribute are manually created by the user.
 
 ```json
@@ -303,7 +309,73 @@ If a log is generated by an SDK integration, the SDK should also set the `sentry
 }
 ```
 
-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.
+#### User Attributes
+
+If `sendDefaultPii`/`send_default_pii` is set to `true` in the SDK, the SDK should attach the following user data if available:
+
+1. `user.id`: The user ID. Maps to `id` in the [User](/sdk/data-model/event-payloads/user/) payload.
+2. `user.name`: The username. Maps to `username` in the [User](/sdk/data-model/event-payloads/user/) payload.
+3. `user.email`: The email address. Maps to `email` in the [User](/sdk/data-model/event-payloads/user/) payload.
+
+```json
+{
+  "user.id": "123",
+  "user.name": "john.doe",
+  "user.email": "[email protected]"
+}
+```
+
+#### User Agent Parsing
+
+By default, Relay should parse the user agent attached to an incoming log envelope to parse `browser` and `os` information for logs. These attributes should be attached by Relay, but SDKs can attach them if they do not forward a user agent when sending logs to Sentry.
+
+1. `browser.name`: Display name of the browser application. Maps to `name` in the [Contexts](/sdk/data-model/event-payloads/contexts/#browser-context) payload.
+2. `browser.version`: Version string of the browser. Maps to `version` in the [Contexts](/sdk/data-model/event-payloads/contexts/#browser-context) payload.
+
+```json
+{
+  "browser.name": "Chrome",
+  "browser.version": "120.0"
+}
+```
+
+#### Backend SDKs
+
+For backend SDKs (Node.js, Python, PHP, etc.), the SDKs should attach the following:
+
+1. `server.address`: The address of the server that sent the log. Equivalent to [`server_name`](sdk/data-model/event-payloads/#optional-attributes) we attach to errors and transactions.
+
+```json
+{
+  "server.address": "foo.example.com"
+}
+```
+
+#### Mobile, Desktop, and Native SDKs
+
+For mobile, desktop, and native SDKs (Android, Apple, Electron, etc.), the SDKs should attach the following:
+
+1. `os.name`: The name of the operating system. Maps to `name` in the [Contexts](/sdk/data-model/event-payloads/contexts/#os-context) payload.
+2. `os.version`: The version of the operating system. Maps to `version` in the [Contexts](/sdk/data-model/event-payloads/contexts/#os-context) payload.
+3. `device.brand`: The brand of the device. Maps to `brand` in the [Contexts](/sdk/data-model/event-payloads/contexts/#device-context) payload.
+4. `device.model`: The model of the device. Maps to `model` in the [Contexts](/sdk/data-model/event-payloads/contexts/#device-context) payload.
+5. `device.family`: The family of the device. Maps to `family` in the [Contexts](/sdk/data-model/event-payloads/contexts/#device-context) payload.
+
+```json
+{
+  "os.name": "iOS",
+  "os.version": "17.0",
+  "device.brand": "Apple",
+  "device.model": "iPhone 15 Pro Max",
+  "device.family": "iPhone"
+}
+```
+
+#### Future Default Attributes
+
+The SDKs should aim to minimize the number of default attributes attached to a log. Logs are intended to be lightweight, and we want to try to keep the average byte size of a log as small as possible as users will be charged per byte size of logs sent.
+
+We are trying to settle on a balance of debuggability vs. smaller byte size for logs which is why new default attributes should only be added after significant feedback from users and discussion internally with the SDK and ingest teams. There is no hard rule about what exact attributes are allowed, every proposed new attribute will be evaluated on a case-by-case basis.
 
 ### Data Category and Rate Limiting