Shaping your tags
Almost every question about Driftmetrics is really a question about which tags a run should carry.
Is this ML data-drift monitoring?
No. Drift here is the slow creep of your numbers between releases: size, RAM, latency, accuracy. We do not watch production inputs or model predictions, only the metrics your build pushes.
We measure on hardware and in a simulator. One project or two?
One project. The environment is a tag, so the same metric can be trended per environment and compared across them in one query. Add the board when you run on more than one.
Debug and release builds?
A tag as well. Both builds push the same metric names, and a filter picks the one you care about. Without the tag the two runs collide on the same coordinate and overwrite each other.
Our repo builds several libraries. How do I keep them apart?
A component tag, one push per component. Use separate projects only when the artifacts are separate products with their own teams, tokens and metric sets.
How do branches fit in?
The version stays the axis and the branch is a tag, so a pull request gets its own series next to main instead of interleaving with it.
Should a metric ever be a tag?
No. Push every number a build produced in one call: the run holds them all. When the same metric repeats per model or per input set, that repetition is the tag.
Our nightly benchmark has no version. What then?
Put the project in time_series mode, where the timestamp joins the identity, so a nightly run appends a point instead of overwriting one. Keep the commit in meta.
What belongs in meta?
Anything that explains a run without identifying it: commit sha, CI run URL, runner name, toolchain version. Move a value out of meta and into a tag the day you want to compare on it.
We tag every push with a git ref and each chart is one-point lines. Help?
A value that changes every push splits every series. Two settings fix it. Merged by default (or the merge toggle on a key on Explore or in a widget) stops the key splitting lines, keeping the newest push where runs meet on the axis, while it stays a filter when you need it. Demote to meta moves the key out of the tags for good: existing runs are rewritten once, colliding ones keep the newest, and later pushes are rewritten on arrival, so CI stays as it is.
A new project or another tag?
A project is an access and history boundary: its own token, its own metric definitions, its own axis. If the numbers belong to one product and you would ever chart them together, use tags.
What happens if I push the same tags twice?
In versioned mode the run is replaced: the new measurements win and a metric you left out is dropped, unless you set options.merge to keep it. In time_series mode a second push appends a point.
How are versions ordered?
As versions: an optional v, 1–4 dot-separated numbers (only the 4th may exceed the int range) and an optional suffix after -, . or +, so 1.9.0 comes before 1.10.0 whatever order you push in. A - suffix is a pre-release and sorts before the release, so git describe output v1.2.3-5-gabc sorts below 1.2.3.