What to Monitor in Daily Linux Server Operations: Interpreting Processes, Disks, and Logs

The difficulty in daily operations is not “which commands to use,” but how to interpret the output. Anyone can type top, but knowing whether to panic when you see a load of 15 is what separates experts from beginners.

Below, we cover three categories: processes, disks, and logs, with a focus on interpretation standards.

1. Processes

top
ps aux --sort=-%cpu | head -15
ps aux --sort=-%mem | head -15

What to Look for in top Output

# Core count (to determine if load is high)
nproc

# Zombie processes
ps aux | awk '$8 ~ /Z/ {print}'
# If zombie processes exist, check the parent process; failure to reap them leads to accumulation

A Key Judgment: High CPU or High I/O?

# Check wa (iowait)
top   # Line 3 shows %wa

# More intuitively: check disk utilization
iostat -x 1 3        # If %util approaches 100%, the disk is saturated

If load is high but CPU usage is low → it’s likely I/O wait. This judgment directly determines whether you should optimize code or investigate the disk.

2. Disks

df -h         # Disk space
df -i         # Inodes
du -sh /var/* # Large directories

Three Metrics: Missing One Can Cause Issues

# Find large directories consuming space (step-by-step localization)
du -sh /var/* 2>/dev/null | sort -rh | head -10
du -sh /var/log/* 2>/dev/null | sort -rh | head -10

# Find directories with the most files (useful when inodes are exhausted)
for d in /var/*; do echo "$(find $d -type f 2>/dev/null | wc -l) $d"; done | sort -rn | head

Precautions During Cleanup

# ❌ Directly rm log files that are currently being written to: Space may not be released immediately, and the application might error out.
# ✅ Correct approach: Truncate content without deleting the file
truncate -s 0 /var/log/nginx/access.log

# Or configure logrotate for daily rotation
cat /etc/logrotate.d/nginx

3. Logs

# System logs (systemd-based)
journalctl -p err --since today --no-pager
journalctl -u nginx --since '1 hour ago' --no-pager

# Traditional logs
tail -100 /var/log/messages
tail -100 /var/log/nginx/error.log
tail -100 /var/log/php-fpm/error.log

# Security-related
last | head -20          # Login records
lastb | head -20         # Failed login attempts

How to Read Logs

# High-frequency usage: Errors for a specific service in the last hour
journalctl -u php-fpm --since '1 hour ago' -p err --no-pager

# Count error frequency (to determine if it's a new or recurring issue)
grep -c 'error' /var/log/nginx/error.log
grep 'error' /var/log/nginx/error.log | awk '{print $1, $2}' | uniq -c | tail

Combined Analysis: Common Symptoms and Causes

# For memory, check 'available', not 'free'
free -m
# Linux uses free memory for caching; small 'free' does not mean memory shortage.
# Criterion: Long-term low 'available' + swap usage indicates real pressure.

Decision Tree

Daily Inspection Interpretation
├─ High Load
│  ├─ High %wa   → I/O Bottleneck (Check disk, database)
│  └─ High %CPU  → Use top to find processes
├─ Disk Anomalies
│  ├─ df -h full → Use du to locate step-by-step, configure logrotate
│  ├─ df -i full → Find directories with many files (sessions/cache fragments)
│  └─ High %util → I/O Bottleneck
├─ Memory
│  └─ Check 'available', not 'free' (cache is counted as used)
└─ Service Anomalies
   └─ journalctl -u service_name to check exit reasons

Scenario Walkthrough: The Site Slowed Down Without Configuration Changes

Symptom: A site has become noticeably slower recently, but no configuration changes were made during this period.
Resource usage (CPU and memory) appears normal.

1. First, confirm where the slowness occurs → Timing shows slow Time to First Byte (TTFB),
   indicating the bottleneck is in the server-side content generation process.
2. Since configs weren’t changed, look at “what is growing” →
   Data volume, queued tasks, and accumulated temporary data are all silently increasing.
3. Check for accumulation at the database level →
   Historical versions, temporary data, and log entries piling up cause normally fast queries to slow down.
4. Check if scheduled tasks are backing up →
   A periodic task failing and retrying endlessly consumes resources.
5. Also check disks and logs → If log rotation isn’t configured,
   long-term accumulation affects write performance and may fill up space.
6. After clearing accumulations, re-test timing →
   Re-test with the same set of requests to confirm the root cause.

# Confirm bottleneck layer via timing
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} total=%{time_total}n' https://example.com/

# Database-level accumulation
mysql -e "SELECT table_name, ROUND(data_length/1024/1024) MB FROM information_schema.tables
          WHERE table_schema='db_name' ORDER BY data_length DESC LIMIT 5;"
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_transient_%'" --allow-root

# Task backlog and long-running processes
ps -eo pid,etime,cmd --sort=-etime | head -10
journalctl --since '1 hour ago' | grep -ci 'failed|timeout'

# Log accumulation
du -sh /var/log 2>/dev/null
ls -lh /var/log/*.log | head -5

Root Cause: It wasn’t a config change, but an increase in data volume.
This type of “silent degradation” has no trigger point and is only discovered after users actually perceive the slowness.

Two Key Takeaways:

• When “slower without config changes,” look at what is growing.
  Data volume, task queues, and logs are typical sources of silent growth.
• Daily inspections should focus on trends, not just current values.
  A single normal reading won’t reveal slow degradation; only continuous data comparison allows early detection.

8 Common Pitfalls

1. Ignoring core count for load: Absolute values are meaningless.
2. Checking CPU but ignoring wa: I/O bottlenecks get missed.
3. Only checking df -h but not df -i: Space remains available when inodes are exhausted.
4. Judging memory by the free column: Should check available.
5. Directly rming logs currently being written to: Use truncate or logrotate.
6. Not filtering logs by level: Reading full logs is extremely inefficient.
7. Ignoring zombie processes: Accumulation can exhaust the process table.
8. Not comparing against historical baselines: Impossible to determine what constitutes an anomaly.

Real Customer Feedback (From Cloud Market Reviews and Consultations for Similar Products)

The following excerpts are taken from real buyer reviews and consultations for similar operation and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Cloud Markets (service providers include our store and peers, provided here for reference only, not fictional tickets from our site):

27***97 2020-08-15 5.0 Affordable price | Comprehensive after-sales | Patient and professional Second visit. Good support.

28***05 2021-06-06 5.0 Secure and reliable | Comprehensive after-sales | Skilled technician (User did not fill in comment content) 10***31 2021-06-06 5.0 On-time delivery | Affordable price | Skilled technician (User did not fill in comment content) 10***31 2021-06-05 5.0 Affordable price | Secure and reliable | Comprehensive after-sales Easy to use. Helped me handle several abnormal processes.

10***44 2026-09-09 5.0 Comprehensive features | User-friendly product | Clean interface Easy to use. Supports the latest WordPress 7.1 system.