Add event.message as a recommendation for events

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.message`
allows a backend to display a human-readable representation of the
event.

.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: Human-readable message representing an 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: []
+
+# (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.message` allows a backend to
+  display a human-readable representation of the event.

docs/attributes-registry/event.md

@@ -10,8 +10,11 @@
 
 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.message` | string | Human-readable message representing an event. [1] | `Workflow started`                            | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
+| `event.name`    | string | Identifies the class / type of event. [2]         | `browser.mouse.click`; `device.app.lifecycle` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
 
-**[1]:** Event names are subject to the same rules as [attribute names](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.33.0/specification/common/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.
+**[1]:** 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.message` allows a backend to display a human-readable representation of the event.
+
+**[2]:** Event names are subject to the same rules as [attribute names](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.33.0/specification/common/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.

docs/general/events.md

@@ -44,9 +44,12 @@ 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.message`](/docs/attributes-registry/event.md) | string | Human-readable message representing an event. [2] | `Workflow started` | `Recommended` | ![Experimental](https://img.shields.io/badge/-experimental-blue) |
 
 **[1]:** Event names are subject to the same rules as [attribute names](https://github.com/open-telemetry/opentelemetry-specification/tree/v1.33.0/specification/common/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.message` allows a backend to display a human-readable representation of the event.
+
 
 
 
@@ -69,6 +72,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.message` 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.message
+        requirement_level: recommended

model/registry/event.yaml

@@ -16,3 +16,13 @@ groups:
           separation of semantics for events in separate domains like browser, mobile, and
           kubernetes.
         examples: ['browser.mouse.click', 'device.app.lifecycle']
+      - id: message
+        type: string
+        stability: experimental
+        brief: >
+          Human-readable message 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.message` allows a backend to
+          display a human-readable representation of the event.
+        examples: ['Workflow started']