Add event.summary as a recommendation for events

.chloggen/event-message.yaml

@@ -0,0 +1,25 @@
+# Use this changelog template to create an entry for release notes.
+#
+# If your change doesn't affect end users you should instead start
+# your pull request title with [chore] or use the "Skip Changelog" label.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: enhancement
+
+# The name of the area of concern in the attributes-registry, (e.g. http, cloud, db)
+component: events
+
+# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: Add a human-readable description as an attribute representing the event
+
+# Mandatory: One or more tracking issues related to the change. You can use the PR number here if no issue exists.
+# The values here must be integers.
+issues: [ 1076 ]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: |
+  Events are identified by an `event.name` and a set of attributes and fields in the body that carry specific
+  meaning. However, since these events will be combined with other logs, `event.description` allows a
+  centralized logging system to display a human-readable representation of the event.

docs/attributes-registry/event.md

@@ -10,8 +10,12 @@
 
 Attributes for Events represented using Log Records.
 
-| Attribute    | Type   | Description                               | Examples                                      | Stability                                                        |
-| ------------ | ------ | ----------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------- |
-| `event.name` | string | Identifies the class / type of event. [1] | `browser.mouse.click`; `device.app.lifecycle` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
+| Attribute       | Type   | Description                                       | Examples                                                                    | Stability                                                        |
+| --------------- | ------ | ------------------------------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------- |
+| `event.name`    | string | Identifies the class / type of event. [1]         | `browser.mouse.click`; `device.app.lifecycle`                               | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
+| `event.summary` | string | Human-readable summary representing an event. [2] | `User clicked element with id 42`; `Device app lifecycle changed to PAUSED` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
 
 **[1]:** Event names are subject to the same rules as [attribute names](/docs/general/attribute-naming.md). Notably, event names are namespaced to avoid collisions and provide a clean separation of semantics for events in separate domains like browser, mobile, and kubernetes.
+
+**[2]:** Events are identified by an `event.name` and a set of attributes and fields in the body that carry specific meaning. However, since these events will be combined with other logs, `event.summary` allows a centralized logging system to display a human-readable representation of the event.
+When summaries are generated, they are not expected to include every attribute and field that is part of the event but could contain those that are meaningful for a human operator when visually navigating a centralized log system. Instrumentation libraries that produce events defined within the standard OpenTelemetry are not expected to add an `event.summary` attribute, as these are well-known events.

docs/general/events.md

@@ -44,9 +44,13 @@ structure and semantics will also be defined.
 | Attribute  | Type | Description  | Examples  | [Requirement Level](https://opentelemetry.io/docs/specs/semconv/general/attribute-requirement-level/) | Stability |
 |---|---|---|---|---|---|
 | [`event.name`](/docs/attributes-registry/event.md) | string | Identifies the class / type of event. [1] | `browser.mouse.click`; `device.app.lifecycle` | `Required` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
+| [`event.summary`](/docs/attributes-registry/event.md) | string | Human-readable summary representing an event. [2] | `User clicked element with id 42`; `Device app lifecycle changed to PAUSED` | `Recommended` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
 
 **[1]:** Event names are subject to the same rules as [attribute names](/docs/general/attribute-naming.md). Notably, event names are namespaced to avoid collisions and provide a clean separation of semantics for events in separate domains like browser, mobile, and kubernetes.
 
+**[2]:** Events are identified by an `event.name` and a set of attributes and fields in the body that carry specific meaning. However, since these events will be combined with other logs, `event.summary` allows a centralized logging system to display a human-readable representation of the event.
+When summaries are generated, they are not expected to include every attribute and field that is part of the event but could contain those that are meaningful for a human operator when visually navigating a centralized log system. Instrumentation libraries that produce events defined within the standard OpenTelemetry are not expected to add an `event.summary` attribute, as these are well-known events.
+
 
 
 
@@ -69,6 +73,8 @@ structure and semantics will also be defined.
   and the semantic conventions will define the expected structure of the _payload_
   (data) for the event.
 * The _payload_ (data) SHOULD be used to represent the structure of the event.
+* The event MAY have an `event.summary` attribute that is a human-readable
+  representation of the event.
 
 Recommendations for defining events:
 

model/logs/events.yaml

@@ -6,3 +6,5 @@ groups:
     attributes:
       - ref: event.name
         requirement_level: required
+      - ref: event.summary
+        requirement_level: recommended

model/registry/event.yaml

@@ -16,3 +16,18 @@ groups:
           separation of semantics for events in separate domains like browser, mobile, and
           kubernetes.
         examples: ['browser.mouse.click', 'device.app.lifecycle']
+      - id: summary
+        type: string
+        stability: experimental
+        brief: >
+          Human-readable summary representing an event.
+        note: >
+          Events are identified by an `event.name` and a set of attributes and fields in the body that carry specific
+          meaning. However, since these events will be combined with other logs, `event.summary` allows a
+          centralized logging system to display a human-readable representation of the event.
+
+          When summaries are generated, they are not expected to include every attribute and field that is part of the
+          event but could contain those that are meaningful for a human operator when visually navigating a centralized
+          log system. Instrumentation libraries that produce events defined within the standard OpenTelemetry are not
+          expected to add an `event.summary` attribute, as these are well-known events.
+        examples: ['User clicked element with id 42', 'Device app lifecycle changed to PAUSED']