At my company we've been using Graphite and StatsD for nearly two years now, we rely on it heavily for tracking performance and troubleshooting issues. We rely on Icinga, Pingdom, NewRelic and other tools to alert of us of problems.<p>Often, when things have gone really wrong (DoS, internal network issues, app errors, disk full) the affected machine(s) stop reporting to graphite (or under-report data). We get alerted by monitoring the services, not the stats.<p>Being alerted about low or unusual values might be helpful in some cases, but based on my experience, it would too noisy. Usually when something bad happens, we anyway investigate Graphite and analytics tools to understand the impact on traffic and KPIs.<p>I could see Rearview being useful for some cases, but not as a replacement for real monitoring and alerting tools.
Server side graphs didn't work out for all our monitoring use, so we don't use graphite. You should make a version that works with istatd :-)
<a href="https://github.com/imvu-open/istatd" rel="nofollow">https://github.com/imvu-open/istatd</a>
This looks really polished and definitely a great idea. I can see why you chose Ruby for the scripting of the monitors, being able to evaluate that code in a predefined binding can be quite powerful, especially with the aid of helpers being pre-defined as well.<p>Why not a full ruby stack, or was the "live" scripting done after the initial inception?
I'm not sure I'm ready to abandon a custom monitoring environment consisting of a shell environment, screen, ssh certs, lugubrious quantities of /proc/, and a fair bit of gnuplot. Seems to me thats all you need? Why commit to a Ruby install for an operator console?