Installing and Configuring Prometheus on CentOS for System Monitoring
Operating servers that serve customers from Sydney to Perth means downtime is costly and visibility is essential. Prometheus has become a go-to monitoring platform for Australian sysadmins because it handles time-series data efficiently, integrates with Alertmanager, and runs well on RHEL-family distributions. This guide walks through the full install and configuration of Prometheus on CentOS, from system preparation to verifying that metrics land correctly.
You will see how to lay down the binaries, write a systemd unit, shape the main configuration file, and attach node exporters so CPU, memory, and disk metrics flow into the platform. Whether you run CentOS Stream 9 in a local data centre or an instance in the ap-southeast-2 region, the steps below apply with only minor path adjustments.
Preparing the CentOS Environment
Before pulling down any package, refresh the base system and install the utilities you will need for verification. A fresh CentOS image in Australia usually arrives with firewalld enabled and SELinux enforcing, so the commands below assume that default. Update first, then add the tools:
sudo dnf update -y
sudo dnf install -y wget tar curl
Create a dedicated user so the daemon does not run as root, then open the ports Prometheus and its exporters will use:
sudo useradd --no-create-home --shell /sbin/nologin prometheus
sudo firewall-cmd --permanent --add-port=9090/tcp
sudo firewall-cmd --reload
If the host already serves web traffic, watch for port conflicts. An admin who has spent time on configuring Apache virtual hosts on RHEL 9 will already know how SELinux labels can affect new services, so factor that into your firewall and policy decisions.
Downloading and Setting Up Prometheus
Grab the latest stable release from the official Prometheus site and unpack it under /opt, where long-lived services commonly live on CentOS:
cd /tmp
wget https://github.com/prometheus/prometheus/releases/download/v2.48.0/prometheus-2.48.0.linux-amd64.tar.gz
tar xzf prometheus-2.48.0.linux-amd64.tar.gz
sudo mv prometheus-2.48.0.linux-amd64 /opt/prometheus
Hand ownership of the binaries and configuration directory to the dedicated user so the service can read its files without elevated privileges:
sudo chown -R prometheus:prometheus /opt/prometheus
sudo mkdir -p /etc/prometheus
sudo mv /opt/prometheus/prometheus.yml /etc/prometheus/
sudo chown -R prometheus:prometheus /etc/prometheus
If you plan to expose the Prometheus UI behind Nginx, the setting up a reverse proxy with Nginx on RHEL walkthrough covers the proxy and TLS pieces in more detail.
Choosing Exporters for Common Workloads
Prometheus itself only reports on its own internals. To collect host-level data, you need exporters running on the machines you want to monitor. The node exporter is the most common starting point and works on any RHEL-family distribution. Picking the right exporter early saves you from rewriting scrape configs later.
Compare the most common exporters before deciding what to deploy:
| Metric | Node Exporter | Blackbox Exporter | HAProxy Exporter |
|---|---|---|---|
| Primary use | Host hardware and OS metrics | Endpoint and TCP probes | Load balancer stats |
| Default port | 9100 | 9115 | 9101 |
| Authentication | None by default | None by default | Optional |
| Typical target | Every server | Public endpoints | Reverse proxies |
Common exporter ports to remember:
- 9100: node exporter
- 9115: blackbox exporter
- 9101: HAProxy exporter
- 9121: Redis exporter
Install the node exporter on each host you want to monitor, add it to the prometheus.yml scrape config, and restart the service. The /targets page will then show whether each endpoint is UP.
Configuring Prometheus Core Settings
The main configuration file lives at /etc/prometheus/prometheus.yml. It defines the scrape interval, evaluation interval, and the list of targets Prometheus will poll. A minimal but production-ready example looks like this:
global:
scrape_interval: 15s
evaluation_interval: 15s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node'
static_configs:
- targets: ['localhost:9100']
For Australian operators, a 15-second scrape interval is a reasonable trade-off between granularity and storage growth, particularly when running across multiple availability zones. Adjust the retention flag later if you need longer history.
Core configuration knobs worth remembering:
scrape_interval: how often targets are polledevaluation_interval: how often recording rules fire--storage.tsdb.retention.time: how long samples are kept--web.external-url: useful when running behind a proxy
Starting Prometheus and Verifying Targets
A systemd unit file makes the daemon survive reboots and integrates with the rest of CentOS. Place the following at /etc/systemd/system/prometheus.service:
[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target
[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/opt/prometheus/prometheus \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.path=/opt/prometheus/data
[Install]
WantedBy=multi-user.target
Reload systemd, then enable and start the service:
sudo systemctl daemon-reload
sudo systemctl enable --now prometheus
sudo systemctl status prometheus
You can verify the service is listening by running ss -tlnp | grep 9090 from the host. From an Australian workstation, point a browser at http://<server-ip>:9090 to see the expression browser and confirm targets are being scraped. If you want mobile dashboards during a local incident, a Jetpack Compose primer is handy for native UI work, though Prometheus's own web UI covers most ad-hoc queries.
Once scrapes return data, the /query endpoint accepts PromQL expressions such as node_cpu_seconds_total{mode="idle"} to chart CPU idle time across the fleet.
Keep /etc/prometheus under version control, watch disk usage on the TSDB path, and revisit scrape configs whenever a new service joins the fleet. Retention settings and alert rules deserve the same disciplined review, because what you forget to monitor today is exactly what pages you at 03:00 AEST tomorrow.