Zabbix è una delle soluzioni di monitoraggio open source più diffuse in ambienti enterprise. In questa guida vedremo cos’è, perché conviene adottarlo e come installarlo su AlmaLinux 9 utilizzando PostgreSQL 17 come database e TimescaleDB per ottimizzare le performance su serie temporali di dati.
La sua architettura consente di monitorare in modo centralizzato
- Server, VM e container (Linux, Windows, VMware, Docker)
- Apparati di rete (switch, router, firewall tramite SNMP, SSH)
- Applicazioni e servizi (database, web server, middleware via agent, JMX, HTTP checks)
- Metriche cloud e ambienti ibridi
Zabbix raccoglie dati attraverso agenti installati sugli host oppure in modalità agentless. Tutti i dati vengono storicizzati nel database e presentati tramite un’interfaccia web, con dashboard personalizzabili, grafici, mappe di rete e un motore di alerting flessibile basato su trigger e azioni automatizzate.
Quale versione scegliere: 7.0 LTS o 7.4
Al momento della stesura di questa guida le versioni attive sono: Zabbix 7.0 LTS e Zabbix 7.4. La scelta dipende dalle priorità del proprio ambiente.
Scegliere Zabbix 7.0 LTS se:
- si sta installando Zabbix in produzione e si ha bisogno di stabilità a lungo termine garantita
- l’organizzazione preferisce aggiornamenti meno frequenti e cicli di rilascio prevedibili
- occorre mantenere la versione allineata con certificazioni o audit di sicurezza
Scegliere Zabbix 7.4 se:
- si vuole accedere alle ultime funzionalità (nuovi widget, miglioramenti al frontend, nuovi template)
- si sta lavorando in un ambiente di laboratorio, sviluppo o si sta avviando una nuova installazione senza vincoli di LTS
- si ha un processo di aggiornamento regolare e non è un problema seguire le minor release
Entrambe le versioni supportano pienamente PostgreSQL 17 e TimescaleDB. I passi di installazione sono identici, con le sole differenze che evidenzieremo nella guida.
Perché PostgreSQL 17 e TimescaleDB
PostgreSQL è il database consigliato per installazioni Zabbix di medie e grandi dimensioni. Rispetto a MySQL/MariaDB offre migliore gestione della concorrenza, supporto nativo per i dati JSON e piena compatibilità con l’estensione TimescaleDB.
TimescaleDB trasforma PostgreSQL in un database ottimizzato per le serie temporali (time-series), tecnologia ideale per i dati generati dal monitoraggio: metriche raccolte a intervalli regolari su migliaia di host. I benefici principali di TimescaleDB sono
- Hypertables: partizionamento automatico dei dati per intervalli temporali, che riduce drasticamente i tempi di query su dati storici
- Compressione nativa: riduzione fino al 90% dello spazio su disco per i dati storici
- Retention policy: gestione automatica della scadenza dei dati
- Query accelerate: prestazioni nettamente superiori su aggregazioni e range temporali
PostgreSQL 17 è la versione major più recente con supporto attivo ed è quella raccomandata negli stack Zabbix aggiornati ad oggi.
Architettura consigliata in produzione
In questa guida installeremo tutti i componenti su un singolo server, configurazione adatta a laboratori, ambienti di test o infrastrutture di dimensioni contenute. In un ambiente di produzione reale, tuttavia, è fortemente consigliabile separare i ruoli su macchine dedicate e affiancare uno o più Zabbix Proxy. Una topologia di riferimento per la produzione prevede almeno tre nodi distinti:
| Nodo | Componenti installati | Motivazione |
|---|---|---|
| DB server | PostgreSQL 17 + TimescaleDB | Isola le risorse I/O e CPU del database. Facilita backup, tuning e scaling indipendente |
| Zabbix server | Zabbix Server + frontend Nginx + Agent | Separare il processo server dal DB riduce la contesa sulle risorse e semplifica la manutenzione |
| Proxy (1+) | Zabbix Proxy + Zabbix Agent | Raccoglie dati localmente e li invia al server in batch, riducendo carico di rete e connessioni sul DB centrale |
Il Zabbix Proxy non è obbligatorio, ma diventa essenziale al crescere dell’infrastruttura. I criteri principali per valutarne l’adozione sono:
- Numero di host monitorati: Zabbix Server può gestire autonomamente diverse migliaia di host con hardware adeguato, ma oltre una certa soglia, indicativamente 500 / 1000 host attivi con polling frequente, distribuire il carico su più proxy diventa consigliabile per mantenere le performance del poller e del trapper
- Distribuzione geografica: Se gli host si trovano in sedi remote, datacenter separati o cloud region differenti, un proxy locale raccoglie i dati autonomamente e li sincronizza con il server centrale. Questo elimina la dipendenza dalla latenza WAN per ogni singola metrica raccolta e garantisce continuità del monitoraggio anche in caso di interruzione temporanea del collegamento verso il server centrale
- Segmentazione di rete: In presenza di firewall, NAT o reti isolate (es. reti OT/SCADA, DMZ, ambienti cloud privati), un proxy posizionato all’interno del segmento raccoglie i dati localmente, richiedendo l’apertura di una sola connessione in uscita verso il Zabbix Server invece di esporre centinaia di agenti verso l’esterno
Il Zabbix Proxy non supporta TimescaleDB come database locale. Per il proxy si utilizza SQLite (piccole installazioni) oppure MySQL/PostgreSQL standard, senza l’estensione TimescaleDB.
Installazione di PostgreSQL 17
Prima di qualsiasi installazione, aggiornare tutti i pacchetti del sistema ed installare alcuni strumenti utili
# Aggiornamento sistema operativo
dnf update -y
# Installazione strumenti utili
dnf install -y vim wget curl net-toolsAlmaLinux 9 include nei propri moduli una versione di PostgreSQL che potrebbe non essere la 17. È necessario quindi utilizzare il repository ufficiale
# Disattivare il modulo PostgreSQL di sistema per evitare conflitti
dnf -qy module disable postgresql
# Installazione del repository ufficiale
dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpmProcediamo ora con l’installazione di PostgreSQL
dnf install -y postgresql17-server postgresql17-contribInizializziamo il cluster e configuriamo il servizio in modo che si avvii automaticamente al riavvio del sistema
/usr/pgsql-17/bin/postgresql-17-setup initdb
systemctl enable postgresql-17 --nowPer concludere, verifichiamo lo stato dell’istanza
systemctl status postgresql-17Installazione di TimescaleDB
Aggiungere il repository ufficiale
tee /etc/yum.repos.d/timescale_timescaledb.repo <<EOL
[timescale_timescaledb]
name=timescale_timescaledb
baseurl=https://packagecloud.io/timescale/timescaledb/el/9/\$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/timescale/timescaledb/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
EOLed procedere con l’installazione dell’estensione TimescaleDB per PostgreSQL 17
dnf install -y timescaledb-2-postgresql-17Il tool timescaledb-tune ottimizza i parametri di PostgreSQL per l’uso con TimescaleDB. Rispondere yes a tutte le domande:
timescaledb-tune --pg-config /usr/pgsql-17/bin/pg_config --max-conns=125Il parametro –max-conns influisce su max_connections in PostgreSQL ed il valore va calcolato in base al proprio ambiente. Per farlo, dobbiamo considerare che le connessioni al database PostgreSQL vengono aperte da tre componenti principali
| Componente | Parametro di riferimento | Note |
|---|---|---|
| Zabbix Server – history syncers | StartDBSyncers impostato in zabbix_server.conf | Ogni syncer è una connessione permanente al DB |
| Zabbix Server – altri processi interni | Stimato in 15 / 20 | Housekeeper, timer, escalator, alert manager, ecc. |
| Zabbix Frontend | Utenti web concorrenti | Ogni sessione attiva apre una connessione |
| Attività di sistema | Stimato in 20 / 30 | pg_dump, monitoraggio PostgreSQL, sessioni amministrative |
La formula pratica è:
max_connections = StartDBSyncers + altri_processi_zabbix + frontend_concorrenti + margine_sicurezza
Configurazione e tuning del WAL
La configurazione del WAL di PostgreSQL è un argomento che merita attenzione dedicata in un’installazione Zabbix: il flusso continuo di INSERT generato dal monitoraggio produce un carico sul WAL molto più intenso rispetto a un database applicativo tradizionale.
I parametri configurabili a caldo che controllano il comportamento del WAL in produzione sono min_wal_size e max_wal_size, che agiscono sulla politica di riciclo e checkpoint dei segmenti. Quindi nel file di configurazione di PostgreSQL
vi /var/lib/pgsql/17/data/postgresql.conf
# Impostare o modificare i seguenti parametri
min_wal_size = 1GB
max_wal_size = 4GBriavviare PostgreSQL per applicare tutte le modifiche
systemctl restart postgresql-17Configurazione del database Zabbix
Accedere alla shell di PostgreSQL come utente postgres
sudo -u postgres psqled eseguire i seguenti comandi SQL per creare l’utenza ed il database
CREATE USER zabbix WITH PASSWORD 'password_sicura';
CREATE DATABASE zabbix OWNER zabbix ENCODING 'UTF8' LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
\qModificare il file pg_hba.conf per aggiungere regole esplicite per l’utente zabbix
vim /var/lib/pgsql/17/data/pg_hba.confAggiungere le due righe specifiche per zabbix prima delle voci generiche host all all, in modo che abbiano priorità. Il file risultante deve apparire così:
# "local" is for Unix domain socket connections only
local all all peer
# Zabbix database access # AGGIUNGERE LE DUE RIGHE SEGUENTI
host zabbix zabbix 127.0.0.1/32 scram-sha-256
host zabbix zabbix ::1/128 scram-sha-256
# IPv4 local connections:
host all all 127.0.0.1/32 scram-sha-256
# IPv6 local connections:
host all all ::1/128 scram-sha-256
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all peer
host replication all 127.0.0.1/32 scram-sha-256
host replication all ::1/128 scram-sha-256e ricaricare la configurazione
systemctl reload postgresql-17Nel caso Database e Zabbix sono su server diversi va specificato nel file pg_hba.conf l’indirizzo IP del server Zabbix
# Zabbix database access from Zabbix Server
host zabbix zabbix 192.168.0.101/32 scram-sha-256Installazione di Zabbix
Possiamo ora passare all’installazione di Zabbix e, come abbiamo visto all’inizio dell’articolo, dobbiamo scegliere se utilizzare la versione 7.0 LTS o la versione 7.4. Iniziamo con l’aggiunta del repository ufficiale
# Zabbix 7.0 LTS
rpm -Uvh https://repo.zabbix.com/zabbix/7.0/alma/9/x86_64/zabbix-release-latest-7.0.el9.noarch.rpm
dnf clean all
# Zabbix 7.4
rpm -Uvh https://repo.zabbix.com/zabbix/7.4/alma/9/x86_64/zabbix-release-latest-7.4.el9.noarch.rpm
dnf clean allSe il repository EPEL è abilitato sul sistema, è necessario escludere i pacchetti Zabbix per evitare conflitti con versioni non ufficiali. Il comando è identico per entrambe le versioni
sed -i 's/\[epel\]/[epel]\nexcludepkgs=zabbix*/' /etc/yum.repos.d/epel.repoAnche il comando di installazione è identico per entrambe le versioni e sarà il repository attivato in precedenza a determinare quale versione verrà installata
dnf install -y \
zabbix-server-pgsql \
zabbix-web-pgsql \
zabbix-nginx-conf \
zabbix-sql-scripts \
zabbix-selinux-policy \
zabbix-agent2Dobbiamo ora importare lo schema del database. Il percorso dello script SQL e il comando di importazione sono identici per entrambe le versioni
zcat /usr/share/zabbix-sql-scripts/postgresql/server.sql.gz | sudo -u zabbix psql zabbixAbilitiamo ora l’estensione TimescaleDB nel database zabbix
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbixed importare il file di configurazione delle hypertable:
cat /usr/share/zabbix-sql-scripts/postgresql/timescaledb/schema.sql | sudo -u zabbix psql zabbixÈ normale ricevere alcuni messaggi di avviso relativi alle best practice su versioni di TimescaleDB 2.9.0 e successive. La configurazione viene completata correttamente nonostante tali avvisi.
Configurazione di Zabbix Server
Modificare il file di configurazione principale
vim /etc/zabbix/zabbix_server.conf
# Impostare i seguenti parametri (o verificarli)
DBHost=localhost
DBName=zabbix
DBUser=zabbix
DBPassword=password_sicuraIl pacchetto zabbix-nginx-conf ha installato un file di configurazione per Nginx. Aprirlo e specificare il server_name e la porta
vim /etc/nginx/conf.d/zabbix.conf
# Decommentare e personalizzare le righe
listen 8080;
server_name zabbix.domain.local;Configurare il timezone PHP nel file php-fpm di Zabbix
vim /etc/php-fpm.d/zabbix.conf
# Impostare il seguente parametro
php_value[date.timezone] = Europe/RomeIl pacchetto zabbix-selinux-policy ha installato le policy necessarie. Se si utilizza PostgreSQL via TCP (con DBHost=localhost), abilitare i booleani SELinux corrispondenti
setsebool -P httpd_can_network_connect on
setsebool -P zabbix_can_network one configurare il firewall aprendo le porte corrispondenti
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-port=8080/tcp
firewall-cmd --permanent --add-port=10051/tcp # Zabbix server (trapper)
firewall-cmd --permanent --add-port=10050/tcp # Zabbix agent
firewall-cmd --reloadProcediamo ad abilitare e riavviare tutti i componenti
systemctl enable --now zabbix-server zabbix-agent2 nginx php-fpm
systemctl restart nginx php-fpm
# Verificare che Zabbix server si sia avviato correttamente
systemctl status zabbix-server
journalctl -u zabbix-server -n 50 --no-pagerCompletamento dell’installazione via web
Aprire il browser e navigare all’indirizzo del server: http://<IndirizzoServer>:8080. La procedura guidata di installazione nell’interfaccia web prevede i passi documentati di seguito
| Avvio del wizard di installazione |  |
| Verificare che siani rispettati i prerequisiti PHP |  |
| Confermare i parametri di connessione al database |  |
| Impostare i dettagli del server Zabbix |  |
| Riepilogo la configurazione prima della conferma |  |
| Esito dell’installazione, completata con successo |  |
| Al termine, accedere con le credenziali di default – Username: Admin – Password: zabbix |  |
Dopo il primo accesso procedere con il cambio della password di default.
Considerazioni finali
L’installazione di Zabbix su AlmaLinux 9 con PostgreSQL 17 e TimescaleDB offre una base solida per il monitoraggio di infrastrutture di qualsiasi dimensione, indipendentemente dalla versione scelta. La combinazione di PostgreSQL e TimescaleDB garantisce scalabilità nel tempo, man mano che il numero di host monitorati cresce e i dati storici si accumulano, le hypertable partizionano automaticamente i dati e la compressione nativa mantiene sotto controllo l’occupazione su disco.
Ora che l’installazione è completata i prossimi passi per l’utilizzo del sistema saranno
- Configurare i template per i sistemi da monitorare (siano essi ufficiali o creati per soluzioni custom)
- Impostare le media type per le notifiche (email, Telegram, …)
- Attivare la compressione TimescaleDB sulle tabelle storiche
- Pianificare un backup regolare del database
- Valutare l’aggiunta di uno o più Zabbix Proxy per ambienti distribuiti o con alta latenza
