11 KiB
Semantic conventions for feature flags in logs
Status: Development
This document defines semantic conventions for recording feature flag evaluations as a log record emitted through the Logger API. This is useful when a flag is evaluated outside of a transaction context such as when the application loads or on a timer.
Motivation
Feature flags are commonly used in modern applications to decouple feature releases from deployments. Many feature flagging tools support the ability to update flag configurations in near real-time from a remote feature flag management service. They also commonly allow rulesets to be defined that return values based on contextual information. For example, a feature could be enabled only for a specific subset of users based on context (e.g. users email domain, membership tier, country).
Since feature flags are dynamic and affect runtime behavior, it's important to collect relevant feature flag telemetry signals. This can be used to determine the impact a feature has on a request, enabling enhanced observability use cases, such as A/B testing or progressive feature releases.
Recording an evaluation
Feature flag evaluations SHOULD be recorded as attributes on the LogRecord passed to the Logger emit operations. Evaluations MAY be recorded on "logs" or "events" depending on the context.
Evaluation event
The table below indicates which attributes should be added to the LogRecord and their types.
The event name MUST be feature_flag.evaluation.
Defines feature flag evaluation as an event.
A feature_flag.evaluation event SHOULD be emitted whenever a feature flag value is evaluated, which may happen many times over the course of an application lifecycle. For example, a website A/B testing different animations may evaluate a flag each time a button is clicked. A feature_flag.evaluation event is emitted on each evaluation even if the result is the same.
| Attribute | Type | Description | Examples | Requirement Level | Stability |
|---|---|---|---|---|---|
feature_flag.key |
string | The lookup key of the feature flag. | logo-color |
Required |
|
error.type |
string | Describes a class of error the operation ended with. [1] | provider_not_ready; targeting_key_missing; provider_fatal; general |
Conditionally Required [2] |
|
feature_flag.result.value |
any | The evaluated value of the feature flag. [3] | #ff0000; true; 3 |
Conditionally Required [4] |
|
feature_flag.result.variant |
string | A semantic identifier for an evaluated flag value. [5] | red; true; on |
Conditionally Required [6] |
|
error.message |
string | A message providing more detail about an error in human-readable form. [7] | Unexpected input type: string; The user has exceeded their storage quota |
Recommended [8] |
|
feature_flag.context.id |
string | The unique identifier for the flag evaluation context. For example, the targeting key. | 5157782b-2203-4c80-a857-dbbd5e7761db |
Recommended |
|
feature_flag.provider.name |
string | Identifies the feature flag provider. | Flag Manager |
Recommended |
|
feature_flag.result.reason |
string | The reason code which shows how a feature flag value was determined. | static; targeting_match; error; default |
Recommended |
|
feature_flag.set.id |
string | The identifier of the flag set to which the feature flag belongs. | proj-1; ab98sgs; service1/dev |
Recommended |
|
feature_flag.version |
string | The version of the ruleset used during the evaluation. This may be any stable value which uniquely identifies the ruleset. | 1; 01ABCDEF |
Recommended |
[1] error.type: If one of these values applies, then it MUST be used; otherwise, a custom value MAY be used.
[2] error.type: If and only if an error occurred during flag evaluation.
[3] feature_flag.result.value: With some feature flag providers, feature flag results can be quite large or contain private or sensitive details.
Because of this, feature_flag.result.variant is often the preferred attribute if it is available.
It may be desirable to redact or otherwise limit the size and scope of feature_flag.result.value if possible.
Because the evaluated flag value is unstructured and may be any type, it is left to the instrumentation author to determine how best to achieve this.
[4] feature_flag.result.value: If and only if feature flag provider does not supply variant or equivalent concept. Otherwise, feature_flag.result.value should be treated as opt-in.
[5] feature_flag.result.variant: A semantic identifier, commonly referred to as a variant, provides a means
for referring to a value without including the value itself. This can
provide additional context for understanding the meaning behind a value.
For example, the variant red maybe be used for the value #c05543.
[6] feature_flag.result.variant: If feature flag provider supplies a variant or equivalent concept.
[7] error.message: Should not simply duplicate the value of error.type, but should provide more context. For example, if error.type is invalid_context the error.message may enumerate which context keys are missing or invalid.
[8] error.message: If and only if an error occurred during flag evaluation and error.type does not sufficiently describe the error.
error.type has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.
| Value | Description | Stability |
|---|---|---|
_OTHER |
A fallback error value to be used when the instrumentation doesn't define a custom value. |
feature_flag.result.reason has the following list of well-known values. If one of them applies, then the respective value MUST be used; otherwise, a custom value MAY be used.