Monitoring and troubleshooting with the web console

The idea

The web console (Cockpit) is a browser interface for one or more RHEL machines. It is not a separate management system: every page calls the tools you already know (systemctl, journalctl, nmcli, lvm, dnf), so what it shows is what the command line would show. Its value in troubleshooting is speed and history: logs, services, graphs and a terminal in one tab, and, when metrics are recorded, graphs of a problem that already ended.

How it works matters when it does not:

• cockpit.socket listens on TCP port 9090. systemd holds the socket and starts cockpit.service (the cockpit-ws web server) only when someone connects, so an idle console uses no memory. That is why ss shows systemd as the listener.
• You log in with a normal system account (the login goes through PAM, see the PAM skill). The account needs sudo rights to use the Administrative access switch; without it the console is read-only.
• A self-signed certificate is created at first start. A browser warning is expected; a certificate you provide goes in /etc/cockpit/ws-certs.d/ as a .cert file, and the last file alphabetically is used.
• The page set depends on installed packages: cockpit (core, logs, services, terminal, networking, accounts, updates), cockpit-storaged (disks, LVM, LUKS, NFS), cockpit-pcp (metrics history), cockpit-podman (containers). Install what you need, then reload the browser.

What to use it for

Page	Troubleshooting use	Command equivalent
Overview	Health, CPU/memory graphs, configuration issues such as SELinux alerts	top, sestatus, systemctl --failed
Metrics and history	CPU, memory, disk I/O, network over time, including hours ago	sar, pmrep
Logs	Filter by time, priority and unit; click an entry for its fields	journalctl -p err -u UNIT --since
Services	Start, stop, enable units; timers; failed units; unit file and its logs	systemctl, systemctl cat
Storage	Disk activity graphs, mount state, LVM, LUKS, NFS	iostat, lsblk, lvs, cryptsetup
Networking	Interfaces, traffic graphs, firewall zones	ip, nmcli, firewall-cmd
Terminal	A shell in the browser, same account	ssh

History needs a collector

The live graphs work immediately. History (what happened at 03:10 last night) exists only if Performance Co-Pilot is recording. cockpit-pcp pulls in the packages; pmlogger is the service that writes archives under /var/log/pcp/pmlogger/HOSTNAME/. The first time you open the metrics page it offers to enable it, but on the exam, and in practice, enable it deliberately.

Try it

sudo dnf install -y cockpit
sudo systemctl enable --now cockpit.socket
sudo firewall-cmd --permanent --add-service=cockpit
sudo firewall-cmd --reload
sudo ss -tlnp | grep 9090

LISTEN 0      4096               *:9090            *:*    users:(("systemd",pid=1,fd=33))

Browse to https://node1.lab.example:9090, accept the certificate warning and log in as alex.

sudo dnf install -y cockpit-pcp
sudo systemctl enable --now pmlogger
systemctl is-active pmlogger
ls /var/log/pcp/pmlogger/$(hostname)/ | head -3

active
20261104.10.15.0.xz
20261104.10.15.index
20261104.10.15.meta.xz

Open Overview, then View metrics and history. Choose a time range such as 1 hour; the vertical cursor shows the exact CPU, memory, disk and network values at that moment.

Logs and services

The Logs page has the same filters as journalctl: a time range, a priority (Errors and worse equals -p err), a unit and free text. Click an entry to see its fields (_PID, _SYSTEMD_UNIT, SYSLOG_IDENTIFIER), the same data as journalctl -o verbose.

journalctl -p err -b --no-pager | tail -3
systemd-run --unit=demo-fail /bin/false
systemctl status demo-fail --no-pager | sed -n 1,4p

Nov 04 10:20:11 node1 systemd[1]: Failed to start tuned.service - Dynamic System Tuning Daemon.
Running as unit: demo-fail.service
× demo-fail.service - /usr/bin/false
     Loaded: loaded (/run/systemd/transient/demo-fail.service; transient)
     Active: failed (Result: exit-code) since Wed 2026-11-04 10:21:02 +03; 1s ago

The Services page lists demo-fail.service under Failed; its detail page shows the same status text and the unit’s logs.

When the console itself will not open

Symptom	Check	Fix
Browser: connection refused / timeout	systemctl status cockpit.socket; ss -tlnp | grep 9090	Enable and start the socket
Timeout only from other hosts	firewall-cmd --list-services	--permanent --add-service=cockpit, reload
Login rejected with correct password	journalctl -u cockpit, /var/log/secure	Locked account or PAM policy: see the PAM skill
Pages missing (no Storage, no Metrics)	rpm -q cockpit-storaged cockpit-pcp	Install the package, reload the page
“Limited access” banner	The account has no sudo rights	Add the user to wheel, log in again
Metrics history empty	systemctl status pmlogger	Enable pmlogger; history starts from then, not retroactively
Port 9090 changed or blocked by SELinux	semanage port -l | grep 9090	Port type websm_port_t must include the port in use

Going further

Beyond the exam. The console can manage several machines from one tab (it connects over SSH with your key), and cockpit-podman manages containers. Neither is an exam topic. A common professional pattern is to leave the console enabled only on a management network: allow the cockpit service in a dedicated firewall zone bound to that interface instead of in public.