Metresis

What it does

The point is context. "91.4" is not information. "91.4 percent line coverage on this commit of main, down from 94.1 on the one before" is. So is "91.4 kg, Tuesday morning, two weeks into a new programme". Metresis keeps the number and its circumstances together, so that "group by X, filter to Y, and mark where things changed" is a query rather than an export to a spreadsheet.

It is domain-neutral by design. Software delivery metrics, health readings, workout logs, weather and sensor data, and project tracking all have the same shape, and nothing in the core knows about any of them. The vocabulary that makes a domain readable lives in a profile, which is data: which labels are high-cardinality context, which metric is a gauge in kilograms, which dashboards and alert rules to offer.

Metresis deliberately has no data-entry screens. People record measurements through front ends built for their own domain and device. Those front ends ask Metresis's catalog endpoint what to render instead of copying its definitions. Systems that cannot post for themselves are read by a bundled collector, which so far supports GitLab, GitHub, and Linux hosts over SSH.

Ideas it is built on

• A metric's type decides which aggregations are legal, and the interface cannot offer an illegal one. The mean of "sad" and "happy" is not a number. Nor is the arithmetic mean of wind directions of 350° and 10°, which comes out as due south when every reading was close to due north. Semantic type and unit family are separate axes, and only aggregations valid on both are offered.
• Definitions are rows, and values point at them by id. Renaming is safe and applies to history. Inserting a step into a scale is an explicit act that leaves earlier data intact.
• Absence is not zero. No aggregation reads a missing sample as a low one. Alerting turns this around: "no data for N minutes" is a first-class condition, because a sensor that stops reporting never trips a threshold.

Alert rules are saved queries plus a condition. Each series is evaluated separately, with a pending state so that one noisy sample does not cause flapping. Notifications go out by signed webhook, email or in-app.

How it is built

The same code and the same test suite run on SQLite (a personal instance is one file you can copy) or Postgres, with TimescaleDB used for partitioning when it is present. Portability comes from the design rather than an abstraction layer. Queries avoid features one backend lacks, and time bucketing and percentiles are computed in Elixir when rollups are built, so the numbers cannot differ depending on the database installed. CI runs every change against both backends.

Charts are drawn by Visualize, on the server. An instance also reports its own request times, query times and scheduler health into itself, through the same client library any other application would use, and ships with an alert rule for when a background job falls behind.

Status

Metresis is in active use and development, at version 0.8. Releases follow semantic versioning with a maintained changelog, and the HTTP API is stable within 0.y. It ships as SQLite and Postgres container images, managed from the host by a single-file control script.