Your website responds, but its server is running out of disk space. Or requests become slower whenever a background task fills the CPU. Server monitoring helps you connect these observations: what changed on the host, when did it happen, and which resource deserves a closer look?
With MetriBeacon, you can collect readings from your own Linux server, review their history and configure useful alerts. This guide starts with CPU, memory, disk space and the agent's check-in. These signals complement the website monitoring guide rather than proving that every application feature works.
What is server monitoring?
Server monitoring regularly records resource usage and relevant states on a host. A single reading describes one moment. The history helps you recognise recurring load, gradual growth and changes after a deployment.
An HTTP monitor observes the service from outside. The agent observes the machine from inside. A working HTTP response does not mean that the filesystem has enough room for tomorrow's import. Equally, low CPU usage does not prove that your visitors can sign in. Use the observations together.
Four signals to start with
| Signal | Useful question | How to interpret it |
|---|---|---|
| CPU usage | Is the processor busy for longer than usual? | Compare sustained load with the task and its timing |
| Memory usage | Is the workload leaving enough usable memory? | Check the measurement definition, cache and changes over time |
| Filesystem usage | Is the relevant drive filling up? | Check remaining room and how quickly usage grows |
| Last check-in | Is the agent still reporting? | Investigate host, agent, connection and quota state |
Begin with the signals you can act on. Add network traffic or other supported components when you have a concrete question. Detecting a component in inventory does not mean that every possible measurement is automatically enabled.
CPU: a spike is different from sustained load
A short CPU spike during an import may be expected. Repeated high usage together with slow HTTP responses deserves investigation. Look at the same period in both histories and compare it with deployments or scheduled tasks.
CPU percentage and load average are different signals. Do not treat a load-average number as a percentage or assume that a busy processor is automatically a failed server. Monitoring helps you choose where to investigate; it does not determine the cause from one chart.
Memory: low free RAM needs context
Linux uses memory for caches as well as applications. A small amount of completely free RAM alone does not prove a memory problem. Check which quantity the series represents and whether the workload is under pressure.
Linux's MemAvailable estimates memory available for new applications without swapping. The Linux kernel documentation explains this distinction. Different tools can show different memory totals because they use different definitions.
Disk space: monitor the filesystem that matters
A reading for the system drive says little about a separate data volume. Choose the filesystem where your application, uploads or database actually write. An unmounted data drive is also different from an empty drive.
When investigating locally on Linux, these read-only commands show space and inode usage for the root filesystem:
df -h /
df -i /
Replace / with the relevant mounted path. -h makes space values easier to read; -i reports inode usage. A filesystem can run out of inodes while still having free bytes. The GNU documentation for df describes the options. A local diagnostic is an additional observation, not a replacement for the history.
Set up Linux server monitoring with MetriBeacon
1. Choose the host and a clear name
Sign in or create a free account. Select a workspace and open the Server/NAS template. Give the monitor a recognisable name, such as “Web server production”. Use separate monitors for different hosts so an alert identifies the affected machine.
2. Select the first measurements
Start with CPU, memory and the system filesystem. Review the selected components, units and intervals. Add a separate data filesystem when your application uses one. Enable suggested alerts deliberately after checking whether they fit your host.
3. Install and connect the agent
Use the verified download and installation steps in the agent guide. Install on the host you intend to observe, then follow the connection flow for your existing account and selected monitor.
The agent sends data through outgoing HTTPS. You do not need to open an incoming public port for MetriBeacon. Keep its identity and keys private. Optional collectors may require additional local permissions; choose only the checks you need.
4. Confirm the first readings and check-in
Open the monitor and check that the last contact advances and the selected series receive readings. Inspect the unit and timestamp, not just the displayed number. Some measurements need an initial sample before they can report a useful value.
If readings are missing, follow the Linux server guide. On the host, the CLI provides status and diagnostics:
metribeacon status
metribeacon doctor
These examples assume that the installed command is on your PATH. Check the selected components, agent state and local permissions before changing alert thresholds.
Use history to find changes
A useful investigation begins with a time window. If the website slowed down around 09:00, inspect CPU and memory around that time and compare them with the HTTP response-time history. If disk usage grows every night, compare it with scheduled jobs.
Use a range long enough to see the pattern. A minute-level peak and an hourly average answer different questions. Check resolution, data coverage and gaps before concluding that nothing unusual happened.
MetriBeacon supports histories and exports for your series. The history and export guide explains how to select a range and retrieve data. An export gives you the recorded observations; it does not fill an unobserved period with invented values.
Configure alerts with a clear next action
Sustained CPU usage
As an illustrative starting point, you might alert when CPU usage remains above 90 percent for five minutes and clear the alert below 75 percent. These numbers are examples, not universal recommendations. Choose them after observing the workload.
A firing duration filters brief peaks. A separate clearing threshold reduces repeated switching near the boundary. The alert guide explains conditions and delivery.
Growing memory or filesystem usage
Check the series unit before entering a numeric limit. If a field expects bytes, 90 GB means 90000000000 bytes, not the number 90. GB and GiB are different units. Match the threshold to the field and the metric you selected.
For disk space, relate the remaining room to growth and response time: will someone be able to investigate before the drive fills? For memory, choose a limit that fits the host's size and the measurement's meaning. A fixed value copied from another server is rarely a useful default.
Missing check-ins or readings
Enable the contact or missing-data alert you need. A last recorded value may look normal while already being stale. A missing signal can come from the agent, network, host or an exhausted data budget; it is not automatically proof of a host failure.
Connect email or Telegram and send a test notification. Plan maintenance windows for intentional interruptions. Each rule should have an intended recipient and a practical first check.
A practical example: website slow during an import
Suppose your HTTP monitor shows a response-time increase at the same time as a nightly import. The server history also shows elevated CPU usage. These are example observations, not measurements from your own host.
First compare their timestamps. Then inspect the import's duration, local logs and the resources it uses. High CPU is a clue; a database lock or another dependency could still be involved. Check the cron job monitoring guide to observe the task's starts, finishes and missed runs separately.
After making a change, compare a similar time window again. That is more informative than assuming that a single green reading proves the problem is resolved.
Server monitoring FAQ
Is server monitoring with MetriBeacon free?
Yes, within the service's technical quotas. The free monitoring overview lists current limits, and your account shows usage. Select useful series and suitable intervals rather than collecting every possible value.
Do I need an agent for server measurements?
The agent collects local resource readings from your host. A public HTTP check can observe an endpoint without an agent, but it does not measure that server's CPU, RAM or filesystem usage.
Can I monitor a server in a private network?
The agent can send observations through outgoing HTTPS if the host can reach MetriBeacon. The public HTTP checker does not reach private addresses or localhost. These are different collection methods.
What does a missing or unavailable value mean?
Check the agent's diagnostic state, permissions, selected component and timestamp. An unsupported or unavailable measurement is not zero. A data gap is not evidence of a healthy host.
Does server monitoring replace application checks?
Resource usage and contact help explain host behaviour. Add HTTP checks and application-specific observations for the functions your users depend on. A server can have spare capacity while an application operation fails.
Start with one server and a useful baseline
Connect one Linux server, confirm CPU, memory, filesystem readings and contact, then observe its normal workload. Add a few actionable alerts and test their delivery. Expand the profile when an additional measurement helps you answer a real question.
Start server monitoring with a free account, then choose Server/NAS in your workspace. The server monitoring overview explains how local readings, history and alerts work together. The button below opens the Website/API template for an additional HTTP check of your public service.
