Do you need a metrics stack, or does the built-in view already answer your question?

There is a step in almost every homelab where somebody sets up a metrics stack, builds beautiful dashboards, and then stops opening them. That is usually read as a discipline failure. It is more often a mismatch: the stack was answering a question nobody was asking.

Alerts and metrics look like the same subject and are not. Alerts answer is something wrong now. Metrics answer what was happening then. Which one you need depends entirely on the questions you actually ask.

The question that decides it

Not "should I monitor my server", because you should. Ask instead: how far back does the answer need to reach?

"Is it broken right now?" The built-in view answers this. Current load, memory, disk usage, which guests are running. Adding a metrics stack for this question adds a service and answers nothing new.

"Was it slow last Tuesday around three in the morning?" Now you need history, and nothing built in keeps it at that resolution for that long. This is the honest reason to run a metrics stack, and it is a good one.

"Will I run out of disk before spring?" You need a trend line, which is history with arithmetic on top. Also a real reason.

"Which of these two changes made it faster?" You need before and after in the same picture. Real reason.

If none of your genuine questions reach past yesterday, a metrics stack is a hobby rather than a tool. That is a fine thing to have, and it is worth knowing which one you are building.

What it costs, honestly

It is another service to keep alive. A metrics stack that has been down for three weeks is worse than none, because you believe you have history and you do not.

It usually runs on the thing it is watching. This is the trap worth naming: when the host has a bad night, the record of that night dies with it. The graph you most want is the one that stopped being written at the moment it got interesting.

Storage grows quietly. Fine-grained metrics from a handful of guests add up faster than people expect, and the growth is invisible until a disk fills.

Dashboards decay. A panel built for a problem you had last year keeps occupying screen space long after that problem was solved.

The two habits that make it worth it

Put the recorder somewhere other than the recorded. Even a small machine elsewhere, even a cheap one. If that is impossible, at least know that your history has the same fate as the host, and treat the graphs as convenience rather than evidence.

Decide retention before resolution. People pick a scrape interval first and discover the storage cost later. The useful order is backwards: decide how far back you need to look, then choose the resolution that fits in the space you are willing to give it. Thirty seconds for a week is usually less useful than five minutes for a year.

What Proxmox already gives you

More than people assume. There is built-in graphing per node and per guest covering processor, memory, network and disk over several time ranges, without installing anything. For a single host with a handful of guests, this covers most of the "was it busy yesterday" questions.

There is also a documented way to push metrics to an external time-series database, which is the supported path when you do decide you need one. That matters: it means the choice is not "hack something together", it is a supported handoff.

What this article is not

Not an argument against Grafana. It is genuinely excellent, and for multiple hosts or long-horizon capacity questions there is no substitute.

Not a claim that dashboards are useless. A dashboard you open weekly is worth ten you built and forgot.

What Atlas does, and what it does not

Atlas is not a metrics stack and does not try to be. It has no time-series database, it does not keep months of fine-grained history, and if your question is "what did the network look like at 03:14 last Tuesday", Atlas is the wrong tool and Grafana is the right one.

What Atlas answers is the other question: does anything here need me today. The daily digest carries unplanned reboots, a kernel installed but not booted, the age of the newest backup, disk and memory pressure, and critical guests that are stopped. Those are yes-or-no answers about the present, not trends about the past.

The one place the two overlap is capacity, and there Atlas stays deliberately shallow: it reports pressure now rather than projecting a curve. If you need the curve, that is a metrics stack, and the honest recommendation is to run one.

The reason to say all this plainly is the same reason the rest of this wiki exists. A tool that tells you what it does not do is easier to trust about what it does.