If you are using the latest Scout agent, you'll notice a beautiful new view of your server metrics:
The new server view combines several moving parts to deliver an at-a-glance, auto-refreshing view into your server with minimal effort.
Key Metrics at the top
CPU Usage, Memory Usage, Disk I/O, and Network Activity are the four key metrics for server performance. The new server view puts these at the top of the page, no scrolling required.
We're using d3 for all of the charts. We love the control (and the crisp, pixel-perfect charts). You'll also notice smooth transitions when your page refreshes every minute.
You don't need to install any plugins to collect these metrics, and Scout auto-detects new devices.
Key Metric Details
Click on an any of the overview charts for details.
The new agent automatically collects process metrics. You'll see these processes listed on the page.
Want more details on a process? Make a process a key process. You'll be able to view time series charts of any key process and add triggers on process metrics.
You can toggle between viewing processes and your custom-installed plugins. We're using Isotope to provide a dense display of data - in many cases, the vertical screen hight will be half the height of the old server view.
You'll also see a sparkline bar chart for every metric a plugin reports. This makes it easy to identify trends across all of your server metrics.
You can change the end time and the duration (from 30 minutes to 1 day) on the server view to easily view past data or longer-range trends.
gem install scout on your server, you'll automatically be upgraded to the new UI. No data is lost when you upgrade - all existing plugins continue to report.
We'll be taking major strides forward on the Scout experience in 2014. Next on our list? Charts and dashboards. Follow us on Twitter for sneak peaks.
Interested in the tech behind Scout Realtime, our open-source tool for realtime server metrics?
Boy, are you in luck! I'll be diving into the guts of Scout Realtime @ the Boulder Ruby Group this evening. The fun starts at 6pm with a beginner's track.
We take pride in building a server monitoring product our customers love with a lean, flat team. We're looking to add the fourth human to our close-knit group.
So, what's special about being a Ruby dev @ Scout?
First, great people! Second, great tech: come build beautiful realtime monitoring visualizations in d3 and Ruby. There won't be an LDAP integration in sight, we promise. Third, you'll have a tremendous impact as developer #2.
Beyond the technical chops, the single most important thing is your initiative. Will you dive into a problem unprompted? Point out problems and give suggestions on fixing it? Given a high-level goal, can you break it actionable chunks, ask for help when you need it, and see everything through to completion? We're a flat organization, and we won't micro-manage your work.
Competitive salary, health care reimbursement, unlimited vacation time, sneak out for a bike ride/hike on a beautiful Colorado day.
Fort Collins, Colorado - best place to live (Money Magazine), ranked 3rd on the Best Bicycle Cities list, one of the Ten Best Vacation Cities for Beer Lovers, and 300 days of sunshine! Our office is located minutes from Old Town, the heart of Fort Collins.
How to apply
Email us at email@example.com. Resumes are fine, but a more personal email is better.
Scout is going all-in on realtime in 2014. As a first step, we're releasing a new open-source (free!) tool, Scout realtime:
The project is currently in beta, and we'd love your feedback on it.
top, but better
top had some charts, so you didn't have to catch numbers flashing on and off your terminal? That's exactly what Scout realtime is. It's much easier to troubleshoot a server issue when you've got a few minutes of historical data on top processes, network traffic, etc.
Give it a try!
gem install scout_realtime
You'll get best results on Linux boxes with the
How it works
Scout realtime is a lightweight daemon that serves up a single, auto-updating web page. It's small enough that you can leave it running in the background and not worry about it.
Don't be shy with feedback or suggestions. The project link again: http://scoutapp.github.io/scout_realtime
Last week, our background task that sends out emails went down. When it came back up, the task sent out a large amount of emails, and it looks like some folks marked the emails as SPAM to clear their inbox. This is causing emails from Scout for some customers to enter their SPAM folder with messages like the following:
We're working on some technical fixes - the fastest way to ensure alerts from Scout don't die in SPAM:
- Search for "in:spam from:scoutapp.com"
- Select all conversations
- Click the "More button" and select the "Not spam" option
- Add the scout notification addresses to your Gmail contact list.
- Google Apps Enterprise customers can whitelist scoutapp.com in the
Google Apps administration settings such that they don't go through
the spam filter at all.
Kevin Lawver, President @ Rails Machine, is our guest author for this post.
Few things feel worst than rolling out a High Availability (HA) system, then regularly seeing that system collapse. For our team at Rails Machine, that failing HA system was MySQL Multi-Master Replication Manager (MMM).
We've been searching for a MMM replacement for a while, and a few months ago, we made the switch to MariaDB + Galera Cluster for High Availability MySQL.
What's wrong with MySQL MMM? What's special about Galera Cluster? Read on!
With the introduction of server roles, we made it easier to manage large setups. Most Scout customers have multiple servers of each type (example: app1, app2, app3), and roles have been a big hit:
of new accounts use roles
But, we got some feedback
You said you needed flexibility on alerts, even when servers are in the same role. An application server in staging has different alerting needs than an application server in production.
Now you can assign environments to your servers in Scout, and manage notifications accordingly:
- create any number of environments (production, development, etc).
- apply roles across environments. For example, production and staging servers can both be part of your "database" role.
- customize notification settings by environment
- filter your account homepage by environment. You'll see only the servers you want to see, with less noise.
Here's an example of a trigger with notification groups customized by environment:
First, select Environments from the account menu, and create one or more environments.
Next, specify an environment with the agent's -e parameter on your server. You'll need the Scout agent version of at least 5.7.0 to use environments.
Don't need environments yet? They'll stay out of your way
If you're using Scout in only one environment, the new feature won't add any complexity. You'll only see the new settings after you've added multiple environments via the account menu.
Read up on environments in our docs.
I've been hearing how Docker is the new awesome, but it didn't click for me until I dug in with a practical question: if we deployed Scout via Docker, would deployment be a more pleasurable experience?
My three takeaways are below.
Just in time for PuppetConf 2013, we've added an official Scout Puppet Module to Puppet Forge. Configuration instructions are right there in the Scout UI:
We're also excited to be a sponsor for PuppetConf - if you'll be attending, drop us a note. We'd love to meetup and talk all things Puppet and monitoring!
A big thanks to Eric Lindvall of Papertrail for adding steal time to Scout's CPU Usage Plugin and helping out on this blog post!
Netflix tracks CPU Steal Time closely. In fact, if steal time exceeds their chosen threshold, they shut down the virtual machine and restart on a different physical server.
If you deploy to a virtualized environment (for example, Amazon EC2), steal time is a metric you'll want to watch. If this number is high, performance can suffer significantly. What is steal time? What causes high steal time? When should you be worried (and what should you do)?