InfluxDB (Time Series) Cheat Sheet
InfluxDB line protocol, Flux and InfluxQL query basics, and core time-series concepts like tags, fields, and cardinality.
Line Protocol (Writing Data)
The text format used to write points.
# measurement,tag_set field_set timestampcpu,host=server01,region=us-west usage=64.2 1465839830100400200# Write via CLI (InfluxDB 2.x)influx write \ --bucket mybucket \ --precision s \ "cpu,host=server01 usage=64.2"
Flux Query Basics (2.x)
Filtering and aggregating a bucket.
from(bucket: "mybucket") |> range(start: -1h) |> filter(fn: (r) => r._measurement == "cpu") |> filter(fn: (r) => r.host == "server01") |> mean()
InfluxQL Basics (1.x-style)
SQL-like querying still supported for compatibility.
SELECT mean("usage") FROM "cpu"WHERE "host" = 'server01' AND time > now() - 1hGROUP BY time(5m)
Core Concepts
Time-series terminology and data model.
- Measurement- analogous to a table; groups related time-series points
- Tag- indexed, string-only metadata key/value used for filtering and grouping
- Field- the actual, unindexed value being recorded, e.g. usage=64.2
- Timestamp- every point is stored with nanosecond-precision time
- Bucket (2.x)- a named storage location with an associated retention policy
- Retention policy- defines how long data is kept before automatic deletion
Advanced Flux Pipeline
Joining, windowing, and shaping data with multiple Flux stages.
cpuData = from(bucket: "mybucket") |> range(start: -6h) |> filter(fn: (r) => r._measurement == "cpu" and r._field == "usage")memData = from(bucket: "mybucket") |> range(start: -6h) |> filter(fn: (r) => r._measurement == "mem" and r._field == "used_percent")join(tables: {cpu: cpuData, mem: memData}, on: ["_time", "host"]) |> aggregateWindow(every: 5m, fn: mean, createEmpty: false) |> yield(name: "joined")
Downsampling with Tasks (2.x)
Scheduled Flux tasks replace 1.x continuous queries for rollups.
option task = {name: "downsample-cpu", every: 1h}from(bucket: "mybucket") |> range(start: -task.every) |> filter(fn: (r) => r._measurement == "cpu") |> aggregateWindow(every: 10m, fn: mean) |> to(bucket: "mybucket_downsampled", org: "myorg")
Schema Exploration API
Discover measurements, tag keys, and tag values without scanning raw points.
import "influxdata/influxdb/schema"schema.measurements(bucket: "mybucket")schema.tagValues( bucket: "mybucket", tag: "host", predicate: (r) => r._measurement == "cpu",)
Bucket Retention & Shard Groups
Tuning storage lifecycle via the CLI instead of the deprecated RETENTION POLICY syntax.
# Create a bucket with a 30-day retention and explicit shard group durationinflux bucket create \ --name mybucket_30d \ --org myorg \ --retention 30d \ --shard-group-duration 1d# Update retention on an existing bucketinflux bucket update --id <bucket-id> --retention 90d
Cardinality & Storage Internals
Concepts that matter once a deployment moves past toy workloads.
- Series key- the unique combination of measurement + tag set that identifies one time series
- Series cardinality- total distinct series in a bucket; the TSI index size scales directly with it
- Shard group- a time-bounded chunk of storage; retention and shard-group duration control how data ages out
- TSM (Time-Structured Merge Tree)- the on-disk storage engine InfluxDB uses, similar in spirit to an LSM tree
- Compaction- background process that merges TSM files to reduce read amplification and reclaim space
- _start / _stop- implicit columns Flux adds to every range() call, useful for windowed joins
Keep high-cardinality values (like unique user IDs or request IDs) out of tags — every distinct tag-value combination creates a new series, and too many series causes a cardinality explosion that badly degrades performance.
