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.
With the Sidekiq Monitor Plugin (by Scott Klein of StatusPage.io) and the Puppet Last Run Plugin (by Didip Kerabat of Kongregrate) Scout’s plugin directory count has now passed 70 plugins!
The Sidekiq Monitor Plugin monitors key metrics for Sidekiq, a Ruby message processing library. Didip’s Puppet Last Run Plugin tracks key metrics for the most recent Puppet run on a monitored server.
Have a useful plugin sitting around? Share it! Send a pull request to our scout-plugins repository on Github.
It’s been a month since I started attaching torture devices disguised as boots to my feet, long wooden sticks to each torture device, and tumbling down mountains. Skiing has changed my outlook on winter. It’s a season to enjoy, not a time where I gaze wistfully out the window, hoping the short, cold days pass by as quickly as possible.
However, there’s a problem when skiing becomes a favorite hobby: not everyday is a great day on the mountain. If it hasn’t snowed in a while, the surface is hard. The temperature might be in the single digits and the wind may be gusting 50 MPH+. It might dump snow in the backcountry, but the avalanche conditions may make it unsafe.
There’s something special about being able to sneak away when the conditions are the best, even if it’s during the work week. It feels a bit like being a kid again (correction: a kid with a receding hairline). It’s a fun reminder that it’s not always bad to feel redundant.
We recently decided it was time for a major update to the public side of Scout. We’d start with a more polished homepage. Since we’re both developers, the obvious next step seemed like hiring a designer. However, working with an outside designer isn’t a hire-and-forget experience:
- Good designers are difficult to find. Design doesn’t scale like a product business.
- Good designers are busy. It could take 30-60 days to start work, then another 30 days for it to come together. This means we could be looking at a 90 day timeline. We wanted to launch it faster.
Instead of starting work with a designer on a blank slate, we decided to start firming up what we wanted the homepage to look like. We’d end up with one of the following outcomes:
- We’re terrible at design, but we’ve at least thought it through. Hire a designer.
- We can get 80% of the way there, but we’ll need a designer for touchups.
- If we iterate enough, we can launch something we’ll be happy with.
Startup Lessions from CCP - EVE Online Style:
Another great example was the formation of “Team Best Friends Forever” (“BFF” is an inside EVE joke). This team is a group of CCP developers whose sole mission is not to work on major features and improvements, but rather to fix all those annoying “little things” that bother their customers. Too many times, product managers and development teams are focused on the big-ticket items – and that’s fine, but TBFF is a great approach that again proves that CCP listens to their customers.
On Jan 15th, all Scout accounts will be switched over to notification groups. Notification groups are designed to make notifiation management easier and more flexible:
- instead of managing notifications per-plugin/per-user, you will assign users to notification groups, and apply notification groups to triggers.
- you can have multiple PagerDuty integrations and webhook endpoints and assign those to notification groups as well. PagerDuty and webhooks are now first-class notification channels; they are no longer all-or-nothing settings.
- you get much finer control over threshold-to-notification channel mappings. You can configure (for example) three triggers on one metric, with the lowest trigger sending you email, the middle trigger sending you SMS, and the high trigger alerting PagerDuty.
If 2011 was the year of fine-tuning, 2012 was the year of major feature enhancements at Scout. Some stats on what’s been a fun year:
Naomi Pomeroy, a Food & Wine Best New Chef, on starting an underground, self-funded restaurant:
When major chefs hear about the way I run Beast, they say, ‘You’ve created a chef’s dream restaurant, because you don’t have to compromise,’ ” she told me. “What happens when you do a million-dollar build-out is that you have to be open seven days a week, be really high end, and have a million choices, and that may not work in today’s economy.
Read more in the New Yorker.
In the Colorado Front Range area? I’ll be talking about the realtime web at the Fort Collins Ruby Meetup this Wednesday.
I’ll show how adding realtime functionality is the easy: in less than 30 minutes, we’ll build a Sinatra app that uses Pusher for realtime functionality.
See the demo Sinatra app, a Ruby Meetup Realtime Heckle Board on Github.
Our navigation header was packed-full of links (and let’s be honest, looked a little stale). We’ve elected a new, fresher, nav header:
What you need to know
- We’ve emphasized the primary pieces of Scout (servers, applications, charts, and dashboards). The less-accessed config-related bits are inside a pulldown in the upper right (people, notifications, billing, etc).
- Hotkeys plus keyboard navigation is the best way to play. Each of the primary areas has an associated pulldown. Reveal each pulldown with a hotkey (the underlined letter in the nav). For example, hit the “s” key to reveal the servers pulldown. Once the pulldown is open, use your up/down keys + enter to navigate.
- We’ve dropped the recently accessed server tabs. These frequently created confusion: how the initial set of tabs was chosen, how they reacted when a new server was picked that shuffled a previously accessed tab off the list, etc. Using the “s” hotkey is the fastest way to travel to your servers within Scout.
The hotkeys for each pulldown (the first letter of each word):
- s – Servers
- a – Applications
- c – Charts
- d – Dashboards
Once a pulldown is open:
- up/down arrow keys – navigate through the list of items
- enter – show the current item
- esc – close the pulldown
If you see any issues, let us know!