InfluxData Blog - Will Faurot

The Chronograf Files: The Curious Case of JavaScript's `sort`

Will Faurot (InfluxData) — Tue, 05 Apr 2016 08:00:03 -0700

“The world is full of obvious things which nobody by any chance ever observes.” — Sir Arthur Conan Doyle, The Hound of the Baskervilles*

It was your average day at the InfluxData offices. The usual sounds filled the air: the clack of a ping pong ball, the ever-present drip of an overworked coffee pot. A day just like any other – or so I thought.

It all started when a new Chronograf ticket came in, where a user had reported their graphs behaving strangely.

The Bug

I give you ‘Exhibit A’, a screenshot submitted by our affected user:

Though this graph is quite the visual cacophony, the issue was clear immediately: Chronograf was plotting this user’s data out of order. For a product like Chronograf, this is about as critical as a bug can be. Because we’re in the business of time series data, we’d better be sure we’re respecting the laws of physics and that time continues to function as it has since the beginning of, well, time.

At this point, Chronograf had seen several releases over the better part of a year. How had we not seen behavior like this before?

The user also provided us with the sample dataset that resulted in the above graph, hereby dubbed ‘Exhibit B’. The dataset itself was large so I won’t reproduce it in full, but here is a small sample we’ll use for investigative purposes: timestamp value --------- ------ 100000000 4 200000000 9 300000000 6 400000000 7 500000000 6 600000000 4 700000000 9 800000000 7 900000000 10 1000000000 6 1100000000 4 ...

Note: InfluxDB supports multiple time formats, though in this case we’re using Unix time. Not to spoil too much, but this will be highly relevant soon!

At first glance, the data seems reasonable. The values seem OK, and the timestamps are ordered chronologically. No cause for alarm, right?

The Fix

“Wait, you said sort does WHAT??’” — Anonymous

Now I had exhibit A, a graph which explained how the bug affected the end-user. And I had exhibit B, a sample dataset I used to accurately reproduce the issue.

The next step was to ask myself a few questions which I’ve found helpful when beginning the debugging process:

1) What sections of the code does this bug touch? Who is the most likely offender?

I immediately thought of a piece of code that converts raw InfluxDB responses, which use JSON formatting, into data structures that our graphing library understands. As far as I could tell, the sample dataset was ordered correctly. It had to be something farther down the line.

2) Are there any obvious anomalies?

As far as plotting data chronologically, Chronograf seemed to function properly in all other known cases. Given the graph we saw earlier, it’s also the kind of bug you feel like you’d tend to notice.

Here is where it starts to get good: the test data was noteworthy because the first point starts on day one of what Unix considers to be the dawn of the universe. Unix timestamps represent the amount of time (usually in seconds or milliseconds) that has passed since 00:00:00 UTC, January 1, 1970.

For example, the ‘Unix time’ as of me finishing this sentence is 1458851975430. On its own, maybe this isn’t a particularly exciting or interesting detail. It’s test data, who cares if we’re plotting points from 1970 or 2016? We do, as it turns out!

I took a hard look at the data after it had gone through the conversion process, immediately before it made its way into our graphing library. I confirmed it was out of order. Using the same small subset of data from the last section, here’s a view of the test data as it appeared to me:

timestamp value --------- ------ 100000000 4 1000000000 6 1100000000 4 200000000 9 300000000 6 400000000 7 500000000 6 600000000 4 700000000 9 800000000 7 900000000 10 ...

Wait, what? Why on earth is 1000000000 (9 zeroes) appearing before 200000000 (8 zeroes)? This new insight was enough for me locate the perpetrator, a line that looked something like this:

// allTimestamps is a list of unique timestamps, // e.g. [100000000, 200000000, 300000000 ...] allTimestamps.sort()

I remembered why this line was initially added: if for any reason the data came in to the converter out of order, or merging multiple series was required, we wanted to ensure that our data was chronological before trying to plot it on a graph.

And suddenly it all made sense. Let’s try something…

If you’re on a device with a keyboard, open your browser’s developer console. On Chrome you can choose View -> Developer -> JavaScript Console and type in the following and hit enter: [2, 10, 5].sort()

Does the result surprise you at all? I imagine it does, as this is the output you should have seen:

[2, 10, 5].sort() // => [10, 2, 5]

It boils down to this: JavaScript’s built-in sort function, by default, sorts its items ‘lexicographically’, i.e. alphabetically. ’1’ comes before ‘2’ in the alphabet according to JavaScript. From this perspective, the output we just saw makes sense. Is this the default behavior we expected when sorting a list of numbers? Not in the slightest.

The fix itself was simple. Instead of using sort without any arguments, we provided what Mozilla calls a compareFunction

If you ran the previous example in your browser’s console, give this one a try:

[2, 10, 5].sort((a, b) => a - b)

Better, right?

OK, now we now how sort works. We know what to fix, but we still haven’t fully answered our original question: Why did we have to wait so long for a bug like this to make an appearance? The answer lies in the number of significant digits for each timestamp. With the provided test data, we had multiple rollovers where the timestamps not only grew in numerical size, they grew enough to require another significant digit to represent them.

We can illustrate this by using the test data, and it only requires a few points:

timestamp value --------- ------ 800000000 4 900000000 6 1000000000 4

Try sorting these timestamps without a compareFunction and see the results:

[800000000, 900000000, 1000000000].sort() // => [1000000000, 800000000, 900000000]

1000000000 appears at the beginning of the list, which is technically correct according to JavaScript. But because it has an extra digit, it results in non-chronological data. Most of the data being fed into Chronograf is recent, typically from the last several years. Enough time has passed since 1970 (the beginning of Unix time) to the point where it will be quite a while before Unix timestamps need another digit to be represented. If we’re using milliseconds, Nov 21, 2286 in fact.

During normal Chronograf usage, if InfluxDB was returning Unix timestamps, they were of the same length in virtually all cases. The fact that JavaScript was treating these numbers as strings when trying to sort them was irrelevant – we’d get the same results regardless of whether we told JavaScript to explicitly sort them as numbers.

One last experiment for the console, where the results should be identical: // Using Three realistic InfluxDB timestamps: [1459444040000, 1459444050000, 1459444060000].sort() [1459444040000, 1459444050000, 1459444060000].sort((a, b) => a - b)

Chronograf was dealing with timestamps like this in virtually all cases, explaining why it took a unique dataset for us to track down this particular bug.

Voila! Another case in the books.

The Lesson

“History is not a burden on the memory but an illumination of the soul.” — Lord Acton

As a developer, this experience was fantastic. It was a fun, unique, mildly infuriating bug with no shortage of teaching potential. Here were my big takeaways:

A deep understanding of your tools will make you a better *insert thing here*. This idea spans all fields and disciplines, though it is especially important in software. The `sort` bug was able to bite us because of a gap in our knowledge, and it serves as inspiration for learning even more about how JavaScript, our most valuable tool, works. It will help inform decisions we make in the future, and maybe even prevent a few bugs.
Critical bugs lurk beneath the surface, and often manifest themselves under the strangest of circumstances.

For us to finally see sort behave in a way we didn’t expect, we needed a dataset that used a specific time format and spanned over two very specific years, 1970-1972. I’ve found that software never ceases to amaze with the sheer multitude of ways in which it can break. In this regard I have a begrudging respect for it’s raw and unbridled creativity.

If you’re interested in a more in-depth look at how sort works under the hood, this article from javascriptkit.com was invaluable.

What's next? Get Started With Chronograf!

Which now sorts numerical timestamps with aplomb!

If you’d like to try Chronograf, the ‘C’ in the TICK stack, you can download the latest version here. We love reading and appreciate any and all feedback, so let us know what you think. Whether it’s bug reports, feature requests, general experience improvements, or any other thoughts or ideas you have about the product, don’t hesitate to email the team: chronograf@influxdata.com.

Announcing Chronograf 0.10 GA

Will Faurot (InfluxData) — Fri, 05 Feb 2016 09:15:10 -0700

Chronograf 0.10 is here! A few quick housekeeping notes: Our last major release was 0.4, but we chose to bump our next major version to 0.10.0 to sync with the rest of the TICK stack. We’ve also tightened up our release cycles, so keep an eye out for future release candidates on the InfluxData downloads page. In this post we’ll take a glance at a few of the new features and improvements, and finish up with a look at what’s in store for Chronograf as 2016 unfolds.

Smarter Query Builder

We’ve radically improved our ability to parse raw InfluxDB queries. This means you’ll now be able to paste a query directly into Chronograf, and the elements of your query (measurement, tags, etc.) will be parsed out and available for use in the builder:

Template Variables

Template variables allow you to apply a value across multiple queries. 0.10.0 introduces a new concept to Chronograf: the tmplTime() and tmplTagValue() functions. These functions allow you to apply either a time or tag template to a query, and can be added via the UI as well as by manually editing the query text.

Time ranges

Use the clause WHERE tmplTime() to apply the globally selected time range to a particular query. This works for queries that use the query builder as well as queries entered manually via copy/paste. Any new queries you add will use tmplTime() by default.

What's next?

Here are a few things in store for Chronograf down the road:

More tools for custom analytics
New visualization types
UI/Performance improvements

Resources

Download Chronograf 0.10.0
Need help getting started? Check out the Chronograf docs or the Getting Started guide.

Announcing Chronograf 0.10 Release Candidate w/ Template Variables

Will Faurot (InfluxData) — Wed, 27 Jan 2016 11:05:27 -0700

We’re hard at work on 0.10.0, Chronograf’s next major release. Plenty of new features and improvements are in store, and we wanted to give a quick preview of our take on an oft-requested feature: template variables.

Keep in mind that 0.10.0-rc1 still has some rough edges as we move towards the final 0.10.0 release and shouldn’t be relied on in production.

Template Variables

Template variables allow you to apply a value across multiple queries. 0.10.0-rc1 introduces support for templated time ranges and tags via the tmplTime() and tmplTagValue() functions.

Time ranges

Use the tmplTime() function to apply the globally selected time range to a particular query. This works for queries that use the query builder as well as queries entered manually:

What's next?

Download the code and get started with [this RC](**placeholder for RC download link**) or with the current stable version
Need help getting started? Check out the Chronograf docs and getting started tutorial.

Drill Baby Drill! Data Exploration in Chronograf

Will Faurot (InfluxData) — Tue, 15 Dec 2015 09:00:35 -0700

Overview

First thing, download the latest version of Chronograf here.

Will from Chronograf here! In this post we’ll take a look at a few of the ways Chronograf allows you to explore your data from InfluxDB. Before we get started, let’s take a look at InfluxDB, time series, and why data exploration is such an important feature in a visual tool like Chronograf.

InfluxDB is optimized for time series data. More often than not, a whole lot of it. Scale is critical in the time series world. When you’re dealing with datasets in the gigabyte, terabyte, or even petabyte range, you could be navigating hundreds if not 1000+ different metrics as well as accompanying metadata. That’s a lot of things. From the beginning, Chronograf was designed with this idea of “drilling down” into data. We start with a large dataset, and filter down into smaller subsets based on selecting measurements and/or tags.

Building Blocks for Exploration: Measurements, and Tags

In this post we’ll focus on measurements and tags, but a full glossary of InfluxDB terms is available here.

Measurements and tags are two of the fundamental building blocks in InfluxDB, and likely where you’ll start when building out queries with Chronograf. Before getting to the examples let’s start with a good working definition of each concept:

Measurements - these are your metrics. We're using Telegraf in these examples, a plugin-driven server agent for reporting metrics into InfluxDB. It can track system metrics like cpu and disk usage, as well as services like Redis and ElasticSearch.
Tags - key/value pairs used to provide metadata (e.g. region=us-west, host=server01).

Drilling Down

We figure there are at least two common use cases for building queries within Chronograf:

You know what you're looking for. You have a query in mind and just want to see a visual representation of your data.
You want to explore. Maybe you have 100+ measurements and want to see which metrics you're tracking in one region. Or it could be the inverse, and you want to see which regions are tracking what measurements. This use case is hugely important to us and is the focus of this post.

Querying for Fun and Profit

Here’s the gist:

Choosing a measurement can reduce the list of available tags
Choosing tags can reduce the list of available measurements and subsequently available tags

In these examples we’ll be focusing on the Filter By pane in the query editor:

When you start building a query, you’ll have the all of your measurements and tags available in the ‘Filter By’ pane. In these examples I’m using Telegraf to track system metrics, where I have 31 measurements and 3 tag keys. Here we’ll pick the measurement cpu_usage_idle. The list of available tag keys is reduced from 3 to 2, meaning cpu and host are the only tags associated with cpu_usage_idle:

The inverse works as well - you don’t have to select a measurement to start exploring tags. Each tag key/value pair can potentially reduce the list of available measurements. Here we’ll take a look at the full list of tags and select the key cpu. You can see this reduces the number of available measurements from 31 to 10, meaning we can more easily browse cpu-based metrics. Selecting a tag also filters subsequent tags. The number of tags to select shrinks from 3 to 2, meaning the tag key host is the only other valid tag to exist alongside cpu:

You’re not limited to picking one tag either. You’re free to keep selecting tags and Chronograf will continue to make smart decisions about what subsequent measurements and tags are still valid to explore.

In Closing

And that’s it! Chronograf is still under active development and we’d love to hear any and all feedback. Send the team an email at chronograf@influxdata.com.

Announcing Chronograf 0.3

Will Faurot (InfluxData) — Wed, 18 Nov 2015 08:00:50 -0700

Will from the Chronograf team here! We’ve been hard at work and are excited to introduce our next major feature: dashboards. Also part of this release are major UI/UX improvements, and improvements to the data exploration and query building experience.

What is Chronograf?

If you’re new to Chronograf, it’s a data visualization tool built specifically for InfluxDB. As a team, our goal is to build a product that is feature-rich, but also accessible. A tool for both developers AND non-developers. Using Chronograf should be seamless and intuitive, all the way from initially connecting to your InfluxDB instance to building meaningful visualizations. How quickly we can go from “zero to graphs” is one of our most important metrics.

New in 0.3 - Where We Are Now

Here’s quick rundown of the features we’ll cover:

Ad-hoc visualizations in Chronograf
Dashboards!
Data exploration improvements

Graphs and Dashboards

Early Chronograf development focused on polishing the ad-hoc data exploration and visualization experience via our query builder. As of 0.3 there are two major ‘things’ in Chronograf: graphs and dashboards. Dashboards mainly function as a collection of graphs, but graphs also exist as their own separate entity. Whether you already have a query in mind and want to paste it directly into the query builder, or you want to explore your measurements and tags, Chronograf is still a great choice for these kind of ad-hoc tasks. Simply create a new graph and start building your query:

Graphs being persisted separately from dashboards also gives you the ability to easily add a single graph to multiple dashboards.

Dashboards, Dashboards Everywhere…

We’re eager to get the first version of Chronograf dashboards out there so we can continue to build on user feedback and make improvements. Here’s a quick tour:

Note: In these examples, I'm building a dashboard for system metrics using data gathered by Telegraf, a plugin-driven server agent for reporting metrics into InfluxDB.

Here we’re creating a new dashboard and adding graphs. You have the option to select from pre-existing graphs or create a new one:

Dashboard layout is fully customizable:

Improvements in Data Exploration

The larger your datasets become, the more important it becomes to have effective tools to navigate and explore your measurements and tags. Chronograf’s query builder is smart: selecting a measurement will mean only tags linked to that measurement will be available to choose, and vice versa.

In this example I start with 30+ Telegraf measurements, only some of which are recording cpu usage. Selecting the tag key cpu filters the list of measurements to only include CPU-based metrics:

What's next?

That’s it for 0.3! Here are a few additional features already in the pipeline for future releases:

Templating
Cloud integration - download pre-built dashboards and upload your own dashboards
Different types of graphs (e.g. line graphs, histograms, etc.)
New kinds of visualizations (e.g. counters)

Want to try it out? Chronograf is free to use, and without user or per server limits. You can download Chronograf here. We’re still in active development and are eager to hear what you think! Contact the team at chronograf@influxdata.com.