Skip to content

Observability

Effectively none, same as sibling backends.

What exists

  • console.log at boot (port banner, socket banner)
  • Ad-hoc console.log / console.error calls in handlers (especially around catch blocks)

What does not exist

Capability Status
Structured logging (JSON logs) ❌
Logging library (winston, pino, bunyan) ❌
Request access log (morgan) ❌
Error tracker (Sentry, Bugsnag) ❌
Tracing (OpenTelemetry) ❌
Metrics (Prometheus, StatsD) ❌
/health endpoint ❌
/ready endpoint ❌
Slow-query logging ❌
DB connection pool metrics ❌

In production

The service is presumed to run under PM2 (per the platform pattern). PM2's default log files capture stdout/stderr; this is the only place errors are visible after the fact.

When an admin user reports a bug:

  1. The handler probably caught the error and called console.log("error", error).
  2. The log line ended up in the PM2 log on the production server.
  3. Finding it requires SSH access and grep.

There is no per-user / per-request correlation id, so reconstructing a user's session from logs is hard.

Minimal improvements

In rough order of cost:

  1. /health endpoint — one-liner, makes load-balancer health checks possible. 
    app.get('/health', (req, res) => res.json({ status: 'ok', uptime: process.uptime() }));
  2. Access log via morgan — already in the platform's habit (verify); adds one line to server.js.
  3. Request id middleware — generate a UUID per request, put it on res.requestId, include in every log line. Makes log correlation possible.
  4. Wrap console.log to print structured JSON — pino is the lowest-friction option.
  5. Sentry integration — @sentry/node SDK; ~10 lines of config; capture handler errors automatically.
  6. Slow-query logging — wrap con.query / connection.query to time and emit a warning when > 500 ms.

Suggested order

Steps 1–3 are appropriate for an admin tool. Steps 4–6 become more valuable as the admin tool's user base grows and incidents need post-mortem.

Cross-component implication

If observability is added across the platform, the admin tool is the cheapest place to start: low traffic, internal users (so any noise from getting it wrong is constrained), and the codebase is small enough that the wiring is fast. Once the pattern is proven here, it can be lifted into the bigger someli-api.