-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Extend the support for partition_logs_by_resource_attributes
to raw encoding
#38999
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Thanks for opening this, I actually have a WIP branch that fix it, as I'm working on moving the partitioning logic out of the individual marshalers. |
#39001 should fix this: partitioning will be done outside of encoders with the exception of Jaeger, which does its own thing. |
dmathieu
pushed a commit
to dmathieu/opentelemetry-collector-contrib
that referenced
this issue
Apr 8, 2025
open-telemetry#39001) #### Description - Move marshaler implementations to internal package - Simplify code to obtain a marshaler given an encoding name - Make marshalers independent of Sarama (Kafka client) - Implement a generic Kafka exporter with type parameter for signal-specific parts - Create more tightly scoped unit tests for encodings, independent of the general functionality of the exporter - Added tests for partitioning logic #### Link to tracking issue Fixes open-telemetry#38999 #### Testing Unit tests added. #### Documentation N/A
LucianoGiannotti
pushed a commit
to LucianoGiannotti/opentelemetry-collector-contrib
that referenced
this issue
Apr 9, 2025
open-telemetry#39001) #### Description - Move marshaler implementations to internal package - Simplify code to obtain a marshaler given an encoding name - Make marshalers independent of Sarama (Kafka client) - Implement a generic Kafka exporter with type parameter for signal-specific parts - Create more tightly scoped unit tests for encodings, independent of the general functionality of the exporter - Added tests for partitioning logic #### Link to tracking issue Fixes open-telemetry#38999 #### Testing Unit tests added. #### Documentation N/A
Fiery-Fenix
pushed a commit
to Fiery-Fenix/opentelemetry-collector-contrib
that referenced
this issue
Apr 24, 2025
open-telemetry#39001) #### Description - Move marshaler implementations to internal package - Simplify code to obtain a marshaler given an encoding name - Make marshalers independent of Sarama (Kafka client) - Implement a generic Kafka exporter with type parameter for signal-specific parts - Create more tightly scoped unit tests for encodings, independent of the general functionality of the exporter - Added tests for partitioning logic #### Link to tracking issue Fixes open-telemetry#38999 #### Testing Unit tests added. #### Documentation N/A
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Component(s)
exporter/kafka
Is your feature request related to a problem? Please describe.
We've migrated our logging pipeline partially to Otel. We used to have a ELK stack, and now we still persist the logstash that receives logs from a Kafka topic, and insert them to ElasticSearch. On the producer side, we have an Otel collector with Kafka exporter. To keep the backward compatibility, we use the
raw
encoding in the Kafka exporter, but it doesn't supportpartition_logs_by_resource_attributes
:opentelemetry-collector-contrib/exporter/kafkaexporter/marshaler.go
Lines 90 to 98 in 0e087ff
I don't see why the raw encoding can't do the same thing as other encodings. The raw marshaler indeed discards the resource and record attributes in the end result (i.e. the message sent to the Kafka), but it still has the access to attributes during marshalling, just as other marshalers.
Describe the solution you'd like
The raw encoding should support
partition_logs_by_resource_attributes
too. Also if #38484 is accepted, raw encoding should also support it.Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: