My startup: Simplified Server Monitoring (pre-launch) | Hacker News Reader

My startup: Simplified Server Monitoring (pre-launch)

checkmint.com

25 pointstenaciousJk21 comments

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.

btw, thanks :)

Perhaps use something like uservoice.com as a simple way to track feature/monitor plugin requests.

Keep it very affordable or have a workable free plan and I will be happy!

deal.

Looks great! We use and love ServerDensity (http://www.serverdensity.com). They just released an amazing looking MongoDB monitoring plugin as well (http://blog.boxedice.com/2011/02/15/mongodb-monitoring-dashb...). Any idea what your pricing will be?

Pricing hasn't been solidified yet. We're competitive...

I believe I have your email address. I'll keep you posted.

Perfect. Are you guys YC funded, or just bootstrapping? Also, props, your landing page is amazing!

Bootstrapped, baby.

And really... thanks for the compliment. We weren't so sure about it :)

This looks cool. How does it compare to something like Big Brother from Quest Software? And would it be available for use on internal networks?

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.

Cool name and really nice design. Can you elaborate on what frameworks you used and how long it took to make?

First, thanks!

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.

I just requested a beta invite.

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.

An update to this post:

http://news.ycombinator.com/item?id=2228000

Looks interesting. How do you compare with Scout? https://scoutapp.com/

We're similar in that we're simplifying the server monitoring process.

For now, that's all I can say...

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 best feedback and advice I've gotten so far.

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'll definitely give you a try if you send me an invite.

Reply on news.ycombinator.com