[UNMAINTAINED]

I might revisit this hobby project in the future, but I currently do not have time to maintain this.

Metriks

metriks.io is a time-series graphing tool that runs on servers. if you can output a number, metriks will create a beautiful graph for you. it builds on top of 'ancient' rrdtool which has proven to work well in production. metriks tries to limit infrastructural dependencies and features in order to provide a robust and pleasant experience for simple graphing needs.

plugins can be written in any language, or you can directly start graphing by tapping into metriks with node:

// metriks is under development, plugins work but the following API is still under discussion:
var metriks = require('metriks');
var graph   = metriks.create('df');
graph.log({'/dev/sda1', '50%'});

Features

• Builds on rrdtool. The network industry standard of saving time-series data to disk with a constant storage footprint.
• Builds on nodejs for optimal concurrency and the ability to run a server without dealing with cgi-bin, etc.
• Minimal dependencies. If you have node.js/npm working, all you need is aptitude install rrdtool and you're ready to go
• Writes RRDs & images to disk, so it works when everything else is down.
• Idempotent. Metriks will create graphs that don't exist, and generally be eager to get you results.
• Trivial to add graphs. It should Just Work by default. Write a plugin file in any language. If it outputs a single number, metriks will graph it for you. You can optionally output configuration strings like # config.interval: 60 or # graph.title: Load average to finetune behavior. Newlines (\n) separate graph lines. Other whitespaces separate graph label from value. See the load plugin for an example how to plot 3 load lines: 1 minute, 5 minute, 15 minute averages.
• Can send out alerts when metrics go outside boundaries

Metriks is basic. If you want advanced, there are plenty other good options out there like graphite, mrtg, observium, cacti, gnuplot, munin, influxdb, or (paid) librato. You may also want to have a look at druid, riemann and grafana. However Metriks will never:

• Require you to deal with a flurry of perl modules / cgi-bin / xml / apache / java / tomcat / etc
• Impose steep learning curves
• Require a central piece of intelligence. Metriks runs distributed. Results can be aggregated centrally but are then saved as static html / json / images on e.g. S3.
• Require networked components to be available to do it's job (in favor of graphing locally, optionally aggregating & uploading to e.g. S3)
• Get in your way
• Ask for your money

Example

Here we'll add a simple graph with response times to different nameservers that looks like this:

To achieve this, open a text file ./plugins/ping.sh, chmod +x it, and make it say:

echo "# config.interval: 60"
echo "# graph.title: Ping resolving nameservers"
echo "# graph.verticalLabel: Roundtrip in ms"

for server in 8.8.8.8 4.2.2.2 208.67.222.222 172.16.0.23; do
  echo "ip_${server} $(ping -c 4 ${server} |tail -1 |awk '{print $4}' |cut -d '/' -f 2)"
done

Options

If you want to keep your plugin files outside of the Metriks source directory, simply point metriks to your own plugin dir via:

metriks --plugin-dir ~/metriks/plugins

By default, metriks writes rrds files to ~/metriks/rrd and images to ~/metriks/png. But you can change that with

metriks --rrd-dir /var/lib/rrd
metriks --png-dir /var/www/graphs

Metriks contains an simple webserver so you can browse the png dir via:

metriks --web-port 8000

If you don't want to automatically build png files but are only interested in gathering data in rrd, use

metriks --auto-write-png false

If you want metriks to automatically upload to S3, use:

metriks --auto-upload-s3 true

Metriks will look for the following environment variables to do the s3 upload:

export METRIKS_S3_KEY=ABCDABCDABCDABCDABCD
export METRIKS_S3_SECRET=abcdabcdabcdabcdabcdabcdabcdabcdabcdabcd
export METRIKS_S3_BUCKET=metriks.example.com

The default permission is public-read, so be careful with that.

Plugins

Configuration

You can echo any of these in your plugin.sh to change behavior of metriks, here are the defaults so you might as well set none of these, and get the same results:

# config->interval  : 60
# config->enabled   : true

# graphStore->consolidation: 'AVERAGE'
# graphStore->xff          : 0.5
# graphStore->step         : 1
# graphStore->rows         : 300

# graph->width        : 1000
# graph->height       : 600
# graph->watermark    : 'kvz.io'
# graph->font         : 'DEFAULT:10:Inconsolata'
# graph->tabwidth     : 20
# graph->border       : 2
# graph->zoom         : 1
# graph->fullSizeMode : true
# graph->dynamicLabels: true
# graph->slopeMode    : true
# graph->end          : 'now'
# graph->start        : 'end-120000s'
# graph->verticalLabel: ''

# lineStore->${dsName}->dsType       : 'GAUGE'
# lineStore->${dsName}->heartBeat    : 600
# lineStore->${dsName}->min          : 'U'
# lineStore->${dsName}->max          : 'U'

# line->${dsName}->title        : '${dsName}'
# line->${dsName}->color        : '#44B824FF' .. '#3A96D0FF'
# line->${dsName}->element      : 'LINE1'
# line->${dsName}->consolidation: 'AVERAGE'

Todo

Metriks is still in early stages of development, here's what needs to be done still:

• Offer an API that so that you can programatically add values in Nodejs programs. e.g. require('metriks').graph('df').addSeries([{'/': '50%'}])
• Offer some way to pipe data into it. I think STDIN vs using webserver as a dependency for that to accommodate decentralized / local preference
  • Should already create a graph without the need to define a plugin or run a daemon
  • Hence should trigger graph->upload
  • Just check if graph hasn't been written in the last 60 seconds to avoid overhead
  • Idea: I think this should be a separate tool.js that requires metriks and uses it's api to handle this. Vs having metriks support the stdin & configuration problems that come with that. More flexibel. Cleaner main program.
• Checkout smokeping sources and try to build a plugin very similar to it. This should expose some limitations and make it more usable in different environments after fixing those. See smokeping.md.
• Example plugin: top-10 memory heavy processes (may require "Dynamically expand ds" first)
• Example plugins: http://word.bitly.com/post/74839060954/ten-things-to-monitor?h=2
• Generate an index page/json of rrd/images. Maybe we can leverage existing connect webserver to write html to disk
• Aggregate datasources into 1 graph using glob (maybe a separate process that uses s3 as source, can do indexes, aggegates, cleaning up old graphs)
• Support for max & min values and a way to communicate problems to the outside world
• Dynamically expand ds using rrdtool dump / import. It's hard, see http://stackoverflow.com/questions/13476226/adding-new-datasource-to-an-existing-rrd
• More unit test coverage
• Show min, max, avg for every ds on every graph by default
• Write metriks version & datetime as watermark to every png
• Should we ship an upstart file so people can daemonize/respawn/log metriks easily on ubuntu? Yes. Probably just output a possible config, and let the end user pipe/copy paste/change it, rather than writing to /etc
• Ship Inconsolate or pick different widely-available font
• Upgrade dependencies (async)
• Don't crash the main process on plugin fatals.
• Handle knox throwing: ECONNRESET. See Automattic/knox#198
• Upload to s3 as a step after rrd -> graph -> upload
• Rename configs. some graph to store. graph->lines to lines.
• Support for graph->lines->*-> for config that applies to all datasources
• More advanced rrd types (COUNTER vs GAUGE, ability to add a custom step, AREA graphs) as req in #1
• Example plugin: network traffic
• Switch to -> as a nesting delimiter. People will want to use . for IPs and such
• One theme object to determine colorscheme
• config nested per line. so line.0.color vs lineColors.0
• Install bin globally
• Add example section to readme with screenshots and plugin code
• Configurable line titles vs hardcoded ds name
• Upgrade flat once this bug has been resolved. Until then, prefix all ds keys with a letter.
• Offer an optional webserver via e.g. send so you can browse through the generated pngs
• _.findWhere
• Refactoring: Plugin
• Refactoring: pluginmanager
• Refactoring: rrdtool
• Refactoring: cli
• Retire thong.tmpl for _.template
• Retire thong.sprintf for util.format
• Retire commander for cli
• Visually show integration test
• One integration test
• Test cases
• Explodetree/flatten, use it for plug-in config (linecolour slice to array) and rrdtool info
• _.isNumeric
• Librato colors
• Graph options need to be interpretted
• Configurable y-axis
• Lose rrd.js over rrdtool.js
• Async.parallel jobs
• Support for .go plugins

Prerequisites

I'm assuming you already have node 0.8+ and Git available.

OSX

To run rrdtool on OSX you'll need XQuartz. Then via Homebrew:

brew install rrdtool coreutils

coreutils is required for timeout, used in integration tests.

Ubuntu

aptitude install rrdtool

Install

Globally

npm install -g metriks

Development

git clone https://github.com/kvz/metriks.git
cd metriks
npm install

Run

With debug output, and a built-in webserver to browse resulting png graphs on port 8000

./bin/metriks --debug --web-port 8000

Test

make test

License

MIT LICENSE

Sponsor development