canary, v128 Dec 2014
I recently released v1 of canaryio/canary and consider it to be the spiritual successor of canaryio/sensord and canaryio/canaryd. After six months of exploration, some amount of clarity has emerged and a course correction was needed.
small, sharp, composable
The previous incarnation of the project unnecessarily aimed at holism. We were building up an entire toolchain of snowflakes to help you understand the availability and performance at the top level of your website. We were experimenting with dashboards and long term storage of data. There was talk of building monitoring and alerting components, as if we could do it better.
It soon became clear that this was a mistake. Instead of trying to own the entire experience, scope should be reduced and I should do what I know how to do best - take measurements and make room so those outputs can be integrated into existing telemetry ecosystems. Today, It is perfectly reasonble for a company to invest in a SaaS product such as Librato or to roll their own in-house solutions based on Graphite and Grafana. Context-rich logs are made searchable via services like Papertrail or in-house via Heka, Elasticsearch, and Kibana. If canary is going to provide value, it needs to be easy to integrate into such environments.
v1 takes a step towards correcting the project and offers a way forward for future experimentation.
what's in v1?
v1 release contains a core set of interfaces along with a cli tool, canary. Usings it looks like so:
$ canary http://www.canary.io 2014/12/27 16:14:59 http://www.canary.io 200 96 true 2014/12/27 16:15:00 http://www.canary.io 200 95 true 2014/12/27 16:15:01 http://www.canary.io 200 102 true ^C
As you can see, we ask the tool to monitor a single website (http://www.canary.io), and the results are emitted to
STDOUT. The canary tool is meant to be used in a similar fashion to ping - it gives you quick insight into the basic availability and performance of your target.
This release also introduces two interfaces,
Publisher that can be read about via the docs. It is believed that these will reduce friction for future expansion.
what's coming in v2?
v2 is an intermediary release that will introduce the canaryd command. canaryd is similar to canary, but is capable of monitoring multiple sites and receives its configuration via a JSON manifest. A representative manifest can be found here.
An example of what it currently looks like when executed:
$ MANIFEST_URL=http://www.canary.io/manifest.json canaryd 2014/12/27 15:20:09 http://www.canary.io 200 128 true 2014/12/27 15:20:09 https://www.simple.com/ 200 252 true 2014/12/27 15:20:09 https://github.com 200 384 true 2014/12/27 15:20:09 https://www.heroku.com/ 200 413 true 2014/12/27 15:20:10 https://www.simple.com/ 200 76 true 2014/12/27 15:20:10 http://www.canary.io 200 94 true 2014/12/27 15:20:10 https://github.com 200 306 true 2014/12/27 15:20:10 https://www.heroku.com/ 200 306 true ^C
Note that things may change before
v2 is merged into master.
v2, I'll build other publishers, beginning with one for Librato.
A roadmap and deprecation
The initial roadmap is housed here and contains a short list of goals that I need to reach in order to scratch a personal itch. Once those have been completed, the project should be in good shape for further improvement.
At this time I also plan to deprecate canaryio/canaryd, canaryio/sensord, and canaryio/meta]. The repositories will remain intact, but all issues will be closed and the READMEs will be updated accordingly. Anyone is welcome to fork and run with those projects as they see fit, but they will no longer be supported by me.
I will also be shutting down the existing api.canary.io and watch.canary.io sites since the core project is now heading in a much simpler direction. I am very grateful for all of the community support, and am especially thankful for the support of Rackspace for hosting us up to this point and for the talented Jeremy Green for all the time spent on watch.canary.io. Thank you very much for helping make this experiment possible.