-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Make Kafka payload encoding configurable #1584
Make Kafka payload encoding configurable #1584
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1584 +/- ##
==========================================
+ Coverage 91.97% 92.03% +0.05%
==========================================
Files 254 259 +5
Lines 17286 17418 +132
==========================================
+ Hits 15899 16030 +131
- Misses 989 990 +1
Partials 398 398
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some initial comments about naming.
exporter/kafkaexporter/README.md
Outdated
- `encoding` (default = otlp_proto): The encoding of the payload sent to kafka. Available encodings: | ||
- `otlp_proto`: the payload is deserialized to `ExportTraceServiceRequest`. | ||
- `jaeger_proto_span`: the payload is deserialized to a single Jaeger proto `Span`. | ||
- `jaeger_json_span`: the payload is deserialized to a single Jaeger JSON Span using `jsonpb`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just for consistency, it might be better to remove the _span
from the above jaeger values, or add _span
to the zipkin ones, as they are all related to spans.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For Jaeger encoding I wanted to empasize that payload is a single span which can have perf implications I assume. However this is the encoding Jaeger upstream uses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok that is reasonable, hadn't understood the difference between jaeger and zipkin (in terms of single versus multiple spans), but clear now.
defaultTopic = "otlp_spans" | ||
defaultBroker = "localhost:9092" | ||
typeStr = "kafka" | ||
defaultTopic = "otlp_spans" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to have a generic defaultTopic
not perceived to be associated with the encoding? e.g. just spans
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please create a separate issue for this. Ideally, this should not clash with other topic names used in OSS systems Zipkin/Jaeger.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that the non OTLP encodings will be used in legacy deployments that already use different topic names (e.g. jaeger-spans
, zipkin
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it is reasonable to have a default topic aligned with the default encoding - so if someone is changing the encoding they are likely to change the topic, so nevermind.
The CI failure does not seem to be related to this PR. |
@bogdandrutu would you like to review this one too? |
5db337f
to
3b849e3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why we need a public mechanism to register marshaler
exporter/kafkaexporter/marshaller.go
Outdated
var marshallers = map[string]Marshaller{} | ||
|
||
// GetMarshaller gets a Marshaller for encoding or nil if no marshaller is registered. | ||
func GetMarshaller(encoding string) Marshaller { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be public?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to make this extensible for people extending the collector. Anybody who imports a custom format (e.g. in exporter) can easily support Kafka transport.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not do this prematurely. If there is a request we will consider to do then. Any public API is extra overhead to maintain
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This extensibility is something we're looking to make use of in hyptertrace, so it would be great if these could be kept public.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so if we need to do this it is anyway necessary to compile again the code with the new marshaler. Can we make the Kafka factory accept the custom encodings then?
Essentially avoid the global state if possible
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can do that, I wanted to make it simpler to provide custom encodings. The base idea was that the registry could be called from any place e.g. exporter that imports custom data model.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, I have exposed (un)marshalers in the factory.
Can somebody restart the build? The failure does not seem to be related to this PR
|
20ac0f4
to
507dd0a
Compare
I think that zipkin allows several encodings of kafka marshalled spans:
|
@marianoao the proto support is not listed here https://github.com/openzipkin/zipkin/tree/master/zipkin-collector/kafka#encoding-spans-into-kafka-messages. After this PR it's easy to add additional encodings. This PR adds Zipkin JSON v2 and Thrift (list of spans). Also this PR does not add Zipkin encodings to exporter, again, it's very easy to add them since we should have all model translators in place. @adriancole could you loop in here? Is the proto encoding supporter in zipkin kafka? |
yeah kafka (and other transports like activemq and rabbit) support proto also |
I will submit support for proto in the follow-up PR. @bogdandrutu this PR is ready for your review. The CI seems flaky and needs a restart. |
@@ -90,7 +90,7 @@ func Components() ( | |||
jaegerexporter.NewFactory(), | |||
fileexporter.NewFactory(), | |||
otlpexporter.NewFactory(), | |||
kafkaexporter.NewFactory(), | |||
kafkaexporter.NewFactory(kafkaexporter.DefaultMarshallers()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can the marshaler be optional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in the next commit, the CI failure does not seem to be related to this PR.
@pavolloffay you need to rebase, the failing test is |
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
d2e82af
to
cf9ee8e
Compare
Rebased |
The build failed again on the contrib test... |
…metry#1584) Bumps [github.com/jaegertracing/jaeger](https://github.com/jaegertracing/jaeger) from 1.33.0 to 1.34.1. - [Release notes](https://github.com/jaegertracing/jaeger/releases) - [Changelog](https://github.com/jaegertracing/jaeger/blob/v1.34.1/CHANGELOG.md) - [Commits](jaegertracing/jaeger@v1.33.0...v1.34.1) --- updated-dependencies: - dependency-name: github.com/jaegertracing/jaeger dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Signed-off-by: Pavol Loffay ploffay@redhat.com
Description:
This PR makes configurable encoding of Kafka message payloads. I have added support for Jaeger proto and JSON for both receiver and exporter and also Zipkin JSON and thrift for receiver to cover the functionality we had in Jaeger. This will allow users to migrate to the OTEL collector and also Jaeger project to use this new implementation directly.
In addition to that additional encodings can be programmatically added via a registry.
Link to tracking Issue:
Resolves #1580
Testing: < Describe what testing was performed and which tests were added.>
Documentation: < Describe the documentation added.>
Added to readme