Rearview on Rails

Steve Akers —  January 24, 2014 — Leave a comment

For those who may not know, Rearview is a real-time monitoring framework that sits on top of Graphite’s time series data. This allows users to create monitors that both visualize and alert on data as it streams from Graphite. The monitors themselves are simple Ruby scripts which run in a sandbox to provide additional security. Monitors are also configured with a crontab compatible time specification used by the scheduler, and alerts can be sent via email, pagerduty, or campfire. Originally implemented in Scala, Rearview was recently rewritten in Ruby. This will make support and development easier going forward as Ruby is the primary language used at LivingSocial.

Technology

From a back-end technology perspective much has changed as you can image. Trent Albright discusses these changes in his excellent post on open sourcing with rails engines. Some highlighted benefits of this approach include: the ability to separate configuration from code, excluding gems that may not be appropriate for all users, and the ability to create well defined extension points for your application. He goes on to discuss various Rails Engine use cases as well as walking you through a refactoring exercise. I highly recommend taking the time to read it.

The front-end technology, on the other hand, did not go through a similar change. In fact, Ian Quattlebaum’s fantastic post on Rearview’s frontview states that less than 1% of the front-end code changed when we ported from Scala to Ruby. As Ian writes, this was because “none of our front-end application was tied to the service implementation, including templates with Handlebars, simply making sure the API didn’t change was all that was needed.” Again, I highly recommend you read the full post as Ian walks you through the thought process of choosing the appropriate technologies for a given project.

Dashboard Categories

The Ruby port of Rearview is much more than a back-end technology change or a long list of bug fixes. Furthermore two major features were added to the application, the first being the ability to organize your monitors into categories. As you can see from Figure 1, adding a new dashboard to the ecosystem works the same as it always has. What’s different is you now have the ability to navigate directly to a dashboard category using the drop-down menu. In this example, we will be loading the “authentication” category of the “accounts” dashboard. This is helpful as it allows users to avoid overly large dashboards by separating monitors into similar groupings.

Continue Reading…

facebooktwittergoogle_plusredditpinterestlinkedinmail
Print Friendly
Input DataFigure 1: Control Chart for Seasonal Metric

In my post on creating control charts with seasonal data, I suggest calculating mean and standard deviation by subtracting today’s raw values from last week’s smoothed values. As I said in that post, we’re assuming deltas calculated in this manner should stay relatively close to zero and only be influenced by the variance of the current data. What I didn’t mention, however, is the fact that there is a trick involved in performing this calculation.

Let’s assume you are creating a control chart that monitors one hour of data (see Figure 1 above.) In rearview, the metrics might look like this:

stats_counts.app.login.successful
lowess(timeShift(stats_counts.app.login.successful,"1w"),0.5,3)
lowess(timeShift(stats_counts.app.login.successful,"2w"),0.5,3)

In this example, the 0.5 corresponds to the smoothing parameter, or bandwidth, for the lowess (locally weighted scatterplot smoothing) function. Likewise, the 3 corresponds to the number of iterations used in the calculation. When creating a seasonal control chart monitor like this, you will want to choose parameters that result in a smoothed line you feel visually represents the historical data’s true trend. Consider the following two images:

Small BandwidthFigure 1: Small Bandwidth of 0.05

Continue Reading…

facebooktwittergoogle_plusredditpinterestlinkedinmail
Print Friendly

I’m happy enough with Mavericks Calendar app that I decided to use it full time. While it generally works well, I quickly found it cumbersome when Google hangouts were involved. And as a remote employee, nearly all my meetings are conducted via hangout, which means loading Google calendar in a browser simply to click the hangout link. This often resulted in me missing or being late to a lot of meetings. Not only that, if I’m going to keep Google calendar open in my browser, then I might as well not use Apple Calendar at all.

This is where the life hack comes in. Inspired by Muness Castle (perhaps you could say stolen from), I decided to programmatically grab upcoming hangout links and use Apple’s desktop notification to present them to me 2 minutes prior to any meeting. This means I no longer need to load Google calendar in the browser, PLUS I am now usually the first person to a meeting. Here’s how I do it:

  1. Install Muness’ gcalcli fork (master branch)
  2. Authorize gcalcli to your account by launching it
  3. Install terminal-notifier (I use the bin wrapper)
  4. Clone and modify my hangout-alert script as needed
  5. Schedule cron to run the script periodically

I setup my cron schedule to run 2 minutes prior to each quarter hour from 8am to 6pm Monday through Friday. I also have the terminal-notifier notification set to “alert” as opposed to “banner” like so:

Hangout Link Notification
Figure 1: Hangout Link Notification

This way notifications stay on my screen until I click “close” or “show”, where show opens the hangout link. With this system in place I am 100% Apple Calendar, and have yet to miss or be late to another hangout!

facebooktwittergoogle_plusredditpinterestlinkedinmail
Print Friendly