Learning AlmaLinux - Cockpit, Monitoring & Web Management

#Introduction

In the previous episode, Episode 10, we dove into the kernel and boot process. Now we shift to how you observe the system every day. There are two worlds here: the visual interface via Cockpit for quick management from the browser, and CLI monitoring commands for deep analysis from the terminal. Great sysadmins master both.

This episode guides you through enabling Cockpit, exploring its feature modules, then practicing the basic monitoring commands that are the universal language of performance troubleshooting.

#Cockpit: The AlmaLinux Web Dashboard

Cockpit is the RHEL family's built-in system management web server. It brings a graphical interface to administrative tasks usually done via the CLI — and can be accessed from any browser on the network.

#Installation and Activation

sudo dnf5 install -y cockpit
sudo systemctl enable --now cockpit.socket
sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload

Note: Cockpit runs as a socket unit (cockpit.socket) — the service is active only when there's a connection. This is a resource-saving pattern typical of systemd. The firewall is opened for the cockpit service (port 9090).

sudo systemctl status cockpit.socket

#Access and Login

Once active, open a browser and go to https://<server-ip>:9090. Log in with a valid system user — users in the wheel group get full administrative rights in the Cockpit UI.

#Cockpit's Main Features

#System Dashboard

The main page shows a summary: real-time CPU, memory, disk, and network traffic usage. For multi-host setups, the Cockpit dashboard can even show several servers at once.

#Service and User Management

• Services — start, stop, restart, and enable systemd units from the UI. Just like systemctl, but with clicks.
• Users — create and edit users, manage groups, and lock accounts — the equivalent of useradd/usermod from episode 6.

#Updates

The Software Updates tab shows packages with available updates and applies dnf5 upgrade from the browser — including applying it again after a reboot.

#Log Viewer

Cockpit's log viewer wraps journalctl in an interface filterable by service and severity — a comfortable visual replacement for quick troubleshooting.

#Modules: Podman and Virtual Machines

Cockpit can be extended with modules:

sudo dnf5 install -y cockpit-podman cockpit-machines

With these modules, Cockpit becomes a single window for services, containers, and VMs — which will be relevant in episode 18.

#Basic Monitoring from the Terminal

Cockpit shows the current state; for analysis and scripting, you need CLI commands. Here are five commands you must master.

#top and htop

top

top shows the top processes by CPU/memory usage, continuously sorted and updated. Press q to quit. htop is a friendlier version:

sudo dnf5 install -y htop
htop

#free

free -h

free -h shows total, used, and available RAM and swap. Watch the available column — that's the realistic number of memory applications can use, not just free.

#df and du

df -h
du -sh /var/log

df -h shows usage per filesystem; du -sh computes the size of one directory — a combination that answers the question "my disk is full, what's big?"

#vmstat

vmstat 2 5

vmstat 2 5 prints statistics (processes, memory, swap, I/O, CPU) every 2 seconds, 5 times. High si/so columns indicate swap thrashing — a sign the system is short on RAM.

#iostat

iostat -x 2

sudo dnf5 install -y sysstat

iostat -x 2 shows disk usage per device every 2 seconds, including %util — the percentage of time the disk is busy. A %util near 100% is a sign of a storage bottleneck.

#journalctl for Troubleshooting

We got to know journalctl in episode 7. The most common troubleshooting pattern:

journalctl -u myapp --since "10 min ago" -p err

This combination of unit, time range, and severity level answers most "why did my service die?" questions without sifting through thousands of raw log lines.

#Common Pitfalls

1. Forgetting to open port 9090 in the firewall. Cockpit looks active but can't be reached — always --add-service=cockpit + --reload.
2. Using free as the only memory gauge. The available column is more accurate for real capacity.
3. Ignoring %util in iostat. This number is the clearest disk bottleneck detector.
4. Guessing without journalctl. Before restarting a service, read its logs first — problems can be prevented, not just patched.
5. Relying on Cockpit as the only tool. Cockpit is great for operations, but CLI understanding is still required for automation and deep debugging.

#Conclusion

In this episode 11 you've gotten to know AlmaLinux's two main observation tools: Cockpit as a web dashboard for managing services, users, updates, logs, and the Podman/KVM modules, plus CLI monitoring commands like top, htop, free, df/du, vmstat, and iostat for diagnostics from the terminal.

Key takeaways:

• Cockpit is accessed at https://<ip>:9090, managed via cockpit.socket, and extended with the podman and machines modules.
• top/htop for processes, free -h for memory (look at the available column).
• df -h for filesystem space, du -sh for directory sizes.
• vmstat detects swapping, iostat -x detects disk bottlenecks.
• journalctl -u <service> --since ... -p err is the most effective troubleshooting pattern.

With the ability to observe, you're ready to manage daily operations. In the next episode, Episode 12, we'll cover Logging, Time Sync & Basic Automation — the journald and rsyslog log flow, logrotate, time synchronization with chrony, and automatic scheduling with cron, systemd timers, and boot analysis with systemd-analyze. See you there!