What Should You Monitor on a Linux Server?

A Linux server can appear perfectly healthy from the outside while problems are developing underneath the surface. A website may still load even though disk space is almost exhausted, memory pressure is increasing, backups have stopped running, or a critical service is repeatedly failing and restarting.

That's why effective Linux server monitoring needs to go well beyond simply checking whether the server responds to a ping or whether the homepage loads.

At AcuNett, we've been administering Linux servers for more than 25 years. Monitoring has always been an important part of keeping those systems reliable because it gives us visibility into what's happening before, during, and after a problem.

So what should you actually monitor on a Linux server? The answer depends on the server's purpose, but there are several areas we consider important in almost every production environment.

1. Server Availability

The most basic monitoring question is also the most important: is the server online?

External availability monitoring can periodically connect to the server from another location and verify that it can be reached.

This can help detect problems involving:

• Server crashes
• Hardware failures
• Network outages
• Firewall problems
• Virtual machine failures
• Data center connectivity

Availability monitoring is an important starting point, but it should never be the only thing being monitored. A server can be online while one or more critical services are unavailable.

2. CPU Utilization

CPU utilization shows how much processing capacity the server is using.

High CPU usage isn't automatically a problem. A server is supposed to use its processors when there's work to be done.

The important questions are how high CPU usage becomes, how long it remains elevated, and whether the behavior is normal for that server.

Persistent high CPU utilization can indicate:

• Increased website or application traffic
• Resource-intensive PHP processes
• Database queries consuming excessive resources
• Runaway processes
• Scheduled jobs
• Software bugs
• Malicious traffic
• Malware or compromised applications
• Insufficient server capacity

Historical CPU data is particularly useful because it helps administrators understand what normal utilization looks like and identify changes over time.

3. System Load

Linux load average is another useful measurement of server activity.

Load averages typically represent activity over the previous 1, 5, and 15 minutes. They provide insight into the amount of work waiting for or using system resources.

However, a load average should never be interpreted without context.

A load of 8 may mean something very different on a 2-core server than it does on a 32-core server. High load can also be caused by more than CPU usage. Processes waiting on disk I/O or other resources can contribute to load as well.

When we investigate high server load, we look at the surrounding conditions rather than treating the load number itself as the diagnosis.

That might include examining:

• CPU utilization
• Disk I/O
• Memory usage
• Running processes
• Database activity
• Network activity

Monitoring tells you that something changed. Linux administration is what determines why it changed.

4. Memory Usage

Memory monitoring is essential, but Linux memory statistics are often misunderstood.

Linux intentionally uses available RAM for caching to improve performance. Seeing a large percentage of memory in use does not necessarily mean the server is running out of memory.

Administrators should look at values such as:

• Total memory
• Available memory
• Application memory consumption
• Cache usage
• Swap utilization

Monitoring memory over time can help identify applications that are consuming increasing amounts of RAM, memory leaks, unexpected processes, or servers that have simply outgrown their current resources.

5. Swap Usage

Swap gives Linux additional virtual memory by allowing portions of memory to be written to disk.

Some swap usage isn't necessarily a problem. Persistent or rapidly increasing swap activity, however, can indicate memory pressure.

Because storage is significantly slower than RAM, excessive swapping can also cause noticeable performance degradation.

If a server begins using much more swap than usual, an administrator should determine why.

The answer may be as simple as adding more memory, but it could also point to a misconfigured application, memory leak, unexpected workload, or another underlying issue.

6. Disk Space

Disk space is one of the most important things to monitor on any Linux server because a full filesystem can quickly create serious problems.

Storage can be consumed unexpectedly by:

• Growing databases
• Website uploads
• Log files
• Temporary files
• Email
• Backup archives
• Application-generated data
• Core dumps

If a critical filesystem reaches 100% utilization, applications may no longer be able to write data. Databases can stop functioning correctly, email queues may stop processing, websites can generate errors, and services may fail.

Disk space alerts should provide administrators enough warning to investigate before the filesystem becomes critical.

7. Inode Usage

Disk capacity isn't the only storage limit that can cause problems.

Linux filesystems also use inodes to store information about files and directories. A filesystem can have available disk space remaining while running out of available inodes because it contains an extremely large number of small files.

This can occur with:

• Session files
• Cache files
• Email storage
• Temporary files
• Application-generated directories

When all available inodes are consumed, the server may be unable to create new files even though the disk appears to have free storage capacity.

For hosting servers and applications that generate large numbers of files, inode monitoring can be just as important as monitoring disk space.

8. Disk I/O and Storage Performance

A server can have plenty of CPU, memory, and free disk space and still perform poorly because its storage system is overloaded.

Disk I/O monitoring can help identify situations where applications are spending excessive time waiting for storage operations.

Heavy disk activity may come from:

• Database workloads
• Backup jobs
• Large file transfers
• Log processing
• Malware scans
• High-traffic applications
• Other virtual machines competing for storage resources

Storage bottlenecks can sometimes appear as high server load even when CPU utilization isn't particularly high.

This is another example of why individual monitoring metrics need to be considered together.

9. Web Server Availability

If a Linux server hosts websites or web applications, the web server should be monitored directly.

Depending on the environment, that might be:

• Apache
• NGINX
• LiteSpeed

The fact that the Linux operating system is online doesn't guarantee that the web server is responding correctly.

Monitoring can check whether HTTP and HTTPS services respond and, in some cases, verify that a particular page returns the expected result.

This can identify situations where the server itself is reachable but websites are unavailable.

10. Database Services

For most dynamic websites and applications, the database is just as important as the web server.

Common Linux database platforms include:

• MySQL
• MariaDB
• PostgreSQL

At a minimum, monitoring should verify that the database service is running and accepting connections.

For more demanding environments, database monitoring may also include:

• Connection usage
• Slow queries
• Query performance
• Replication status
• Database size
• Resource consumption

A database problem can make an application unavailable even while every other service on the server continues running normally.

11. PHP and Application Services

Modern Linux web servers often depend on additional application services beyond the web server itself.

For example, a website may rely on PHP-FPM. A custom application may require a background worker, queue processor, Node.js process, Java service, or another application-specific daemon.

If those processes stop, the server and web server may remain online while the application fails.

Monitoring should therefore reflect the complete application stack rather than only the operating system.

12. Network Connectivity and Traffic

Network monitoring can help administrators identify connectivity problems and unusual traffic patterns.

Depending on the environment, useful information may include:

• Inbound traffic
• Outbound traffic
• Network interface status
• Packet loss
• Latency
• Unexpected bandwidth spikes

A sudden increase in traffic could represent legitimate customer activity, a large file transfer, a backup process, abusive traffic, or an attack.

Historical network data helps provide context when investigating these events.

13. DNS Services

If the server provides authoritative DNS services, those services should be monitored as well.

A website can be functioning perfectly on the server but remain inaccessible to visitors if DNS isn't responding correctly.

DNS monitoring can help identify:

• Unavailable DNS services
• Network connectivity problems
• Incorrect responses
• Configuration problems

For infrastructure using external DNS providers, it may also be useful to monitor critical DNS records from outside the server.

14. Email Services

Linux servers that handle email have several additional services that may need monitoring.

Depending on the mail platform, these may include:

• SMTP
• IMAP
• POP3
• Mail queues
• Spam filtering services

Mail queue monitoring can be particularly useful. A rapidly growing queue can indicate delivery problems, DNS issues, remote server problems, application abuse, or a compromised account sending large amounts of email.

Simply checking that the mail server process is running may not reveal those problems.

15. SSL Certificate Expiration

SSL certificates have expiration dates.

Although certificate renewal is increasingly automated, automated processes can fail because of DNS changes, validation errors, firewall rules, configuration changes, or other issues.

An expired certificate can result in browser security warnings or application connection failures.

Monitoring certificate expiration gives administrators time to investigate renewal problems before users are affected.

16. Backup Status

A failed backup usually doesn't cause an immediate production outage, which makes backup monitoring easy to overlook.

The server keeps running normally even if no successful backup has been created for days.

That becomes a serious problem when a restore is needed.

Backup monitoring should help answer questions such as:

• Did the scheduled backup run?
• Did it complete successfully?
• When was the last successful backup?
• Was the expected amount of data backed up?
• Is there enough backup storage available?
• Are offsite copies being created successfully?

Monitoring backup jobs is important, but periodic restore testing is still necessary. A successful backup notification doesn't guarantee that every required file or database can actually be recovered.

17. Important Log Activity

Linux servers generate a tremendous amount of information through logs.

Logs can provide valuable information about:

• Service failures
• Application errors
• Authentication attempts
• Security events
• Database problems
• Web server errors
• Kernel events
• Resource problems

On a busy server, manually reviewing every log entry isn't practical. Monitoring and log management tools can help identify important patterns, errors, and events that warrant investigation.

Logs are also extremely valuable after an incident because they can help administrators reconstruct what happened and when.

18. Server Time

Accurate system time is easy to take for granted, but it matters to many server functions.

Incorrect time can create problems with:

• Authentication systems
• SSL/TLS connections
• Scheduled jobs
• Distributed applications
• Log analysis
• Database operations

Linux servers should generally synchronize their clocks using an appropriate network time service, and significant time synchronization problems should be investigated.

19. Security and Authentication Activity

Monitoring can also provide visibility into potentially suspicious activity.

Depending on the environment, administrators may watch for:

• Repeated failed login attempts
• Unexpected privileged access
• New administrative users
• Unusual SSH activity
• Unexpected listening services
• Significant firewall events

Security monitoring is a large subject on its own, but operational monitoring and security monitoring often overlap. An unexpected process consuming CPU or a sudden increase in outbound network traffic, for example, could turn out to have a security-related cause.

20. Application-Specific Metrics

Generic server monitoring can tell you a lot about infrastructure health, but business-critical applications may require their own monitoring.

Examples might include:

• Queue depth
• Application response time
• Failed jobs
• API availability
• Transaction failures
• Replication status
• Application-specific background processes

The closer monitoring gets to the actual business function of the server, the more useful it can become.

A server being online isn't particularly helpful if the application your customers need isn't working.

Monitoring Thresholds Need to Match the Server

There isn't one set of alert thresholds that's appropriate for every Linux server.

A database server, web server, mail server, and hosting server may all have very different normal operating conditions.

Thresholds that are too sensitive generate constant alerts for normal activity. Thresholds that are too relaxed may not provide enough warning before a real problem occurs.

Effective monitoring requires establishing a baseline and understanding the normal behavior of the individual server.

For example, a temporary increase in CPU usage might be normal during a nightly job. A similar spike at an unexpected time could deserve investigation.

Avoid Alert Fatigue

A monitoring platform that sends hundreds of meaningless alerts can actually make infrastructure harder to manage.

If administrators become accustomed to alerts that require no action, there's a risk that an important notification will be overlooked.

We prefer monitoring that provides useful, actionable information.

Alerts should be prioritized based on their potential impact. A web server becoming unavailable deserves a different level of urgency than a filesystem reaching an early warning threshold.

Good monitoring isn't about generating the largest possible number of alerts. It's about making sure the right people know when something needs attention.

Monitor Trends, Not Just Emergencies

Monitoring is valuable even when nothing is wrong.

Historical data can reveal trends that help with capacity planning and performance optimization.

For example, you may discover that:

• Disk usage increases by several percent each month
• Database memory requirements are steadily growing
• Traffic has doubled over the past year
• Backup windows are becoming longer
• Peak CPU utilization is gradually increasing

Those trends can help businesses upgrade infrastructure before resource limitations become emergencies.

Monitoring Software Is Only Part of the Solution

There are many excellent server monitoring platforms available. Installing one, however, isn't the same as actively managing a server.

Monitoring can tell you that disk usage reached 95%. It can't always tell you why.

It can tell you that load increased dramatically. It doesn't necessarily know whether the cause is MySQL, a backup process, a traffic spike, disk I/O, a compromised website, or a runaway application.

It can tell you that a service stopped. Someone still needs to determine why it stopped and whether simply restarting it is the correct solution.

That's where experienced Linux administration becomes important.

Monitoring provides the information. An administrator interprets that information, investigates the underlying cause, and determines what action should be taken.

What We Monitor Depends on What Your Server Does

After more than 25 years of Linux server administration, one thing we've learned is that monitoring should be designed around the server rather than the monitoring software.

A basic web server doesn't need exactly the same monitoring as a large database server. A cPanel hosting environment has different requirements from a custom application server. A server processing business transactions may need application-level checks that wouldn't make sense anywhere else.

The right question isn't simply, "Is monitoring installed?"

The better question is, "Are we monitoring the things that could affect this server and the business services running on it?"

24/7 Linux Server Monitoring from AcuNett

At AcuNett, we've been managing Linux servers for more than 25 years. Our server monitoring services are designed to provide visibility into the resources and services businesses depend on while giving our Linux administrators the information they need to respond when problems occur.

We can monitor server availability, system resources, disk utilization, critical services, databases, websites, SSL certificates, backups, and other important components of your Linux infrastructure.

More importantly, our monitoring is backed by experienced Linux administrators who can investigate what an alert actually means and help correct the underlying problem.

Whether you're running a single production server, a VPS, a dedicated server, or a larger Linux environment, AcuNett can help you build a monitoring strategy around the systems that matter most to your business.