A Command Line Interface (CLI) is an old concept in the world of computing. Present at the introduction of the keyboard interface for typing in commands, it’s been the most basic way for us to ‘speak’ to a computer to ask for something to be done. And long before that, people would even switch dials or punch in paper cards! For the most part, better modern interfaces prevail – like a mouse, graphical user interface (GUI), or even speech recognition – to lessen the learning curves and increase productivity.

However, there are use cases where the good old-fashioned CLI still counts and makes things easier.

Wavefront is a SaaS-based monitoring platform that comes with an appealing web user interface. Naturally, having logged in to the Wavefront website, you would help yourself to its GUI to perform much of the visualization, alerting, and troubleshooting functions. Alas, the user interface which makes general usage easier can become cumbersome when you want to perform various automated tasks, be it programmed or scripted.

Wavefront provides a public REST API – the interface for you to interact with, either via the integration with an external program or by scripts for the specific cases. However, APIs are generally somewhat challenging for users who don’t want to develop programs every time they need to use it.

So what’s a good alternative that can bridge these two different worlds? Answer: a CLI that can better understand human commands yet have the simplicity and flexibility of the API. That’s also quite appealing to users who are familiar with the culture of shell scripting and working with importing, exporting and manipulating data outside of Wavefront. For example, what if you want to check all the names of the metrics currently flowing into Wavefront, and at the same time check the dashboards that are not receiving anything? What if you want to periodically run a batch script that would produce a report about users who are not actively using Wavefront vs. active users? What if you wish to derive the list of alerts no longer receiving any data, to purge them periodically or delete all, oldest alerts first? Rather than doing it by repetitious mouse clicks, you should try a series of Wavefront CLI command scans – that should make the job easier.

Setting up the Wavefront CLI

Before I dig into the details, I first want to give a shout-out to the long-time Wavefront customer and user, Robert Fisher, who not only developed this CLI, he also continues to maintain it. An accomplished SRE, he also runs a very detailed blog about using the Wavefront CLI. So this blog post is not meant to replace his writings, but merely to introduce his work to those who have not come across it.

Setting up Wavefront CLI is quite easy. You need to have ruby runtime in the environment (and in case you do not have ruby runtime environment, please refer to https://www.ruby-lang.org/en/documentation/installation/), and then install Wavefront CLI using gem install command).

$ gem install wavefront-cli

Configuration Steps

Before using the Wavefront CLI, it’s useful to define a configuration file which may contain default connection parameters to the Wavefront server instance. The CLI uses a “.wavefront file” (which can be located in your path) when running and which may contain important parameters set as default.

[default]
token = xx6ba479-e3bf-c1xx-4a21-631c74xx11def
endpoint = longboard.wavefront.com
proxy = localhost
format = human

The token is the same API token that you use for the Wavefront API, and can be found under your user profile page (don’t worry, the token shown above is not a real token, so don’t try using it). The endpoint is your Wavefront cluster domain. Proxy is the optional wavefront proxy address in case the CLI uses it, and format can be either “json”, “yaml, and human dictates which output format the CLI produces by default.

Using Wavefront CLI

That’s it. You’re now ready to use Wavefront CLI. Wasn’t this simple enough?

The main command is wf, so you could thus start typing wf (assuming you already have a shell prompt to run it), and a brief usage appears.

yooh-a01:~ yooh$ wf
Usage:
wf command [options]
wf --version
wf --help

More details can be found by running wf –help, or by issuing wf <command> –help. We’ll skip going in too much detail about each f the commands, as this could quickly turn into a CLI’s manual page. However, feel free to check out Rob Fisher’s blog about Wavefront CLI here.

Examples of How to Use the Wavefront CLI

Let’s see what we can do with the Wavefront CLI. The truth is you can do much of what you do in your Wavefront UI with CLI added. Let’s say you want to check out the list of your currently registered proxies. Simply run this command:

wf proxy list

and you get the list of the proxies.

You can also change the output format using -f parameter:

wf proxy list -f json

and get the output in json format.

Okay, so what are some of the interesting things that we can do with this?

Well, let’s say you want to check and change all the running alerts in SNOOZED mode.

First, run wf alert list to get the list of the alerts:

Then, using wf alert –help, can get the list of available commands and their syntaxes. The syntax of snoozing the alert is as follows:

wf alert snooze [-DnV] [-c file] [-P profile] [-E endpoint] [-t token] [-T time] <id>

It requires the alert id as input, and we can combine wf commands with a UNIX “awk” command to snooze all the available alerts, like this:

wf alert list | awk '{system("wf alert snooze " $1)}'

What if you want to quickly get the list of all the sources that are reporting the metrics ‘~sample.cpu.loadavg.1m’? You can do it via the following command:

wf query "avg(ts(~sample.cpu.loadavg.1m), sources)" -f yaml | grep 'host:' | awk '{print $2}'

And this will print out all the reporting sources for you, without any need for the APIs going into the Wavefront UI.

Extracting Data Using the CLI

You might have been wondering about extracting some of the metrics from Wavefront for various reasons. Maybe you need to back up your metrics data or migrate part of your data from one cluster to another. Maybe you need to duplicate or modify the data with a different metric name or sources for other analytical reasons. Most of the time, extracting data is not necessary for Wavefront, but being able to take data out can be useful for a variety of reasons.

You can easily do it by using -f wavefront on your query command, like this:

wf query "ts(~sample.cpu.loadavg.1m)" -f wavefront

If you haven’t specified the start and the end time, the output will display metrics on the last 10 minutes by default, in a format that can easily be turned into wavefront compatible format and fed right back via the Wavefront Proxy. Alternatively, why use a proxy? You can use wf write command to input the same data back into Wavefront once you have obtained it.

Conclusion

There are countless ways for having the Wavefront CLI to help with your Wavefront operations, from maintaining your alerts to querying and extracting data out of Wavefront – all with a simple set of easy-to-use commands. Rather than building your own application tools, you can script Wavefront CLI commands combined with other UNIX commands that can be scripted to run many automated tasks that were just too cumbersome to be done via normal UI. On the other hand, maybe you’re just a bit lazy to program something using the Wavefront API – using scripts instead does just fine.

If you’re a keyboard-happy hacker type of person, give the CLI a try. You might enjoy commanding waves in Wavefront even better.

Get Started with Wavefront Follow @YooHoward Follow @WavefrontHQ

The post Commanding the Waves Using the Wavefront CLI appeared first on Wavefront by VMware.