Skip to content

Release 2.48.0-rc0#12959

Merged
bboreham merged 3 commits intoprometheus:release-2.48from
LeviHarrison:release-2.48.0-rc0
Oct 17, 2023
Merged

Release 2.48.0-rc0#12959
bboreham merged 3 commits intoprometheus:release-2.48from
LeviHarrison:release-2.48.0-rc0

Conversation

@LeviHarrison
Copy link
Copy Markdown
Contributor

@LeviHarrison LeviHarrison commented Oct 9, 2023

Waiting for 10/10 Go release


## 2.48.0-rc.0 / 2023-10-10

* [CHANGE] Remote-write: respect Retry-After header on 5xx errors. #12677
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Wasn't sure about calling this a change or an enhancement, but it does change the current behavior of remote-write retries

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Could see it as a bugfix, even.

Copy link
Copy Markdown
Contributor Author

@LeviHarrison LeviHarrison Oct 11, 2023

Choose a reason for hiding this comment

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

Yeah, I just don't know how expected that behavior is. Especially as it's not a configuration option. But, I'm up to whatever you want.

Also on another note I see in that PR there was some discussion around documenting it, but I'm not sure if that that ever happened?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

it's a change to me

@roidelapluie
Copy link
Copy Markdown
Member

did we update the dependencies?

@LeviHarrison
Copy link
Copy Markdown
Contributor Author

Was waiting on the go release to do that all in one

Signed-off-by: Levi Harrison <git@leviharrison.dev>
@LeviHarrison LeviHarrison marked this pull request as ready for review October 16, 2023 02:34
Copy link
Copy Markdown
Member

@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.

I had a couple of thoughts about making the text more widely understood.
Not critical.

Signed-off-by: Levi Harrison <git@leviharrison.dev>
@roidelapluie
Copy link
Copy Markdown
Member

Lgtm

Signed-off-by: Levi Harrison <git@leviharrison.dev>
@bboreham bboreham merged commit 551fa83 into prometheus:release-2.48 Oct 17, 2023
@LeviHarrison
Copy link
Copy Markdown
Contributor Author

/prombench v2.47.2

@prombot
Copy link
Copy Markdown
Contributor

prombot commented Oct 17, 2023

⏱️ Welcome to Prometheus Benchmarking Tool. ⏱️

Compared versions: PR-12959 and v2.47.2

After successful deployment, the benchmarking results can be viewed at:

Other Commands:
To stop benchmark: /prombench cancel
To restart benchmark: /prombench restart v2.47.2

@zenador
Copy link
Copy Markdown
Contributor

zenador commented Oct 20, 2023

Note that NewPossibleNonCounterInfo in #12152 makes rate queries inefficient, needs fixing before release.

@juliusv
Copy link
Copy Markdown
Member

juliusv commented Oct 20, 2023

@zenador Looking at that PR again, that warning looks like something that we should be able to figure out statically when looking at the PromQL, so maybe it can be extracted from the actual function implementation completely? Then it also doesn't have to be evaluated (and the annotation added) for each resolution step of a range query.

@juliusv
Copy link
Copy Markdown
Member

juliusv commented Oct 20, 2023

Addendum to doing it statically: It wouldn't work in the case where you don't equality-match on the metric name, but at least you could check it once after resolving series identities for selectors, not for each resolution step?

@zenador
Copy link
Copy Markdown
Contributor

zenador commented Oct 20, 2023

Yes I agree, that particular warning and another one can be derived from the query itself, so we will move it out, but until then, we can remove it for now for a quick fix. However, other warnings do actually look at the data and so those will need to be applied every step.

@bboreham
Copy link
Copy Markdown
Member

Some analysis of Prombench on this PR, plus meta-analysis.

I think the problem is clearest in the PromQL timings - it's 10-20% slower:
image

And once you know what's happening you can see it in memory allocations:
image

However CPU is unchanged? What gives?
image

I believe this is because the load-generator is configured to fire queries faster than they can execute, resulting in each Prometheus doing as much work as it can, and the slower one doing less work.
You can just about make that out in the requests/sec (note the y-axis is incorrectly labeled):
image

@prombot
Copy link
Copy Markdown
Contributor

prombot commented Oct 20, 2023

Benchmark tests are running for 3 days! If this is intended ignore this message otherwise you can cancel it by commenting: /prombench cancel

@prombot
Copy link
Copy Markdown
Contributor

prombot commented Oct 22, 2023

Benchmark tests are running for 5 days! If this is intended ignore this message otherwise you can cancel it by commenting: /prombench cancel

@LeviHarrison
Copy link
Copy Markdown
Contributor Author

/prombench cancel

@prombot
Copy link
Copy Markdown
Contributor

prombot commented Oct 22, 2023

Benchmark cancel is in progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants