Skip to content
This repository

Convert a formatted log stream into metrics

tag: v2.0beta

Fetching latest commit…


Cannot retrieve the latest commit at this time

Octocat-spinner-32 auth
Octocat-spinner-32 bucket
Octocat-spinner-32 conf
Octocat-spinner-32 encoding
Octocat-spinner-32 outlet
Octocat-spinner-32 receiver
Octocat-spinner-32 store
Octocat-spinner-32 utils
Octocat-spinner-32 .godir
Octocat-spinner-32 LICENSE add meta files July 30, 2013
Octocat-spinner-32 Procfile
Octocat-spinner-32 main.go
Octocat-spinner-32 setup


Convert a formatted log stream into metrics.

Current Release


L2met receives HTTP requests that contain a body of rfc5424 formatted data. Commonly data is drained into l2met by logplex or log-shuttle.

Once data is delivered, l2met extracts and parses the individual log lines using the log conventions and then stores the data in redis so that outlets can read the data and build metrics. The librato_outlet is the most popular and will put all of your metrics into your Librato account. See the getting started section to get started.

Log Conventions

L2met uses convention over configuration to build metrics. Keys that are prefixed with measure. and have numerical values will be analyzed. L2met uses a loosely defined key=val log structure.


There are only a few keywords that l2met will parse.

  • measure.*
  • source

Any key that begins with measure. will be considered for a measurement. You can add a source key to further identify the measurement.

A simple example:


Metrics Produced:

  • db.latency.{min, median, perc95, perc99, max, mean, last, count, sum}

An example using multi-metrics and a source key:

$stdout.puts("source=prod measure.db.latency=20 measure.view.latency=10")

Metrics Produced:

  • prod.db.latency.{min, median, perc95, perc99, max, mean, last, count, sum}
  • prod.view.latency.{min, median, perc95, perc99, max, mean, last, count, sum}



We want to be able to specify multiple measurements on a single line so as not to have to pay the (albeit low) overhead of writing to stdout. However, we don't want to take every k=v under the sun. L2met has always forced you to think about the things you are measuring and this feature does not regress in that regard.


echo 'measure.hello=10' | log-shuttle

This will result in 2 buckets:

  1. {name=hello, vals=[10], ...}
  2. {name=world, vals=[10], ...}

Thus you can measure multiple things provided the key is prefixed with measure..

Heroku Router

The Heroku router has a log line convention described here.

This feature will read the User field in the syslog packet looking for the string "router." If a match is had, we will parse the structured data and massage it to match the l2met convention. Furthermore, we will prefix the measurement name with the parsed host field in the log line.


path=/logs connect=1ms service=2ms bytes=0

Would produce the following buckets:

  1. {name=router.connect,, vals=[1]}
  2. {name=router.service,, vals=[2]}
  3. {name=router.bytes,, vals=[0]}

Drain Parameters

There are several configuration options that can be specified at the drain level. These options will be applied to all of the metrics coming into the drain.

  • Resolution
  • Prefix

High Resolution Buckets

By default, l2met will hold measurements in 1 minute buckets. This means that data visible in Librato and Graphite have a granularity of 1 minute. However, it is possible to achieve a greater level of resolution. For example, you can get 1 second level resolution by appending a query parameter to your drain url. Note that the resolution is specified in seconds.

The supported resolutions are: 1, 5, 30, 60.

Drain URL:

Drain Prefix

It can be useful to prepend a string to all metrics going into a drain. For instance, say you want all of your metrics to include the environment or app name. You can achieve this by adding a drain prefix.

Drain URL:

Bucket Attrs

Most outlet providers allow meta-data to be associated with measurements. Bucket attrs is the l2met feature that allows you to interact with this meta-data.


L2met supports associating units with numbers by appending a non-digit sequence after the digits. L2met will assign all measurements a units of y unless specified. You can specify a unit by prepending /[a-zA-z]+/ after the digit. For instance:

measure.db.get=1ms measure.web.get=1

This will create the following buckets:

  1. {name=db.get, vals=[1], units=ms}
  2. {name=web.get, vals=[1], units=y}

Min Y Value

Librato allows charts to have a min y value. L2met sets this to 0. It cannot be overridden at this time. Open a GH issue if this is a problem for you.

HTTP Outlet

The HTTP Outlet is a read API for your metrics. You can query metrics by id. Id construction is a bit rough at this stage, but if you know what you are looking for, reading metrics can be quite simple. For example, if the following logs are emitted:


The metrics can be accessed by the following request:

$ curl

Depending on the resolution of the drain, you will get the last bucket offset by one. The offset implies that you are reading the previous bucket with respect to time. For instance, if your resolution is 60 (1 minute) then an offset of 1 will produce the last minute's bucket.

Metric Assertion

You can also assert what you expect the metrics to be. This is useful in that you can point pingdom directly at your l2met instance and create alerts on metrics. For example, if an alert must be made when user signups fall below 5 per minute, we could construct the following request:

$ curl

If there were only 4 counts of user.signup, then the query would return a 404 which would cause pingdom to send the alert.

The following metrics can be asserted:

  • count
  • mean
  • sum

Tolerance can also be applied to all of the assertions. This compensates for the lack of inequality operators in the URL. If the tolerance is not present, it is assumed to be 0. If the tolerance is specified, it applies to all metric assertions. You must construct separate requests if you want unique tolerance to metric assertions.

For example, if we wanted to test if the count was 5 +/- 2, the following request would suffice:

$ curl

Getting Started

The easiest way to get l2met up and running is to deploy to Heroku. This guide assumes you have already created a Heroku & Librato account.

$ curl | tar xvz

$ ./setup my-l2met abc123
Drain URL:

This command will create Heroku app named my-l2met and return a drain URL with encrypted Librato credentials for a Librato account with email and an API token of abc123. After you have created my-l2met, you can add the drain URL to a Heroku app. A copy of the log stream will be delivered to my-l2met and metrics will be sent to the Librato account which your provided in the setup.

$ heroku drains:add -a myapp

You can manually send data to my-l2met by the following curl command:

$ curl "" --data "94 <190>1 2013-03-27T20:02:24+00:00 hostname token shuttle - - measure.hello=99"

Verify the command worked by viewing the newly created metrics.


There are several knobs and levers to use in order to optimize l2met operations.

Internal Metrics

The receiver keeps track of the time spent processing incoming logs. This data is sent through the normal flow for metrics. To enable, ensure the following config var is set:

$ export OUTLET_USER="" OUTLET_PASS="abc123"

By setting these config vars, l2met will be able to outlet the internal metrics to your librato account.

Hacking on l2met

Before working on a new feature, send your proposal to the mailing list for tips & feedback. Be sure to work on a feature branch and submit a PR when ready.

Build Status

$ go version
go version go1.1rc2 darwin/amd64
$ git clone git://
$ cd l2met
$ export OUTLET_USER="na" OUTLET_PASS="na" 
$ export SECRETS=$(dd if=/dev/urandom bs=32 count=1 2>/dev/null | openssl base64)
$ go test ./...
Something went wrong with that request. Please try again.