Skip to content

[RW]: Adopt client_golang/exp/api/remote types for receiving RW1 and RW2#17197

Merged
bwplotka merged 9 commits intoprometheus:mainfrom
pipiland2612:Official_client
Oct 24, 2025
Merged

[RW]: Adopt client_golang/exp/api/remote types for receiving RW1 and RW2#17197
bwplotka merged 9 commits intoprometheus:mainfrom
pipiland2612:Official_client

Conversation

@pipiland2612
Copy link
Contributor

@pipiland2612 pipiland2612 commented Sep 16, 2025

Which issue(s) does the PR fix:

Scope

This PR migrates Prometheus to use the official github.com/prometheus/client_golang/exp/api/remote package types for remote write protocol handling. This change covers:

What's included:

  • Receiving side: Write handler now uses exp/api/remote types for processing both RW1 (prometheus.WriteRequest) and RW2 (io.prometheus.write.v2.Request) incoming requests
  • Sending side: Queue manager and write client updated to use exp/api/remote types when sending remote write requests (both RW1 and RW2)
  • Replaces config.RemoteWriteProtoMsg with remoteapi.WriteMessageType throughout the codebase
  • Removes duplicate protocol type definitions from Prometheus config package

What's NOT included:

  • No changes to protocol behavior or specifications
  • No functional changes to how remote write works
  • The Remote Write protocols (1.0 and 2.0) remain stable and unchanged

Does this PR introduce a user-facing change?

NONE

@pipiland2612 pipiland2612 changed the title revert Use client_golang_exp/api/remote for handling remote writes Sep 16, 2025
@pipiland2612 pipiland2612 reopened this Sep 16, 2025
@bboreham
Copy link
Member

Thanks for this. I guess @bwplotka should take a look.

The exp area is declared Experimental, so can we rely on it in Prometheus?

@pipiland2612
Copy link
Contributor Author

Hi @bboreham, thanks for check out my PR. I think @bwplotka has already explained this quite carefully here. You can check it out: #16086 (comment)

Copy link
Member

@saswatamcode saswatamcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Great work 💪🏻

Some small nits!

Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>

# Conflicts:
#	storage/remote/write_handler.go
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
@pipiland2612
Copy link
Contributor Author

cc @bwplotka

Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
Copy link
Member

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial look - looks great! Some small comments, thanks!

Copy link
Member

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checked the rest, generally LGTM, modulo above comments, great work! 💪🏽

Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
@pipiland2612
Copy link
Contributor Author

Hi @bwplotka, thanks for pointing those out. Please take a look again when you have time. I have fixed at 0639af2

Copy link
Member

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks!

Before merging, let's ensure (wait for response) @bboreham is still objecting this change after our explanation, also pinged on prometheus-dev https://cloud-native.slack.com/archives/C01AUBA4PFE/p1759757051305119

@bboreham
Copy link
Member

bboreham commented Oct 7, 2025

In regard to "experimental", I would prefer if the comment was modified to say something different to "The module may be contain breaking changes or be removed in the future."
What about "This code is used by released versions of Prometheus, but should not be relied upon outside of the Prometheus project" ?

@bboreham
Copy link
Member

bboreham commented Oct 7, 2025

Can you clarify the title "Use client_golang_exp/api/remote for handling remote writes" please?
Looks like this is focused on configuration and RW2. I do not see RW1 structs in client_golang.

EDIT: according to a Slack comment, this PR is for receiving, and sending will be changed later.
Please make the scope clear.

@bboreham
Copy link
Member

bboreham commented Oct 7, 2025

Is RW2 covered by PromBench?

@bwplotka
Copy link
Member

bwplotka commented Oct 7, 2025

Great points, do you mind @pipiland2612 helping with client_golang/exp module documentation and this PR title description? (@bboreham is right that "handling" remote write can mean both sending and receiving, in this case it's receiving).

Is RW2 covered by PromBench?

Yes (prometheus/test-infra#845) -- although for sending, which we don't change here.

We don't have prombench for receiving for anything AFAIK

Signed-off-by: pipiland2612 <nguyen.t.dang.minh@gmail.com>
@pipiland2612 pipiland2612 changed the title Use client_golang_exp/api/remote for handling remote writes [RW]: Adopt client_golang/exp/api/remote types for RW1 and RW2 Oct 17, 2025
@pipiland2612
Copy link
Contributor Author

Can you clarify the title "Use client_golang_exp/api/remote for handling remote writes" please? Looks like this is focused on configuration and RW2. I do not see RW1 structs in client_golang.

EDIT: according to a Slack comment, this PR is for receiving, and sending will be changed later. Please make the scope clear.

Hi @bboreham, Indeed, thanks for suggesting. I have updated the PR title and descriptions

@pipiland2612
Copy link
Contributor Author

In regard to "experimental", I would prefer if the comment was modified to say something different to "The module may be contain breaking changes or be removed in the future." What about "This code is used by released versions of Prometheus, but should not be relied upon outside of the Prometheus project" ?

Thanks! Making changes at https://github.com/prometheus/client_golang/pull/1894/files. PTAL

@bboreham
Copy link
Member

Thanks, the scope and impact is much clearer now.

Copy link
Member

@bwplotka bwplotka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@bwplotka bwplotka changed the title [RW]: Adopt client_golang/exp/api/remote types for RW1 and RW2 [RW]: Adopt client_golang/exp/api/remote types for receiving RW1 and RW2 Oct 24, 2025
@bwplotka bwplotka merged commit f070e35 into prometheus:main Oct 24, 2025
31 checks passed
@bwplotka
Copy link
Member

I changed title and squashed commit msg to include "receiving" word, otherwise it looks like we adopt this lib for all RW interactions in this PR. Next time, please ensure clear PR titles and descriptions, it's quite important. @pipiland2612 (:

@pipiland2612 pipiland2612 deleted the Official_client branch October 24, 2025 09:55
songy23 pushed a commit to open-telemetry/opentelemetry-collector-contrib that referenced this pull request Dec 12, 2025
## Summary

This PR upgrades the `github.com/prometheus/prometheus` dependency from
v0.307.3 to v0.308.0.

## Changes Made

#### Fixed `RemoteWriteProtoMsg` unrecognized

In prometheus/prometheus v0.308.0, the remote write protocol message
types were moved from `github.com/prometheus/prometheus/config` to
`github.com/prometheus/client_golang/exp/api/remote` as part of
[prometheus/prometheus#17197](prometheus/prometheus#17197).

#### Fixed `CreatedTimestamp` → `StartTimestamp`

In
[prometheus/prometheus#17411](prometheus/prometheus#17411),
the Remote Write 2.0 spec was updated to 2.0-rc.4. The
`CreatedTimestamp` field was renamed to `StartTimestamp` and moved from
`TimeSeries` to individual `Sample` and `Histogram` messages.

#### Fixed not enough arguments in`api_v1.NewAPI` 

The `api_v1.NewAPI` function signature changed due to
[prometheus/prometheus#17470](prometheus/prometheus#17470)
- Added `appendMetadata bool` parameter for remote write metadata
handling. Added the new parameter `appendMetadata = false` -
prometheusreceiver scrapes targets, doesn't receive remote write
requests

## Remaining Issues

### `EnableNativeHistogramsIngestion` removed from `scrape.Options`

There's one change in this upgrade that I'd love to get the community's
input on before finalizing.

In
[prometheus/prometheus#17315](prometheus/prometheus#17315),
Prometheus removed the `EnableNativeHistogramsIngestion` field from
`scrape.Options`. Native histogram ingestion is now controlled through
the Prometheus scrape config option `scrape_native_histograms` rather
than programmatically.

This creates an interesting situation for us. Currently, we have the
feature gate `receiver.prometheusreceiver.EnableNativeHistograms` that
controls whether native histograms are converted to OTel exponential
histograms. But with this Prometheus change, the *ingestion* of native
histograms during scraping is now a separate concern controlled by
Prometheus config.

I see two paths forward here. We could automatically inject
`scrape_native_histograms: true` into the scrape config whenever our
feature gate is enabled, preserving the current behavior where enabling
the feature gate is all users need to do. Alternatively, we could simply
remove the line and require users to configure
`scrape_native_histograms: true` in their Prometheus scrape config
themselves, which is more explicit but adds an extra configuration step.

What do you think? I'm also wondering if this constitutes a breaking
change that should be called out in the changelog. Would appreciate any
thoughts!

---------

Signed-off-by: Arthur Silva Sens <arthursens2005@gmail.com>
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.

4 participants