feat: add appendix D (observability) #287
Conversation
toddbaert
commented
Dec 16, 2024
toddbaert
commented
- adds small appendix section to spec that defines how particular SDK fields are mapped to the recently merge OTel semantics
- this allows providers and hooks to export OTel data consistently for easy interop
- adds a couple supporting glossary liks
toddbaert
force-pushed
the
feat/appendix-d-observabilty
branch
from
8dd27f0 to
fcbbf2a
Compare
|
|
||
| | Provider Metadata Field | Log Record Attribute | Notes | | ||
| | ----------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------ | | ||
| | `name` | `feature_flag.provider_name` | The name of the provider as defined in the `provider metadata`, available in the `hook context`. | |
There was a problem hiding this comment.
I wonder if we should add a note that it's recommended to keep provider names consistent across provider implementations.
There was a problem hiding this comment.
I don't think it's worth mentioning. I guess providers can decide for themselves if they want the name to be consistent.
There was a problem hiding this comment.
I think so too @toddbaert, it might be interesting for some consumers to see the provider implementations instead of a common name. But I guess @beeme1mr's case is the more common.
There was a problem hiding this comment.
I'm also with @toddbaert regarding a provider name. But I can imagine your point @beeme1mr of having an identifiying property for post processing. Maybe there should also be a provider_id property we could propose in otel?
Signed-off-by: Todd Baert <[email protected]>
toddbaert
force-pushed
the
feat/appendix-d-observabilty
branch
from
fcbbf2a to
2d44c6d
Compare
| | ------------------------ | --------------------------------------- | ---------------------------------------------------- | | ||
| | `flag key` | `feature_flag.key` | See: [flag key](./glossary.md#flag-key) | | ||
| | `error code` | `error.type` | See: [error code](./types.md#error-code) | | ||
| | `variant` | `feature_flag.variant` | See: [variant](./glossary.md#variant) | |
There was a problem hiding this comment.
There's questions about how exactly to represent value (important if provider cannot supply variant):
- is it represented in the body?
- can it be of
anytype?
There was a problem hiding this comment.
is it represented in the body?
Do you mean the body of the log record?
The spec says:
value: If and only if feature flag provider does not supply variant or equivalent concept.
Otherwise, value should be treated as opt-in.
And the type is undefined there as there is no any type in OTEL.
Recently there was also opened a PR to add the value_type to the event: open-telemetry/semantic-conventions#1689
toddbaert
requested review from
justinabrahms,
moredip,
federicobond,
beeme1mr,
davejohnston,
dyladan,
benjiro,
bacherfl,
askpt,
kinyoklion,
fabriziodemaria,
Kavindu-Dodan,
aepfli,
maxveldink and
lukas-reining
|
I've marked as draft for now since theres some ongoing conversations in OTel about how to represent certain types of event data: open-telemetry/semantic-conventions#1651 (comment) |
Signed-off-by: Todd Baert <[email protected]>
Signed-off-by: Todd Baert <[email protected]>
| | ------------------------ | --------------------------------------- | ---------------------------------------------------- | | ||
| | `flag key` | `feature_flag.key` | See: [flag key](./glossary.md#flag-key) | | ||
| | `error code` | `error.type` | See: [error code](./types.md#error-code) | | ||
| | `variant` | `feature_flag.variant` | See: [variant](./glossary.md#variant) | |
There was a problem hiding this comment.
is it represented in the body?
Do you mean the body of the log record?
The spec says:
value: If and only if feature flag provider does not supply variant or equivalent concept.
Otherwise, value should be treated as opt-in.
And the type is undefined there as there is no any type in OTEL.
Recently there was also opened a PR to add the value_type to the event: open-telemetry/semantic-conventions#1689
|
|
||
| | Provider Metadata Field | Log Record Attribute | Notes | | ||
| | ----------------------- | ---------------------------- | ------------------------------------------------------------------------------------------------ | | ||
| | `name` | `feature_flag.provider_name` | The name of the provider as defined in the `provider metadata`, available in the `hook context`. | |
There was a problem hiding this comment.
I think so too @toddbaert, it might be interesting for some consumers to see the provider implementations instead of a common name. But I guess @beeme1mr's case is the more common.
| | `flag key` | `feature_flag.key` | See: [flag key](./glossary.md#flag-key) | | ||
| | `error code` | `error.type` | See: [error code](./types.md#error-code) | | ||
| | `variant` | `feature_flag.variant` | See: [variant](./glossary.md#variant) | | ||
| | `error message` | `feature_flag.evaluation.error.message` | An error message associated with a failed evaluation | |
There was a problem hiding this comment.
Should we here also make clear that it is not recommended to not repat error.type here, like it's stated in the otel semcon?
