[comment]: # ({6b30eb7c-98c082ce}) # 7 Configurazione di TimescaleDB [comment]: # ({/6b30eb7c-98c082ce}) [comment]: # ({36fb6804-acb21280}) #### Panoramica Zabbix supporta TimescaleDB, una soluzione di database basata su PostgreSQL che partiziona automaticamente i dati in blocchi basati sul tempo per supportare prestazioni più elevate su larga scala. ::: notewarning Attualmente, TimescaleDB non è supportato da Zabbix proxy. ::: Le istruzioni in questa pagina possono essere utilizzate per i seguenti scenari: - Creazione di un database TimescaleDB o migrazione dalle tabelle PostgreSQL esistenti a TimescaleDB (vedere [Configurazione](#configuration)). - Aggiornamento dello schema di un database TimescaleDB esistente durante l'aggiornamento di Zabbix (vedere [Aggiornamento dello schema TimescaleDB](#upgrading-timescaledb-schema)). [comment]: # ({/36fb6804-acb21280}) [comment]: # ({082fb7aa-f731725c}) #### Configurazione **Prerequisiti**: estensione TimescaleDB di una [versione supportata](/manual/installation/requirements#thirdparty-external-surrounding-software) installata sul server del database. Per le istruzioni di installazione, vedere la [documentazione di TimescaleDB](https://docs.tigerdata.com/self-hosted/latest/install/). ::: notewarning Prima di installare TimescaleDB, installare una release PostgreSQL supportata dal repository [ufficiale di PostgreSQL](https://www.postgresql.org/download/). ::: Abilitare l'estensione TimescaleDB per il database specifico eseguendo: ```bash echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix ``` L'esecuzione di questo comando richiede privilegi di amministratore del database. ::: noteclassic Se si utilizza uno schema del database diverso da 'public', è necessario aggiungere una clausola SCHEMA al comando sopra. Ad es.:
`echo "CREATE EXTENSION IF NOT EXISTS timescaledb SCHEMA yourschema CASCADE;" | sudo -u postgres psql zabbix` ::: Quindi eseguire lo script `postgresql/timescaledb/schema.sql`. Per le nuove installazioni, lo script deve essere eseguito dopo che il normale database PostgreSQL è stato creato con lo schema/dati iniziali (vedere [creazione del database](/manual/appendix/install/db_scripts)). ```bash cat /usr/share/zabbix/sql-scripts/postgresql/timescaledb/schema.sql | sudo -u zabbix psql zabbix ``` ::: noteimportant Ignorare i messaggi di avviso che informano che le best practice non vengono seguite durante l'esecuzione dello script `schema.sql` su TimescaleDB versione 2.9.0 e successive. Nonostante questo avviso, la configurazione verrà completata correttamente. ::: La migrazione dei dati esistenti di history, trend e audit log può richiedere molto tempo. Zabbix server e frontend devono essere arrestati per tutta la durata della migrazione. Lo script `schema.sql` imposta i seguenti parametri di housekeeping: - Override del periodo di history degli item - Override del periodo di trend degli item Per utilizzare l'housekeeping partizionato per history e trend, entrambe queste opzioni devono essere abilitate. È anche possibile abilitare l'override singolarmente solo per history o solo per trend. Per PostgreSQL e TimescaleDB, lo script `postgresql/timescaledb/schema.sql` imposta due parametri aggiuntivi: - Abilita la compressione - Comprimi i record più vecchi di 7 giorni [comment]: # ({/082fb7aa-f731725c}) [comment]: # ({5c6ac2c3-60e46db2}) Per rimuovere correttamente i dati compressi tramite housekeeper, devono essere abilitate entrambe le opzioni *Override item history period* e *Override item trend period*. Se l'override è disabilitato e le tabelle contengono chunk compressi, housekeeper non rimuoverà i dati da queste tabelle e verranno visualizzati avvisi di configurazione non corretta nelle sezioni [*Housekeeping*](/manual/web_interface/frontend_sections/administration/housekeeping) e [*System information*](/manual/web_interface/frontend_sections/reports/status_of_zabbix). [comment]: # ({/5c6ac2c3-60e46db2}) [comment]: # ({56721869-8c3a80a9}) Tutti questi parametri possono essere modificati in *Administration* > [*Housekeeping*](/manual/web_interface/frontend_sections/administration/housekeeping) dopo l'installazione. ::: notetip Potresti voler eseguire lo strumento timescaledb-tune fornito da TimescaleDB per ottimizzare i parametri di configurazione di PostgreSQL nel tuo `postgresql.conf`. ::: [comment]: # ({/56721869-8c3a80a9}) [comment]: # ({0bea3ea4-d6ee4f10}) ##### Aggiornamento dello schema TimescaleDB Quando si aggiorna Zabbix a una versione che contiene nuovi hypertable di TimescaleDB, il server Zabbix non configura automaticamente tali hypertable (ad esempio, durante l'aggiornamento da Zabbix 6.4 a 7.4, poiché le versioni 7.0.0 e 7.0.2 hanno introdotto nuovi hypertable). Per configurare i nuovi hypertable di TimescaleDB, seguire questi passaggi: 1. Avviare il server Zabbix; questo aggiorna il database esistente. 2. Verificare nel file di log del server che l'aggiornamento del database sia completato; una volta completato, arrestare il server Zabbix. Si noti che il server registra un avviso se tenta di abilitare la compressione per una tabella che non è un hypertable. 3. Eseguire lo script `postgresql/timescaledb/schema.sql`; questo configura i nuovi hypertable di TimescaleDB. Si noti che, a partire da Zabbix 7.0.0, la posizione e il nome dello script sono cambiati da `postgresql/timescaledb.sql` a `postgresql/timescaledb/schema.sql`. ::: noteimportant Ignorare i messaggi di avviso che informano che le best practice non sono seguite durante l'esecuzione dello script `schema.sql` sulla versione 2.9.0 e successive di TimescaleDB. Indipendentemente da questo avviso, la configurazione verrà completata correttamente. ::: [comment]: # ({/0bea3ea4-d6ee4f10}) [comment]: # ({dc9d91b5-2012f0a6}) #### Compressione di TimescaleDB La compressione nativa di TimescaleDB è supportata per tutte le tabelle Zabbix che sono hypertable di TimescaleDB. Durante l'aggiornamento o la migrazione a TimescaleDB, la compressione iniziale delle tabelle di grandi dimensioni può richiedere molto tempo. Si noti che la compressione è supportata con la licenza Timescale Community "timescale" e non è supportata con la licenza Apache 2.0 "apache". Se Zabbix rileva che la compressione non è supportata, viene scritto un messaggio di avviso nel log del server Zabbix e gli utenti non possono abilitare la compressione nel frontend. ::: notetip Si consiglia agli utenti di acquisire familiarità con la compressione nella [documentazione di TimescaleDB](https://docs.tigerdata.com/use-timescale/latest/compression/) prima di utilizzare la compressione. ::: Si noti che esistono alcune limitazioni imposte dalla compressione, in particolare: - Non sono consentite modifiche ai chunk compressi (insert, delete, update) - Non sono consentite modifiche allo schema per le tabelle compresse. Le impostazioni di compressione possono essere modificate nel blocco *Compressione di cronologia, trend e log di audit* nella sezione *Amministrazione* > *Housekeeping* del frontend di Zabbix. |Parametro|Predefinito|Commenti| |--|--|------| |*Abilita compressione*|Abilitata|Selezionare o deselezionare la casella di controllo non attiva/disattiva immediatamente la compressione. Poiché la compressione è gestita da Housekeeper, le modifiche avranno effetto entro un massimo di 2 volte `HousekeepingFrequency` ore (impostato in [zabbix\_server.conf](/manual/appendix/config/zabbix_server))

Dopo aver disabilitato la compressione, i nuovi chunk che rientrano nel periodo di compressione non verranno compressi. Tuttavia, tutti i dati precedentemente compressi rimarranno compressi. Per decomprimere i chunk compressi in precedenza, seguire le istruzioni nella [documentazione di TimescaleDB](https://docs.tigerdata.com/use-timescale/latest/compression/).

Durante l'aggiornamento da versioni precedenti di Zabbix con supporto TimescaleDB, la compressione non sarà abilitata per impostazione predefinita.| |*Comprimi record più vecchi di*|7d|Questo parametro non può essere inferiore a 7 giorni.

A causa dell'immutabilità dei chunk compressi, tutti i dati tardivi (ad esempio dati ritardati da un proxy) più vecchi di questo valore verranno scartati.| :::note Per ottenere prestazioni migliori nell'aggiornamento dei trend, è possibile ridurre "chunk_time_interval" per le tabelle `trends` e `trends_uint` da 30 giorni a 7 giorni o meno, a seconda di quanti item utilizzano i trend. Lo scopo di questa impostazione è aderire alle best practice di TimescaleDB e garantire che la dimensione dei chunk rimanga entro le risorse disponibili del sistema. ::: [comment]: # ({/dc9d91b5-2012f0a6})