Scout vs Skylight: What are the differences?
Scout: Application Monitoring that Developers Love. Scout is application monitoring that points developers right to the source of problems: N+1 database queries, memory bloat, performance trends, and more Scout eliminates much of the investigation part when performance woes occur. ; Skylight: The smart profiler for your Rails apps. Skylight is a smart profiler for your Rails apps that visualizes request performance across all of your servers.
Scout and Skylight can be categorized as "Performance Monitoring" tools.
Some of the features offered by Scout are:
- Monitors Ruby & Elixir apps with more languages to come
- Easy install
- Detailed transaction traces
On the other hand, Skylight provides the following key features:
- Skylight looks at how your code is behaving in production, alerting you to improvements you can make before they become showstoppers.
- Skylight tells you exactly how your app is spending its time where it matters most—in your production environment
- Pricing starts at $20 for the first million requests, with automatic discounts for high-volume customers
"Easy setup" is the top reason why over 9 developers like Scout, while over 10 developers mention "Beautiful UI" as the leading cause for choosing Skylight.
StackShare, Inside.com, and Firecracker are some of the popular companies that use Skylight, whereas Scout is used by Binary.com, Rollbar, and Publitas. Skylight has a broader approval, being mentioned in 39 company stacks & 5 developers stacks; compared to Scout, which is listed in 29 company stacks and 7 developer stacks.
What is Scout?
What is Skylight?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Scout?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Skylight?
Sign up to get full access to all the tool integrationsMake informed product decisions
We currently monitor performance with the following tools:
- Heroku Metrics: our main app is Hosted on Heroku, so it is the best place to get quick server metrics like memory usage, load averages, or response times.
- Good old New Relic for detailed general metrics, including transaction times.
- Skylight for more specific Rails
Controller#actiontransaction times. Navigating those timings is much better than with New Relic, as you get a clear full breakdown of everything that happens for a given request.
Skylight offers better Rails performance insights, so why use New Relic? Because it does frontend monitoring, while Skylight doesn't. Now that we have a separate frontend app though, our frontend engineers are looking into more specialized frontend monitoring solutions.
Finally, if one of our apps go down, Pingdom alerts us on Slack and texts some of us.
We love Scout at Rollbar. Here's how we use it.
Zero configuration monitoring for new hosts
We have added Scout to our Ansible configuration for new host setup. So, when we provision a new machine, we get basic monitoring without any extra configuration. Once the host is up and running, we add it to the appropriate role in Scout and all of our monitoring plugins are magically deployed and enabled on the new host.
Monitoring HTTP response codes
One of the best things about Scout is how beautiful and therefore usable their graphs are. We have a Scout dashboard which shows all of our response codes which allows us to quickly see connections between different hosts when problems occur.
Scout's plugin model makes it really easy to extend. We have implemented our own log monitoring plugin which reports metrics like the 90th percentile of slow queries on our site. These types of plugins allow us to see issues at a glance during deploys, maintenance and load spikes.
Slowly taking over Nagios
Nagios is amazing, but let's be real... Anyone who has used it knows how painful it is to set up, administer and extend. We are in the process of cutting over from Nagios to Scout to handle more of our infrastructure monitoring and soon, alerting.
I'm a freelance developer with a handful of servers that needed insightful monitoring and alerts. I searched high and low across both hosted and self hosted solutions... paid and open source. While many are quite capable the self-hosted solutions were clunky and overkill. The few self-hosted for pay solutions costs structure were completely outside of a freelances budget. ScoutApp is the first that had the easy to use setup, amazing plugins for specific app monitoring and the price was actually affordable. Setup couldn't be easier. Plugins are handled amazingly with a single click that initiates the agent to install remotely. The interface is minimal and easy to read. Triggers are so well done and easy to setup with clear human language detailing the alert criteria. Real-time graphing is just icing on the cake.
ScoutApp is great for not just small but enterprise level infrastructures as well. Added features such as roles, multi-user accounts, environments and even an API make growing with it a no brainer.
Very well done and highly recommended.
I used to have NewRelic on https://doorbell.io for my monitoring. It worked pretty well for the basic things, and the basic plan is free.
However, as https://doorbell.io's stack got increasingly complicated, the plugins of NewRelic didn't work as well as I needed, in order to reliably monitor all aspects of the platform.
I decided to try out Scout as an alternative, since even though it doesn't have a free plan, the basic plan is only $8/month (compared to $149 for NewRelic).
I found the interface to be really good, and they have great documentation. I found plugins for every single part of my stack, and they all worked very easily "out of the box". And best of all, added practically no overhead to the server!
So overall, I'd say it's a service that's well worth paying for. It's a steal at $8/month!
We migrated our infrastructure monitoring to Scout about six months ago when our previous monitoring solution became unreliable and cumbersome to maintain. We were pleasantly surprised at the ease of implementation and the library of plugins already available.
The fine grain polling frequency and long term metric logging helped us maintain the high level of uptime our application requires. Moreover, due to the nature of the Scout protocol, changes to our specific application monitoring can be configured at a high level in their interface with a few clicks.
For the few times we have been in communication with their support team to help sort our questions or clarify details, we have been thoroughly impressed at their response time and personalized attention to our needs.
We highly recommend using Scout.
We are a very small non profit with a very simple server setup. Our two developers do not have any special training as sys admins. But it was very easy to get setup with Scout and start some simple monitoring of our servers. Most of what we do is check that some key processes are running and that our URLs are up. It was easy to do all of that with Scout. That said: we're interested in learning more about Scout's capabilities and doing more sophisticated server monitoring down the line.
If you follow the registration flow you end up with running analytics virtually in a minute. Awesome first experience.
I don't have my application in production so I needed to enable skylight in development, but Skylight navigated me nicely to the exact paragraph of a documentation, which helped.
When we were facing performance issues with the new StackShare app. We originally thought it was a server issue. So we did quite a bit of research to see how many dynos we should be using for the sort of application we have and traffic profile. We couldn’t find anything useful online so I ended up asking my buddy Alain over at BlockScore. After a quick convo with him, I knew we should be totally fine with just 2 dynos.
We also tested the theory by increasing the number of dynos and running the load tests. They had little to no effect on error rate, so this also confirmed that it wasn’t a server issue.
So that meant it was an application issue. New Relic wasn’t any help. I spoke with another friend who suggested we use a profiler. We totally should have been using one all along. We added mini-profiler, which was great for identifying slow queries and overall page load times. We also had the Rails Chrome extension so we could see how long view rendering was taking. So we cleaned up the slowest queries.
We tried to use mini-profiler in production on the new StackShare app and for some reason, we couldn’t get it to work. We were in a time crunch so I asked Alain what they used and he said that they use Skylight in production. Funny enough, I remembered the name Skylight because we listed it on the site a while back. So we did that, and at first we couldn’t really see how it was useful. Then we realized what we were seeing were a ton of repeat queries on some of the pages we load tested.
Skylight is cool because it sort of gives you the full MVC profile. We were able to pinpoint specific db queries that being repeated. So we cleaned those up pretty quickly. But then we noticed the views were taking up all the load time, so we start implementing caching more aggressively. After we cleaned up the db queries and added more caching, our pages went from this: to this:
Skylight ended up being super useful. We use it in production now.
We are a very small non profit with a very simple server setup. Our two developers do not have any special training as sys admins. That said, it was very simple to get setup with Scout and start some simple monitoring of our servers. Most of what we do is check that some key processes are running and that our URLs are up. But we're interested in learning more aboutS Scout's capabilities/ doing more sophisticated server monitoring down the line.