Documentation previewThese docs are actively being built. Some pages may change as the framework and examples are finalized.
Skip to content

Metrics

Metrics are numeric operational signals emitted by the App.

Generated Apps expose Prometheus-compatible metrics through github.com/goforj/metrics.

Endpoints

Standalone host mode prefers one shared metrics endpoint:

text
http://localhost:9100/metrics

Direct runtime commands may expose source-specific listeners:

text
http://localhost:9100/metrics  # HTTP
http://localhost:9101/metrics  # jobs
http://localhost:9102/metrics  # scheduler

When HTTP metrics are enabled, the App may also expose:

text
GET /metrics

Toggles

Framework metrics can be controlled per surface:

text
METRICS_HTTP_ENABLED=true
METRICS_CACHE_ENABLED=true
METRICS_STORAGE_ENABLED=true
METRICS_EVENTS_ENABLED=true
METRICS_QUEUE_ENABLED=true
METRICS_DATABASE_ENABLED=true
METRICS_AUTH_ENABLED=true
METRICS_SCHEDULER_ENABLED=true

Disabled instrumentation should be absent or inert enough to make overhead decisions honest.

Labels

Labels should be bounded and operator-facing.

Prefer route patterns, queue names, job names, schedule names, cache names, disk names, bus names, and driver names.

Avoid user IDs, emails, raw URLs, raw SQL, cache keys, filenames, request IDs, and arbitrary error strings.

Proving Path

GoForj metrics should prove themselves against standard Prometheus-compatible tooling before Lighthouse adapts them into UI views.

This keeps metric names, labels, and dashboards honest.

Common Mistakes

Common mistakes

  • Do not add high-cardinality labels.
  • Do not count internal scrape traffic as application traffic.
  • Do not create a second metrics registry for normal App metrics.
  • Do not use metrics as a replacement for logs or inspects.

Next Steps