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

Update prometheus/exporter-toolkit to v0.8.2 and gRPC to 1.47 #262

Merged

Conversation

rabenhorst
Copy link
Contributor

@rabenhorst rabenhorst commented Nov 14, 2022

Updated prometheus/exporter-toolkit to v0.8.2 to make it work with Prometheus v0.40.1.

Copy link
Collaborator

@bboreham bboreham left a comment

Choose a reason for hiding this comment

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

Can we avoid bumping gRPC?
Also, did you go mod tidy ? Seems like a lot of lines added in go.sum compared to actual change.

google.golang.org/grpc v1.31.0
golang.org/x/net v0.0.0-20220909164309-bea034e7d591
golang.org/x/tools v0.1.5
google.golang.org/grpc v1.47.0
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can it be done without this update? This is an enormous jump.

If not, someone needs to do forwards/backwards compatibility testing to confirm that old and new clients work against old and new servers.

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually mimir has been running with 1.45 grpc since 14th June grafana/mimir#2098

Copy link
Contributor

Choose a reason for hiding this comment

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

We've concluded that Mimir's usage of grpc is not proof and I'm going to reuse the server test code (httpgrpc/server_test, with a few additions) to test compatibility of versions:
client using 1.31 grpc -> server 1.47
client 1.47 -> server 1.31

Copy link
Contributor

Choose a reason for hiding this comment

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

What I did to test gprc message handling compatibility:

Extracted the client and server sides of the httpgrpc/server/server.go and httpgrpc/server/server_test.go` files into https://github.com/krajorama/weaveworks-common-testclient and https://github.com/krajorama/weaveworks-common-testserver .

Added a test to return the OrgId extracted on the server side in the body . And another to test sending a method different then GET.

To run a test I execute the server and copied the URL it listened on, then run the client tests with:
weaveworks-common-testclient$ SERVER_URL=direct://127.0.0.1:35635 go test -count 1 -v ./...

The baseline was using the latest weaveworks/common at v0.0.0-20221125125352-88dcecd133b1, where:

require (
        ...
	github.com/weaveworks/common v0.0.0-20221125125352-88dcecd133b1
	google.golang.org/grpc v1.31.0
)

Then doing a go.mod replace to get:

replace github.com/weaveworks/common v0.0.0-20221125125352-88dcecd133b1 => github.com/rabenhorst/common v0.0.0-20221130173339-6d74945c9349

require (
        ...
	github.com/weaveworks/common v0.0.0-20221125125352-88dcecd133b1
	google.golang.org/grpc v1.47.0
)

I've run the test with all combinations: client version x server version. All tests passed.

@bboreham
Copy link
Collaborator

Thanks for the PR, by the way.

@bboreham
Copy link
Collaborator

Looks like the chain of dependencies that updates gRPC is:

github.com/prometheus/[email protected]
-> golang.org/x/[email protected] here
-> cloud.google.com/go/[email protected] here
-> google.golang.org/[email protected] here

I don't see a way to break that, except larger-scale copy-paste.

@krajorama
Copy link
Contributor

This is actually needed for native historgrams work as well in mimir-prometheus.

Copy link
Contributor

@krajorama krajorama left a comment

Choose a reason for hiding this comment

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

Please run make protos and add the result to the PR, thanks

@krajorama
Copy link
Contributor

Please run make protos and add the result to the PR, thanks

Actually this lead to errors for Mimir, so let's forget it for now. I'm trying to figure out what happened.

@krajorama
Copy link
Contributor

krajorama commented Nov 24, 2022

We should merge #264 first. Fixes the make protos issue above.

@rabenhorst rabenhorst force-pushed the prometheus-exporter-toolkit-v0.8.1 branch from 9eb1f14 to 20964de Compare November 29, 2022 14:04
@rabenhorst
Copy link
Contributor Author

rabenhorst commented Nov 29, 2022

We should merge #264 first. Fixes the make protos issue above.

I rebased on master, ran make protos on both macOS arm and linux x86 machine and always get an error:

gogoproto/gogo.proto: File not found.
httpgrpc/httpgrpc.proto:5:1: Import “gogoproto/gogo.proto” was not found or had errors.

Any idea how to fix this?

@cristiangreco
Copy link

Drive-by: prometheus/[email protected] has been released today, which fixes https://pkg.go.dev/vuln/GO-2022-1130

@krajorama
Copy link
Contributor

krajorama commented Nov 30, 2022

We should merge #264 first. Fixes the make protos issue above.

I rebased on master, ran make protos on both macOS arm and linux x86 machine and always get an error:

gogoproto/gogo.proto: File not found.
httpgrpc/httpgrpc.proto:5:1: Import “gogoproto/gogo.proto” was not found or had errors.

Any idea how to fix this?

Put the path to gogoproto/gogo.proto in the -I include path of protoc compiler. (Since it is already a dependency of thanos-io).

E.g. in mimir:
https://github.com/grafana/mimir/blob/0f2929359b8b02b8427f1a901839b1805f43d58b/Makefile#L243

But since you're not using vendoring, you might have to do like in prometheus/alertmanager:
https://github.com/prometheus/alertmanager/blob/6ef6e6868dbeb7984d2d577dd4bf75c65bf1904f/Makefile.common#L241
https://github.com/prometheus/alertmanager/blob/main/scripts/genproto.sh

And possibly add a tools.go to make go get actually download it :(
https://github.com/weaveworks/common/blob/master/httpgrpc/tools.go

Background: we found that make protos here in weaveworks/common did not reproduce the generated files since it was missing the gogo extension definitions. Now this is added so CI can check protobuf definitions and generated files automatically.

@rabenhorst
Copy link
Contributor Author

Put the path to gogoproto/gogo.proto in the -I include path of protoc compiler. (Since it is already a dependency of thanos-io).

Thx. It worked and there is no change in generated files. Is this expected?

Also I updated exporter-toolkit to v0.8.2.

@rabenhorst rabenhorst changed the title Updated prometheus/exporter-toolkit to v0.8.1 Updated prometheus/exporter-toolkit to v0.8.2 Nov 30, 2022
Signed-off-by: Sebastian Rabenhorst <[email protected]>
@krajorama
Copy link
Contributor

Put the path to gogoproto/gogo.proto in the -I include path of protoc compiler. (Since it is already a dependency of thanos-io).

Thx. It worked and there is no change in generated files. Is this expected?

Also I updated exporter-toolkit to v0.8.2.

Yes, that's expected, we just wanted to get to a reproducable build where make protos does not result in diffs in git.

Copy link
Collaborator

@bboreham bboreham left a comment

Choose a reason for hiding this comment

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

As noted in individual comments, this is a big jump in gRPC version, and the stats say something has changed on the wire, but I'm very grateful to @krajorama for testing backwards and forwards compatibility.

@@ -211,7 +211,7 @@ func TestGrpcStatsStreaming(t *testing.T) {
received_payload_bytes_bucket{method="gRPC",route="/middleware.EchoServer/Process",le="1.048576e+08"} 5
received_payload_bytes_bucket{method="gRPC",route="/middleware.EchoServer/Process",le="2.62144e+08"} 5
received_payload_bytes_bucket{method="gRPC",route="/middleware.EchoServer/Process",le="+Inf"} 5
received_payload_bytes_sum{method="gRPC",route="/middleware.EchoServer/Process"} 1.5728664e+07
received_payload_bytes_sum{method="gRPC",route="/middleware.EchoServer/Process"} 1.5728689e+07
Copy link
Collaborator

Choose a reason for hiding this comment

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

Noting this difference suggests to me the code is seeing 5 bytes more on the wire.

Copy link
Contributor

Choose a reason for hiding this comment

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

This turned out to be an artifact from this fix in grpc: grpc/grpc-go#3886 , the old code was reporting wrong wirelength to the statistics callback actually.

@bboreham bboreham merged commit 7c2720a into weaveworks:master Dec 1, 2022
@bboreham bboreham changed the title Updated prometheus/exporter-toolkit to v0.8.2 Update prometheus/exporter-toolkit to v0.8.2 and gRPC to 1.47 Dec 1, 2022
MasslessParticle pushed a commit to grafana/loki that referenced this pull request Jan 12, 2023
…mmon` (#8125)

Not needed after weaveworks/common#254 and
weaveworks/common#262

More rationale on the issue.

Fixes #8085 

Signed-off-by: Kaviraj <[email protected]>
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