Mikołaj Świątek

The otel operator does not scale naturally. Increasing the number of replicas in a naive way only gives you hot standbys, as the replicas will elect a leader, and the...

@rashmichandrashekar could you please rebase your branch, so your PR only has changes to the prometheus receiver? Right now, it has a bunch of other random changes.

@rashmichandrashekar it looks like we might be moving the target allocator related code to its own package, as per #33146. For that reason, your PR might need to wait until...

I'd like to see some benchmarks before we merge this. The storage extension is used by the persistent queue in core, which writes each request to the queue. Enabling or...

Part of the problem is that the value of this setting should likely depend on what the extension is used for. The persistent queue use case is performance-sensitive, but use...

We could also consider other storage engines. Our API is very simple and maps readily to any embedded transactional key-value store. I once ran some benchmarks across a variety of...

@djaglowski I'll see if I can dig it up. Even if I can't, I don't think it'll be difficult to reproduce.

In our fork of k8sattributes, we've had success reducing memory usage of the informer stores themselves by using [`SetTransform`](https://pkg.go.dev/k8s.io/client-go/tools/cache#TransformFunc) on the larger informers. https://github.com/SumoLogic/sumologic-otel-collector/pull/593 made a very big difference for...

> @swiatekm-sumo sounds like a good idea to reduce the size of the items fetched by the informer. It'd be great if you can upstream it. But we still need...

> > keep the ReplicaSet footprint low enough that we could just store all of them. > > I agree with @dmitryax that if the `Node` (or `NodeFromEnvVar`) filter is...