Bryan Boreham

BTW I just added a link to a blog post in #1578 that describes the efficiency gains.

We could count the number of in-flight requests to ingesters and fail (response 5xx) the incoming request when that number goes over a threshold. This would prevent OOM on the...

Slightly more sophisticated: Count the number of requests in-flight per ingester. If one of them is over a threshold, treat that ingester as unhealthy and spill the samples to the...

We added `-distributor.instance-limits.max-inflight-push-requests` and `-ingester.instance-limits.max-inflight-push-requests` in 1.9.0. Note that `-distributor.instance-limits.max-inflight-push-requests` does not address this problem on its own, because it decrements the counter after 2 responses have been received; the...

As far as I can see the change in #4018 did not cover the "state the label name" part; reopening.

Wild idea to get a query-optimizer: Embed SQLite, create a row per series, translate the PromQL labels into a SQL SELECT, then the SQLite query optimizer will tell you which...

This reminds me of #3097.

We have `-ingester.instance-limits.max-inflight-push-requests` now which will allow the requests to be capped and avoid OOM, however it will still create a lot of noise from error messages and retried requests.

I don't think this should be closed.

@pstibrany explained the last point: the next heartbeat will save the in-memory state to Consul. So, maybe all we need is a better check in `Ingester.transfer()` ?