I'm learning Linux system administration and building a RHEL-based application server from scratch during an internship. One requirement is to implement a basic server health check, and I'm trying to understand what experienced administrators normally verify before calling a system healthy.
My initial checklist includes CPU utilization and load average, memory and swap, disk and inode usage, filesystems and mount points, network interfaces, IP configuration, gateway and DNS, external connectivity, critical services such as sshd, chronyd and firewalld, time synchronization, SELinux, firewall state, system logs, package updates and subscription status.
What are the minimum checks every Linux server should have? What additional checks are useful in production? Are there important metrics or best practices that beginners commonly overlook?
5 Answers
Your host-level checklist is a good start, but make sure you also check the services that actually run the application. A web server, application process, database, scheduled job, log forwarder or authentication agent may be more important than a generic process simply being present.
Separate “is the operating system alive?” from “is the application working?” Include an end-to-end check against the real HTTP or HTTPS endpoint, and verify important dependencies such as the database, mounted volumes and external services. A machine can have low CPU and plenty of memory while the application is completely unusable.
For the operating system, also monitor disk I/O and iowait, network errors and dropped packets, recent kernel, OOM and storage errors, and whether filesystems are mounted read/write as expected. Track trends over time too—gradually increasing memory use or rapidly shrinking disk space can be more useful than a single snapshot.
This matters even more with containers or virtual machines, where an undersized guest can be OOM-killed quickly. Include memory pressure and restart events in the checks.
On physical enterprise hardware, include out-of-band management such as IPMI or a vendor platform like iDRAC or iLO. It can independently report fan and temperature problems, power issues, RAID controller health and array status. Sending those events to centralized logging or alerting is useful because some hardware failures are difficult to detect reliably from inside the operating system.
Security and access checks are worth adding: confirm that required security agents, log forwarding and vulnerability or endpoint protection services are running, and verify that centralized authentication can reach its identity servers. Alert on unexpected su or sudo activity and important configuration changes.
For production, use an established monitoring system rather than relying only on a script. The tool is less important than defining checks that reflect the server’s purpose, collecting historical data, and alerting on failures and trends. Periodically review listening ports and the processes behind them so that every exposed service is intentional and monitored.
Do not overlook scheduled work. For cron jobs, verify that expected jobs actually ran and produced a successful result rather than only checking that cron is active. For systemd timers, review the last trigger time and exit status. Application-specific logs, database health, HTTP checks and important background processes should be monitored as well.
Also watch /var/log and especially /var/log/audit on RHEL systems. Bad rotation or an unexpectedly noisy service can fill the filesystem even when the rest of the server looks normal.
Exactly. The meaningful test is whether the service delivers the expected result, not merely whether its process exists. Check that the website returns the correct response, the file share accepts connections, or the database answers queries.