Pre-filing checklist
Component(s)
Rust OTAP dataflow (rust/otap-dataflow/)
Is your feature request related to a problem?
As seen in #2596 we have an interest in both compressed and uncompressed exporter/receiver bytes.
Proposed Solution
This was done in Phase 1 components, see
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/otelarrowexporter/#exporter-metrics
Alternatives Considered
Sometimes we can use HTTP or gRPC specific instrumentation to get this, and we can follow OTel semantic conventions by protocol.
Additional Context
As an important note, on the receiver side we expect that the computation used to compute uncompressed and compressed bytes are shared with any rate-limiting infrastructure that may want to use the same numbers. Detailed request measurements should be considered shared context for extensions.
Pre-filing checklist
Component(s)
Rust OTAP dataflow (rust/otap-dataflow/)
Is your feature request related to a problem?
As seen in #2596 we have an interest in both compressed and uncompressed exporter/receiver bytes.
Proposed Solution
This was done in Phase 1 components, see
https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/otelarrowexporter/#exporter-metrics
Alternatives Considered
Sometimes we can use HTTP or gRPC specific instrumentation to get this, and we can follow OTel semantic conventions by protocol.
Additional Context
As an important note, on the receiver side we expect that the computation used to compute uncompressed and compressed bytes are shared with any rate-limiting infrastructure that may want to use the same numbers. Detailed request measurements should be considered shared context for extensions.