4 ms·
(Prometheus author here) Yeah, I did that benchmark with 11x overhead for storing typical Prometheus metrics in InfluxDB in March of 2014. Not sure if anything
by jrv 12y ago
(Prometheus author here)
Yeah, I did that benchmark with 11x overhead for storing typical Prometheus metrics in InfluxDB in March of 2014. Not sure if anything has changed conceptually since then, but if anyone can point out any flaws in my reasoning, that'd be interesting:
https://docs.google.com/document/d/1OgnI7YBCT_Ub9Em39dEfx9BuiqRNS3oA62i8fJbwwQ8/edit https://docs.google.com/document/d/1OgnI7YBCT_Ub9Em39dEfx9Bu...
- rdsubhas 12y agoHi, this definitely looks very cool, but how about cases where we have a bunch of instances running behind a load balancer, and each servers its own metrics? We can't pull them, because hitting the load balancer would randomly choose only one instance. Instances are scaled up based on load. So we can't specify the target instances in Prometheus because it keeps on changing. We'd like to try this out, but any ideas what to do for the above?
- bbrazil 12y agoWhat you want to do is separately scrape each instance. We're working on service discovery support[1] so that you can dynamically change what hosts/ports Prometheus scrapes. Currently you can use DNS for service discovery, or change the config file and restart prometheus. [1]http://prometheus.io/docs/introduction/roadmap/ http://prometheus.io/docs/introduction/roadmap/
- pauldix 12y agoInfluxDB CEO here. The next version (0.9.0) has support for tags and efficiently encodes the measurement name + tagset as a single 4 byte uint. Previously, you would have had to encode metadata in the series name. Otherwise if you used string columns you'd see a massive waste in disk space since they were repeated on every measurement.