Skip to content
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

Merged
merged 4 commits into from
Aug 26, 2020

Conversation

pavolloffay
Copy link
Member

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

@codecov
Copy link

codecov bot commented Aug 18, 2020

Codecov Report

Merging #1584 into master will increase coverage by 0.05%.
The diff coverage is 95.62%.

Impacted file tree graph

@@            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              
Impacted Files Coverage Δ
exporter/kafkaexporter/otlp_marshaller.go 77.77% <77.77%> (ø)
exporter/kafkaexporter/jaeger_marshaller.go 90.00% <90.00%> (ø)
receiver/kafkareceiver/zipkin_unmarshaller.go 92.85% <92.85%> (ø)
exporter/kafkaexporter/factory.go 100.00% <100.00%> (ø)
exporter/kafkaexporter/kafka_exporter.go 100.00% <100.00%> (ø)
exporter/kafkaexporter/marshaller.go 100.00% <100.00%> (ø)
receiver/kafkareceiver/factory.go 100.00% <100.00%> (ø)
receiver/kafkareceiver/jaeger_unmarshaller.go 100.00% <100.00%> (ø)
receiver/kafkareceiver/kafka_receiver.go 100.00% <100.00%> (ø)
receiver/kafkareceiver/otlp_unmarshaller.go 100.00% <100.00%> (ø)
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b13392b...cf9ee8e. Read the comment docs.

Copy link
Contributor

@objectiser objectiser left a 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.

- `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`.
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

exporter/kafkaexporter/config.go Outdated Show resolved Hide resolved
defaultTopic = "otlp_spans"
defaultBroker = "localhost:9092"
typeStr = "kafka"
defaultTopic = "otlp_spans"
Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Member Author

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).

Copy link
Contributor

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.

receiver/kafkareceiver/README.md Outdated Show resolved Hide resolved
@pavolloffay
Copy link
Member Author

The CI failure does not seem to be related to this PR.

@pavolloffay
Copy link
Member Author

@bogdandrutu would you like to review this one too?

Copy link
Member

@bogdandrutu bogdandrutu left a 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

var marshallers = map[string]Marshaller{}

// GetMarshaller gets a Marshaller for encoding or nil if no marshaller is registered.
func GetMarshaller(encoding string) Marshaller {
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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

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.

Copy link
Member

@bogdandrutu bogdandrutu Aug 22, 2020

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

Copy link
Member Author

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.

Copy link
Member Author

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.

exporter/kafkaexporter/marshaller.go Outdated Show resolved Hide resolved
@pavolloffay
Copy link
Member Author

Can somebody restart the build?

The failure does not seem to be related to this PR

ERROR: 1 dead links found!
[✖] https://cortexmetrics.io/docs/apis/ → Status: 404

@marianoao
Copy link

I think that zipkin allows several encodings of kafka marshalled spans:

https://github.com/openzipkin/zipkin/blob/master/zipkin/src/main/java/zipkin2/codec/SpanBytesDecoder.java

  • zipkin v1 json
  • zipkin v2 json
  • thrift
  • proto3

@pavolloffay
Copy link
Member Author

pavolloffay commented Aug 24, 2020

@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?

@codefromthecrypt
Copy link
Contributor

yeah kafka (and other transports like activemq and rabbit) support proto also

@pavolloffay
Copy link
Member Author

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()),
Copy link
Member

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?

Copy link
Member Author

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.

@bogdandrutu
Copy link
Member

@pavolloffay you need to rebase, the failing test is TestGRPCReceptionWithTLS in jaeger which had the expired certificates and most likely you did not rebase since then so will always fail.

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>
@pavolloffay
Copy link
Member Author

Rebased

@pavolloffay
Copy link
Member Author

The build failed again on the contrib test...

@bogdandrutu bogdandrutu merged commit 7f13eb6 into open-telemetry:master Aug 26, 2020
hughesjj pushed a commit to hughesjj/opentelemetry-collector that referenced this pull request Apr 27, 2023
…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>
Troels51 pushed a commit to Troels51/opentelemetry-collector that referenced this pull request Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support custom encoding in Kafka
6 participants