Lightweight Monitoring for €4/month VPS: Real RAM Benchmark
Performance · · 7 min read
Renting an entry-level VPS on budget cloud providers like Hetzner (CX22 for ~€4/mo) or Scaleway is one of the smartest infrastructure decisions for side projects, bootstrapped startups, and client APIs. For less than the price of a coffee, you receive 1 vCPU and 2 GB of RAM — ample capacity for PostgreSQL, Redis, and a modern backend in Go, Node.js, or Python.
Yet the moment you install an observability stack to keep an eye on uptime and system health, a paradox emerges: monitoring competes for memory with your own applications.
The Out-Of-Memory (OOMKiller) Trap on 2 GB Servers
On a 2 GB VPS, PostgreSQL, Redis and your backend already share most of the memory. Whatever the monitoring stack runs on the same server (a Prometheus with its time-series database, an agent with a Python runtime, or a collector with many modules) comes out of what is left.
Under the first traffic spike, the Linux kernel triggers the OOM Killer, which kills the process using the most memory. That is almost never the metrics agent: it is usually your database or web server.
What We Measured
We measured three agents that collect host metrics: OxiPulse, node_exporter and the OpenTelemetry Collector with the hostmetrics receiver. Each one runs alone, with 60 s of warm-up that is discarded and 300 s measured, on a GitHub Actions ubuntu-24.04 runner (4 vCPU, 16 GB RAM) on 2026-10-10:
| Agent | Private memory (avg) | RSS (avg) | CPU (% of one core) |
|---|---|---|---|
| OxiPulse 0.3.14 | 3.5 MB | 11.4 MB | 0.01% |
| node_exporter 1.12.1 | 10.2 MB | 24.0 MB | 0.04% |
| otelcol-contrib 0.162.0 (hostmetrics) | 41.2 MB | 203.9 MB | 0.06% |
- Private memory (
RssAnon) is the memory the process really owns. RSS also counts shared pages, such as the mapped binary, which is why the Collector's RSS is much larger than its private memory. - Each tool collects a different set of metrics: node_exporter exposes far more series by default. Read the numbers as the cost of a host metrics agent, not as a feature race.
- We did not measure Prometheus (the server), Netdata, Datadog or Telegraf, so we give no numbers for them.
The script and the results are in the benchmark in the OxiPulse repository, so you can run it yourself.
Why OxiPulse Uses So Little
OxiPulse was engineered with a strict principle: a monitoring agent should never steal resources from your production workload.
- No Garbage Collector: Compiled natively in Rust, eliminating runtime pauses and dynamic heap expansion.
- Direct Kernel Pseudo-FS Reads: Pulls metrics directly from
/procand/syswithout intermediate daemon layers. - Offline buffer: If the network drops, it keeps up to 8,640 samples in memory (72 hours at one every 30 s) and resends them with their original timestamps when it comes back. That buffer does take memory: about 20 MB after 72 hours offline.
- Native OTLP export: Sends telemetry as protobuf over OTLP/gRPC (HTTP/2).
Standalone Local Execution (Zero Vendor Lock-In)
OxiPulse is open source under the Apache-2.0 license. You can run it standalone pointing to any generic OTLP collector:
# Point OxiPulse to your own OpenTelemetry Collector, Grafana or SigNoz:
OXIPULSE_ENDPOINT=http://localhost:4317 cargo run --release
On your server it runs as a systemd service, and you can check how much memory it uses at any time:
systemctl status oxipulse
Summary
Monitoring a €4/month server should not cost you licenses that are pricier than the server, nor the memory your applications need.
With OxiPulse, monitoring takes a few megabytes and the rest of the VPS stays with your actual users and code. Connect your first server for free on SecuryBlack.