refactor: align telemetry signals with the latest OTel semantic conventions

- move custom attribute keys out of reserved OTel namespaces to flow.*
prefixes
- define official keys once in shared
SemConvAttributes/SemConvMetrics/CacheAttributes (flow-php/telemetry)
- HTTP spans: client name is bare {method}, server.port always set;
server span gains url.query/user_agent.original, drops url.full
- messenger: destination = transport, remove metrics_duration_unit
option and enum, duration fixed at seconds
- phpunit: official test.* registry keys, new test.suite.run.status,
durations ms→s
- UCUM units (By, {operation}, {row}, {test}, {row}/s) and
low-cardinality span names (filesystem.read/write,
cache.set/delete/clear); upgrading.md migration tables

Author: norberttech

documentation/components/bridges/phpunit-telemetry-bridge.md

@@ -258,21 +258,24 @@ When enabled, the extension creates spans for:
 
 Each span includes attributes like:
 
-- `test.suite` - Test suite name
-- `test.id` - Test identifier
-- `test.name` - Test name
-- `test.class` - Test class name
-- `test.method` - Test method name
-- `test.status` - Test result status (passed, failed, errored, skipped, incomplete)
+- `test.suite.name` - Test suite name
+- `test.suite.run.status` - Suite outcome (success, failure, skipped)
+- `test.case.name` - Test name
+- `test.case.result.status` - Test result status (passed, failed, errored, skipped, incomplete)
+- `flow.phpunit.test.id` - Test identifier
+- `flow.phpunit.test.class` - Test class name
+- `flow.phpunit.test.method` - Test method name
+- `flow.phpunit.test.memory.peak` / `flow.phpunit.test.memory.delta` - Memory usage in bytes
 
 ### Metrics
 
 When enabled, the extension records:
 
-- `flow.phpunit.suite.duration` - Histogram of suite execution time
-- `flow.phpunit.suite.test_count` - Counter of tests per suite
-- `flow.phpunit.test.duration` - Histogram of individual test execution time
-- `flow.phpunit.test.count` - Counter of tests by status
+- `flow.phpunit.suite.duration` - Histogram of suite execution time (seconds)
+- `flow.phpunit.suite.test_count` - Counter of tests per suite (`{test}`)
+- `flow.phpunit.test.duration` - Histogram of individual test execution time (seconds)
+- `flow.phpunit.test.count` - Counter of tests by status (`{test}`)
+- `flow.phpunit.test.memory.peak` / `flow.phpunit.test.memory.delta` - Memory histograms (`By`)
 
 ## Running with Docker Compose
 

documentation/components/bridges/symfony-telemetry-bundle.md

@@ -780,7 +780,7 @@ per-channel (or per-attribute) severity thresholds are expressible alongside any
 These keys exist only for the filter decision — they are never exported (severity already travels in the native OTLP
 `severityNumber`/`severityText` fields) and they shadow any user attribute of the same name. Because they live on the
 `signal` source, an `all` node that combines severity with another attribute needs that attribute on `signal` too — the
-channel's `log.channel` attribute is on `signal` under the default `channel_attribute_target: both`.
+channel's `flow.log.channel` attribute is on `signal` under the default `channel_attribute_target: both`.
 
 Keep `error`+ from the `payments` channel but `debug`+ from the `importer` channel (`exclude: false` keeps only
 matching records — exactly the case a single global [`severity_filtering`](#pipeline-logger_provider-only) threshold
@@ -797,10 +797,10 @@ flow_telemetry:
           matcher:
             any:
               - all:
-                  - { path: log.channel, mode: equal, value: payments }
+                  - { path: flow.log.channel, mode: equal, value: payments }
                   - { path: log.severity, mode: greater_than_equal, value: 17 }   # error+
               - all:
-                  - { path: log.channel, mode: equal, value: importer }
+                  - { path: flow.log.channel, mode: equal, value: importer }
                   - { path: log.severity, mode: greater_than_equal, value: 5 }    # debug+
       sink:
         type: batching
@@ -1181,8 +1181,8 @@ the request span (same instrumentation scope, kind `INTERNAL`). They are emitted
 exists, so disabling `http_kernel` or excluding the path produces none.
 
 - `trace_controller` (default **true**) — the controller **body** execution. The span is named after the
-  resolved controller (e.g. `App\Controller\OrderController::import`) and carries `code.namespace`,
-  `code.function` and `controller` attributes. It starts after argument resolution and completes at
+  resolved controller (e.g. `App\Controller\OrderController::import`) and carries `code.function.name`
+  and `flow.symfony.controller` attributes. It starts after argument resolution and completes at
   `kernel.view`/`kernel.response`, so it excludes resolution time and appears in both the OTLP export and the
   Flow Telemetry profiler panel.
 - `trace_controller_resolution` (default **false**) — controller resolution
@@ -1281,7 +1281,6 @@ flow_telemetry:
       context_propagation: true    # Propagate context across message boundaries
       trace: true                  # Emit a per-message span (default true)
       metrics: true                # Emit messaging metrics (default true)
-      metrics_duration_unit: s     # process.duration histogram unit: 's' (OTEL semconv, default) or 'ms'
 ```
 
 The tracing middleware is injected into **every** message bus automatically — no manual `framework.messenger`
@@ -1328,12 +1327,11 @@ in-flight requests complete in the background.
 
 | Metric                               | Instrument | Unit          | Emitted                       | Attributes                                                                                                                        |
 |--------------------------------------|------------|---------------|-------------------------------|-----------------------------------------------------------------------------------------------------------------------------------|
-| `messaging.client.consumed.messages` | Counter    | `{message}`   | once per **received** message | `messaging.system`, `messaging.operation.name=process`, `messaging.destination.name`, `messaging.consumer.group.name` (transport) |
-| `messaging.process.duration`         | Histogram  | `s` (or `ms`) | per **received** message      | same as above, plus `error.type` when the handler fails                                                                           |
-| `messaging.client.sent.messages`     | Counter    | `{message}`   | once per **sent** message     | `messaging.system`, `messaging.operation.name=send`, `messaging.destination.name`                                                 |
+| `messaging.client.consumed.messages` | Counter    | `{message}`   | once per **received** message | `messaging.system`, `messaging.operation.name=process`, `messaging.destination.name` (transport) |
+| `messaging.process.duration`         | Histogram  | `s`           | per **received** message      | same as above, plus `error.type` when the handler fails                                                                           |
+| `messaging.client.sent.messages`     | Counter    | `{message}`   | once per **sent** message     | `messaging.system`, `messaging.operation.name=send`                                                                                |
 
-`metrics_duration_unit` controls the `messaging.process.duration` histogram: `s` (default) uses seconds with the
-OTEL-recommended bucket boundaries; `ms` uses milliseconds with Flow's native histogram buckets.
+`messaging.process.duration` is recorded in seconds with the OTEL-recommended bucket boundaries.
 
 #### Twig
 
@@ -1550,7 +1548,7 @@ flow_telemetry:
 
 Channels let you route different parts of your application to different telemetry loggers — the Flow Telemetry
 equivalent of Monolog channels — without installing Monolog. Each channel is a [named logger](#named-instruments);
-messages emitted through it carry a `log.channel` attribute, so you can filter and group them per channel in your
+messages emitted through it carry a `flow.log.channel` attribute, so you can filter and group them per channel in your
 backend. Where that attribute is placed — the instrumentation scope, every emitted record, or both — is controlled by
 [`channel_attribute_target`](#channel-attribute-placement).
 
@@ -1592,10 +1590,10 @@ services:
 **Behavior:**
 
 - Each distinct channel is synthesized on demand as `flow.telemetry.<channel>.logger` (+ its PSR-3 wrapper
-  `flow.telemetry.<channel>.logger.psr3`), carrying a `log.channel: <channel>` attribute placed per
+  `flow.telemetry.<channel>.logger.psr3`), carrying a `flow.log.channel: <channel>` attribute placed per
   [`channel_attribute_target`](#channel-attribute-placement) — unless a logger of that name already exists, which is
   then
-  reused untouched (so the `log.channel` attribute is only added to loggers the bundle creates).
+  reused untouched (so the `flow.log.channel` attribute is only added to loggers the bundle creates).
 - To route a service to the bundle's main logger, use the `default` channel (`#[WithTelemetryChannel('default')]`).
   A `default` logger always exists, so it is reused as-is rather than re-created. Every channel name — including `app`,
   which carries no special meaning here — behaves the same way.
@@ -1605,7 +1603,7 @@ services:
 - On a tagged service, an explicit `@logger` reference is rewritten to the channel logger as well — in both constructor
   arguments and method calls (e.g. `setLogger()`), preserving the reference's invalid-behavior flag.
 - A channel already declared under `loggers` is **not** overwritten, so you can customise its `version`, `schema_url`,
-  or `attributes`. Because declaring it opts out of synthesis, set `log.channel` yourself if you want it:
+  or `attributes`. Because declaring it opts out of synthesis, set `flow.log.channel` yourself if you want it:
 
 ```yaml
 flow_telemetry:
@@ -1614,7 +1612,7 @@ flow_telemetry:
       version: '1.0.0'
       attributes:
         scope:
-          log.channel: events    # not auto-added for a declared logger — set it explicitly
+          flow.log.channel: events    # not auto-added for a declared logger — set it explicitly
           team: checkout
 ```
 
@@ -1636,7 +1634,7 @@ flow_telemetry:
 ```
 
 Each framework channel becomes `flow.telemetry.<channel>.logger` (e.g. `flow.telemetry.router.logger`,
-`flow.telemetry.http_client.logger`), carries the `log.channel` attribute (placed per
+`flow.telemetry.http_client.logger`), carries the `flow.log.channel` attribute (placed per
 [`channel_attribute_target`](#channel-attribute-placement)), and gets the
 `LoggerInterface $<channel>Logger` / `Logger $<channel>Logger` autowiring aliases — the same treatment as an explicitly
 tagged service. A channel you declare under `loggers` still wins, so you can customise any framework channel's scope.
@@ -1646,7 +1644,7 @@ regardless of this flag.
 
 #### Channel Attribute Placement
 
-The synthesized `log.channel` attribute can be attached to the instrumentation **scope**, to every emitted **signal**
+The synthesized `flow.log.channel` attribute can be attached to the instrumentation **scope**, to every emitted **signal**
 (log record), or to **both**. `channel_attribute_target` controls this for **all** synthesized channel loggers —
 framework-captured and `#[WithTelemetryChannel]` alike:
 
@@ -1655,15 +1653,15 @@ flow_telemetry:
   channel_attribute_target: both   # both (default) | scope | signal
 ```
 
-- **`scope`** — `log.channel` sits on the instrumentation scope. Filter by channel with an
+- **`scope`** — `flow.log.channel` sits on the instrumentation scope. Filter by channel with an
   [`attribute_filtering`](#attribute_filtering) processor using `sources: [scope]`. Not present on individual records.
-- **`signal`** — `log.channel` is merged into every emitted record, so it is visible per-record and filterable with the
+- **`signal`** — `flow.log.channel` is merged into every emitted record, so it is visible per-record and filterable with the
   default `sources: [signal]` (the closest match to how Monolog stamps the channel on each record).
 - **`both`** (default) — placed on the scope *and* every record, so it is filterable either way at the cost of storing
   the attribute on each record.
 
 This only governs channels the bundle synthesizes; a channel you declare yourself under `loggers` opts out of synthesis,
-so set `log.channel` explicitly on whichever of `attributes.scope` / `attributes.signal` you want.
+so set `flow.log.channel` explicitly on whichever of `attributes.scope` / `attributes.signal` you want.
 
 > [!NOTE]
 > `capture_framework_channels` rewrites the `logger` reference on framework services to their channel logger. A

documentation/components/core/telemetry.md

@@ -201,13 +201,14 @@ $transport = otlp_grpc_transport(endpoint: 'localhost:4317');
 
 Every DataFrame execution creates a root span with the following attributes:
 
-| Attribute                    | Description                                   |
-|------------------------------|-----------------------------------------------|
-| `dataframe.id`               | Unique identifier for the DataFrame execution |
-| `rows.total`                 | Total number of rows processed                |
-| `rows.throughput.per_second` | Processing throughput                         |
-| `memory.min.mb`              | Minimum memory consumption during execution   |
-| `memory.max.mb`              | Maximum memory consumption during execution   |
+| Attribute                             | Description                                   |
+|---------------------------------------|-----------------------------------------------|
+| `flow.etl.dataframe.id`               | Unique identifier for the DataFrame execution |
+| `flow.etl.dataframe.name`             | Configured DataFrame name                     |
+| `flow.etl.rows.total`                 | Total number of rows processed                |
+| `flow.etl.rows.throughput.per_second` | Processing throughput                         |
+| `flow.etl.memory.min`                 | Minimum memory consumption during execution (MB) |
+| `flow.etl.memory.max`                 | Maximum memory consumption during execution (MB) |
 
 When `trace_loading` is enabled, child spans are created for each loader with:
 
@@ -225,10 +226,10 @@ When `trace_transformations` is enabled, child spans are created for each transf
 
 When `collect_metrics` is enabled:
 
-| Metric                      | Type       | Description                        |
-|-----------------------------|------------|------------------------------------|
-| `rows.processed.total`      | Counter    | Cumulative count of processed rows |
-| `rows.processed.throughput` | Throughput | Rows processed per time unit       |
+| Metric                     | Type       | Unit       | Description                        |
+|----------------------------|------------|------------|------------------------------------|
+| `flow.etl.rows.processed`  | Counter    | `{row}`    | Cumulative count of processed rows |
+| `flow.etl.rows.throughput` | Throughput | `{row}/s`  | Rows processed per second          |
 
 ### Logs
 

documentation/components/libs/filesystem.md

@@ -232,15 +232,18 @@ automatically wrap all mounted filesystems with telemetry.
 
 **Spans:**
 
-- `SourceStream` - spans the lifecycle of a read stream from creation to close
-- `DestinationStream` - spans the lifecycle of a write stream from creation to close
+- `filesystem.read` - spans the lifecycle of a read stream from creation to close
+- `filesystem.write` - spans the lifecycle of a write stream from creation to close
+
+Spans carry `flow.filesystem.path.uri`, `flow.filesystem.protocol`, `flow.filesystem.stream.type` and, on close,
+`flow.filesystem.bytes.total_read` / `flow.filesystem.bytes.total_written`.
 
 **Metrics:**
 
-- `filesystem.source.bytes_read` - total bytes read from source streams
-- `filesystem.source.operations` - number of read operations
-- `filesystem.destination.bytes_written` - total bytes written to destination streams
-- `filesystem.destination.operations` - number of write operations
+- `flow.filesystem.read.size` (`By`) - total bytes read from source streams
+- `flow.filesystem.read.operations` (`{operation}`) - number of read operations
+- `flow.filesystem.write.size` (`By`) - total bytes written to destination streams
+- `flow.filesystem.write.operations` (`{operation}`) - number of write operations
 
 Metadata operations (list, status, rm, mv) are logged but do not create spans.
 

documentation/components/libs/postgresql/client-telemetry.md

@@ -174,10 +174,10 @@ Spans include attributes following [OpenTelemetry database semantic conventions]
 
 ### Transaction-Specific Attributes
 
-| Attribute                       | Description                   | Example        |
-|---------------------------------|-------------------------------|----------------|
-| `db.transaction.nesting_level`  | Current nesting depth         | `1`, `2`       |
-| `db.transaction.savepoint`      | Savepoint name (nested txns)  | `savepoint_1`  |
+| Attribute                            | Description                   | Example        |
+|--------------------------------------|-------------------------------|----------------|
+| `flow.db.transaction.nesting_level`  | Current nesting depth         | `1`, `2`       |
+| `flow.db.transaction.savepoint`      | Savepoint name (nested txns)  | `savepoint_1`  |
 
 ## Security Considerations