server

Panoramica

Zabbix server è il processo centrale del software Zabbix.

Il server esegue il polling e il trapping dei dati, calcola i trigger e invia notifiche agli utenti. È il componente centrale a cui gli agent e i proxy di Zabbix segnalano 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 archiviati 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, frontend e archiviazione del database.

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

Vedi anche:

• Configurazione ad alta disponibilità per Zabbix server
• Parametri di configurazione: Zabbix server

Esecuzione del 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

Allo stesso modo, per arrestare/riavviare/visualizzare lo stato, usare i seguenti comandi:

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

Avvio manuale

Se quanto sopra non funziona, devi avviarlo manualmente. Trova il percorso del binario zabbix_server ed esegui:

zabbix_server

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

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:

Quando un tipo di processo è specificato come destinazione per il controllo runtime, il comando si applica solo ai processi in esecuzione di quel tipo. Se al momento non è in esecuzione alcun processo del tipo specificato, il comando restituisce un errore:

zabbix_server -R log_level_increase='discovery manager'
Cannot redirect signal: "discovery manager" process does not exist

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 di 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:

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

# Raccogli 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

Esempio di utilizzo del controllo runtime per avviare 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

Processo utente

Zabbix server è progettato per essere eseguito come utente non root. Verrà eseguito come l'utente non root con cui viene avviato. Quindi puoi eseguire server come qualsiasi utente non root senza problemi.

Se provi a eseguirlo come 'root', passerà a un utente 'zabbix' hardcoded, che deve essere presente nel tuo sistema. Puoi eseguire server come 'root' solo se modifichi di conseguenza il parametro 'AllowRoot' nel file di configurazione del server.

Se Zabbix server e agent vengono eseguiti sulla stessa macchina, è consigliato usare un utente diverso per l'esecuzione del server rispetto a quello usato per l'esecuzione dell'agent. Altrimenti, se entrambi vengono eseguiti come lo stesso utente, l'agent può accedere al file di configurazione del server e qualsiasi utente con livello Admin in Zabbix può facilmente recuperare, ad esempio, la password del database.

File di configurazione

Il percorso predefinito del file di configurazione dipende dal sistema operativo e dal metodo di installazione di Zabbix:

• Per l'installazione dai sorgenti: /usr/local/etc/zabbix_server.conf, oppure come impostato dalle variabili di compilazione --sysconfdir o --prefix.
• Per l'installazione dai pacchetti: /etc/zabbix/zabbix_server.conf.

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 alert;
• alert syncer - writer del DB 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 provenienti 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 DB della history;
• housekeeper - processo per la rimozione dei dati obsoleti (history e trends degli item, sessioni utente, eventi, ecc.), nonché dei dati residui lasciati da oggetti eliminati;
• http agent poller - processo poller asincrono per i 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 i 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 i controlli SNMP con un thread worker (solo item walk[OID] e get[OID]);
• snmp trapper - trapper per i trap SNMP;
• supervisor - coordina l'avvio e l'arresto dei processi e dei thread del server e ne monitora la disponibilità;
• task manager - processo per l'esecuzione remota delle attività richieste da altri componenti (ad esempio, chiusura di un problema, conferma di un problema, verifica immediata del 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 da 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 del 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>] item.

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 degli item e trend, 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.

Quando il processo housekeeper rimuove i dati residui lasciati dagli oggetti eliminati, si basa sui task presenti nella tabella housekeeper, che viene popolata ogni volta che un oggetto viene eliminato. Ad esempio, quando elimini un host, Zabbix elimina i relativi item, ma non il loro storico, i trend o i problemi. Al loro posto, 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 con task senza verificare la presenza di dati associati all'oggetto; tale verifica viene eseguita dal processo housekeeper quando rimuove i dati:

• Per gli item eliminati (incluse le regole LLD) - rimuove i relativi 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). Rimuove anche i relativi eventi interni dalla tabella problem.

• Per i trigger eliminati - rimuove i relativi eventi dalle tabelle correlate agli eventi (problem, event_symptom, events; il database stesso rimuove anche gli eventi dalla tabella event_recovery). Inoltre notifica il processo service manager degli eventi rimossi.

• Per i service eliminati - rimuove i relativi problemi dalla tabella problem; gli eventi dalla tabella events vengono rimossi solo dopo il periodo di conservazione dei dati configurato.

• Per gli host/service rilevati eliminati (network discovery) - rimuove i relativi eventi dalla tabella events.

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

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 in modo costante le prestazioni, la tolleranza ai guasti e la resilienza necessarie. Zabbix funziona sulle versioni leader di mercato.

Il server Zabbix è testato sulle seguenti piattaforme:

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

Locale

Si noti che il server richiede una locale UTF-8 affinché alcuni elementi testuali possano essere interpretati correttamente. La maggior parte dei moderni sistemi Unix-like ha una locale UTF-8 impostata come predefinita; tuttavia, in alcuni sistemi potrebbe essere necessario configurarla esplicitamente.