(collaboration) add opt-in prometheus metrics to yhub

Same we did before with django-prometheus, we want metrics for yhub, the
is no integration available like django-prometheus so everything is
craft in the repository. The documentation is also available in
documentation/metrics.md
This commit is contained in:
Manuel Raynaud
2026-09-21 14:48:42 +02:00
parent 03fec236e1
commit fca347d730
21 changed files with 1081 additions and 57 deletions
+4
View File
@@ -199,6 +199,10 @@ documents what each of them changes.
| SENTRY_RELEASE | Release the events are reported under. Detected by the SDK when unset | |
| SENTRY_TRACES_SAMPLE_RATE | Share of the traces sent to Sentry, between `0` and `1` | 0 |
| SENTRY_PROFILES_SAMPLE_RATE | Share of the sampled traces that are also profiled, between `0` and `1`. The native profiler is only loaded above `0` | 0 |
| PROMETHEUS_METRICS_ENABLED | Set to "true" to serve the prometheus metrics of the process, server or worker, on a port of their own. See the "Metrics" section of `src/yhub-server/README.md` | false |
| PROMETHEUS_API_KEY | Bearer token required by the metrics listener. Required when the metrics are enabled: starting without it is an error. Can be read from a file with PROMETHEUS_API_KEY_FILE | |
| PROMETHEUS_METRICS_PORT | Port the metrics are served on | 9464 |
| PROMETHEUS_METRICS_PATH | Path the metrics are served on, and the only one answered | /metrics |
| SOFT_MIGRATION | Set to "true" to seed a room from the legacy Django/S3 document store the first time it is opened | false |
| LEGACY_S3_ENDPOINT_URL | Required by SOFT_MIGRATION, endpoint of the legacy media bucket, without a path | |
| LEGACY_S3_ACCESS_KEY_ID | Required by SOFT_MIGRATION, read access to that bucket (or LEGACY_S3_ACCESS_KEY_ID_FILE) | |
+33 -1
View File
@@ -1,4 +1,12 @@
# Prometheus metrics of the backend
# Prometheus metrics
This page is about the backend. The collaboration server (yhub) has metrics of
its own, served the same way — a bearer token, outside of what the ingress of
the application publishes — and documented in the "Metrics" section of
`src/yhub-server/README.md`. The [Helm section](#kubernetes-helm-chart) below
covers both.
## Backend
The backend ships an **opt-in** instrumentation,
[django-prometheus](https://github.com/django-commons/django-prometheus). It is
@@ -117,6 +125,30 @@ ingressMetrics:
`ingressMetrics` routes the exact path `/metrics` of that host to the backend
and nothing else. Its host has to be in `DJANGO_ALLOWED_HOSTS`.
With yhub, the same ingress also publishes the server and the worker, each on an
exact path of its own:
```yaml
yhub:
envVars:
PROMETHEUS_API_KEY: # the worker inherits it
secretKeyRef:
name: yhub
key: PROMETHEUS_API_KEY
metrics:
enabled: true # /metrics/yhub and /metrics/yhub-worker
```
| Path | Served by |
|---|---|
| `/metrics` | backend |
| `/metrics/yhub` | yhub server (websockets, authorizations, backend calls) |
| `/metrics/yhub-worker` | yhub worker (compactions), when `yhub.worker.enabled` |
That is three scrape jobs on one host, differing by `metrics_path`. What is said
above about [several replicas](#several-replicas-behind-one-address) applies to
each of them: yhub labels its samples with `hostname` too.
The celery worker receives `backend.envVars` too. It serves no request, so its
metrics are never read: turn them off there with
`backend.celery.envVars.PROMETHEUS_METRICS_ENABLED: "False"`.