3 ms·
I took offence with @valyala posting about Victoria Metrics in the Cortex Slack channel in the past, but I'm so glad he did because we had _endless_ issues with
by shitloadofbooks 7y ago
I took offence with @valyala posting about Victoria Metrics in the Cortex Slack channel in the past, but I'm so glad he did because we had _endless_ issues with Cortex and we found Victoria Metrics to be _incredibly_ fast and reliable after trying it when he suggested that it could do something Cortex couldn't.
This github response wasn't cross promotion though -- this was @vayala explaining how it could be implemented, as someone who has done it. The fact that no one complained when Thanos was mentioned, but complained when VM was mentioned shows how hypocritical some Prometheus contributors are.
Honestly, @valyala should just create a metrics collector and then I wouldn't have to deal with the "we know better" attitude from some Prometheus contributors.
The Victoria Metrics contributors are absolutely amazing. Every issue or suggestion has been implemented within days (sometimes hours) and every question answered in incredible detail, with warmth and friendliness.
- valyala 7y agoThanks for the warm response! > Honestly, @valyala should just create a metrics collector and then I wouldn't have to deal with the "we know better" attitude from some Prometheus contributors We didn't want going this route, since this could hurt Prometheus community in the long run. But we constantly keep hearing this feature request from VictoriaMetrics users, who deal with high ingestion rates. Probably such a collector will be implemented in the future unless Prometheus devs address the following issues in Prometheus: * Increased RAM and CPU usage when enabling remote_write. * Increased disk space usage on high ingestion rate. * High network bandwidth usage for pushing data to remote storage.