Is email just not fast enough? Do you want instant notification of Scout alerts in your HipChat room? We've added a direct integration to HipChat:
Setup is just what you'd expect - provide your API token (a notification token is fine) and the room name or ID:
Once set up, the HipChat intgration can be added to any of your notification groups. If you need notifications in multiple HipChat rooms, just click "Add HipChat" multiple times (you can reuse the API key for multiple integrations)
If you aren't familiar with HipChat, think group chat built for teams. It's designed for the simplicity of consumer IM, with business-oriented administrative tools.
Keeping Scout Connected
HipChat joins PagerDuty, Zapier, webhooks, email, and SMS as ways to send Scout alerts. Got another way you'd like to hook up your Scout notifications? Let us know!
Zapier glues together hundreds of online applications so they can talk seamlessly with one another. Think Legos for web services. Or Unix pipes for the web world. Want a task assignment in Basecamp to trigger a HipChat message? Zapier makes it possible.
Scout alerts are now supported as Zapier inputs. So, you can wire Scout alerts to any of Zapier's 200+ services. How about giving a shoutout in Google Talk whenever a Scout alert fires?
A couple of years ago I visited Argentina. I have trouble enough pronouncing my limited English vocabulary and I don't speak Spanish, but after a bit of time, it was pretty easy to order food, buy groceries, and use a taxi. However, occasional hangups that happen during my regular life in the states would throw me out of sorts in Spanish: a taxi driver trying to explain he doesn't have enough change would send me off the rails.
Ruby is my English when it comes to writing software, so when I hit hangups installing something Ruby-related, I can usually work my way out of them. Our monitoring agent at Scout is a Ruby gem, and while most of our customers already have Ruby installed, for those that don't a seemingly small hangup to me can be frustrating for them.
Now, thanks to Omnibus, there's an easy way to distribute your Ruby gems as standalone, full-stack program. This means folks without Ruby can have as smooth of an experience with your hip new gem as a hardened Rubyist.
Here's how I've built a full-stack installer for our scout Ruby Gem.
Back in 2010, we suggested using /bin/bash -l -c to run scout via Cron when using RVM. However, this was a brute approach: /bin/bash -l -c tells bash to behave as a login, interactive process. However, as Daniel Szmulewicz elequently stated in the comments for the original blog post, "Cron jobs are by nature non-login, non-interactive processes".
Fast-forward to today: RVM usage is continuing in production, and to make things more complicated, Cron jobs often need to account for both RVM and Bundler. So, what's our preferred approach when running Ruby executables via Cron in an RVM, RVM+Bundler, or Bundler environment? A shell script.
Cron Shell Script: RVM + Bundler
Lets say we want to run a Ruby executable (scout [KEY]) via Cron with (1) Ruby 1.9.2 and (2) my Rails App's Gem bundle:
Make the shell script executable: chmod +x FILE.sh.
Add the Cron job:
* * * * * shell_script.sh
But that's a lot of typing...
It's tempting to use /bin/bash -l -c when you are busy/lazy. To get around this, the scout install [KEY] command will detect if you are using (1) RVM and/or (2) Bundler. If so, we generate the shell script for you and make it executable.
scout install BNrIneEBMwE8h6VlhO4Bw4WmOVSLmnygSFZEPCfi
=== Scout Installation Wizard ===
It looks like you've installed Scout under RVM and/or Bundler.
We've generated a shell script for you.
Run `crontab -e`, pasting the line below into your Crontab file:
* * * * * /Users/dlite/.scout/scout_cron.sh
How do we detect RVM and Bundler? We've encapsulated it into an Environment class:
We're overjoyed with the reaction to server roles, our new feature that makes monitoring many servers as easy as monitoring a few. The end result hits our favorite sweet spot: it makes something that used to be painful into something fun.
Server Roles was the biggest release since the launch of Scout and the path to the release was anything but a smooth, rolling path. It's a story of fast-changing deployment environments, tangents, a failed experiment, listening, first-hand experience, and finally, something we were happy with.
Here's the story of Scout's evolution to roles.
Oct 2007: Before AWS
Scout started as an internal tool at Highgroove Studios (now Big Nerd Ranch) in 2007, or, roughly one year before AWS exited Beta status. For you young chicks out there, this was a time when you couldn't click a button to provision a server.
Since it wasn't as easy to provision servers, there was less churn in the size of environments. When you wanted to monitor a new server in Scout, you'd create it in our UI and then use the provided locally in your Crontab entry. The manual step of copying the key to to the server didn't feel tedious (and was way easier than configuring Nagios, Munin, etc) since our customers weren't provisioning servers frequently.
Last week, one of our application servers died. We have four app servers, so in theory, the death of one app server shouldn't bring the entire platoon down. However, real-life had other plans: 95% of requests were handled fine, but around 5% were being dropped. Here's the story of how we diagnosed and fixed the issue with our realtime charts.
I’m sitting in the Denver Airport – in a couple of minutes, I’ll board the plane to RailsConf in Portland, Oregon. I’m already getting amped for Voodoo Donuts, Stumpdown Coffee, well-trimmed beards, and of-course, lots of Rails-related chats.
I’m bringing a fresh load of Scout T-Shirts. These aren’t your normal heavy-weight, poor-fitting shirts. They are tastefully designed, American Apparel – Tri-Blend (otherwise known as the most comfortable shirt you’ll own). If you’re attending RailsConf, shoot us an email so we can meetup and improve your wordrobe at the same time. Or, just look for us (Andre and Derek). We don’t always rest our arms on each other, but when we do, we look like this:
It's been three weeks since the launch of the largest feature enhancement in Scout's existence: roles. Haven't heard of roles? Nutshell: roles let you monitor many serves with fewer clicks and more joy. Roles were driven by your feedback and it's showing in the fast adoption numbers below.
Time to give an awkward nerd high-five of thanks:
- Customers on our Roles BETA program - your feedback and willingness to try new things helped us iron out the edges for the public rollout.
- Contributors to our Chef recipe - we've already had six authors commit to our Chef recipe for deploying Scout. It's great to see a hardened Chef recipe based on real-world usage.
- Feedback since the launch - we built roles because of your feedback, and we've enjoyed reading your suggestions post-launch.
Haven't tried roles yet? To get started, see the "Roles" dropdown on your account, and read the FAQ on roles.
Roles are a new feature available immediately for all new and existing accounts.
You have a carefully thought out architecture. You frequently add new servers as your business grows. In fact, scaling up is part of business as usual. Monitoring should scale easily with you -- that's why we're introducing roles.
Roles make it easy to setup plugins and triggers across many servers. Instead of individually configuring servers, configure roles. Then, apply roles to your servers through our UI, the command line, or your configuration management tool.
Some examples of how roles will make your life easier:
- Updating a trigger on 50 app servers
- Adding a Memory Usage plugin on 100 memcached servers
- Updating a plugin to a new version across all 10 MongoDB servers
Roles are available now on your account. Look for the new "Roles" item on the top navigation. If you previously had servers organized by groups, your groups have been upgraded to roles. See documentation here on creating roles and organizing your existing plugins into roles.
Your account now has a single, account-wide key -- use it for any new servers you add. Your existing keys will continue to work, so you don't have to touch any servers you're currently monitoring.
Most setups have a limited number of server configurations (app, db, utility, for example), and several servers of each configuration. When you add another app server, it probably needs the same monitoring template as your existing app servers. Adding more servers using existing templates is the scenario we wanted to make dead simple in Scout.
There's no need to stick to one template at a time: servers can have any number of roles in Scout, so feel free to mix and combine roles as needed to reflect the functionality of your servers. Is one of your HAProxy boxes also running memcached? No need to create a brand new roles, just apply two of the roles you already have.
Once defined, roles are "active": if you update a role (say by adding a plugin or a trigger), all the servers in that role are automatically updated to reflect the changes. It's a much easier way to to manage your monitoring configuration.
Best friends with Chef
We provide an official Chef Recipe designed to work with roles.
To simplify deployment, Scout now provides a single, account-wide key you can use on all your servers.
Even if you're not using Chef, you can (optionally) specify roles directly through the Scout executable:
scout -rdb,app to assign the db and app roles, for example. This makes role assignments highly script-able, whether you're using Chef, Puppet, or Moonshine.
Fine-tuned for large environments
With the recent notification group changes and now roles, we're making monitoring easier for large environments. Our previous tools -- cloud keys and plugin copy-paste -- were useful, but it was easy for things to get out of sync. Roles our our answer for keeping monitoring in sync in large environments.
Roles in Summary
With Roles, we want to make deploying and scaling scout on large environments as easy as possible:
- Roles are "active": updating role's triggers or plugins propagates to all the role's servers.
- Better than templates: Servers can belong to more than one role.
- Account-wide keys: no need to provision keys for new servers - reuse the same 40-character account key in the crontab across all your servers
- Specify roles via the crontab: optionally, you can pass a command-line argument to the scout agent to specify the roles it should belong to.
- Friendly with Chef: we also provide an official chef recipe for roles-enabled server configuration.
To get started, see the "Roles" dropdown on your account, and read the FAQ on roles here.
Whenever we’re asked how to make on-call notification schedules for Scout alerts, we recommend PagerDuty. PagerDuty has invested a ton of time in building a dedicated notification scheduling service, and it’s a great complement to Scout.
With our recent release of notification groups, Scout’s integration with PagerDuty got even more powerful:
- Multiple PagerDuty services: add as many PagerDuty services to Scout as necessary.
- Trigger-specific escalation policies: assign any PagerDuty escalation policy to any threshold in Scout. If you need to create multiple thresholds on a given metric with different escalation policies, it’s simple to do – just add another trigger.
- Automatic incident resolution from Scout: since all integrations are routed through PagerDuty’s API, Scout now auto-resolves any PagerDuty incidents when Scout’s trigger stops firing.
Multiple services in PagerDuty:
... and those same services integrated into Scout:
Adding PagerDuty services within Scout
You need to start in Scout to create a PagerDuty integration:
- Click on Notifications (in the top navigation bar),
- Click on “Add PagerDuty Integration.”
- You’ll be given the option to create a new PagerDuty service, or connect to an existing service within your account.
To assign a PagerDuty service to a trigger, ensure the PagerDuty integration is part of a notification group (the notification group can contain other items too, if needed), then assign that notification group to a trigger.