Skip to content

Commit 25dac91

Browse files
authored
chore: rename from log to event, clarify value requirements (#341)
Signed-off-by: Michael Beemer <[email protected]>
1 parent ece8b7c commit 25dac91

File tree

1 file changed

+11
-11
lines changed

1 file changed

+11
-11
lines changed
Lines changed: 11 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,14 +1,14 @@
11
---
22
id: appendix-d
33
title: "Appendix D: Observability"
4-
description: Conventions for OpenFeature telemetry signals
4+
description: Conventions for OpenFeature telemetry signals
55
sidebar_position: 5
66
---
77

88
# Appendix D: Observability
99

1010
This document describes conventions for extracting data from the OpenFeature SDK for use in telemetry signals.
11-
It primarily focuses on providing recommendations for mapping well-known fields in OpenFeature to [OpenTelemetry feature-flag log records][otel-ff-logs] and other semantic conventions.
11+
It primarily focuses on providing recommendations for mapping well-known fields in OpenFeature to [OpenTelemetry feature-flag event records][otel-ff-events] and other semantic conventions.
1212

1313
## Evaluations
1414

@@ -17,9 +17,9 @@ This is particularly relevant to telemetry-related [hooks](./sections/04-hooks.m
1717

1818
### Evaluation Details
1919

20-
The following describes how fields on the [evaluation details](types.md#evaluation-details) are mapped to feature flag log records:
20+
The following describes how fields on the [evaluation details](types.md#evaluation-details) are mapped to feature flag event records:
2121

22-
| Log Record Attribute | Source Field or Derived Value from Evaluation Details | Requirement level | Type | Notes |
22+
| Event Record Attribute | Source Field or Derived Value from Evaluation Details | Requirement level | Type | Notes |
2323
| ----------------------------- | ----------------------------------------------------- | ----------------------------- | ----------- | --------------------------------------------------------------------------------------------------------------------- |
2424
| `feature_flag.key` | `flag key` | `Required` | `string` | See: [flag key](./glossary.md#flag-key) |
2525
| `feature_flag.result.variant` | `variant` | `Conditionally Required` [^1] | `string` | See: [variant](./glossary.md#variant) |
@@ -29,14 +29,14 @@ The following describes how fields on the [evaluation details](types.md#evaluati
2929
| `error.message` | `error message` | `Conditionally Required` [^3] | `string` | A human-readable error message associated with a failed evaluation. For programmatic purposes, refer to `error code`. |
3030

3131
> [!NOTE]
32-
> The `error.type` and `feature_flag.result.reason` enumerations use a lowercase "snake_case" convention (see [OpenTelemetry feature-flag log records][otel-ff-logs]).
32+
> The `error.type` and `feature_flag.result.reason` enumerations use a lowercase "snake_case" convention (see [OpenTelemetry feature-flag event records][otel-ff-events]).
3333
> OpenFeature [error codes](types.md#error-code) and [resolution reasons](./types.md#resolution-reason) should be transformed accordingly by integrations which include this data.
3434
3535
### Flag Metadata
3636

37-
The following describes how keys in [flag metadata](types.md#flag-metadata) are mapped to feature flag log records:
37+
The following describes how keys in [flag metadata](types.md#flag-metadata) are mapped to feature flag event records:
3838

39-
| Log Record Attribute | Flag Metadata Key | Requirement level | Type | Notes |
39+
| Event Record Attribute | Flag Metadata Key | Requirement level | Type | Notes |
4040
| ------------------------- | ----------------- | ----------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
4141
| `feature_flag.context.id` | `contextId` | `Recommended` | `string` | The context identifier returned in the flag metadata uniquely identifies the subject of the flag evaluation. If not available, the [targeting key](./glossary.md#targeting-key) should be used. |
4242
| `feature_flag.set.id` | `flagSetId` | `Recommended` | `string` | A logical identifier for the [flag set](./glossary.md#flag-set). |
@@ -47,14 +47,14 @@ The following describes how keys in [flag metadata](types.md#flag-metadata) are
4747
4848
### Provider Metadata
4949

50-
| Log Record Attribute | Provider Metadata Field | Requirement level | Type | Notes |
50+
| Event Record Attribute | Provider Metadata Field | Requirement level | Type | Notes |
5151
| ---------------------------- | ----------------------- | ----------------- | -------- | ------------------------------------------------------------------------------------------------ |
5252
| `feature_flag.provider.name` | `name` | `Recommended` | `string` | The name of the provider as defined in the `provider metadata`, available in the `hook context`. |
5353

5454
## History
5555

5656
Feature flags in the OpenTelemetry semantic conventions are currently in development and are marked as experimental.
57-
The following table describes the history of changes to the OpenTelemetry feature flag log records as it progresses towards a stable release.
57+
The following table describes the history of changes to the OpenTelemetry feature flag event records as it progresses towards a stable release.
5858

5959
| Original Field Name | New Field Name | Semantic Convention Release |
6060
| --------------------------------------- | ----------------------------- | -------------------------------------------------------------------------------------- |
@@ -67,7 +67,7 @@ The following table describes the history of changes to the OpenTelemetry featur
6767
## Footnotes
6868

6969
[^1]: The `variant` field should be included whenever possible as it represents the symbolic name of the flag's returned value (e.g., "on"/"off", "control"/"treatment"). Only omit if the provider doesn't supply this information.
70-
[^2]: The `value` field should be included whenever a `variant` is unavailable. Large or sensitive values should be redacted or omitted prior to being captured in telemetry signals.
70+
[^2]: The `value` field is required when a `variant` is not available, and recommended when it is. Considerations should be made for large and/or sensitive values, which should be redacted or omitted prior to being captured in telemetry signals.
7171
[^3]: Include `error.type` and `error.message`, if and only if an error occurred during a flag evaluation.
7272

73-
[otel-ff-logs]: https://opentelemetry.io/docs/specs/semconv/feature-flags/feature-flags-logs/
73+
[otel-ff-events]: https://opentelemetry.io/docs/specs/semconv/feature-flags/feature-flags-logs/

0 commit comments

Comments
 (0)