chore: remove span-metrics leftovers and lazy-init generator clients - #6618
Conversation
| t.cfg.Distributor.KafkaWritePathEnabled = t.cfg.Ingest.Enabled // TODO: Don't mix config params | ||
| t.cfg.Distributor.KafkaWritePathEnabled = false | ||
| t.cfg.Distributor.PushSpansToKafka = true | ||
| t.cfg.Distributor.PushSpansToGenerator = singleBinary |
There was a problem hiding this comment.
This is necessary until we implement the LiveStore grpc path
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 552bd48166
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| t.cfg.Distributor.KafkaConfig = t.cfg.Ingest.Kafka | ||
| t.cfg.Distributor.IngesterWritePathEnabled = false | ||
| t.cfg.Distributor.KafkaWritePathEnabled = t.cfg.Ingest.Enabled // TODO: Don't mix config params | ||
| t.cfg.Distributor.PushSpansToKafka = true |
There was a problem hiding this comment.
Gate Kafka write-path enablement on actual ingest configuration
initDistributor now forces PushSpansToKafka = true for every target, which makes distributor.New() always validate Kafka settings and fail when ingest.kafka.topic is unset. With the current defaults (ingest.enabled: false, empty topic), this turns the default all target into a startup error path (ErrMissingKafkaTopic) even for configs that previously booted without Kafka; the test change to BackendScheduler masks this regression rather than fixing it. Please only enable Kafka routing when the deployment/config is actually Kafka-backed (or provide a non-empty default topic).
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Kafka is the only deployment model now unless we are in singlebinary mode. So this is totally right
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f34eb0b7f2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
mapno
left a comment
There was a problem hiding this comment.
Love the cleanup, but I think it can be further simplified.
| }() | ||
|
|
||
| config := NewDefaultConfig() | ||
| config.Target = BackendScheduler |
There was a problem hiding this comment.
Now setting up Kafka is mandatory. If we dont set it and we dont set target we get a validation error:
level=info msg="server listening on addresses" http=[::]:60047 grpc=[::]:60048
--- FAIL: TestApp_RunStop (30.00s)
app_test.go:44: Checking Tempo is up...
app_test.go:38:
Error Trace: /Users/javimolina/grafana/tempo.fork/cmd/tempo/app/app_test.go:38
/opt/homebrew/Cellar/go/1.26.0/libexec/src/runtime/asm_arm64.s:1447
Error: Received unexpected error:
failed to init module services: error initialising module: distributor: failed to create distributor: the Kafka topic has not been configured
Test: TestApp_RunStop
app_test.go:43:
Error Trace: /Users/javimolina/grafana/tempo.fork/cmd/tempo/app/app_test.go:43
Error: Condition never satisfied
Test: TestApp_RunStop
FAIL
exit status 1
FAIL github.com/grafana/tempo/cmd/tempo/app 30.994sUntil we make the whole target --all kafkaless we need to use a non kafka module. It can be the backendscheduler or any other one
| KafkaConfig ingest.KafkaConfig `yaml:"kafka_config"` | ||
|
|
||
| // Internal routing toggle set by app wiring (not user-configurable). | ||
| PushSpansToKafka bool `yaml:"-"` |
There was a problem hiding this comment.
Isn't this always true? Why have this param?
There was a problem hiding this comment.
This is a placeholder. When we make the kafkaless mode this will be set to false instructing the distributor to not push to kafka
| var generatorsPoolFactory ring_client.PoolAddrFunc = func(addr string) (ring_client.PoolClient, error) { | ||
| return generator_client.New(addr, generatorClientCfg) | ||
| if d.pushSpansToLocalFunc != nil { | ||
| d.generatorForwarder = newGeneratorForwarder(logger, d.sendToGenerators, o) |
There was a problem hiding this comment.
I don't think there is a strong argument to keep all this complexity. If the push fails we can log the error and continue. No need to keep channels, workers, etc.
There was a problem hiding this comment.
The main advantage of this is the decoupling between the distributor and the generator execution. Not that much for error handling but for e2e latency. We can remove it, or we can simplify it to a single bounded channel to not spawn infinite goroutines
There was a problem hiding this comment.
I think we should follow up this in a different pr because it has some tradeoff we need to discuss
There was a problem hiding this comment.
If the concern is decoupling, a goroutine or a simple buffered channel is sufficient. The current queuing code is over-engineered for an in-process call.
I'm ok to leave it if it gets addressed in another PR.
| var pushSpansToLocalGenerator distributor.PushSpansFunc | ||
| if singleBinary { | ||
| pushSpansToLocalGenerator = func(ctx context.Context, req *tempopb.PushSpansRequest) (*tempopb.PushResponse, error) { | ||
| if t.generator == nil { | ||
| return nil, errors.New("metrics-generator not initialized") | ||
| } | ||
| return t.generator.PushSpans(ctx, req) | ||
| } | ||
| } |
There was a problem hiding this comment.
Thinking about more kafkaless changes, it'd be nice to instead have a call in the distributor .AddDirectPush() that appends these types of calls, because we're going to need it for the live-store as well. That way it also doesn't change the happy path.
I'm fine if you prefer it this way.
There was a problem hiding this comment.
do you mind if we do it in a different pr? this is wired with the middleware and the shim and it involves some other changes
| return t.generator, nil | ||
| } | ||
|
|
||
| func (t *App) initGeneratorNoLocalBlocks() (services.Service, error) { |
There was a problem hiding this comment.
I believe there is now no functional difference between the two can could be consolidated.
There was a problem hiding this comment.
Yes, this is something I want to tackle on a different PR. We need first to allow the initGenerator to use a different ring and differect codecs for at least one release since this target (initGeneratorNoLocalBlocks) is already in use
…rafana#6618) * chore: route generator by deployment model and deprecate ingest.enabled * chore: remove metrics-generator query RPCs and handlers * chore: remove span-metrics leftovers and lazy-init generator clients * docs(changelog): add entry for grafana#6618 * breaking change * manifest * remove deprecated fields * fix errored test * remove generator grpc path * fmt * simplify code
What this PR does:
Now that we have decoupled the livestores from the MetricsGenerator service we can now complete the cleanup. This pr does:
How this has been tested:
Which issue(s) this PR fixes:
Fixes #
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]