You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today we use the shared TagTransformer in OtlpExporter, ZipkinExporter, & ConsoleExporter.
There are some issues with its design:
It has to return things. In the case of OtlpExporter, it returns classes generated from the protos (KeyValue, AnyValue, ArrayValue, etc.). In the case of ZipkinExporter and ConsoleExporter, it returns strings. These things all must be allocated and garbage collected. In the ZipkinExporter case, the json sent to Zipkin misrepresents bool/double/long tag values as strings.
It leaves array-handling code up to each implementation. OtlpExporter has a switch which must match the logic of the base class. ZipkinExporter and ConsoleExporter use TagTransformerJsonHelper which must match the base class and be annotated correctly for AoT compilation.
This epic is to track replacing TagTransformer with something which has the following design goals:
It should be possible to write directly onto something (instead of returning the thing to write). This is how we achieve high-performance and eliminate allocations. In the case of ZipkinExporter, we can write directly to the outgoing stream. OtlpExporter will still write onto the proto objects. But follow-up projects (probably OTLP Exporter Enhancements #5450) should be able to utilize this design to write directly onto a stream or buffer (sort of how PrometheusExporter works today). ConsoleExporter will continue to build strings for now as it is primarily a test tool. But this work could be utilized to support emitting JSON or YAML to the console efficiently and potentially make the performance suitable for production usage.
All of the array handling should be encapsulated into the base class. Implementations shouldn't need to worry about the supported types only writing out the normalized string/long/double/bool values.
ZipkinExporter should respect bool/double/long tag values.
Today we use the shared TagTransformer in OtlpExporter, ZipkinExporter, & ConsoleExporter.
There are some issues with its design:
It has to return things. In the case of OtlpExporter, it returns classes generated from the protos (KeyValue, AnyValue, ArrayValue, etc.). In the case of ZipkinExporter and ConsoleExporter, it returns strings. These things all must be allocated and garbage collected. In the ZipkinExporter case, the json sent to Zipkin misrepresents bool/double/long tag values as strings.
It leaves array-handling code up to each implementation. OtlpExporter has a switch which must match the logic of the base class. ZipkinExporter and ConsoleExporter use TagTransformerJsonHelper which must match the base class and be annotated correctly for AoT compilation.
This epic is to track replacing
TagTransformer
with something which has the following design goals:It should be possible to write directly onto something (instead of returning the thing to write). This is how we achieve high-performance and eliminate allocations. In the case of ZipkinExporter, we can write directly to the outgoing stream. OtlpExporter will still write onto the proto objects. But follow-up projects (probably OTLP Exporter Enhancements #5450) should be able to utilize this design to write directly onto a stream or buffer (sort of how PrometheusExporter works today). ConsoleExporter will continue to build strings for now as it is primarily a test tool. But this work could be utilized to support emitting JSON or YAML to the console efficiently and potentially make the performance suitable for production usage.
All of the array handling should be encapsulated into the base class. Implementations shouldn't need to worry about the supported types only writing out the normalized string/long/double/bool values.
ZipkinExporter should respect bool/double/long tag values.
Tasks:
The text was updated successfully, but these errors were encountered: