My How-to for the Snap Telemetry Framework
Updated November 30th, 2016
Today was the announcement that Snap reached a 1.0.0 release. On our journey toward this milestone, we did a rename of the binaries used in Snap (snapd is now snapteld and snapctl is snaptel) to avoid a conflict with another package. Since this post is the most popular of our series on Snap, so I updated it given this change. Enjoy!
I was fortunate enough to be part of the release of Snap, an open telemetry framework, a few months ago and the feedback has been phenomenal.
Organizations big and small see opportunity in a single API to manage any and all layers of their data center metrics. One-on-one conversations have been productive — I love those moments when the idea of snap clicks in as we discuss telemetry and its value in mass. Eyes widen. Data pipelines are whiteboarded. Everyone leaves happier after we discuss it.
I could, however, do better at sharing that story beyond the one-on-ones and to the rest of us out here. Let’s fix this with a no assumptions introduction. We can talk telemetry later: let’s get Snap running right away.
Download and Run snaptel
When you want to start using Snap, you start with the Snap daemon, snapteld. Each version is hosted on GitHub under the repositories releases tab as shown in the video below. As of today, you can pull the latest build, now 1.0.0, and get up and running with just a download. Packages are also available here. If you’re beginning with Snap, start simple and give this a watch:
The take home notes I like to highlight:
- You don’t need to write Go code to use Snap
- snapteld is designed with security concerns in mind, so plugin trust levels are always required (Disabled, Enabled, Warning) through the CLI or configuration files
- The plugins provide by the team are not cryptographically signed at this time, so we need to run at trust-level 0
- Run snaptel to communicate with snapteld, or use the REST API directly
Load Some Plugins
Running snapteld is a prerequisite to doing anything interesting, but the daemon doesn’t do anything until we plug in some plugins and a workflow for them.
A Task Manifest is the declarative expression of a workflow, written in JSON or YAML, that uses plugins to collect, process (optional) and publish metrics. I load 3 plugins and use the following Task Manifest for them in the next video. Here’s the YAML for it:
And here’s the video:
The takeaway points are:
- Plugins are binaries loaded into snapteld instances based on their path
- Upon loading plugins, metrics become available to collect
- Plugins collect, process and publish as defined by a workflow expressed in a Task Manifest
Watching Telemetry Fly In
If you followed along, you’ve run the Snap daemon, understood its required flags, loaded plugins and created a task that leverages them. That’s pretty cool for a few reasons:
- I can continually read and write telemetry and know it’s managed by snapteld
- I can add further tasks to read and write telemetry without disrupting my current tasks
All these concepts are nice to grasp, but they make more sense when you use them yourself. Keep familiarizing yourself with further example tasks, then run task watch to monitor live telemetry. Keep exploring the current plugins in the catalog or start writing your own. If you decide to do either, chat with me about it on Twitter and the rest of the team on Slack.