[comment]: # ({cbb57ea2-cbb57ea2})
# 1 Server

[comment]: # ({/cbb57ea2-cbb57ea2})

[comment]: # ({d54fc79c-0e549571})
#### Panoramica

Zabbix server è il processo centrale del software Zabbix.

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.

[comment]: # ({/d54fc79c-0e549571})

[comment]: # ({c20247df-c20247df})
#### Eseguire il server

[comment]: # ({/c20247df-c20247df})

[comment]: # ({ec500727-1314fd6f})
##### Se installato come pacchetto

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

```bash
systemctl start zabbix-server
```

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

```bash
/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

[comment]: # ({/ec500727-1314fd6f})

[comment]: # ({3563f7d5-bbb4c5d8})
##### Avvio manuale

Se quanto sopra non funziona, è necessario avviarlo manualmente.
Individua il percorso del binario `zabbix_server` ed esegui:

```bash
zabbix_server
```

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

```bash
-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:

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

[comment]: # ({/3563f7d5-bbb4c5d8})

[comment]: # ({4836c205-a339702b})
##### 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.| |
|`diaginfo[=<section>]`|Raccoglie informazioni diagnostiche nel file di log del server.|`historycache` - statistiche della cache della cronologia;<br>`valuecache` - statistiche della cache dei valori;<br>`preprocessing` - statistiche del manager di preprocessing;<br>`alerting` - statistiche del manager degli alert;<br>`lld` - statistiche del manager LLD;<br>`locks` - elenco dei mutex (è vuoto sui sistemi *BSD*);<br>`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.<br>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).<br>Sono supportati i [suffissi temporali](/manual/appendix/suffixes), 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.<br>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 — svuota le proprietà del motore SNMP (engine time, engine boots, engine id, credenziali) per tutti gli host. Da usare per forzare una pulizia globale della cache durante la risoluzione dei problemi SNMP.| |
|`housekeeper_execute`|Avvia la procedura di [housekeeping](/manual/web_interface/frontend_sections/administration/housekeeping).<br>Ignorato se la procedura di housekeeping è attualmente in corso.| |
|`trigger_housekeeper_execute`|Avvia la procedura di housekeeping dei trigger.<br>Ignorato se la procedura di housekeeping dei trigger è attualmente in corso.<br>Fino all'avvio della procedura di housekeeping dei trigger, i problemi causati da trigger che nel frattempo sono stati eliminati potrebbero ancora generare problemi di servizio e assegnarli ai servizi. Se la tua configurazione include molte regole di [calcolo dello stato](/manual/it_services/service_tree#service-configuration) dei servizi basate su trigger scoperti/non scoperti frequentemente, valuta di aumentare la frequenza della procedura di housekeeping regolando il parametro di configurazione del server [`ProblemHousekeepingFrequency`](/manual/appendix/config/zabbix_server#problemhousekeepingfrequency).| |
|`log_level_increase[=<target>]`|Aumenta il livello di log, interessa tutti i processi se il target non è specificato.<br>Non supportato sui sistemi *BSD*.|**process type** - tutti i processi del tipo specificato (ad esempio, `poller`).<br>Vedi tutti i [tipi di processo del server](#server-process-types-and-threads).<br>**process type,N** - tipo di processo e numero (ad esempio, `poller,3`).<br>**pid** - identificatore del processo (`1` to `65535`). Per valori maggiori specifica il target come 'process type,N'.|
|`log_level_decrease[=<target>]`|Diminuisce il livello di log, interessa tutti i processi se il target non è specificato.<br>Non supportato sui sistemi *BSD*.|^|
|`prof_enable[=<target>]`|Abilita il profiling.<br>Interessa tutti i processi se il target non è specificato.<br>Il profiling abilitato fornisce dettagli di tutti gli rwlock/mutex per nome funzione.|**process type** - tutti i processi del tipo specificato (ad esempio `history syncer`)<br>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`.<br>**process type,N** - tipo di processo e numero (ad esempio, `history syncer,1`).<br>**pid** - identificatore del processo (`1` to `65535`). Per valori maggiori specifica il target come 'process type,N'.<br>**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.<br>Interessa tutti i processi se il target non è specificato.|**process type** - tutti i processi del tipo specificato (ad esempio, `history syncer`).<br>I tipi di processo supportati come target di profiling: vedi `prof_enable`.<br>**process type,N** - tipo di processo e numero (ad esempio, `history syncer,1`).<br>**pid** - identificatore del processo (`1` to `65535`). Per valori maggiori specifica il target come 'process type,N'.|

[comment]: # ({/4836c205-a339702b})

[comment]: # ({bd45cfce-1cb7f51c})
Esempio di utilizzo del controllo runtime per ricaricare la cache di configurazione del server:

```bash
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:

```bash
# 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
```

Esempi di utilizzo del controllo runtime per raccogliere informazioni diagnostiche:

```bash
# 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:

```bash
zabbix_server -R snmp_cache_reload
```

::: noteimportant
Quando un'interfaccia SNMPv3 viene aggiornata tramite la Zabbix UI, Zabbix ricaricherà automaticamente le nuove credenziali SNMPv3 per tale interfaccia nella maggior parte dei casi; usa `-R snmp_cache_reload` solo se il polling continua a non riuscire dopo la modifica delle credenziali (ad esempio, a causa di incoerenze engineBoots/engineID o di dispositivi non conformi agli RFC), oppure quando devi forzare una cancellazione globale della cache SNMP per la risoluzione dei problemi.
:::

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

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

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

```bash
# 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:

```bash
zabbix_server -R ha_set_failover_delay=10s
```

[comment]: # ({/bd45cfce-1cb7f51c})

[comment]: # ({141af812-b4f10179})
##### Utente del processo

Zabbix server è progettato per essere eseguito come utente non root.
Verrà eseguito con 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](/manual/installation/install) 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](agent) vengono eseguiti sulla stessa macchina, è consigliabile usare un utente diverso per l'esecuzione del server rispetto a quello usato per l'esecuzione dell'agent.
Altrimenti, se entrambi vengono eseguiti con lo stesso utente, l'agent può accedere al file di configurazione del server e qualsiasi utente con livello Admin in Zabbix può recuperare con relativa facilità, ad esempio, la password del database.

[comment]: # ({/141af812-b4f10179})

[comment]: # ({822335b2-0a81f475})
##### File di configurazione

Vedere le opzioni del [file di configurazione](/manual/appendix/config/zabbix_server) per i dettagli sulla configurazione di `zabbix_server`.

[comment]: # ({/822335b2-0a81f475})

[comment]: # ({5d50d9d1-49247ffc})
##### 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.

[comment]: # ({/5d50d9d1-49247ffc})

[comment]: # ({c6db57fa-9f05badb})
#### Tipi di processi e thread del server

-   `agent poller` - processo poller asincrono per i 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 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 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 da oggetti eliminati;
-   `http agent poller` - processo poller asincrono per i controlli HTTP con un thread worker;
-   `http poller` - poller per il web monitoring;
-   `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 dei report pianificati;
-   `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 sui problemi, sui tag dei problemi e sulla risoluzione dei problemi da history syncer, task manager e alert manager;
-   `snmp poller` - processo poller asincrono per i controlli SNMP con un thread worker (`walk[OID]` e `get[OID]` solo item);
-   `snmp trapper` - trapper per i trap SNMP;
-   `task manager` - processo per l'esecuzione remota delle attività richieste da altri componenti (ad esempio, chiusura del problema, riconoscimento del problema, verifica immediata del valore dell'item, funzionalità di comando remoto);
-   `timer` - timer per l'elaborazione delle manutenzioni;
-   `trapper` - trapper per i controlli attivi, i trap e la 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.

A partire da Zabbix 7.0.22, 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>]` [item](/manual/config/items/itemtypes/internal).

[comment]: # ({/c6db57fa-9f05badb})

[comment]: # ({56afbd4a-cdd68340})
#### 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

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

[comment]: # ({/56afbd4a-cdd68340})

[comment]: # ({eef646bb-982e2546})
#### 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.

[comment]: # ({/eef646bb-982e2546})