Il server esegue il polling e la ricezione dei dati, calcola i trigger, invia notifiche agli utenti. È il componente centrale a cui gli agent e i proxy Zabbix riportano i dati sulla disponibilità e sull'integrità dei sistemi. Il server può anche controllare da remoto i servizi di rete (come web server e mail server) utilizzando semplici controlli dei servizi.

Il server è il repository centrale in cui vengono memorizzati tutti i dati di configurazione, statistici e operativi, ed è l'entità di Zabbix che avviserà attivamente gli amministratori quando si verificano problemi in uno qualsiasi dei sistemi monitorati.

Il funzionamento di un server Zabbix di base è suddiviso in tre componenti distinti; essi sono: Zabbix server, web frontend e archiviazione del database.

Tutte le informazioni di configurazione di Zabbix sono memorizzate nel database, con cui interagiscono sia il server sia il web frontend. Ad esempio, quando si crea un nuovo item utilizzando il web frontend (o API), esso viene aggiunto alla tabella items nel database. Successivamente, circa una volta al minuto, Zabbix server interroga la tabella items per ottenere un elenco degli item attivi, che viene poi memorizzato in una cache all'interno di Zabbix server. Per questo motivo, possono essere necessari fino a due minuti prima che eventuali modifiche apportate nel frontend di Zabbix vengano visualizzate nella sezione dati più recenti.

Eseguire il server

Se installato come pacchetto

Zabbix server viene eseguito come processo daemon. Il server può essere avviato eseguendo:

systemctl start zabbix-server

Questo funzionerà sulla maggior parte dei sistemi GNU/Linux. Su altri sistemi potrebbe essere necessario eseguire:

/etc/init.d/zabbix-server start

Analogamente, per arrestare/riavviare/visualizzare lo stato, utilizzare i seguenti comandi:

systemctl stop zabbix-server
systemctl restart zabbix-server
systemctl status zabbix-server

Avvio manuale

Se quanto sopra non funziona, è necessario avviarlo manualmente. Individuare il percorso del binario zabbix_server ed eseguire:

zabbix_server

Con Zabbix server è possibile utilizzare i seguenti parametri della riga di comando:

-c --config <file>              percorso del file di configurazione (il valore predefinito è /usr/local/etc/zabbix_server.conf)
-f --foreground                 esegui Zabbix server in primo piano
-R --runtime-control <option>   esegui funzioni amministrative
-T --test-config                convalida il file di configurazione ed esci
-h --help                       mostra questo aiuto
-V --version                    visualizza il numero di versione

Esempi di esecuzione di Zabbix server con parametri della riga di comando:

zabbix_server -c /usr/local/etc/zabbix_server.conf
zabbix_server --help
zabbix_server -V

Controllo di runtime

Opzioni di controllo di runtime:

Option	Description	Target
config_cache_reload	Ricarica la cache di configurazione. Ignorato se la cache è attualmente in fase di caricamento.
history_cache_clear=target	Cancella la cache della cronologia per l'item specificato dal suo ID. Influisce su tutti i valori dell'item, eccetto il primo e l'ultimo valore.	target - ID dell'item
diaginfo[=<section>]	Raccoglie informazioni diagnostiche nel file di log del server.	historycache - statistiche della cache della cronologia valuecache - statistiche della cache dei valori preprocessing - statistiche del manager di preprocessing alerting - statistiche dell'alert manager lld - statistiche del manager LLD locks - elenco dei mutex (vuoto sui sistemi BSD) connector - statistiche per i connettori con la coda più grande
ha_status	Registra lo stato del cluster ad alta disponibilità (HA).
ha_remove_node=target	Rimuove il nodo ad alta disponibilità (HA) specificato dal suo nome o ID. Si noti che i nodi attivi/in standby non possono essere rimossi.	target - nome o ID del nodo (può essere ottenuto eseguendo ha_status)
ha_set_failover_delay=delay	Imposta il ritardo di failover dell'alta disponibilità (HA). I suffissi temporali sono supportati, ad esempio 10s, 1m.
proxy_config_cache_reload[=<target>]	Ricarica la cache di configurazione del proxy.	target - elenco di nomi di proxy separati da virgole Se target non è specificato, ricarica la configurazione per tutti i proxy
secrets_reload	Ricarica i segreti da Vault.
service_cache_reload	Ricarica la cache del service manager.
snmp_cache_reload	Ricarica la cache SNMP — cancella le proprietà del motore SNMP (engine time, engine boots, engine id, credenziali) per tutti gli host. Usare per forzare una cancellazione globale della cache durante la risoluzione dei problemi SNMP.
housekeeper_execute	Avvia la procedura di housekeeping. Ignorato se la procedura di housekeeping è attualmente in corso.
trigger_housekeeper_execute	Avvia la procedura di housekeeping dei trigger. Ignorato se la procedura di housekeeping dei trigger è attualmente in corso.
log_level_increase[=<target>]	Aumenta il livello di log; influisce su tutti i processi se target non è specificato. Non supportato sui sistemi BSD.	process type - Tutti i processi del tipo specificato (ad esempio, poller) Vedere tutti i tipi di processo del server. process type,N - Tipo di processo e numero (ad esempio, poller,3) pid - Identificatore di processo (da 1 a 65535). Per valori maggiori, specificare target come 'process type,N'.
log_level_decrease[=<target>]	Diminuisce il livello di log; influisce su tutti i processi se target non è specificato. Non supportato sui sistemi BSD.
prof_enable[=<target>]	Abilita la profilazione. Influisce su tutti i processi se target non è specificato. La profilazione abilitata fornisce dettagli di tutti i rwlock/mutex per nome funzione.	process type - Tutti i processi del tipo specificato (ad esempio history syncer) Tipi di processo supportati come target di profilazione: alerter, alert manager, availability manager, configuration syncer, discovery manager, escalator, history poller, history syncer, housekeeper, http poller, icmp pinger, ipmi manager, ipmi poller, java poller, lld manager, lld worker, odbc poller, poller, preprocessing manager, preprocessing worker, proxy poller, self-monitoring, service manager, snmp trapper, task manager, timer, trapper, unreachable poller, vmware collector process type,N - Tipo di processo e numero (ad esempio, history syncer,1) pid - Identificatore di processo (da 1 a 65535). Per valori maggiori, specificare target come 'process type,N'. scope - `rwlock`, `mutex`, `processing` possono essere usati con il tipo e il numero di processo (ad esempio, history syncer,1,processing) oppure con tutti i processi del tipo (ad esempio, history syncer,rwlock)
prof_disable[=<target>]	Disabilita la profilazione. Influisce su tutti i processi se target non è specificato.	process type - Tutti i processi del tipo specificato (ad esempio history syncer) Tipi di processo supportati come target di profilazione: vedere `prof_enable` process type,N - Tipo di processo e numero (ad esempio, history syncer,1) pid - Identificatore di processo (da 1 a 65535). Per valori maggiori, specificare target come 'process type,N'.

Esempio di utilizzo del controllo runtime per ricaricare la cache di configurazione del server:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload

Esempi di utilizzo del controllo runtime per ricaricare la configurazione del proxy:

# Ricarica la configurazione di tutti i proxy:
zabbix_server -R proxy_config_cache_reload

# Ricarica la configurazione di Proxy1 e Proxy2:
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

Esempio di utilizzo del controllo runtime per svuotare la cache della cronologia per un item:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243

Esempi di utilizzo del controllo runtime per raccogliere informazioni diagnostiche:

# Raccoglie tutte le informazioni diagnostiche disponibili nel file di log del server:
zabbix_server -R diaginfo

# Raccoglie le statistiche della cache della cronologia nel file di log del server:
zabbix_server -R diaginfo=historycache

Esempio di utilizzo del controllo runtime per ricaricare la cache SNMP:

zabbix_server -R snmp_cache_reload

Quando un'interfaccia SNMPv3 viene aggiornata tramite la UI di Zabbix, Zabbix ricarica automaticamente le nuove credenziali SNMPv3 per tale interfaccia nella maggior parte dei casi; utilizzare -R snmp_cache_reload solo se il polling continua a non riuscire dopo le modifiche alle credenziali (ad esempio, a causa di incongruenze di engineBoots/engineID o di dispositivi non RFC), oppure quando è necessario forzare una cancellazione globale della cache SNMP per la risoluzione dei problemi.

Esempio di utilizzo del controllo runtime per attivare l'esecuzione di housekeeper:

zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute

Esempi di utilizzo del controllo runtime per modificare il livello di log:

# Aumenta il livello di log di tutti i processi:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase

# Aumenta il livello di log del secondo processo poller:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2

# Aumenta il livello di log del processo con PID 1234:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234

# Diminuisce il livello di log di tutti i processi http poller:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

Esempio di impostazione del ritardo di failover HA al minimo di 10 secondi:

zabbix_server -R ha_set_failover_delay=10s

Utente del processo

Zabbix server è progettato per essere eseguito come utente non root. Verrà eseguito come qualsiasi utente non root con cui viene avviato. Quindi è possibile eseguire il server come qualsiasi utente non root senza alcun problema.

Se si tenta di eseguirlo come 'root', passerà a un utente 'zabbix' codificato in modo statico, che deve essere presente nel sistema. È possibile eseguire il server come 'root' solo se si modifica di conseguenza il parametro 'AllowRoot' nel file di configurazione del server.

Se Zabbix server e l'agent vengono eseguiti sulla stessa macchina, si consiglia di utilizzare un utente diverso per eseguire il server rispetto a quello usato per eseguire l'agent. Altrimenti, se entrambi vengono eseguiti con lo stesso utente, l'agent può accedere al file di configurazione del server e qualsiasi utente di livello Admin in Zabbix può recuperare abbastanza facilmente, ad esempio, la password del database.

File di configurazione

Per i dettagli sulla configurazione di zabbix_server, vedere le opzioni del file di configurazione.

Script di avvio

Gli script vengono utilizzati per avviare/arrestare automaticamente i processi di Zabbix durante l'avvio/arresto del sistema. Gli script si trovano nella directory misc/init.d.

Tipi di processi e thread del server

agent poller - processo poller asincrono per controlli passivi con un thread worker
alert manager - gestore della coda degli avvisi
alert syncer - processo di scrittura degli avvisi nel DB
alerter - processo per l'invio delle notifiche
availability manager - processo per gli aggiornamenti della disponibilità degli host
browser poller - poller per i controlli degli item del browser
configuration syncer - processo per la gestione della cache in memoria dei dati di configurazione
configuration syncer worker - processo per la risoluzione e la sincronizzazione dei valori delle macro utente nei nomi degli item
connector manager - processo manager per i connettori
connector worker - processo per la gestione delle richieste dal connector manager
discovery manager - processo manager per il discovery dei dispositivi
discovery worker - processo per la gestione delle attività di discovery dal discovery manager
escalator - processo per l'escalation delle azioni
ha manager - processo per la gestione dell'alta disponibilità
history poller - processo per la gestione dei controlli calcolati che richiedono una connessione al database
history syncer - processo di scrittura dello storico nel DB
housekeeper - processo per la rimozione dei dati obsoleti (storico e trend degli item, sessioni utente, eventi, ecc.), nonché dei dati lasciati da oggetti eliminati
http agent poller - processo poller asincrono per controlli HTTP con un thread worker
http poller - poller per il monitoraggio web
icmp pinger - poller per i controlli icmpping
internal poller - poller per i controlli interni
ipmi manager - manager del poller IPMI
ipmi poller - poller per i controlli IPMI
java poller - poller per i controlli Java
lld manager - processo manager delle attività di low-level discovery
lld worker - processo worker delle attività di low-level discovery
odbc poller - poller per i controlli ODBC
poller - poller normale per i controlli passivi
preprocessing manager - manager delle attività di preprocessing con thread worker di preprocessing
preprocessing worker - thread per il preprocessing dei dati
proxy poller - poller per proxy passivi
proxy group manager - manager del bilanciamento del carico dei proxy e dell'alta disponibilità
report manager- manager delle attività di generazione pianificata dei report
report writer - processo per la generazione dei report pianificati
self-monitoring - processo per la raccolta delle statistiche interne del server
service manager - processo per la gestione dei servizi ricevendo informazioni su problemi, tag dei problemi e ripristino dei problemi da history syncer, task manager e alert manager
snmp poller - processo poller asincrono per controlli SNMP con un thread worker (solo item walk[OID] e get[OID])
snmp trapper - trapper per trap SNMP
task manager - processo per l'esecuzione remota di attività richieste da altri componenti (ad esempio, chiusura problema, riconoscimento problema, controllo immediato del valore di un item, funzionalità di comando remoto)
timer - timer per l'elaborazione delle maintenance
trapper - trapper per controlli attivi, trap, comunicazione proxy
trigger housekeeper - processo per la rimozione di problemi ed eventi generati da trigger che nel frattempo sono stati eliminati
unreachable poller - poller per dispositivi non raggiungibili
vmware collector - collettore di dati VMware responsabile della raccolta dei dati dai servizi VMware

Il file di log del server può essere utilizzato per osservare questi tipi di processi.

Il file di log del server viene creato con permessi di lettura-scrittura solo per il proprietario del file. Inoltre, il file è leggibile dal gruppo proprietario. Tutti gli altri permessi sono negati.

Vari tipi di processi del server Zabbix possono essere monitorati utilizzando l'item interno zabbix[process,<type>,<mode>,<state>] item.

Statistiche delle transazioni del history syncer

Il titolo del processo history syncer visualizza statistiche dettagliate sulle transazioni del history syncer:

205182 ?        S      0:00  zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
205183 ?        S      0:00  zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
205184 ?        S      0:00  zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]

In "A+B triggers":

A - trigger elaborati a causa dei valori della history;
B - trigger elaborati a causa dei timer.

I tempi, in "processed...in N (<timings>) sec", sono:

Tempo impiegato per scrivere i valori degli item nel database;
Tempo impiegato per aggiornare i dati degli item (stato, errori, inventario host, ecc.);
Tempo impiegato per scaricare i trend nel database;
Tempo impiegato per calcolare i trigger;
Tempo impiegato per elaborare eventi e azioni.

Procedura di housekeeping

Il processo housekeeper rimuove periodicamente i dati obsoleti (storico e trend degli item, sessioni utente, eventi, ecc.), nonché i dati lasciati da oggetti eliminati. Viene eseguito in cicli, con frequenza e limite di eliminazione per ciclo determinati da HousekeepingFrequency e MaxHousekeeperDelete. Tutti i dati non rimossi in un ciclo vengono riportati al ciclo successivo. L'housekeeping automatico può essere abilitato e configurato in Administration > Housekeeping.

Per rimuovere i dati lasciati da oggetti eliminati, il processo housekeeper si basa sui task della tabella housekeeper, che viene popolata ogni volta che un oggetto viene eliminato. Ad esempio, quando elimini un host, Zabbix elimina anche i suoi item, ma non il loro storico, i trend o i problemi. Invece, i trigger del database popolano la tabella housekeeper con task costituiti da questi campi:

housekeeperid - ID del task
object - tipo di oggetto (0 - item; 1 - trigger; 2 - servizio; 3 - host rilevato; 4 - servizio rilevato)
objectid - ID dell'oggetto (aiuta l'housekeeper a trovare i dati correlati all'oggetto)

Ad esempio, l'eliminazione di un host con due item e un trigger popola la tabella housekeeper come segue:

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

I trigger del database popolano la tabella housekeeper senza verificare la presenza di dati correlati all'oggetto; tale verifica viene eseguita dal processo housekeeper.

Ogni task produce una o più operazioni di housekeeper che dipendono dal tipo di oggetto:

Per gli item (incluse le regole LLD) - rimuove i dati da tutte le tabelle di storico e trend (history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint) che contengono valori per quegli item. Inoltre, controlla la tabella problems e rimuove gli eventi interni obsoleti associati a quegli item.
Per i trigger - controlla le tabelle correlate agli eventi (problem, event_symptom, event_recovery, events) e rimuove gli eventi obsoleti associati a quei trigger, notificando inoltre il processo service manager degli eventi rimossi.

Un processo trigger housekeeper separato gestisce un'attività più specifica: rimuovere problemi ed eventi che non hanno un trigger sorgente noto. La frequenza di esecuzione è controllata da ProblemHousekeepingFrequency.

Fino all'avvio della procedura di housekeeping dei trigger, i problemi causati da trigger che nel frattempo sono stati eliminati potrebbero comunque generare problemi di servizio e assegnarli ai servizi. Se la tua configurazione include molte regole di calcolo dello stato dei servizi basate su trigger rilevati/non più rilevati frequentemente, valuta di aumentare la frequenza della procedura di housekeeping modificando il parametro di configurazione del server ProblemHousekeepingFrequency.

Per i servizi - controlla la tabella problems e rimuove gli eventi di servizio obsoleti, nonché i problemi di servizio obsoleti, risolvendoli quindi al momento dell'housekeeping.
Per il rilevamento di rete - rimuove gli eventi di discovery obsoleti dalla tabella problems.

L'housekeeper rimuove solo gli eventi che non sono associati a problemi. Ad esempio, un evento obsoleto di problema/ripristino non verrà rimosso se è associato a un problema aperto. Quando l'housekeeper rimuove entità obsolete, rimuove prima i problemi e poi gli eventi.

Le tabelle che utilizzano la modalità partition (tabelle partizionate TimescaleDB) vengono saltate; vengono elaborate solo le tabelle che utilizzano la modalità regular.

Piattaforme supportate

A causa dei requisiti di sicurezza e della natura mission-critical del funzionamento del server, UNIX è l'unico sistema operativo in grado di garantire costantemente le prestazioni, la tolleranza ai guasti e la resilienza necessarie. Zabbix opera sulle versioni leader di mercato.

Zabbix server è testato sulle seguenti piattaforme:

Linux
Solaris
AIX
HP-UX
Mac OS X
FreeBSD
OpenBSD
NetBSD
SCO Open Server

Zabbix potrebbe funzionare anche su altri sistemi operativi di tipo Unix.

Impostazioni locali

Si noti che il server richiede una locale UTF-8 affinché alcuni item testuali possano essere interpretati correttamente. La maggior parte dei moderni sistemi di tipo Unix utilizza una locale UTF-8 come predefinita; tuttavia, esistono alcuni sistemi nei quali potrebbe essere necessario impostarla esplicitamente.

What’s next?

1 Alta disponibilità

Docs

1 Server

Panoramica