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
[WIP] Implement spans exporting for ClickHouse storage in Jaeger V2 #4941
base: main
Are you sure you want to change the base?
Conversation
@yurishkuro This still needs some supplements and a lot of cleanups and tests. I'm still working on them. But could you take an initial look to see if I'm going the right way? Thanks! |
plugin/storage/clickhouse/factory.go
Outdated
//TODO: Move some steps to Initialize() | ||
} | ||
|
||
func (f *Factory) CreateSpansTable(ctx context.Context) { |
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.
why is this function public, who would call it?
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.
Currently, Jaeger V2's exporter checks the type of Factory. If it's a clickhouse Factory, then f.CreateSpansTable() is called, as you can see in this piece.
} | ||
} | ||
|
||
func (f *Factory) ExportSpans(ctx context.Context, td ptrace.Traces) error { |
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.
why is ExportSpans defined on the factory instead of span store?
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.
The logic is defined in plugin/storage/clickhouse/spanstore/exporter.go
(link). But Jaeger V2's exporter is depending on the real type of Factory to decide whether to call SpanWriter.WriteSpan()
or ExportSpans()
(link). So I think making ExportSpans()
a func of clickhouse Factory
may be a good idea.
Of course, a better idea is to define a new API for ExportSpans()
, but maybe we can do that later? Or you have a better idea?
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 have a better idea, but it is not well formed yet, I need to write it down and maybe put together the new interfaces. Will try to do this later this weekend. Are you blocked on it?
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.
No I don't think this blocks the progress. Can continue.
063ac74
to
4608c16
Compare
👍 I've been waiting clickhouse support for a long time. Is there anything I can help you with? |
@k0zl Sure! For this PR (spans exporting), the remaining parts are:
After finishing with spans exporting, we'll move to spans reading,... Also, since clickhouse storage is supported in Jaeger v2, to make this realeased you could also help with Jaeger v2 roadmap, in the issue I linked above. Please choose whatever interests you. Thanks! |
@haanhvu it would be useful to write a design doc / roadmap documenting what we're doing and what tasks need to be done, are you up for that? You can model it after the Jaeger V2 document. |
Yeah I'll create an issue for supporting clickhouse in jaeger v2 tomorrow |
7010d65
to
5b69530
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #4941 +/- ##
==========================================
- Coverage 95.62% 95.08% -0.54%
==========================================
Files 314 318 +4
Lines 18294 18438 +144
==========================================
+ Hits 17493 17532 +39
- Misses 642 737 +95
- Partials 159 169 +10
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
31cc9b7
to
d780080
Compare
@yurishkuro Could you take a look at the failed all-in-one build? |
I am seeing error
|
config *Config | ||
logger *zap.Logger | ||
spanWriter spanstore.Writer | ||
exportTraces func(ctx context.Context, td ptrace.Traces) error |
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.
nit: I would call this consumeTraces
, because the argument that we pass to the exporter helper is consumer.ConsumeTracesFunc
return fmt.Errorf("cannot create span writer: %w", err) | ||
} | ||
exp.requireBatchInsert = false | ||
exp.exportTraces = exp.pushTraces |
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.
nit: I'd rename s/pushTraces/writeSpans/
to indicate jaeger-v1 style storage
@yurishkuro This error didn't come up in my |
This test doesn't just run on its own, it expects the binary running, so how are you starting the binary? For example, this works: # terminal 1
$ go run -tags=ui ./cmd/jaeger
# terminal 2
$ SKIP_SAMPLING=true make all-in-one-integration-test But this is running with default aio config for OTEL, whereas you need to provide your own config in order to test the same against CH. |
Ah, I ran the binary with |
The So now I'll have to run clickhouse server, make my own jaeger v2 config (that exports to clickhouse) and |
Signed-off-by: haanhvu <haanh6594@gmail.com>
Signed-off-by: haanhvu <haanh6594@gmail.com>
@yurishkuro I ran the binary with my config.yaml, spans were exported successfully to clickhouse: Should we add an e2e test now, or wait until spans reading are implemented? Also, can you check the unit tests? I just have one Pls check if there's anything else you think we should test in this PR. |
You wouldn't be able to do e2e without reading, that's how the tests verify that traces are saved. |
switch t := f.(type) { | ||
case *ch.Factory: | ||
exp.clickhouse = true | ||
t.CreateSpansTable(ctx) |
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.
why can't we do this inside clickhouse.NewFactory
? storageexporter
doesn't need to know about internal details of each storage implementation
Which problem is this PR solving?
Part of #5058