itsderek23

Sorry - mind sharing the output of "top -l1 -n0 -u"? Looks like an issue parsing out the memory stats on OSX.

Checkout https://github.com/scoutapp/server_metrics (Ruby - gem install server_metrics). Grabs all the key server + process metrics, handles Linux memory cache, etc.

Requires a distro w/ "proc" functionality for the most metrics.

Scout Founder (Derek) here.

Here's my (biased) quick take on the differences between New Relic and Scout plugins:

* It looks like New Relic supports 2 types of plugins (1) direct integrations w/other SaaS services and (2) plugins you place directly on your servers. With Scout, you typically don't need to touch your servers to add plugins, but we don't support direct integrations w/other services (the actual plugins are run on your servers). So, if you're monitoring something server-side (like MySQL), Scout will feel easier. If you're pulling in data from another service (like MongoHQ), New Relic will feel easier.

* New Relic supports Java and Ruby plugins, we just support Ruby.

As a whole, Scout is more of a leaner approach to monitoring than New Relic.

Plugins are a part of most monitoring products. It's really the experience that matters. I love well-maintained tools that just work, so our approach to a plugin system reflects that:

* Gardening - Our plugin repo (https://github.com/scoutapp/scout-plugins) has 1000+ commits from 45 authors. We work hard to make sure plugins work, even when they weren't originally created by us. All of our plugins are open-source, so anyone can submit a pull request.

* One language (Ruby) - Why do we only support Ruby? (1) It's an easy scripting language to grasp (2) we know Ruby very well, so when something breaks, we can fix it 95% of the time vs. having to wait for the plugin author to address it. If you've ever browsed through plugins in an open source system like Nagios or Munin, you'll see how disjointed things can get.

A real-world example:

We track plugin errors in Scout so we can look for trends and plugins w/issues. Today, a customer reported an issue with our Delayed Job plugin via our UI. Beside it, we captured the actual error. They told us their workaround fix, which we then incorporated:

https://github.com/scoutapp/scout-plugins/commit/02239c8785f...

...and added a help entry in case other users run into the same problem:

https://scoutapp.com/plugin_urls/281-delayed-job/help_entrie...

So the total time from the reported issue to the fix was just a couple of hours, which is neato.

This was obviously a difficult decision for Rails Machine. I put food on the table from an application we've hosted at Rails Machine for several years: they are simply a fantastic team to work with. I can't imagine using a different Rails hosting provider.

First, I'm shameless. Second, I'm working on http://redwoodapp.com, a Spotlight-like OSX app that's similar to Greplin. Two key differences:

(1) Privacy - Redwood doesn't index your data: it conducts searches in parallel. When you open an item, it's cached locally for as-you-type search. Redwood doesn't intercept your traffic in anyway.

(2) No syncing complexity. Your Gigabytes of "Rent-A-Kitten" business plans on Google Docs are searchable immediately. Same with new messages in your 60k-message inbox.

We're using MacRuby, so you'll need OSX 10.6 or greater to try the beta.

Boy, I'm tired of the war/sports/kill-or-be-killed rhetoric. Haven't seen this at all in my business.

Sounds like a good guy to go to war with. Not the best guy to work with though.

We actually just talked about the monitoring stack we use at Scout. There isn't one do-it-all tool (if there is, it'd be pretty ugly).

Scout,Monit,Hoptoad,New Relic, and Pingdom:

http://blog.scoutapp.com/articles/2010/10/19/monitor-rails-c...

> prepare to [have] a night of adventure.

This is exactly why we don't deploy at night. In what other line of work do you schedule complex work when you're going to be tired?

If by backend you mean the server-side, I don't think that's really the case. The server-side is usually less than 20% of the page load timeline:

http://developer.yahoo.com/performance/rules.html

...if you include sites with JS widgets, it's probably even less.

Interesting - I can't think of a website that has 500 ms page load times. The average is closer to 5 seconds, or 10x 500 ms. Latency may be down, but that's only part of the equation.

http://www.datacenterknowledge.com/archives/2010/06/23/googl...

There's a common perception that answering support inquires is a waste of time. I agree - it's a problem if you're spending a lot of time debugging issues that aren't incorporated back into the product. It's not an issue if it's good feedback that helps build a better product for everyone else. Most of our support inquires are the latter.

@jd - Thanks for pointing out the support link. We've fixed the link on the site.