Librato and Heroku, a Match Made of Win — Librato Blog

Librato and Heroku, a Match Made of Win


We probably don't need to tell you that Heroku is awesome. Git-based deployment, ground-breaking process-level abstraction, a command-line interface, log aggregation, one of the most mature addon marketplaces -- they pretty much have it wired when it comes to Platform-as-a-Service (PaaS). But having the platform abstracted away can be challenging when you want to get useful information about how your application is performing.

Performance metrics are critical to PaaS apps because they directly translate to dollars per hour. You need them to optimize your application for the platform, discover bottlenecks, root out latency, and answer fundamental questions like: Is the platform delivering the performance that was promised by the SLA? Do I need to tweak the Dyno-slider?

All of your metrics down the drain

Heroku's platform abstraction layer unifies all interesting events related to your dynos and workers into a common log stream.  You can view this log stream using the Heroku CLI, and additionally, you can install log-drains to copy the stream to external log-processing systems. 

Librato's add-on for Heroku automatically adds a log-drain to your application that extracts metric samples from your Heroku log-stream. By visualizing these metrics the Librato add-on can help you gain some badly needed insight into your application performance on Heroku. Just provision the Librato add-on and it will automatically populate a Librato dashboard specifically designed to display critical metrics from your Heroku-hosted application for free!

Visit the Heroku add-ons page for the Librato add-on for instructions on enabling the add-on. While you're there, you'll notice several tiered paid plans that provide you with additional storage in the Librato back-end that you can use to store your performance data, but what you might not realize is that you get a wealth of additional native metrics once you've upgraded to a paid plan.

More metrics?

Heroku automatically generates three different classes of metrics to the log stream. Router metrics give you insight into the latency and throughput of Heroku's internal request-routing layer.  Postgres metrics give you information about Postgres Database I/O and usage. Dyno-runtime metrics give you CPU and Memory stats for each of your running dynos (these are disabled by default check out Heroku's instructions to enable them).   

You get all of the Router metrics for free on the developer plan, but when you upgrade to a paid plan, you get full access to the additional native metrics as well, including:

  • Postgres: 13 Metrics (instead of 2),
    • Number of Current Transactions
    • Number of Connections waiting on a lock
    • Database size (in tables and bytes)
    • Memory and swap utilization for non multi-tenant Postgres
    • 1, 5, and 15 minute Load statistics
  • Per-Dyno Runtime Metrics: 9 Stats per Dyno,
    • 1, 5 and 15 min Load avg
    • Memory and swap utilization
    • Disk paging activity

But wait, that's not all

In addition to the native metrics provided by Heroku, you can extract and store custom metrics with any paid plan. Using the log drain that's automatically installed when you enable the Librato Add-on, you can send custom metrics to Librato by printing them to stdout from your application using the following format: [type#additional.metrics=value]

Metrics are prefaced by a value type (count, sample, or measure) delimited from their values by equal signs, and separated from each other by spaces. Here are three example custom metrics to give you a feel for the format:

measure#db.latency=1ms sample#db.size=100MB count#db.queries=2

Custom metrics make it possible to instrument your application to track details like internal buffer sizes, business metrics and ephemeral, application-specific signs of success.  The engineers at Koala, for example, use custom metrics to track "heys" in their Heroku app. 


Custom Metrics!

Internally, Librato stores all three types (counts, samples, and measures) as gauges. There is no effective difference between the sample type, and a Librato gauge. A sample represents an arbitrary value at a single point in time. The count type is used to track occurrences of some event in your application. You send the number of occurrences and Librato aggregates them for you.  Finally, the measurement type is intended to measure duration, or other values for which you'd like to have summary statistics. You send Librato a value, and Librato computes the min, max, count, mean, median, 95th percentile, and 99th percentile for that value for the duration of the sample period.

Heroku automatically logs whatever your application sends to stdout, so to track a custom metric you need only install the Librato add-on using a paid plan, and emit a properly formatted string to standard-out. Heroku, and Librato will take care of the rest.

Full-Strength Librato

Last but not least, with an upgrade to a paid plan, you get unfettered access to the Librato user interface. Construct custom dashboards, add context to your graphs with rich annotations, setup detection and alerting for aberrant metric thresholds,  and correlate and display your metrics in whatever way you need.  Check out, for example this dashboard, which showcases some custom metrics sourced from Heroku, along with a few of the Postgres and Dyno runtime metrics you get with a paid account.

Already have a Librato account?

When you enable the Librato Add-On, a shiny new Librato account is automatically created to house your Heroku metrics, but if you already have a Librato account, and you'd like to send your Heroku metrics to it instead of a new account, you can. Just manually install a log drain on your Heroku application, and point it at your pre-existing Librato account.