41–50 of 122 posts
In your architecture I see a single monolithic database server called 'Prometheus'. Does it shard? I can't find it in the documentation. You mention it's compatible with TSDB, why did you choose to implement your own backend, or is this a fork of TSDB? The tech does look awesome though!
In your architecture I see a single monolithic database server called 'Prometheus'. Does it shard? I can't find it in the documentation. You mention it's compatible with TSDB, why did you choose to implement your own backend, or is this a fork of TSDB? The tech does look awesome though!
Currently you can manually vertically shard, and in future we may have support for some horizontal sharding for when the targets of a given job are too many to be handled by a single server. You should only hit this when you get into thousands of targets.
Our roadmap[1] includes hierarchical federation to support this use case.
> You mention it's compatible with TSDB, why did you choose to implement your own backend, or is this a fork of TSDB?
Prometheus isn't based on OpenTSDB, though it has the same data model. We've a comparison[2] in the docs. The core difference is that OpenTSDB is only a database, it doesn't offer a query language, graphing, client libraries and integration with other systems.
We plan to offer OpenTSDB as a long-term storage backend for Prometheus.
[1] http://prometheus.io/docs/introduction/roadmap/ [2] http://prometheus.io/docs/introduction/comparison/#prometheu...
This looks very interesting. From http://prometheus.io/docs/introduction/getting_started/ > Prometheus collects metrics from monitored targets by scraping metrics HTTP endpoints on these targets. I wonder if we'll see some plugins that allow data collection via snmp or nagios monitoring scripts or so. That would make it much easier to switch large existing monitoring systems over to prometheus.
Want to do something amazing? Get this into your requirement:
Give a modern i7 with 64G RAM, 24x 250G 6Gbit/sec SSD and 2x 10G NICs achieve sustained ingest of 6Gbit/sec of metrics over 1 NIC and be able to accept commands spit out results of queries over the second NIC while being capable of running purge cleanups of the garbage. Oh and let clients use SQL to pull the data on the flow level
Not only this would be impressive but it would actually optimize and simplify the monitoring in a great way.
We've been looking for something like this, unfortunately the "pull" model won't work for us. We really need a push model so that our statistics server doesn't need access to every single producer. I see the pushgateway, but it seems deliberately not a centralized storage. I wonder what InfluxDB means by "distributed", that is, if I could use it to implement a push (where distributed agents push to a centralized metr…
Earlier quoted context omitted.
Same here; need push for integration. It appears that Prometheus favours pull to a fault. To me it makes sense to have a push/message infrastructure that you can then write scrapers for to your hearts content. InfluxDB has push, but I read that it uses 12X the storage due to storing metadata with each metric; Yikes!
(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_Ub9Em39dEfx9Bu...
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?
I currently use a combination of sensu/graphite/grafana which allows a lot of flexability (albeit with some initial wrangling with the setup)
Earlier quoted context omitted.
(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_Ub9Em39dEfx9Bu...
Hi, 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 wh…
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.
I'm a little wary of a monolithic solutions to monitoring/graphing/time series data storage - it gives me flashbacks of nagios/zabbix ;) I currently use a combination of sensu/graphite/grafana which allows a lot of flexability (albeit with some initial wrangling with the setup)
Of course a piecemeal solution is more flexible, but as you said, configuration can be a beast, so many people prefer monolithic systems.
We've been looking for something like this, unfortunately the "pull" model won't work for us. We really need a push model so that our statistics server doesn't need access to every single producer. I see the pushgateway, but it seems deliberately not a centralized storage. I wonder what InfluxDB means by "distributed", that is, if I could use it to implement a push (where distributed agents push to a centralized metr…
From my experience with distributed systems push replication will get you in trouble, very soon.
Edit: I was too quick to post this question. An obvious scenario is where the client is behind a firewall. Never mind me. I am an idiot.