apitech/loki - loki - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Ed Welch	4c88be0ef2	chore: update loki modules for 3.0 release (#12433 ) Signed-off-by: Edward Welch <edward.welch@grafana.com>	1 year ago
Danny Kopping	9734c4b832	Minor fixes to congestion control mechanism (#10319 ) What this PR does / why we need it: Minor logging / metric improvements to #10140	2 years ago
Danny Kopping	beed298549	Dynamic client-side throttling to avoid object storage rate-limits (GCS only) (#10140 ) What this PR does / why we need it: Across the various cloud providers' object storage services, there are different rate-limits implemented. Rate-limits can be imposed under multiple conditions, such as server-side scale up (ramping up from low volume to high, "local" limit), reaching some defined upper limit ("absolute" limit), etc. We cannot know apriori when these rate-limits will be imposed, so we can't set up a client-side limiter to only allow a certain number of requests through per second. Additionally, that would require global coordination between queriers - which is difficult. With the above constraints, I have instead taken inspiration from TCP's [congestion control algorithms](https://en.wikipedia.org/wiki/TCP_congestion_control). This PR implements [AIMD](https://en.wikipedia.org/wiki/Additive_increase/multiplicative_decrease) (Additive Increase, Multiplicative Decrease), which is used in the congestion _avoidance_ phase of congestion control. The default window size (object store requests per second) is 2000; in other words, we skip the "slow start" phase. The controller uses the Go [`rate.Limiter`](https://pkg.go.dev/golang.org/x/time/rate), which implements the token-bucket algorithm. To put it simply: - every successful request widens the window (per second client rate-limit) - every rate-limited response reduces the window size by a backoff factor (0.5 by default, so it will halve) - when the limit has been reached, the querier will be delayed from making further requests until tokens are available	2 years ago

Author

SHA1

Message

Date

Ed Welch

4c88be0ef2

chore: update loki modules for 3.0 release (#12433 )

Signed-off-by: Edward Welch <edward.welch@grafana.com>

1 year ago

Danny Kopping

9734c4b832

Minor fixes to congestion control mechanism (#10319 )

**What this PR does / why we need it**:
Minor logging / metric improvements to #10140

2 years ago

Danny Kopping

beed298549

Dynamic client-side throttling to avoid object storage rate-limits (GCS only) (#10140 )

**What this PR does / why we need it**:
Across the various cloud providers' object storage services, there are
different rate-limits implemented. Rate-limits can be imposed under
multiple conditions, such as server-side scale up (ramping up from low
volume to high, "local" limit), reaching some defined upper limit
("absolute" limit), etc.

We cannot know apriori when these rate-limits will be imposed, so we
can't set up a client-side limiter to only allow a certain number of
requests through per second. Additionally, that would require global
coordination between queriers - which is difficult.

With the above constraints, I have instead taken inspiration from TCP's
[congestion control
algorithms](https://en.wikipedia.org/wiki/TCP_congestion_control). This
PR implements
[AIMD](https://en.wikipedia.org/wiki/Additive_increase/multiplicative_decrease)
(Additive Increase, Multiplicative Decrease), which is used in the
congestion _avoidance_ phase of congestion control. The default window
size (object store requests per second) is 2000; in other words, we skip
the "slow start" phase.

The controller uses the Go
[`rate.Limiter`](https://pkg.go.dev/golang.org/x/time/rate), which
implements the token-bucket algorithm.

To put it simply:
- every successful request widens the window (per second client
rate-limit)
- every rate-limited response reduces the window size by a backoff
factor (0.5 by default, so it will halve)
- when the limit has been reached, the querier will be delayed from
making further requests until tokens are available

2 years ago

3 Commits (39c47e5b5a188b763b32e3e92939ccfce01d2a86)