Problem
The service depends on prom-client and collects metrics in several places (a shared registry in src/metrics, plus module-specific endpoints such as /compiler/metrics and /api/v1/assets/metrics), but there is no single, documented Prometheus scrape endpoint that exposes the shared registry. Operators cannot point a scraper at one well-known path, and the metrics surface is undocumented.
What needs to be done
- Expose the shared
prom-client registry at a single documented endpoint (for example GET /metrics), including default process metrics.
- Ensure the module-specific metrics register into the shared registry so they appear at the unified endpoint.
- Document the endpoint, the exported metric names, and a sample scrape config in the README.
- Consider whether the endpoint should be access-controlled or bound to an internal interface, and document the choice.
Files
src/metrics, src/index.ts (route wiring)
README.md
Acceptance deliverables
- A single documented endpoint exposes the shared registry in Prometheus format.
- Module metrics are visible at that endpoint.
- All CI checks pass; the change cannot be merged until CI is green.
Tests to pass
- Test: the metrics endpoint returns Prometheus-formatted output including a known metric.
Problem
The service depends on
prom-clientand collects metrics in several places (a sharedregistryinsrc/metrics, plus module-specific endpoints such as/compiler/metricsand/api/v1/assets/metrics), but there is no single, documented Prometheus scrape endpoint that exposes the shared registry. Operators cannot point a scraper at one well-known path, and the metrics surface is undocumented.What needs to be done
prom-clientregistry at a single documented endpoint (for exampleGET /metrics), including default process metrics.Files
src/metrics,src/index.ts(route wiring)README.mdAcceptance deliverables
Tests to pass