Databases Azure

InfluxDB 2 on Ubuntu 24.04 on Azure User Guide

| Product: InfluxDB 2.9 on Ubuntu 24.04 LTS on Azure

Overview

InfluxDB is InfluxData's open-source time-series database: a single Go server that stores timestamped measurements and serves them back over an HTTP API, with a built-in web UI for exploring, dashboarding and alerting on that data. It is the standard store behind metrics, IoT sensor and application-telemetry pipelines, and it speaks the line protocol that Telegraf and hundreds of client libraries already emit.

The cloudimg image installs InfluxDB 2.9.1 from InfluxData's own signed package repository, publishes the API and the web UI over HTTPS on port 8086, and generates a unique administrator password, operator API token and TLS certificate on the first boot of every VM. Nothing is pre-created at build time: the image ships with an empty data directory, so there is no organisation, bucket, user or token in it that anyone else could know. Backed by 24/7 cloudimg support.

What is included:

  • InfluxDB 2.9.1 (MIT), the open-source single-node server, with the built-in web UI, Flux and InfluxQL
  • The influx command-line client (influxdb2-cli, MIT)
  • The HTTP API and the web UI served over HTTPS on port 8086, using a TLS certificate minted per VM on first boot
  • A unique admin password and a unique operator API token generated on first boot, written to a root-only credentials file
  • An organisation (cloudimg) and a bucket (metrics, infinite retention) created on first boot, with a small demo measurement so the UI opens on real data
  • influxdb.service as a systemd unit, enabled and gated so it can never serve an un-bootstrapped instance
  • 24/7 cloudimg support

Why the 2.x line

InfluxDB has three live major lines and they are not interchangeable. 1.x is legacy. 3.x is a separate product line that splits a free Core edition from a paid Enterprise edition, and Core has no built-in administrative web UI. 2.x is the fully-functional single-node appliance: one binary, one port, a complete web UI, and no paid tier gating any part of what this image does. If you specifically want the 3.x engine, cloudimg publishes a separate InfluxDB 3 image.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point; scale up for higher ingest rates. NSG inbound: allow 22/tcp from your management network and 8086/tcp from the hosts and workstations that will write and query data. Do not expose 8086/tcp to the whole internet.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for InfluxDB by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22). Then Review + create -> Create. Add an inbound rule for 8086/tcp scoped to your own address range once the VM exists.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name influxdb \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Then open the API/UI port, scoped to your own address range rather than the whole internet:

az vm open-port --resource-group <your-rg> --name influxdb --port 8086 --priority 1001

Step 3 - Retrieve the per-VM credentials

A unique admin password and a unique operator API token are generated on the first boot of every VM and written to a root-only credentials file. SSH in and read it:

ssh azureuser@<vm-public-ip>
sudo cat /root/influxdb-credentials.txt

The file is 0600 root:root and contains the URL, the organisation, the bucket, the admin login and the operator token:

INFLUXDB_URL=https://<vm-public-ip>:8086
influxdb.host=<vm-public-ip>
influxdb.port=8086
influxdb.username=admin
influxdb.password=<INFLUXDB_PASSWORD>
influxdb.org=cloudimg
influxdb.bucket=metrics
influxdb.token=<INFLUXDB_TOKEN>

The per-VM credentials this VM generated on first boot, with the secrets masked

The password signs you in to the web UI. The token authenticates API and influx CLI requests. Keep both safe - they are unique to this VM and are shown in plain text only in this file.

Step 4 - Confirm InfluxDB is healthy

systemctl is-active influxdb
influxd version
curl -ks https://127.0.0.1:8086/health

/health reports "status":"pass" once the server is ready for reads and writes:

InfluxDB 2.9.1 healthy under systemd and serving HTTPS on port 8086

Note the -k on curl: the certificate is self-signed and unique to this VM, so clients either skip verification or trust the certificate explicitly. Replacing it with your own certificate is covered below.

Step 5 - Sign in to the web UI

Browse to https://<vm-public-ip>:8086/. Your browser will warn once about the self-signed certificate - accept it to continue. Sign in as admin with the password from the credentials file:

The InfluxDB sign-in page, served over HTTPS on port 8086

After signing in you land on the getting-started page, which links the client libraries, the CLI and Telegraf, and shows the running version in the lower right:

The signed-in InfluxDB home page showing version v2.9.1

You can verify the password from the command line too - the sign-in endpoint answers 204 for the per-VM password:

PASSWORD=$(sudo sed -n 's/^influxdb.password=//p' /root/influxdb-credentials.txt)
curl -ks -o /dev/null -w 'signin: %{http_code}\n' -XPOST https://127.0.0.1:8086/api/v2/signin -u "admin:$PASSWORD"

Step 6 - Write your first points

Every write is authenticated with the operator token and addressed to an organisation and a bucket. Read the token out of the credentials file and post a point in line protocol - a successful write returns 204:

TOKEN=$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)
curl -ks -o /dev/null -w 'write: %{http_code}\n' \
  -XPOST "https://127.0.0.1:8086/api/v2/write?org=cloudimg&bucket=metrics&precision=s" \
  -H "Authorization: Token $TOKEN" \
  --data-binary "cpu,host=web-01 usage=63.5 $(date +%s)"

Line protocol is measurement,tag=value field=value timestamp. Tags are indexed and are what you filter and group by; fields hold the numbers.

Step 7 - Query it back with Flux

The influx CLI ships with the image. Because the certificate is self-signed, pass --skip-verify - the CLI does not accept curl's -k:

TOKEN=$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)
influx query --skip-verify --host https://127.0.0.1:8086 -t "$TOKEN" -o cloudimg \
  'from(bucket:"metrics") |> range(start:-15m) |> filter(fn:(r) => r._measurement == "cpu")'

Writing a point over TLS with the per-VM operator token and reading it back with the influx CLI

The same query over the raw HTTP API returns annotated CSV:

TOKEN=$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)
curl -ks -XPOST "https://127.0.0.1:8086/api/v2/query?org=cloudimg" \
  -H "Authorization: Token $TOKEN" \
  -H 'Accept: application/csv' \
  -H 'Content-Type: application/vnd.flux' \
  --data 'from(bucket:"metrics") |> range(start:-15m) |> filter(fn:(r) => r._measurement == "cpu") |> last()'

In the web UI the same thing is interactive. Open Data Explorer from the left-hand nav, either assemble the query with the point-and-click Query Builder or switch to Script Editor and write Flux directly, then press Submit:

The InfluxDB Data Explorer plotting a Flux query result as a time-series graph

The image seeds a small cloudimg_demo measurement on first boot, so the Data Explorer has something to draw before you send any data of your own.

Step 8 - Buckets and retention

Data lives in buckets, and each bucket has a retention policy that expires points automatically. The image creates metrics with infinite retention. Open Load Data -> Buckets to see it, change its retention, or create more:

The Buckets tab showing the metrics bucket with infinite retention

From the command line:

TOKEN=$(sudo sed -n 's/^influxdb.token=//p' /root/influxdb-credentials.txt)
influx bucket list --skip-verify --host https://127.0.0.1:8086 -t "$TOKEN" -o cloudimg

Create a bucket that keeps 30 days of data:

influx bucket create --skip-verify --host https://127.0.0.1:8086 -t "$TOKEN" \
  -o cloudimg -n telemetry -r 30d

Step 9 - How access is protected

InfluxDB authorises every API request with a token, and this image serves the API only over TLS. Requests with no token, a guessed token, or a common default password are all rejected with 401, and the instance is already claimed so nobody can run the setup wizard against it:

curl -ks -o /dev/null -w 'no token:      %{http_code}\n' https://127.0.0.1:8086/api/v2/buckets
curl -ks -o /dev/null -w 'guessed token: %{http_code}\n' https://127.0.0.1:8086/api/v2/buckets -H 'Authorization: Token admin'
curl -ks -o /dev/null -w 'weak password: %{http_code}\n' -XPOST https://127.0.0.1:8086/api/v2/signin -u admin:password
curl -ks https://127.0.0.1:8086/api/v2/setup

Unauthenticated requests, guessed tokens and common default passwords all rejected with HTTP 401

"allowed": false from /api/v2/setup is the proof that this instance has already been bootstrapped with your per-VM credentials.

Issue additional, narrower tokens rather than sharing the operator token with applications. A write-only token for one bucket:

influx auth create --skip-verify --host https://127.0.0.1:8086 -t "$TOKEN" \
  -o cloudimg --write-bucket <bucket-id> --description "telegraf write-only"

The Azure network security group remains your first line of defence - keep 8086/tcp scoped to the hosts that need it.

Step 10 - Collect metrics with Telegraf

Telegraf is InfluxData's collection agent and is the usual way to fill a bucket. Install it from the same repository this image already trusts, then point it at the local server:

sudo apt-get update && sudo apt-get install -y telegraf

In /etc/telegraf/telegraf.conf set the output plugin:

[[outputs.influxdb_v2]]
  urls = ["https://127.0.0.1:8086"]
  token = "<INFLUXDB_TOKEN>"
  organization = "cloudimg"
  bucket = "metrics"
  insecure_skip_verify = true

Then sudo systemctl restart telegraf. Any client library works the same way - the URL, the token, the organisation and the bucket are all you need.

Replacing the self-signed TLS certificate

The image mints a self-signed certificate per VM so nothing is ever served in plaintext. To use your own certificate, replace the two files and restart:

sudo install -o influxdb -g influxdb -m 0644 fullchain.pem /etc/influxdb/tls/influxdb-server.crt
sudo install -o influxdb -g influxdb -m 0600 privkey.pem   /etc/influxdb/tls/influxdb-server.key
sudo systemctl restart influxdb

The paths are set in /etc/influxdb/config.toml; keep the same filenames and no configuration change is needed. Clients can then drop -k and --skip-verify.

Maintenance

Check where the configuration and data live:

ls -l /etc/influxdb/config.toml
sudo ls -ld /var/lib/influxdb

Read the service log:

sudo journalctl -u influxdb --no-pager -n 20

Back up a bucket to a directory (the backup includes the metadata store, so keep it as private as the credentials file):

influx backup --skip-verify --host https://127.0.0.1:8086 -t "$TOKEN" /var/backups/influxdb-$(date +%F)

Upgrades come from the InfluxData repository the image already trusts:

sudo apt-get update && sudo apt-get install --only-upgrade influxdb2 influxdb2-cli
sudo systemctl restart influxdb

Security updates for the operating system are applied automatically by unattended-upgrades.

Troubleshooting

The service is not running after a reboot. InfluxDB is deliberately gated on a bootstrap-ready marker written by the first-boot service, so it can never serve an un-bootstrapped instance. Confirm both are in order:

systemctl is-enabled influxdb
systemctl show influxdb-firstboot.service --property=ActiveState --value
sudo ls -l /var/lib/cloudimg/influxdb-ready

If the marker is missing, the first-boot service did not finish. Its log explains why:

sudo tail -20 /var/log/cloudimg-firstboot.log

curl reports a certificate problem. That is expected with the per-VM self-signed certificate. Use -k with curl, --skip-verify with influx, or install your own certificate as above.

A write returns 401. The token is wrong or missing. Re-read it from /root/influxdb-credentials.txt; the header must be exactly Authorization: Token <token>.

A write returns 404. The organisation or bucket name in the query string does not exist. List them with influx bucket list as in Step 8.

Support

This image is published and supported by cloudimg. For assistance, contact support@cloudimg.co.uk.