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

Il server è il repository centrale in cui vengono memorizzati tutti i dati di configurazione, statistici e operativi, ed è l'entità in Zabbix che avvisa 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 database storage.

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 usando il web frontend (o l'API), questo viene aggiunto alla tabella items nel database. Quindi, circa una volta al minuto, Zabbix server interrogherà 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, le modifiche apportate in Zabbix frontend possono richiedere fino a due minuti prima di comparire nella sezione dei 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. Individua il percorso del binario zabbix_server ed esegui:

zabbix_server

Puoi usare i seguenti parametri da riga di comando con Zabbix server:

-c --config <file>              Percorso del file di configurazione (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                Valida il file di configurazione ed esci
-h --help                       Mostra questo aiuto
-V --version                    Mostra il numero di versione

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

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

Controllo runtime

Opzioni di controllo 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 history per l'item specificato dal suo ID. Influisce su tutti i valori dell'item, tranne 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 history; `valuecache` - statistiche della cache dei valori; `preprocessing` - statistiche del manager di preprocessing; `alerting` - statistiche del manager degli alert; `lld` - statistiche del manager LLD; `locks` - elenco dei mutex (è vuoto sui sistemi BSD); `connector` - statistiche per i connector 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 per nome o ID. Nota che i nodi active/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). Sono supportati i suffissi temporali, 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 non viene specificato alcun target, 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, interessa tutti i processi se il target non è specificato. Non supportato sui sistemi BSD.	process type - tutti i processi del tipo specificato (ad esempio, `poller`). Vedi tutti i tipi di processo del server. process type,N - tipo di processo e numero (ad esempio, `poller,3`). pid - identificatore del processo (`1` to `65535`). Per valori maggiori specificare il target come 'process type,N'.
`log_level_decrease[=<target>]`	Diminuisce il livello di log, interessa tutti i processi se il target non è specificato. Non supportato sui sistemi BSD.
`prof_enable[=<target>]`	Abilita il profiling. Interessa tutti i processi se il target non è specificato. Il profiling abilitato fornisce dettagli di tutti i rwlock/mutex per nome funzione.	process type - tutti i processi del tipo specificato (ad esempio `history syncer`) I tipi di processo supportati come target di profiling: `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 del processo (`1` to `65535`). Per valori maggiori specificare il target come 'process type,N'. scope - `rwlock`, `mutex`, `processing` possono essere usati con il tipo di processo e il numero (ad esempio, `history syncer,1,processing`) oppure con tutti i processi di un tipo (ad esempio, `history syncer,rwlock`).
`prof_disable[=<target>]`	Disabilita il profiling. Interessa tutti i processi se il target non è specificato.	process type - tutti i processi del tipo specificato (ad esempio, `history syncer`). I tipi di processo supportati come target di profiling: vedi `prof_enable`. process type,N - tipo di processo e numero (ad esempio, `history syncer,1`). pid - identificatore del processo (`1` to `65535`). Per valori maggiori specificare il 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

Vedere le opzioni del file di configurazione per i dettagli sulla configurazione di zabbix_server.

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 alert;
alert syncer - writer del database degli alert;
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 connector;
connector worker - processo per la gestione delle richieste provenienti dal connector manager;
discovery manager - processo manager per la 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 - writer del database della history;
housekeeper - processo per la rimozione dei dati obsoleti (history e trend degli item, sessioni utente, eventi, ecc.), nonché dei dati residui lasciati dagli 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 - gestore 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 controlli passivi;
preprocessing manager - gestore delle attività di preprocessing con thread worker di preprocessing;
preprocessing worker - thread per il preprocessing dei dati;
proxy poller - poller per i proxy passivi;
proxy group manager - gestore del bilanciamento del carico e dell'alta disponibilità dei proxy;
report manager- gestore 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 (walk[OID] e get[OID] item soltanto);
snmp trapper - trapper per i trap SNMP;
task manager - processo per l'esecuzione remota delle attività richieste da altri componenti (ad esempio, chiudere un problema, riconoscere un problema, verificare ora il valore di un item, funzionalità di comando remoto);
timer - timer per l'elaborazione delle manutenzioni;
trapper - trapper per controlli attivi, trap, comunicazione con il proxy;
trigger housekeeper - processo per la rimozione dei problemi e degli eventi generati dai trigger che sono stati successivamente eliminati;
unreachable poller - poller per i dispositivi non raggiungibili;
vmware collector - raccoglitore 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 processo.

Il file di log del server viene creato con permessi di lettura e 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 usando l'item interno zabbix[process,<type>,<mode>,<state>].

Statistiche delle transazioni del history syncer

Il titolo del processo history syncer mostra 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 di 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 dell'host, ecc.);
Tempo impiegato per svuotare le trends 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.), oltre ai dati residui lasciati dagli oggetti eliminati. Viene eseguito in cicli, con frequenza e limite di eliminazione per ciclo determinati da HousekeepingFrequency e MaxHousekeeperDelete. I dati non rimossi in un ciclo vengono trasferiti al successivo. L'housekeeping automatico può essere abilitato e configurato in Administration > Housekeeping.

Per rimuovere i dati residui lasciati dagli oggetti eliminati, il processo housekeeper si basa su task presenti nella tabella housekeeper, che viene popolata ogni volta che un oggetto viene eliminato. Ad esempio, quando elimini un host, Zabbix elimina anche i relativi item, ma non il loro storico, i trend o i problemi. Invece, i trigger del database popolano la tabella housekeeper con task composti dai seguenti campi:

housekeeperid - ID del task
object - tipo di oggetto (0 - item; 1 - trigger; 2 - service; 3 - host rilevato; 4 - service rilevato)
objectid - ID dell'oggetto (aiuta il housekeeper a trovare i dati associati 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 associati all'oggetto; tale verifica viene eseguita dal processo housekeeper.

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

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

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

Fino all'avvio della procedura di housekeeping dei trigger, i problemi causati da trigger successivamente eliminati potrebbero continuare a generare problemi di servizio e ad assegnarli ai servizi. Se la tua configurazione include molte regole di calcolo dello stato dei servizi basate su trigger rilevati/non rilevati frequentemente, considera di aumentare la frequenza della procedura di housekeeping regolando il parametro di configurazione del server ProblemHousekeepingFrequency.

Per i service - controlla la tabella problems e rimuove gli eventi di servizio obsoleti, oltre ai problemi di servizio obsoleti, risolvendoli quindi al momento dell'housekeeping.
Per la network discovery - rimuove gli eventi di discovery obsoleti dalla tabella problems.

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

Le tabelle che usano la modalità partition (tabelle partizionate di TimescaleDB) vengono ignorate; vengono elaborate solo le tabelle che usano 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