feat(scrape)[PART5b]: Add AppenderV2 support to scrape.NewManager constructor#17872
feat(scrape)[PART5b]: Add AppenderV2 support to scrape.NewManager constructor#17872
Conversation
|
Windows |
There was a problem hiding this comment.
Pull request overview
This PR adds support for AppendableV2 to scrape.NewManager as part of the ongoing migration from Appendable to AppendableV2. The changes allow users to optionally specify AppendableV2 when creating a scrape manager, while maintaining backward compatibility by still accepting the legacy Appendable interface.
Changes:
- Modified
scrape.NewManagersignature to accept bothappendableandappendableV2parameters - Added validation to prevent both parameters from being specified simultaneously
- Updated all test code and production code to use the new signature
- Removed workaround code from AppendV2 tests that manually set private fields
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| scrape/manager.go | Updated NewManager to accept both Appendable and AppendableV2 parameters with validation |
| scrape/scrape_test.go | Updated test to pass nil for appendableV2 parameter |
| scrape/scrape_append_v2_test.go | Updated to use appendableV2 parameter and removed workaround code |
| scrape/manager_test.go | Updated all test calls and runManagers helper to support both parameters |
| cmd/prometheus/main.go | Updated production call with nil for appendableV2 (migration pending) |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
21315c2 to
49c60b0
Compare
49c60b0 to
28be7e7
Compare
a939a0f to
9e1d128
Compare
9e1d128 to
067f5f8
Compare
067f5f8 to
e40df21
Compare
|
|
…ionally to V1 Signed-off-by: bwplotka <bwplotka@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
Signed-off-by: bwplotka <bwplotka@gmail.com>
e40df21 to
0c6a269
Compare
|
Hey 👋 -- I've tried out the commit SHA from this PR in the collector just to have a glance at how much the code could be simplified with the new interface. The PR can be seen here: open-telemetry/opentelemetry-collector-contrib#45597 Overall, the codebase looks a lot more readable and easier to navigate. There was a lot of state handling for the v1 appender, e.g. when handling histogram ingestion or when deciding which suffixes to remove based on metadata.Type (the collector has functionality to remove suffixes from metric names). Another awesome improvement is that in v1 we were forced to have an intermediate struct between what the appender gives us and what we provide to the next consumer in the collector pipeline. With appenderv2, we can generate pmetric.Metrics directly from the Append method. If you compare the Things that aren't working so well yet are:
I'll be honest and say that I haven't been as invested in this refactoring as other folks here, so I'm not sure if I had different expectations for the metadata and summary problems, but I'd be happy to continue providing feedback from the collector side |
|
Thanks for looking so quickly on this! 🤗 Looks like it fulfills the mission! Also benchmark results should look sweet. I wished we could see the lines removed impact of it, but I understand you want to feature gate the switch (do you need to? no functionality changed). This is actually an important decision because supporting both V1 and V2 Appender implementations is extremely complex. Ideally we remove V1 ASAP. How long do you think we need to support this for Collector? 2mo-6mo is fine, but eventually we need to remove that huge tech debt. We can remove some metadata caches at some point with #17619 to reduce allocs a lot on collector even more (and Prometheus side)
Yes, you need to adjust your scrape opts. Explained in the comment: https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/45597/changes#r2720171281
Well, also classic histograms. Or do you strictly use NHCB? 🎉 If you are on NHCB, and state handling is an overhead, then sounds like we have a strong motivation to push forward NativeSummaries, at least on Appender level. |
Co-authored-by: Arve Knudsen <arve.knudsen@gmail.com> Signed-off-by: Bartlomiej Plotka <bwplotka@gmail.com>
|
Indeed, benchmarks are showing improvements (we're doing more work on append, but a lot less on commit): Bartek and I chatted briefly on Slack, and it seems the collector won't be able to eliminate state handling completely; we still need it to parse summaries correctly. For classic histograms, we're thinking about hardcoding the scrape setting that transforms classic histograms into NHCB, which means we could get rid of state handling for histograms at least :) |
Progresses the #17632
This small PR allows NewManager users to use AppendableV2. Does not switch prod yet.
This PR allows OpenTelemetry Collector use new interface to see how much it improves (or not) the Otel collector complexity and efficiency with
prometheusreceivercc @dashpole @aknuds1Does this PR introduce a user-facing change?