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.
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.
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.