Metrics: connect Prometheus or an OpenTelemetry service in words

jcoffey-dev commented

2026-09-28 21:46:52 +00:00

Owner

Fifth second-wave item from the settings-reorg spec. Based on main; independent of the other open PRs.

The three metrics pages (General, OpenTelemetry, Prometheus) open with Where the server's numbers go.

Prometheus

A switch, a user name (default prometheus), and Make a password, generated in the browser with crypto.getRandomValues and shown once.
The scrape address: /metrics/prometheus on the server's web address, the route in http/src/request.rs.
A scrape_configs job to copy, with scheme, path, target and basic_auth.
Check it answers: fetches the endpoint and reports the number of measurements, asks for the user name and password: as it should on a 401, or that the browser couldn't read it.
With no user name, a warning that anyone who can reach the server can read the numbers.

OpenTelemetry

Honeycomb: api.honeycomb.io/v1/metrics, with key and dataset as x-honeycomb-* headers.
Grafana Cloud: the OTLP gateway, with instance ID and token as Basic auth. A note says the server sends counters as deltas (Temporality::Delta), so some counters may need a Collector with deltatocumulative in between.
Your own collector: over HTTP or gRPC.
An HTTP endpoint in the settings is used exactly as given (opentelemetry-otlp resolve_http_endpoint), so /v1/metrics is added to a bare address.
Secrets: a saved Honeycomb key (a plain header the server returns) is kept when the field is left empty. Grafana's token, a secret the server never returns, is asked for again whenever its settings change.

Only changed parts are sent, so saving OpenTelemetry leaves Prometheus's password alone. The page's own settings (which metrics) are folded underneath.

Checked: 5 unit tests for the scrape address and job, passwords, provider values and reading them back (430 total), plus typecheck, lint and build. In Chrome against a local server:

Prometheus on with a generated password saved (authUsername: prometheus, secret set).
Check it answers got the 401: the browser can read the endpoint and it's protected.
Your own collector (HTTP) at http://localhost:4318 saved as http://localhost:4318/v1/metrics, and the Prometheus secret was untouched.
No config warnings.
A bug found in that run is fixed: Save changes stayed up after saving a new password.

Not tried against a live Honeycomb or Grafana Cloud account.

English only: about 40 new strings.

Fifth second-wave item from the settings-reorg spec. Based on main; independent of the other open PRs. The three metrics pages (General, OpenTelemetry, Prometheus) open with *Where the server's numbers go*. **Prometheus** - A switch, a user name (default `prometheus`), and *Make a password*, generated in the browser with `crypto.getRandomValues` and shown once. - The scrape address: `/metrics/prometheus` on the server's web address, the route in `http/src/request.rs`. - A `scrape_configs` job to copy, with scheme, path, target and `basic_auth`. - *Check it answers*: fetches the endpoint and reports the number of measurements, *asks for the user name and password: as it should* on a 401, or that the browser couldn't read it. - With no user name, a warning that anyone who can reach the server can read the numbers. **OpenTelemetry** - **Honeycomb:** `api.honeycomb.io/v1/metrics`, with key and dataset as `x-honeycomb-*` headers. - **Grafana Cloud:** the OTLP gateway, with instance ID and token as Basic auth. A note says the server sends counters as deltas (`Temporality::Delta`), so some counters may need a Collector with `deltatocumulative` in between. - **Your own collector:** over HTTP or gRPC. - An HTTP endpoint in the settings is used exactly as given (opentelemetry-otlp `resolve_http_endpoint`), so `/v1/metrics` is added to a bare address. - **Secrets:** a saved Honeycomb key (a plain header the server returns) is kept when the field is left empty. Grafana's token, a secret the server never returns, is asked for again whenever its settings change. Only changed parts are sent, so saving OpenTelemetry leaves Prometheus's password alone. The page's own settings (which metrics) are folded underneath. **Checked:** 5 unit tests for the scrape address and job, passwords, provider values and reading them back (430 total), plus typecheck, lint and build. In Chrome against a local server: - Prometheus on with a generated password saved (`authUsername: prometheus`, secret set). - *Check it answers* got the 401: the browser can read the endpoint and it's protected. - *Your own collector (HTTP)* at `http://localhost:4318` saved as `http://localhost:4318/v1/metrics`, and the Prometheus secret was untouched. - No config warnings. - A bug found in that run is fixed: *Save changes* stayed up after saving a new password. Not tried against a live Honeycomb or Grafana Cloud account. English only: about 40 new strings.

jcoffey-dev added 7 commits 2026-09-28 21:57:21 +00:00

Guided setup: connect a sign-in directory

ci / build (pull_request) Successful in 2m4s

Details

ci / publish (pull_request) Skipped

Details

0c64ff214b

Directories and Authentication offer a guide ("Guided or manual?" each
time) that:

- starts from Active Directory, OpenLDAP, FreeIPA, Keycloak, Authentik
  or another OpenID Connect provider, with filters and attributes set for
  that directory and example connection values;
- saves the directory, which changes nothing while no domain uses it,
  and tests a real person against it with the server's directory test:
  found or not (with aliases and groups), and whether a password signs
  in, a wrong password told apart from a broken connection. The guide
  won't go on until a person is found and, if given, the password works;
- then asks which domains sign in through it, with each domain's account
  count, and the server default as a separate switch. Choosing the
  domain you sign in on, or the default, needs an explicit "I've checked
  I can still sign in";
- switches the chosen domains over, putting them back if making it the
  default is refused.

Needs inbuxa-server's POST /api/directory/test.

Sender checks as a level: Relaxed, Recommended or Strict

ci / build (pull_request) Successful in 1m38s

Details

ci / publish (pull_request) Skipped

Details

86ae2c6672

Mail flow › Receiving › Sender checks opens with one choice instead of
six strategy fields, and a table of what each level does to mail that
fails. From the SMTP code:

- Relaxed (the stock settings): SPF, DKIM, DMARC and reverse DNS are
  checked on port 25 and scored by the spam filter; nothing is refused.
- Recommended: also refuses mail that fails DMARC for a domain that
  publishes p=reject, and checks ARC.
- Strict: also refuses senders that fail reverse DNS or SPF on MAIL
  FROM (including senders with none), and broken ARC chains. It warns
  that some real mail from small or badly set-up servers will bounce.

No level refuses unsigned mail (strict DKIM, which RFC 6376 advises
against). Checks stay on port 25, like the stock settings. Values set by
hand show as "Set by hand below", and applying a level then says it
replaces them. The form reloads after a level is applied; DKIM signing
isn't touched.

Limits as sentences, with presets for who uses the server

ci / build (pull_request) Successful in 2m4s

Details

ci / publish (pull_request) Skipped

Details

8fdae4a32b

A stock server has no rate limits: one stolen password can send without
end. A guide ("Guided or manual?" each time) asks who uses the server
(me and my family, a company or school, open to the public) and offers
five rules as sentences with numbers you can change:

- each outside server may connect N times a minute on port 25;
- each signed-in person may send N messages an hour;
- each signed-in person may address N recipients an hour in total
  (keyed by account alone; the condition reads rcpt, so the server
  checks it at RCPT TO);
- at most N deliveries a minute to any one receiving server;
- each sender may have at most N messages waiting.

Rules it writes are marked "Preset:" so running it again edits them; it
never touches rules made by hand. Above the incoming, outgoing and quota
lists, every rule now reads as a sentence, and an empty list says that
nothing is limited.

Retention on one page, as sentences

ci / build (pull_request) Successful in 2m2s

Details

ci / publish (pull_request) Skipped

Details

7b65b8eb34

Every "how long is this kept" setting was spread over four pages of
fields named after the config, plus log files on the Hardening page.
Each retention page now opens with all of them as sentences:

- in people's mailboxes: empty Trash and Junk after, clear handled
  calendar invitations after, forget share notices after, forget the
  sending status of sent mail after;
- getting deleted things back: deleted items and deleted accounts;
- the server's own records: delivery history, charts' history, DMARC
  and TLS reports from other servers, and old log files.

Each has a number and unit (or its own never / off / forever), its
default beneath, and an unsaved mark until the changes are saved
together. It says that mail under a legal hold is kept whatever these
say. The page's own settings (schedules and the like) are folded
underneath and reload after a save.

Reports in a few sentences, on every report page

ci / build (pull_request) Successful in 1m29s

Details

ci / publish (pull_request) Skipped

Details

c12b117fe7

Six report pages were mostly From names, subjects and signing domains;
whether reports go out at all was a frequency or rate expression inside
them. Each report page now opens with:

- tell other domains how their mail fared here (DMARC summaries):
  every hour, once a day, once a week or never;
- tell them whether their mail reached us encrypted (TLS summaries):
  the same;
- report each message that fails their checks (DMARC, DKIM and SPF
  failure reports together): on, at most once a day per address, or off,
  noting they carry message headers and that most large providers don't
  send them. Off is a value that isn't a rate, which sends none;
- send them, and bounce messages, from addresses at the default domain
  or a chosen one;
- read reports sent to postmaster@* (or other addresses) and show them
  under Management › Reports, and whether to still deliver them.

A value set by a rule with conditions is shown as such and left to its
page. The page's own settings are folded underneath and reload after a
save.

Alerts from templates, and every alert as a sentence

ci / build (pull_request) Successful in 1m59s

Details

ci / publish (pull_request) Skipped

Details

db8b0b1d26

Monitoring › Alerts needed a metrics expression to do anything. It now
opens with each alert in words ("When more than 500 messages are waiting
to be delivered, email [email protected].") and five templates: pick one,
set the number if it has one, say who to email, done.

- The queue is backing up (queue.count, a gauge: re-arms when it
  drains).
- Memory is running high (server.memory in MB, a gauge).
- Certificate renewal failed, the data store reported an error, and
  publishing DNS records failed: counters, which are totals since the
  server started, so each fires the first time and again only after a
  restart. The page says so.

No template watches a rate: counters in a condition are totals since
start, so "failures per hour" can't be written honestly. Templates are
recognised again on the page ("In use"), and an empty page says that
nothing will tell you when something goes wrong.

Metrics: connect Prometheus or an OpenTelemetry service in words

ci / build (pull_request) Successful in 1m39s

Details

ci / publish (pull_request) Skipped

Details

bdbefd831d

The metrics pages open with where the server's numbers go.

Prometheus: a switch, a user name and a password made in the browser
(shown once), then the scrape address (/metrics/prometheus on the
server's web address), a scrape job to paste into prometheus.yml, and a
check that the endpoint answers. Without a user name it warns that
anyone who can reach the server can read the numbers.

OpenTelemetry: Honeycomb (key and dataset as headers), Grafana Cloud
(OTLP endpoint, instance ID and token as Basic auth, with a note that
counters go out as deltas), or your own collector over HTTP or gRPC. An
HTTP endpoint in the settings is used exactly as given, so /v1/metrics
is added to a bare collector address. A saved Honeycomb key is kept when
the field is left empty; Grafana's token, which the server never sends
back, is asked for again when its settings change.

The page's own settings (which metrics) are folded underneath.

jcoffey-dev force-pushed feature/metrics-connect from 92f4b14a8b to bdbefd831d

2026-09-28 21:57:21 +00:00

Compare

jcoffey-dev merged commit 9e6b6f3606 into main

2026-09-28 22:02:07 +00:00

jcoffey-dev deleted branch feature/metrics-connect

2026-09-28 22:02:08 +00:00

Metrics: connect Prometheus or an OpenTelemetry service in words #46