Overview

InfluxDB databases are time-series databases, which means that they are made to especially work on time-stamped data that are sampled over time. All JMeter, Telegraf, profiling, and custom metrics such as those of Okapi are stored in InfluxDB databases.  Each team's Rancher area has an instance of the InfluxDB. This way each team has its own InfluxDB instance that contains the data which can be retrieved by Grafana or interrogated by ad hoc queries at any time. 

There are six InfluxDB databases

• profiling: to hold profiling data
• comparison: to hold data between test runs for comparison.
• jmeter: stores JMeter data for all test runs
• Okapi: stores Okapi custom metrics
• telegraf: stores data forwarded by Telegraf. This is the physical server's data such as CPU, memory, heap state, disk IO, etc.
• threholds: stores threshold metadata.

Administering InfluxDB Server

InfluxDB can be found in each team's Rancher's space:

Creating the database

Databases are created automatically by Teraform scripts. Normally teams don't have to do this. In the unlikely event that the databases need to be created from scratch, one can execute the following commands:

1. Get on the InfluxDB serer by typing:

   docker exec ti carrier influx influx

2. One by one, create the databases above by this command:

   create database <databaseName>

3. To see the databases created,  type:

   show databases  

4. Set retention policy on a database to set when the data shall be expired. 

   alter retention policy "autogen" on "<databaseName>" duration 6w default.

     Do this for all databases.

   1. 1. Here we are setting the policy autogen on the database to have its data automatically deleted after 6 weeks. The default is one week. Setting it to 6 weeks give us room to retrieve the test results and to compare against future test runs.

Backing up and Restoring the databases

Periodically it's a good idea to back up the databases to preserve the test data. For example, if we want to compare test data of one release to another, we should back up the database because each release spans over the 6 weeks retention (above).  Alternatively, we might want to back up the databases in case of something might happen to them when administering the InfluxDB server. Lastly, teams may want to back up the databases periodically because the database's disk may run out of space, especially if the disk space is overwhelmed by profiling or metrics data, which are pumped to their respective databases every few seconds. 

Follow instructions inAdministeringInfluxDB.pdf,  to back up and restore databases.

DO's and DON'T's

• DO back up the databases
• DO NOT let a profiled module (or modules) run past the test time because while the module is not being used the module is constantly being profiled and the profiling data is sent to the InfluxDB, therefore filling it up quickly.  
• DO NOT let a enabled-metrics module (or modules) run past the test time for the same reason as letting profiled modules running past the test time. 
• DO NOT shut down the InfluxDB server without backing up the databases first to prevent data loss by accident.