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:
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.