iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
For a continuously running Node.js SaaS API, expose a /metrics endpoint and let Prometheus scrape it. Use Pushgateway only for a narrow case: a short-lived service-level batch job that finishes before Prometheus can scrape it and whose result must remain available afterward.
Pull or push: which pattern fits your workload?
| Question | Pull scraping | Pushgateway |
|---|---|---|
| What is running? | A long-running API, worker, or service process. | A short-lived job that exits before a scrape can reach it. |
| What does the metric describe? | Per-process or per-instance state and behavior. | A service-level job outcome independent of one machine or process instance. |
| How is collection health visible? | Prometheus records scrape health, including the target’s up series. |
Pushed metrics do not provide the ordinary per-target scrape-health signal. |
| What happens when work or a target ends? | Target metrics follow the target lifecycle and disappear when the target is no longer scraped. | Pushed series remain until explicitly deleted, so cleanup must be managed. |
| What infrastructure is needed? | Prometheus must be able to reach the metrics endpoint. | The job cannot be scraped directly, and a reachable Pushgateway must be available. |
Pull is the normal choice for a small SaaS service. Pushgateway adds a dependency and a lifecycle problem without improving the fit for a process that is already available to scrape. Prometheus’s FAQ says pulling is “slightly better” overall, while cautioning that it should not be the main criterion for choosing a monitoring system. Prometheus FAQ.
How to expose custom metrics from Node.js
The Node.js client linked from Prometheus’s client-library directory is an unofficial third-party client, not a Prometheus-maintained official-language client. Its repository currently calls the package @prometheus-io/client and says it was previously published as prom-client. Confirm current package naming and migration guidance in the Node.js client repository before installing: package names and APIs can change.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Instrument the service process. Create the metrics you need with the client, using counters, gauges, histograms, or summaries as appropriate.
- Expose a scrape endpoint. Return the registry output from an HTTP handler. The client README shows serving
await registry.metrics()in response to scrape requests. - Configure Prometheus to scrape the target. Keep Prometheus able to reach that endpoint; successful scrapes give you the usual target-health signal as well as the metric samples.
The same client can optionally provide default Node.js runtime metrics, including event-loop lag, active handles, garbage-collection data, and Node.js version. Its README notes that some file-descriptor and memory metrics are Linux-only. For a point-in-time value that should be observed during collection, the client documents a collect() callback. These capabilities are documented in the client README.
#1 Best Overall
Choose metric types and labels around operational questions
Start with requests, errors, and latency
For an online-serving API, begin with request or query count, errors, and latency; in-progress requests can also be useful. Keep those observations aligned: Prometheus recommends counting completed queries so count, error, and latency measurements describe the same completed work. For a batch job, useful measures include last success, stage and total runtime, last completion, and job-level totals. See the Prometheus instrumentation guidance.
Match metric type to what changes
- Counter: cumulative events that only increase, except for resets when the process restarts, such as total requests. Use PromQL
rate()to calculate a per-second increase. - Gauge: a current or point-in-time value that can rise or fall, such as in-progress work. Do not apply
rate()to a gauge. - Histogram or summary: distributions such as request duration. They are not interchangeable; choose according to the aggregation and percentile behavior your deployment needs.
Keep label values bounded
Labels multiply time series, so avoid unbounded values such as user IDs and request IDs. Use bounded labels—such as method or status class—only when they answer a real operational question. Prometheus offers a rule of thumb to keep metric cardinality below 10, and to limit metrics that exceed that to a handful across the whole system. It advises investigating alternatives for metrics above 100 or likely to grow that high. These are guidance thresholds, not measured performance limits. Prometheus instrumentation guidance.
If a metric should be visible before its first event, export a known default where appropriate. A labeled series generally cannot be exported before its label values are known; the Node.js client README also documents explicitly zeroing expected label combinations for histograms. See the client README.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteWhen Pushgateway is appropriate—and what it costs
Use Pushgateway when a short-lived job cannot be scraped directly and its service-level result needs to remain available after the process exits. The pushed metric should represent the job outcome, not pretend to be ongoing per-instance service health. For machine-related batch jobs, Prometheus points to the Node Exporter textfile collector rather than Pushgateway. The Pushgateway guidance describes the intended use and limitations.
- Plan deletion and freshness. Pushgateway retains pushed series until they are explicitly deleted. Without deliberate cleanup, old results can outlive the job that produced them.
- Account for the gateway dependency. A shared gateway may become a bottleneck or a single point of failure in the push path.
- Do not treat pushed data as scrape health. The usual per-target
upsignal comes from scraping a target; pushed metrics do not replace that signal. - Reconsider frequent batch work. Prometheus gives jobs running more often than every 15 minutes as an example to consider converting into daemons. This is guidance, not a universal cutoff. Prometheus instrumentation guidance.
The Node.js client documents Pushgateway methods such as push, add, and delete, but client support only establishes that the API exists; it does not make pushing appropriate for a long-running SaaS service. Node.js client repository.
Network access is the real exception to check
Prometheus recommends keeping the server on the same network as monitored instances when possible. If firewalls or NAT prevent scraping, its guidance suggests moving Prometheus behind the network barrier or considering PushProx. A connectivity obstacle should be addressed as an infrastructure design issue rather than assuming Pushgateway is the general replacement for pull. Prometheus Pushgateway guidance.
Rank #4
Use dashboards after collection is working
Prometheus’s FAQ recommends Grafana for production dashboards. It is an optional visualization layer after choosing and configuring metric collection; it does not change whether the Node.js service should expose metrics for scraping or whether a short-lived job needs Pushgateway. Prometheus FAQ.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
