Use extended attributes everywhere #4587
Conversation
| self, | ||
| amount: Union[int, float], | ||
| attributes: Optional[Attributes] = None, | ||
| attributes: Optional[_MetricAttributes] = None, |
There was a problem hiding this comment.
TODO: we can use Attributes and let users use complex attributes on metrics without any restrictions. We can also introduce an alias for a limited attribute set.
There was a problem hiding this comment.
I like the idea of allowing it at runtime but blocking it at type checking time. It gives users feedback that they're doing something probably wrong but is easy to override.
...xporter-otlp-proto-common/src/opentelemetry/exporter/otlp/proto/common/_internal/__init__.py
Show resolved
Hide resolved
adriangb
left a comment
There was a problem hiding this comment.
Overall this looks pretty straightforward to me. It goes to show that there's not much of a change for the SDKs to support complex attributes.
| self, | ||
| amount: Union[int, float], | ||
| attributes: Optional[Attributes] = None, | ||
| attributes: Optional[_MetricAttributes] = None, |
There was a problem hiding this comment.
I like the idea of allowing it at runtime but blocking it at type checking time. It gives users feedback that they're doing something probably wrong but is easy to override.
| root.set_attributes( | ||
| {"correct-value": "foo", "non-primitive-data-type": {}} | ||
| ) | ||
|
|
||
| with self.assertLogs(level=WARNING): | ||
| root.set_attribute("non-primitive-data-type", {}) | ||
| with self.assertLogs(level=WARNING): | ||
| root.set_attribute( | ||
| "list-of-mixed-data-types-numeric-first", | ||
| [123, False, "string"], | ||
| ) | ||
| with self.assertLogs(level=WARNING): | ||
| root.set_attribute( | ||
| "list-of-mixed-data-types-non-numeric-first", | ||
| [False, 123, "string"], | ||
| ) | ||
| with self.assertLogs(level=WARNING): | ||
| root.set_attribute( | ||
| "list-with-non-primitive-data-type", [{}, 123] | ||
| ) | ||
| with self.assertLogs(level=WARNING): | ||
| root.set_attribute("list-with-numeric-and-bool", [1, True]) |
There was a problem hiding this comment.
Maybe keep these tests but remove the assertLogs context manager / i.e. they should pass?
|
What is the status of this ? Seems like the OTEP is about to be merged and then we can possibly merge this too ? I'd kind of like to see it merged because it helps with some type checking issues I ran into in https://github.com/open-telemetry/opentelemetry-python/pull/4583/files |
Fixes #4710 OTEP #4485 (Extending attributes to support complex values) ## What Stabilize the complex `AnyValue` attribute value types and the corresponding attribute limits. Simplifiy the Logs Data Model to rely on `AnyValue` and Attribute Collections instead of custom `any` / `map<string, any>` types. ## Why Per the OTEP-implementing PR [#4485](#4485) tht was merged on **2025‑07‑15**, so the 6‑month window ends around **2026‑01‑15**. This PR is intended to be merged around **2026‑01‑15**, in line with that requirement. > Stable exporters will be prohibited from emitting complex attributes by default on signals other than Logs until at least 6 months after this OTEP is merged. OpenTelemetry **Go** and **Java** treat the common package as a **stable cross‑cutting surface**. They need these `AnyValue` types and limits to be Stable in the spec before they can add corresponding features to their APIs, SDKs, and exporters. ## Prototypes We have **three independent prototypes** that exercised the complex `AnyValue` attribute types and limits: - Java: open-telemetry/opentelemetry-java#7814 ( - Python: open-telemetry/opentelemetry-python#4587 - Go: open-telemetry/opentelemetry-go#6809 In summary, they: 1. Validated that complex attributes can be represented and processed end‑to‑end using `AnyValue`. 2. Confirmed that the specified attribute limits (length and count) are acceptable. 3. Demonstrated that existing implementations can adopt complex attributes without breaking current stable behavior. ## Other I was thinking about adding something to `spec-compliance-matrix.md`, but I do not see any obvious place where it could be located. I think we can tackle it in a separate PR if there would be a demand for it. EDIT: Tracked under #4808
This is a prototype of open-telemetry/opentelemetry-specification#4485:
TODO:
Benchmarks:
Perf is not a priority - we don't really want people to use complex attributes on metrics, to goal here to show that even if they do, the impact is not huge.
Based on the results, the cost of reporting complex attribute is ~1.5-2 times higher than a standard one.