Prometheus and Grafana on a VPS: three metrics worth monitoring
Published on 2026-10-26 by frfrand
CPU, memory, disk, and alerts for production applications
When a website slows down, the number of visits is not enough to explain what happened. Three basic metrics can give you a useful overview: available memory, CPU usage, and disk space. Prometheus collects time series and Grafana presents them.
Let's get down to earth: what it means, how to test it, and what happens when you use it with clients or real information. Most problems are not fixed with a magic button, but with steps you can repeat and measure.
What Prometheus and Grafana are on VPS and why it matters
Prometheus queries metrics exposed by exporters and services, while Grafana builds dashboards and alerts with data sources. For Linux infrastructure, node_exporter is usually used, with access to its endpoint restricted to the monitoring network.
One thing is for a demo to work for five minutes and another is to sustain a service every day. For that you need limits, permissions, activity logs, and procedures to resolve failures without improvising.
Implementation or diagnosis example
# Ejemplo de consultas PromQL, adaptar job/labels
100 * (1 - avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])))
node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100
(node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100
# Reglas/umbrales deben considerar volúmenes y exclusionesIt is a didactic reference, not a template you should blindly run in production. Replace the example values, choose identities with minimum permissions, and make sure no sensitive key ends up in a log or repository.
How I would put it to work
- Install an exporter on the VPS and protect its endpoint; do not open it to the Internet out of habit.
- Configure Prometheus to collect metrics with clear labels per server.
- Create a Grafana panel with CPU, available memory, and disk per volume.
- Add an application signal: HTTP latency, error rate, or job queue.
- Configure actionable alerts and check what information you will receive before a failure.
After each step, verify a concrete result: an authorized action, an HTTP status, a processed task, a recorded cost, or a stable metric. If something does not work, check what the first failure was before retrying in a loop.
An example that may appear in a real project
A FastAPI API handles reservations with Celery. The dashboard shows RAM running out when the worker starts, while PostgreSQL queries remain fast. That data guides you to review task concurrency, not DNS.
If that application has multiple clients, separate contexts and resources. It is especially important when a chatbot or an agent can query data: the ease of connecting tools should not bypass privacy and authorization limits.
The most common mistake
A nice dashboard does not mean there are alerts. Avoid showing exporters without authentication nor registering metrics for each URL with private IDs; they can cause excessive cardinality.
A configuration with good defaults helps, but does not eliminate the need for testing. For services that write data or trigger actions, consider retries, duplicates, and mid-process failures.
Where does ArduMaker fit in?
ArduMaker allows you to manage the VPS and its processes. A metrics layer with Prometheus/Grafana helps to size and detect incidents before users complain.
With ArduMaker you can host the backend on a VPS, deploy from Git, configure an HTTPS domain, and use database, service, and MCP tools according to the project. This makes it easier to bring operations together in one environment, although business rules and security remain the responsibility of the software.
What I would measure to know if it improved
I would not measure only "works/does not work." I would also review resource consumption, errors, response times, or API usage, depending on the functionality. Define a success metric before the change and compare it with the same scenario afterward.
If a piece of data seems strange, check the sample and the time window. An average can hide extreme cases, and a single successful execution does not prove that an automation can handle thousands of requests.
Frequently asked questions
Do I need a large infrastructure to get started? Not necessarily. First solve the problem with a simple architecture and measure the point where it starts to fall short.
What happens if the external provider fails? You need timeouts, a retry policy, and a useful response for the user. Do not assume external APIs are always available.
How do I maintain control? Log important events, separate permissions, and keep a tested procedure to undo changes or recover information.
References to follow
The final idea: automating and measuring is worth it when you also know how to detect an error, limit its effects, and recover.