lbrt
LibratoLibrato alerts, spaces, and services as code (historical)
- Manages
- Librato alerts and dashboards
- Language
- Ruby
- Package
- lbrt
- CLI
- lbrt
- Config file
- alert.rb
alert "alert1" do
description "My Alert1"
attributes "runbook_url"=>"http://example.com"
active true
rearm_seconds 600
rearm_per_signal false
condition do
type "below"
metric_name "login-delay"
source "foo.bar.com"
threshold 1.0
summary_function "sum"
end
service "mail", "my email"
endlbrt was a Ruby command-line tool that managed Librato alerts, dashboards, and notification services as code. It used per-resource subcommands with export, dry-run, and idempotent apply. Librato has since been sunset, so this page is kept as a historical reference for the pattern.
What is lbrt?
lbrt was a command-line tool for managing Librato, a hosted metrics and alerting platform, as code. It covered four resource types through Thor-style subcommands: lbrt alert, lbrt space, lbrt service, and lbrt metric. Each one defined its slice of Librato in a Ruby DSL you could export, diff, and apply. Auth used the LIBRATO_USER and LIBRATO_TOKEN variables.
One honest note up front: Librato no longer exists. It was folded into SolarWinds AppOptics, which has itself been sunset. There is no service left for lbrt to manage. This page stays as a historical reference. lbrt is a clean, complete example of codenization applied to a monitoring SaaS, with alerts, dashboards, and notification channels all under version control.
Want the same workflow against a living service? Barkdog does monitors-as-code for Datadog. The design ideas here, like per-resource subcommands and dry-run, carry straight over.
- Managed Librato alerts, spaces, and services from a Ruby DSL.
- Used four subcommands:
alert,space,service, andmetric. - Every apply had a dry-run, and applies were idempotent.
- Librato is sunset, so this is a historical reference, not a live tool.
- For a living service, Radiosonde and Barkdog cover Datadog.
- The repository is archived and dormant since 2016.
Install and run lbrt
Install
Install the lbrt gem (Ruby required).
$ gem install lbrtExport current state
Pull the live Librato configuration into a alert.rb.
$ lbrt alert export alert.rbDry-run, then apply
Preview the diff, then apply the change for real.
$ lbrt alert apply alert.rb --dry-runlbrt followed the standard export, review, apply loop, once per resource type. lbrt alert export dumped every alert into the DSL, while lbrt space export and lbrt service export did the same for dashboards and notification channels. Committing those files gave the team a reviewable baseline of its whole Librato setup.
Changes were edits to the DSL. lbrt alert apply --dry-run printed what would be created, updated, or removed. The diff went through code review, and lbrt alert apply made it real. Applies were idempotent, so re-running was harmless and CI could apply on merge. The same loop worked for spaces, which mattered because dashboards drift even faster than alerts when everyone can edit them in a web UI.
Do not install lbrt hoping to use it. Read its DSL and subcommand layout instead, as a template for building your own as-code CLI against a modern monitoring API.
What lbrt can do
Alerts with conditions and services
Alert blocks declared thresholds, absent-metric conditions, rearm behavior, and runbook attributes. Each alert wired to notification services by name.
Spaces and charts as code
<code>lbrt space</code> managed Librato dashboards: spaces holding charts, each with typed metric streams, group functions, and summary functions, applied with configurable concurrency.
Notification services
<code>lbrt service</code> codified delivery channels like mail addresses and Slack webhook URLs, so alert routing lived in the same repo as the alerts.
Idempotent apply with dry-run
Every apply subcommand took <code>--dry-run</code> to print the planned changes. Applying an unchanged file reported <em>No change</em> instead of re-issuing API calls.
Templates with context
<code>template</code> and <code>include_template</code> stamped out repeated charts or per-host alert sets, with context values like hostname or metric name filling in the specifics.
peco integration
<code>lbrt alert peco</code> and its siblings piped resources through the peco interactive filter for quick lookup from the terminal.
When teams reach for lbrt
Alerting rules under review (then)
Teams on Librato used lbrt to move threshold changes into pull requests, with rearm windows and runbook URLs visible in the diff. The alert history lived in Git, not a vendor changelog.
Per-host dashboard generation (then)
Template support turned one dstat dashboard into a space per host via <code>include_template</code>. Dozens of near-identical dashboards stayed consistent without manual editing.
Studying the pattern (now)
lbrt is a compact case study in codifying a monitoring SaaS: per-resource subcommands, export as the adoption path, dry-run as the safety net. It is worth reading before you design an as-code CLI for any modern API.