The website and application are built on Tornado Web services (tornadoweb.org).
The front-end that you're seeing took about a week to finalize with revisions and fine-tuning, etc. At some point I just said "enough! let's put this in to production" and went with it.
The referral portion is also custom built, but only took a few hours total including the backend admin. The actual monitoring application took /quite a bit longer/ and is still in development.
It's pretty, and sounds good. I've used Nagios for server monitoring in the past and that can be a bit of a pain, but that's because you can use it to monitor damn near anything. As a sometimes-sys-admin, I assume that in order to achieve your claim of "Monitor virtually any Linux, Windows or Cloud Service" that you're going to be offering only pretty basic metrics. Can you elaborate on how you'll keep it simple when dealing with virtually-infinite possible combination of server configs?
Keeping it simple while still remaining functional for "advanced" users is one of my primary goals. We will start with the basics, but only so we can actually launch the product asap.
That's really the problem we're looking to solving though. Simplifying the mess. (that includes billing)
In the end, we have a certain feature set that's our internal goal. Whether their is demand for every part of that is another topic. Polling and a/b testing will determine where our development efforts are focused and how the first iterations shape up.
We used to use Scout. They're a great group of guys, but ultimately, we ended up just falling back to a Munin install. The biggest challenge for monitoring software seems to be the wide variety of environments you'll encounter on various servers. Scout does a nice job of focusing on Rails apps, but their scripts required just enough of my time tweaking that I ended up deciding that it wasn't worth the effort for the added insight we gained. Keep that in mind when developing your service. Make your documentation top notch, and provide an accessible support conduit for when users encounter issues.
Just to be clear, our decision to not use Scout wasn't because their service was bad. To the contrary, the service itself was very good. It just required a little bit too much setup and required a high degree of inference from the sysadmin. You more or less had to read the code in some of the plugins in order to make things work. That added up to more effort than I felt we were getting in benefit when compared to something like a local Munin install.
The monitoring product idea was created because of that exact issue. Nothing seemed to really solve the problem for us. I'll definitely refer back to this comment often.
You can follow me directly on twitter (same username) for any feedback or suggestions.
I haven't used Big Brother specifically. Big Brother appears to be filling an enterprise level need for "everything". I'm guessing the majority of their users only actually need 80% of its functionality (if that).
We're starting with that majority-of-users functionality and building from there. Ease of use will and simplicity are our primary goals. Internal monitoring by way of server-side agents is part of the plan.
I work with a company that uses Big Brother and they're not fans of it. Its user interface, ease of use and poor visualizations draw a lot of complaints. I'll keep an eye on your project as it develops, good luck with it.
This sounds like exactly what I'm looking for for my startup. I had a love/hate relationship with Nagios/Cacti/Zabbix at my last job. Having something simple I can set up and (mostly) forget about is all I need at this stage.
22 comments
[ 2.8 ms ] story [ 68.4 ms ] threadThe website and application are built on Tornado Web services (tornadoweb.org).
The front-end that you're seeing took about a week to finalize with revisions and fine-tuning, etc. At some point I just said "enough! let's put this in to production" and went with it.
The referral portion is also custom built, but only took a few hours total including the backend admin. The actual monitoring application took /quite a bit longer/ and is still in development.
That's really the problem we're looking to solving though. Simplifying the mess. (that includes billing)
In the end, we have a certain feature set that's our internal goal. Whether their is demand for every part of that is another topic. Polling and a/b testing will determine where our development efforts are focused and how the first iterations shape up.
btw, thanks :)
For now, that's all I can say...
Just to be clear, our decision to not use Scout wasn't because their service was bad. To the contrary, the service itself was very good. It just required a little bit too much setup and required a high degree of inference from the sysadmin. You more or less had to read the code in some of the plugins in order to make things work. That added up to more effort than I felt we were getting in benefit when compared to something like a local Munin install.
The monitoring product idea was created because of that exact issue. Nothing seemed to really solve the problem for us. I'll definitely refer back to this comment often.
You can follow me directly on twitter (same username) for any feedback or suggestions.
We're starting with that majority-of-users functionality and building from there. Ease of use will and simplicity are our primary goals. Internal monitoring by way of server-side agents is part of the plan.
This sounds like exactly what I'm looking for for my startup. I had a love/hate relationship with Nagios/Cacti/Zabbix at my last job. Having something simple I can set up and (mostly) forget about is all I need at this stage.
http://news.ycombinator.com/item?id=2228000
I believe I have your email address. I'll keep you posted.
And really... thanks for the compliment. We weren't so sure about it :)