A common problem that our clients often bring to our attention—and one that we have ourselves—is the need to create multiple copies of a board so that the the same information can be shown in different contexts.
This problem crops up all the time; for example, some of our clients that use Telemetry to provide their customers with individualized boards that share a common design. Others use Telemetry to monitor how their mobile apps are doing, and often want to create a separate board for each app. Even the Telemetry team uses multiple boards to track the health of our internal systems, and want to track the same metrics for each component of our architecture.
One board, multiple copies
In all cases, there is a common thread: the various copies of the board all feature the same layout and contain the same kind of information, but take their data from different sources.
The obvious way to deal with this problem is to simply create a brand new board every time. This has been possible almost from the very beginning using our API, but it is highly inconvenient for a number of reasons. First, it could lead to the creation of hundreds, or even thousands of boards that needlessly clutter up your Telemetry account.
Second—and more important—each board you create this way is completely different from every other board, which means that, if you want to make a change anywhere, you'll have to copy that change over (manually) to every other board.
Enter virtual channels
Today, we are officially introducing a new feature that addresses this specific problem and makes handling multiple copies of a single board a breeze. We call it Virtual Channels.
Virtual channels allow you to take an existing board and create a “virtual” copy of it. The copy will have its own data channel, but will share the board design of its master copy.
Let's look at how they work through the (much simplified) example of an ISP that wants to keep their customers informed with a message of the day, and also provide them with individualized information about the CPU usage of their server.
For this purpose, the ISP creates a board that includes a text widget with the tag
motd, and a gauge with the tag
cpu. The board itself has the secure tag
6a90b016752b7ff651a07ca281ce8708, which allows us to send updates to it using Telemetry's flow API. For example, we can set a new message of the day with a simple
curl --user 'apikey:' \ -X PUT https://data.telemetryapp.com/flows/motd/data \ --data 'title=MOTD' \ --data 'text=Hello there.'
And we can change the contents of the CPU gauge with a similar command:
curl --user 'apikey:' \ -X PUT https://data.telemetryapp.com/flows/cpu/data \ --data 'title=CPU Usage' \ --data 'value=50' \ --data 'value_type=percent'
Virtualizing the board
Now that we have a working board, we can virtualize it. This is done by clicking on the board dropdown in the Telemetry admin, then selecting “Add Channel” and choosing a name for the new virtual channel.
Once this process is complete, the board's original layout is now associated with two channels, which can be visualized independently of each other:
We can repeat this process as many times as you want, and each time we will be adding what, from the outside, looks like a completely separate board with its own secure, unguessable URL.
From our point of view, however, all these boards share the same layout; any change we make to the layout of the main board—including adding new flows—is automatically reflected in every single one of the virtualized copies.
But wait, it gets better. If we now try to send data to the various flows on the board using the same syntax as before, Telemetry will automatically send a copy of the data to every virtual board. For example, if we want to send every user the same message of the day, we can do this with a single API call:
curl --user 'apikey:' \ -X PUT https://data.telemetryapp.com/flows/motd/data \ --data 'title=MOTD' \ --data 'text=Hello everyone.'
We call this broadcast mode; as its name implies, it's meant to be used whenever you want to broadcast data to all channels of a virtualized board.
What about sending data to a specific virtual channel? Our API provides a very simple endpoint—dubbed channel mode—that makes this easy. For example, the virtual board we created above has the unique tag
e2963000088701c7b4115f20cd420967, and we can change the CPU gauge on it with this API call:
curl --user 'apikey:' \ -X PUT https://data.telemetryapp.com/channels/2963000088701c7b4115f20cd420967/flows/cpu/data \ --data 'title=CPU Usage' \ --data 'value=59' \ --data 'value_type=percent'
This change will only be reflected on the specific board we addressed, and will be ignored by every board.
Note that you can use this same approach for multi-flow updates as well:
# Multi-flow update to every channel curl \ --user 'apikey:' -X PUT https://data.telemetryapp.com/data \ --data 'data[motd][title]=MOTD' --data 'data[motd][text]=Hello there.' # Multi-flow update to a single virtual channel curl \ --user 'apikey:' -X PUT https://data.telemetryapp.com/channels/e2963000088701c7b4115f20cd420967/data \ --data 'data[motd][title]=MOTD' --data 'data[motd][text]=Hello there.'
One board to rule them all
We're very excited about virtual channels; it's a feature we've been working on for a long time and that we think will open up all sorts of opportunities in fields that range from public utilities, to industrial monitoring, to Internet services of all kinds.
We think of this as one more step towards our ultimate goal: Making Telemetry the visualization layer of the Internet.