[comment]: # ({6d5b9456-fe9e2978}) # 2 Best practice di configurazione [comment]: # ({/6d5b9456-fe9e2978}) [comment]: # ({663732c3-28bc317f}) ### Panoramica Questa sezione illustra le best practice per configurare Zabbix al fine di ottenere prestazioni ottimali e facilità d'uso. Le raccomandazioni si basano sui consigli degli sviluppatori di Zabbix e sull'esperienza pratica dei formatori e degli ingegneri del supporto Zabbix. Ogni installazione di Zabbix è unica e alcune di queste linee guida potrebbero non essere adatte alla tua configurazione specifica. Tuttavia, si consiglia di cercare di attenersi a queste linee guida il più possibile per evitare i problemi potenziali più comuni. :::notetip Se ritieni che questa pagina possa essere migliorata, saremo lieti di ricevere il tuo feedback! Evidenzia il testo in questione e premi **ctrl+Enter** per segnalare un errore o condividere i tuoi commenti. ::: [comment]: # ({/663732c3-28bc317f}) [comment]: # ({5cfb221c-072ed520}) ### Host e item [comment]: # ({/5cfb221c-072ed520}) [comment]: # ({f17bceb0-330dd01f}) #### Definizione di un host Un host in Zabbix non è una macchina o un dispositivo fisico, ma un'entità logica. Ai fini del monitoraggio, è possibile creare host separati per un database o, ad esempio, per una macchina virtuale. In alternativa, è possibile creare un host generico *Il laptop di John* e monitorare tutte le metriche sotto quel host. La best practice consiste nel creare un host separato per ogni istanza indipendente, come una macchina virtuale, un database, un container o uno switch di rete. Utilizzando questo approccio, potrete: 1. Evitare confusione nei dati di monitoraggio grazie a item, trigger e notifiche di allarme separati per ciascun host. 2. Ottimizzare i livelli di accesso degli utenti. È possibile configurare [user-roles](/manual/web_interface/frontend_sections/users/user_roles) per concedere l'accesso alla visualizzazione e/o alla configurazione solo di host specifici. Vedi anche [il principio del privilegio minimo](/manual/best_practices/security/access_control#principle-of-least-privilege). [comment]: # ({/f17bceb0-330dd01f}) [comment]: # ({e32f8a5d-8db12f37}) #### Host con item duplicati Se hai diversi host simili, come *Network switch 1* e *Network switch 2*, Zabbix offre diversi modi per ricreare rapidamente l'host. Puoi semplicemente clonare un host con tutte le sue metriche premendo il pulsante Clone, ma in questo caso, per aggiornare in seguito un item, dovrai farlo manualmente su ciascun host. La best practice consiste nel creare un template con tutte le metriche richieste, ad esempio *Network switch template*. Quindi raggruppa gli host simili in un host group; per l'esempio sopra potrebbe essere *Network switches*. Ora, nella sezione *Data Collection -> Hosts* puoi filtrare tutti gli host per host group e usare il pulsante *Mass update* per collegare il template a tutti i tuoi switch di rete. [comment]: # ({/e32f8a5d-8db12f37}) [comment]: # ({657d4bfb-1a8f9462}) #### Elementi dipendenti Per ridurre al minimo il numero di richieste all'entità di destinazione, Zabbix consente la creazione di item master e item dipendenti. In questo caso, l'item master raccoglie un ampio insieme di informazioni in un'unica richiesta. Gli item dipendenti possono quindi essere configurati per estrarre specifiche porzioni di dati da tale raccolta tramite preprocessing e memorizzarle come metriche individuali. Ad esempio, l'item master potrebbe raccogliere una risposta JSON o XML contenente più metriche oppure eseguire una query al database che restituisce più colonne di dati (ad esempio, numero di connessioni aperte, connessioni interrotte, numero massimo consentito di connessioni simultanee e numero totale cumulativo di connessioni dall'avvio), mentre gli item dipendenti analizzeranno e memorizzeranno separatamente ogni valore richiesto. La best practice per questa configurazione consiste nel scartare la history dell'item master subito dopo la raccolta e conservare solo i dati degli item dipendenti. [comment]: # ({/657d4bfb-1a8f9462}) [comment]: # ({5372cab0-773f6eb4}) ### Server e proxy Se tutti gli host si trovano nella stessa rete locale del server Zabbix e non ci sono problemi di scalabilità o prestazioni, potrebbe non essere necessario un proxy. In ambienti più grandi o più complessi, il monitoraggio diretto degli host con il server Zabbix potrebbe non essere sufficiente. Aggiungere un proxy e assegnare parte degli host a quel proxy consente una distribuzione del carico più uniforme. La best practice è aggiungere un proxy Zabbix quando: 1. Si stanno monitorando più host utilizzando vari metodi di raccolta delle metriche dietro un firewall. Il proxy raccoglierà i dati dagli host e li inoltrerà al server Zabbix, riducendo la necessità di aprire più porte del firewall. 2. Si stanno monitorando sedi remote, filiali e/o reti. In caso di interruzione di rete tra il server Zabbix e le sedi remote, i proxy Zabbix distribuiti nelle sedi remote continueranno la raccolta dei dati e invieranno i dati raccolti al server Zabbix non appena la connessione di rete verrà ripristinata. 3. Si dispone di un'implementazione su larga scala e si desidera ridurre il carico sul server Zabbix e migliorare le prestazioni. La definizione di implementazione su larga scala è molto ampia e dipende non solo dal numero di host, ma anche dal numero di valori raccolti al secondo. [comment]: # ({/5372cab0-773f6eb4})