Hello, I’m Arthur. I was working on a small server project and wanted a simple way to see what was happening on the machine.
I didn't want to install a huge monitoring system just to answer a few basic questions:
Is the CPU getting too high?
How much RAM is left?
Is the disk filling up?
How long has the server been running?
So I decided to make a tiny monitor with Python.
It turned out to be a pretty useful little project.
What We're Building
The script will show:
- CPU usage
- RAM usage
- Disk usage
- Server uptime
- Simple warnings when resources get too high
We'll use Python and the psutil library.
The nice thing is that the same script can run on a Linux VPS, a local machine, or a small cloud server.
Step 1: Install psutil
First, install the library:
pip install psutil
On some Linux systems:
python3 -m pip install psutil
Now create a file called:
server_monitor.py
Step 2: Check CPU Usage
Let's start with something simple:
import psutil
cpu = psutil.cpu_percent(interval=1)
print(f"CPU Usage: {cpu}%")
The interval=1 gives Python one second to calculate CPU usage.
You might see:
CPU Usage: 78.4%
Or on an idle server:
CPU Usage: 8.2%
This is already more useful than guessing whether your server is busy.
Step 3: Check RAM
Now let's check memory:
memory = psutil.virtual_memory()
print(f"RAM Usage: {memory.percent}%")
print(f"Available RAM: {memory.available / (1024 ** 3):.2f} GB")
For example:
RAM Usage: 42.7%
Available RAM: 9.14 GB
One thing worth remembering is that Linux uses memory for caching too.
So don't panic just because RAM usage isn't close to zero.
The important thing is whether your applications have enough memory to work properly.
Step 4: Check Disk Space
Next:
disk = psutil.disk_usage("/")
print(f"Disk Usage: {disk.percent}%")
print(f"Free Space: {disk.free / (1024 ** 3):.2f} GB")
You could get:
Disk Usage: 63.1%
Free Space: 71.82 GB
This is useful because server storage can slowly fill up without you noticing.
Logs, backups, databases, Docker images, and uploaded files can all take space.
Step 5: Check Server Uptime
Here's one of my favorite parts:
import time
import psutil
boot_time = psutil.boot_time()
uptime = time.time() - boot_time
days = int(uptime // 86400)
hours = int((uptime % 86400) // 3600)
minutes = int((uptime % 3600) // 60)
print(f"Uptime: {days} days, {hours} hours, {minutes} minutes")
You might see:
Uptime: 12 days, 7 hours, 31 minutes
Uptime doesn't tell you that a server is healthy by itself, but it gives useful context when troubleshooting.
Step 6: Put Everything Together
Now let's combine everything:
import time
import psutil
cpu = psutil.cpu_percent(interval=1)
memory = psutil.virtual_memory()
disk = psutil.disk_usage("/")
boot_time = psutil.boot_time()
uptime = time.time() - boot_time
days = int(uptime // 86400)
hours = int((uptime % 86400) // 3600)
minutes = int((uptime % 3600) // 60)
print("=== Server Monitor ===")
print(f"CPU Usage: {cpu}%")
print(f"RAM Usage: {memory.percent}%")
print(f"Disk Usage: {disk.percent}%")
print(f"Free Disk: {disk.free / (1024 ** 3):.2f} GB")
print(f"Uptime: {days}d {hours}h {minutes}m")
Run it with:
python3 server_monitor.py
And you now have a basic server monitor in your terminal.
Let's Add Some Warnings
We can make it a little smarter:
if cpu > 80:
print("WARNING: CPU usage is high!")
if memory.percent > 80:
print("WARNING: RAM usage is high!")
if disk.percent > 80:
print("WARNING: Disk usage is high!")
Now the script doesn't just show numbers.
It tells you when something needs attention.
Why Is This Useful?
You might be thinking:
"Why build this when monitoring tools already exist?"
Fair question.
The goal isn't to replace professional monitoring tools.
It's to understand what is happening underneath them.
When you build something small yourself, you start understanding how CPU, memory, storage, and system information are actually collected.
That's useful when you're learning Python, Linux, or DevOps.
One More Thing: Network Traffic
We can also check network activity:
network = psutil.net_io_counters()
print(f"Bytes Sent: {network.bytes_sent / (1024 ** 2):.2f} MB")
print(f"Bytes Received: {network.bytes_recv / (1024 ** 2):.2f} MB")
This gives you the total bytes sent and received.
You can later take two measurements a few seconds apart and calculate the difference to estimate network speed.
That's a nice little challenge if you want to extend the project.
Running It on a VPS
This type of project becomes more interesting when you run it on an actual Linux VPS.
A VPS gives you a remote environment where you can install Python, experiment with Linux commands, run scripts, and keep your project online.
If you're comparing options for a development or testing server, you can check HelloServer VPS hosting and compare the available resources with what your project needs.
For example, a monitoring script doesn't need a massive server. The important thing is choosing resources that match the workload.
Another Useful Project Idea
Once this basic monitor works, you can turn it into something much more useful.
For example, instead of printing:
WARNING: Disk usage is high!
you could make Python send an email when disk usage crosses a limit.
Or you could save the readings to a file:
time,cpu,ram,disk
10:00,21,43,61
10:05,27,45,61
10:10,82,78,62
After collecting this data for a while, you could create a graph and see when your server normally gets busy.
That's when a simple script starts becoming a real monitoring tool.
What I'd Add Next
If I continued building it, I'd add features one at a time:
Version 2
- Monitor specific processes
- Check network speed
- Save readings to CSV
Version 3
- Run automatically
- Send email alerts
- Keep historical data
Version 4
- Create a small web dashboard
- Add graphs
- Monitor multiple servers
You could even run these projects on your own Linux VPS while learning server administration.
Final Thought
The interesting thing about coding isn't always building something huge.
Sometimes a small script can teach you a lot.
This project covers Python, Linux, system resources, monitoring, and automation without needing a complicated setup.
And the best part?
You can change it.
Break it.
Fix it.
Add another feature.
Run it again.
That's usually where the real learning starts.
Top comments (0)