vSphere Performance data – Part 4 – InfluxDB

This is Part 4 of my series on vSphere Performance data.

Part 1 discusses the project, Part 2 is about exploring how to retrieve data, Part 3 is about using Get-Stat for the retrieval. This post will be about the database used to store the retrieved data, InfluxDB.

The last post left of with the beginning of a script that had retrieved data from vCenter. Before I can finish that script I need to have somewhere to put that data. As I discussed in Part 1 I had decided to use InfluxDB for this purpose.

InfluxDB is a time-series database built for storing large amounts of timestamped data. The database promises high-performance for time-series data and gives interfaces for interacting with the data in a SQL-like fashion. To learn more about it, and get all the marketing stuff visit their website

InfluxDB is currently in version 1.2 and that is the version we will use. It seems they have made some changes in their latest versions so please be aware of this if you already have Influx installed and want to compare.

So Influx needs to be downloaded and installed. There are lots of ways to do this and I will not go through this as it’s pretty well explained on their Getting started page.


Key concepts

I started out with a RedHat 7 VM with 1 CPU and 4 GB RAM (I have also used CentOS which is free compared to RHEL). The download and installation is as I’ve explained really easy.

So after installing Influx on a VM I started exploring.

The data in Influx is organized by time series, a time serie will be a measured value. In my instance it could be “cpu_ready”. This will be referred to as a “measurement”. Each measurement will consist of zero to many “points”. A point is like a “point-in-time” sample of what you are measuring. Each point will contain the measurement, the timestamp and a value field, as well as zero to many key-value tags which could be some metadata about this value.

We can think of a measurment as kind of similar to an SQL table. The measurements’ primary index would be the time (timestamp). The tags and fields would be columns. One thing to be aware of is that tags are also indexed while fields are not. One key difference with an SQL table is that you don’t define the “tables” or measurements up front. They will be created and indexed as they are written to the database.

So with this in mind I could start writing data.


Writing and querying data

I first created a database from the influx CLI called “testing”

Continuing with CPU Ready as an example, one point could be written like this to the database:

We are starting with defining the measurement as “cpu_ready”. Then we create som key-value tags, namely “vm”, “host”, “vcenter” and “unit”. After the tags we have the value field and lastly the timestamp. Note that the timestamp by default will be a unix timestamp in nanoseconds

We could have more than 1 value field, then you would need to separate them with commas. You can also omit the timestamp to have Influx write the local timestamp.

With a point written to the database we can do a SELECT query to retrieve the written data:

With a couple of more points written we’ll get some more results

If you want to use Influx for storing data I really suggest that you spend some time in exploring and trying different ways to store your data. Even though it is similar to SQL there are differences and this could infer other ways to store the data than how you are used to. These kinds of databases, as well as other document db’s, will have more difficulties with relations than your traditional Relational Database systems.

You can group data in Influx based on your tags. Let’s group on host as this is the differentiator in my small example

Let’s insert three new points for a different timestamp

As you can see they are ordered by time, but you can of course order in the other direction (Note that you can only order by time and not other tags/fields)

The SELECT query can filter the points as you would normally do with a WHERE clause. Note that the query can be quite specific on how you need to use the quotation marks. Also keep in mind that tags are index where as fields (the value field in my example) is not


If you want to add additional metadata tags to your data it’s as easy as just adding it to your insert query:

Another important thing to consider when exploring the database is thinking about how and what metadata (aka tags) you want to use. Even though it’s really easy to add more tags (or stop using them), it’s not that easy to update previous records with the same. This might not be an issue, but if you want to use tags for filtering then it could turn out to be a pain point.



The InfluxDB also has an API for inserting and retrieving data which will be what I’ll use for writing my data from vCenter. With the API you can also create and manipulate databases.

The InfluxDB documentation uses curl in their examples, but I’ll of course use Powershell to test the API (the $db variable will be in the format of “http://<your-db-server>:<port (8086 is the default)>/”)

If the query is successful you’ll get an empty response

So, let’s query the data as well.
I’ll start by building the same $uri and a $query with the same SELECT query we have used already, and do an Invoke-Restmethod. I’ll put the response in a $result variable as we need to use that for exploring the output.

With this exploration I figured out that the API was the way to go when it came to writing to the database. You could also write to a file and somehow import that to the DB, but it’s much more easy to write directly without having a need for shared storage etc.

I did some testing on the writing of stats from my script and found that I needed to decide on if I would do one query for each metric and VM or if I could write it in bulk.

Influx’ API supports a POST with multiple points, which is no more than multiple points (to multiple series if you like) separated with a new line. This should be much more performant than having to POST for each point.
The API also supports writing points from a passed file, which is actually similar to the multiple points query above.


With that I went back to my script to create the logic for writing data to InfluxDB through the API and that will be the focus for the next part of this blog series.




Working with Cloud Infrastructure @ Intility, Oslo Norway. VMware vExpert. Mainly focused on automating Datacenter stuff. All posts are personal

2 thoughts to “vSphere Performance data – Part 4 – InfluxDB”

Leave a Reply

Your email address will not be published. Required fields are marked *