On 2013-06-26 16:00, Michael Hsu wrote:
The problem is that the pollers write to rrd's local to the poller box and observium isn't written in a way where these can be easily distributed. I wrote the patch that added that comment as that was my goal. I tested using parallel rsync methods as well as using glusterfs replicated filesystem across multiple datacenters but couldn't get my polling runs + syncing to complete within 5 minute runs (quickest I could get were 8 minute runs writing to about 16,000+ rrds). I have a large number of ports however so smaller installations could probably work.
Why would you even want to? If you have the I/O to rsync 16k RRDs, you have the I/O to run it all on one host. If you don't have enough I/O to run it all on one host, you just need to buy another SSD or some more RAM. Observium rarely becomes CPU bound, and when it does, it's related to rendering pages in the web interface.
Note: I don't consider people wanting to use 6 year old CPUs as a valid reason to expect us to double the complexity of our polling/discovery code.
I wonder what the plans are for being able to distribute observium across multiple hosts, geographically or not. Or if anyone else has attempted this.
None. We have some vague plans to allow http-based proxying of SNMP and agent requests, though.
What would be great would be the option to use something like graphite for the graphing backend so pollers could just send data to graphite and observium could use graphite to create the graphs for the web interface.
We would quite like to do this, but the amount of code that would need to be rewritten makes it somewhat unfeasable.
It would also not be an option, it would completely replace RRD and the existing RRD-related code would be removed.
There's almost zero chance of us maintaining two redundant data storage/graphing engines. It's just entirely pointless, like maintaining support for 2 databases to placate people who want to do their own supercoolthing(tm).
Our drive is always to minimize the ongoing cost of any code changes/additions, else we'll end up with an unmaintainable application.
adam.