{"id":38927,"date":"2019-10-31T22:26:48","date_gmt":"2019-10-31T19:26:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\/"},"modified":"2019-10-31T22:26:48","modified_gmt":"2019-10-31T19:26:48","slug":"vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix \u00e8 un sistema di monitoraggio. Come qualsiasi altro sistema, affronta tre problemi principali comuni a tutti i sistemi di monitoraggio: raccolta e elaborazione dei dati, archiviazione della cronologia e la sua pulizia.<\/p>\n<p>Le fasi di acquisizione, elaborazione e registrazione dei dati richiedono tempo. Poco, ma per un sistema di grandi dimensioni questo pu\u00f2 tradursi in ritardi significativi. Il problema dell'archiviazione riguarda l'accesso ai dati, che vengono utilizzati per report, verifiche e trigger. I ritardi nell'accesso ai dati incidono anche sulle prestazioni. Man mano che i database crescono, \u00e8 necessario rimuovere i dati obsoleti. La cancellazione \u00e8 un'operazione pesante che consuma anche parte delle risorse.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nI problemi di latenza nella raccolta e nell'archiviazione in Zabbix vengono risolti tramite caching: diversi tipi di cache, caching nel database. Per affrontare il terzo problema, il caching non \u00e8 adatto, quindi in Zabbix \u00e8 stato adottato TimescaleDB. Ne parler\u00e0 <strong>Andrej Gu\u0161\u010din<\/strong> \u2014 ingegnere del supporto tecnico <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrej lavora nel supporto di Zabbix da oltre 6 anni e si confronta direttamente con le prestazioni.<\/p>\n<p>Come funziona TimescaleDB e quali prestazioni pu\u00f2 offrire rispetto a un tradizionale PostgreSQL? Qual \u00e8 il ruolo di Zabbix per il database TimescaleDB? Come avviare da zero e come migrare da PostgreSQL, e quale configurazione offre le migliori prestazioni? Di tutto ci\u00f2 parleremo nel seguito.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Riproduci video\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Sfide delle prestazioni<\/h2>\n<p>\nOgni sistema di monitoraggio affronta determinate sfide in termini di prestazioni. Parler\u00f2 di tre di esse: raccolta e trattamento dei dati, archiviazione, pulizia della storia.<\/p>\n<p><strong>Raccolta e trattamento dei dati rapidi. <\/strong>Un buon sistema di monitoraggio deve ricevere rapidamente tutti i dati e trattarli secondo le espressioni di attivazione, in base ai propri criteri. Dopo il trattamento, il sistema deve anche salvare rapidamente questi dati nel database per un utilizzo successivo.<\/p>\n<p><strong>Archiviazione della storia. <\/strong>Un buon sistema di monitoraggio deve conservare la cronologia nel database e fornire un facile accesso alle metriche. La cronologia \u00e8 necessaria per utilizzarla in report, grafici, attivazioni, soglie e elementi di dati calcolati per le notifiche.<\/p>\n<p><strong>Pulizia della storia. <\/strong>A volte arriva il giorno in cui non hai pi\u00f9 bisogno di conservare le metriche. Perch\u00e9 mai dovresti avere dati raccolti cinque anni fa, un mese o due fa: alcuni nodi sono stati rimossi, alcuni host o metriche non sono pi\u00f9 necessari perch\u00e9 obsoleti e non vengono pi\u00f9 raccolti. Un buon sistema di monitoraggio dovrebbe conservare i dati storici e periodicamente rimuoverli per evitare che il database cresca eccessivamente.<\/p>\n<blockquote><p>La pulizia dei dati obsoleti \u00e8 una questione cruciale che influisce notevolmente sulle prestazioni del database.<\/p><\/blockquote>\n<p><\/p>\n<h2>Caching in Zabbix<\/h2>\n<p>\nIn Zabbix, la prima e la seconda chiamata vengono gestite tramite caching. Per la raccolta e l'elaborazione dei dati viene utilizzata la memoria RAM. Per lo storage \u2014 la storia nei trigger, nei grafici e negli elementi di dati calcolati. Lato database, c'\u00e8 un certo caching per le query principali, ad esempio per i grafici.<\/p>\n<p>Il caching sul server Zabbix \u00e8:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nEsaminiamoli in dettaglio.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nQuesto \u00e8 il caching principale in cui conserviamo metriche, host, elementi di dati, trigger \u2014 tutto ci\u00f2 che \u00e8 necessario per il PreProcessing e per la raccolta dei dati.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTutto ci\u00f2 \u00e8 memorizzato in ConfigurationCache, per evitare richieste superflue al database. Dopo l'avvio del server, aggiorniamo questa cache, creiamo e aggiorniamo periodicamente le configurazioni.<\/p>\n<h3>Raccolta dati<\/h3>\n<p>\nLo schema \u00e8 abbastanza grande, ma l'aspetto principale \u00e8 <strong>raccoltori<\/strong>. Si tratta di vari \u00abpoller\u00bb \u2014 processi di raccolta. Si occupano di diversi tipi di raccolta: raccolgono dati tramite SNMP, IPMI, e trasferiscono tutto su PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>I raccoglitori sono evidenziati da una linea arancione.<\/em><\/p>\n<p>In Zabbix ci sono elementi di dati aggregati calcolati, necessari per aggregare le verifiche. Se abbiamo questi elementi, otteniamo i dati direttamente da ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nTutti i raccoglitori utilizzano ConfigurationCache per ricevere i compiti. Successivamente, li trasferiscono a PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPreProcessing utilizza ConfigurationCache per ricevere i passaggi di PreProcessing. Elabora questi dati in vari modi.<\/p>\n<p>Dopo aver elaborato i dati tramite PreProcessing, li salviamo in HistoryCache per un successivo trattamento. A questo punto si conclude la raccolta dei dati e procediamo al processo principale in Zabbix \u2014 <strong>history syncer<\/strong>, dato che si tratta di un'architettura monolitica.<\/p>\n<p><em>Nota: il PreProcessing \u00e8 un'operazione piuttosto pesante. Con la versione 4.2 \u00e8 stato spostato sul proxy. Se avete un Zabbix molto grande con un alto numero di elementi dati e una frequenza di raccolta elevata, questo semplifica notevolmente il lavoro.<\/em><\/p>\n<h3>ValueCache, cache storica e di tendenze<\/h3>\n<p><\/p>\n<blockquote><p>Il History syncer \u00e8 il processo principale che elabora in modo atomico ogni elemento dati, vale a dire ogni valore.<\/p><\/blockquote>\n<p>\nIl History syncer preleva i valori dalla HistoryCache e verifica nel Configuration la presenza di trigger per i calcoli. Se presenti, esegue i calcoli.<\/p>\n<p>Il History syncer genera un evento, un'escalation per creare avvisi, se richiesto dalla configurazione, e registra. Se ci sono trigger per una successiva elaborazione, memorizza quel valore nel ValueCache, in modo da non dover accedere alla tabella storica. In questo modo, il ValueCache si riempie di dati necessari per il calcolo dei trigger e degli elementi calcolati.<\/p>\n<p>Il History syncer scrive tutti i dati nel DB, e il DB su disco. Il processo di elaborazione si conclude qui.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching nel DB<\/h3>\n<p>\nDallato del DB ci sono vari cache quando si desidera visualizzare grafici o report sugli eventi:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> lato MySQL;<\/li>\n<li><code>shared_buffers<\/code> lato PostgreSQL;<\/li>\n<li><code>effective_cache_size<\/code> lato Oracle;<\/li>\n<li><code>shared_pool<\/code> lato DB2.<\/li>\n<\/ul>\n<p>\nCi sono molti altri cache, ma questi sono i principali per tutti i DB. Permettono di mantenere in memoria i dati che sono frequentemente necessari per le query. Ciascuno di essi ha la propria tecnologia per questo.<\/p>\n<h3>Le prestazioni del DB sono cruciali.<\/h3>\n<p>\nIl server Zabbix raccoglie continuamente dati e li registra. Al riavvio, legge anche dalla cronologia per popolare il ValueCache. Utilizza script e report. <strong>Zabbix API<\/strong>, che \u00e8 costruito sulla base dell'interfaccia web. L'API di Zabbix accede al database e ottiene i dati necessari per grafici, report, elenchi eventi e problemi recenti.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer la visualizzazione \u2014 <strong>Grafana<\/strong>. Tra i nostri utenti, questa \u00e8 una soluzione popolare. \u00c8 in grado di inviare direttamente richieste sia attraverso l'API di Zabbix che al DB, creando una certa concorrenza per ottenere dati. Pertanto, \u00e8 necessaria una configurazione pi\u00f9 fine e migliore del DB per garantire una rapida fornitura di risultati e test.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nLa terza sfida delle prestazioni in Zabbix \u00e8 la pulizia della cronologia tramite Housekeeper. Questo rispetta tutte le impostazioni: negli elementi dei dati \u00e8 indicato per quanti giorni mantenere la dinamica delle variazioni (trend).<\/p>\n<p>TrendsCache calcola i dati al volo. Quando arrivano le informazioni, le aggrega in un'ora e le registra nelle tabelle per monitorare le variazioni delle tendenze.<\/p>\n<p>Housekeeper viene eseguito e rimuove le informazioni dal database con normali 'select'. Questo non \u00e8 sempre efficiente, come si pu\u00f2 vedere dai grafici delle prestazioni dei processi interni.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl grafico rosso mostra che il History syncer \u00e8 costantemente occupato. Il grafico arancione sopra \u00e8 Housekeeper, che viene avviato di continuo. Attende che il database elimini tutte le righe che ha indicato.<\/p>\n<p>Quando \u00e8 opportuno disattivare Housekeeper? Ad esempio, se ci sono 'Item ID' e si devono rimuovere le ultime 5.000 righe in un determinato intervallo di tempo. Certamente, questo avviene tramite gli indici. Tuttavia, di solito il dataset \u00e8 molto grande, e il database legge comunque dal disco e carica in cache. Questo \u00e8 sempre un'operazione molto costosa per il database e, a seconda delle dimensioni, pu\u00f2 causare problemi di prestazioni.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>\u00c8 sufficiente disattivare Housekeeper. Nell'interfaccia web c'\u00e8 un'impostazione in 'Amministrazione generale' per Housekeeper. Disattiviamo il mantenimento interno per la cronologia interna delle tendenze e non gestisce pi\u00f9 questa parte.<\/p>\n<p>Le pulizie sono state disattivate, i grafici si sono allineati \u2014 quali possono essere i problemi in questo caso e cosa pu\u00f2 aiutare a risolvere la terza chiamata alle prestazioni?<\/p>\n<h2>Partizionamento \u2014 segmentazione o partizionamento<\/h2>\n<p>\nDi solito, il partizionamento viene configurato in modi diversi su ogni database relazionale che ho elencato. Ognuno ha la propria tecnologia, ma sono simili, in generale. La creazione di una nuova partizione porta spesso a determinati problemi.<\/p>\n<p>Di solito, le partizioni vengono configurate in base al \u00absetup\u00bb \u2014 alla quantit\u00e0 di dati che vengono generati in un giorno. Di norma, il partizionamento viene impostato su un giorno, questo \u00e8 il minimo. Per le tendenze della nuova partizione \u2014 su 1 mese.<\/p>\n<p>I valori possono cambiare in caso di un \u00absetup\u00bb molto grande. Se il piccolo \u00absetup\u00bb \u00e8 fino a 5.000 nvps (nuovi valori al secondo), medio \u2014 da 5.000 a 25.000, allora grande \u2014 sopra 25.000 nvps. Queste sono installazioni grandi e molto grandi, che richiedono un'accurata configurazione proprio del database.<\/p>\n<p>Su installazioni molto grandi, elaborare un segmento in un solo giorno potrebbe non essere ottimale. Ho visto partizioni in MySQL di 40 GB o pi\u00f9 al giorno. Si tratta di una quantit\u00e0 di dati molto elevata, che pu\u00f2 portare a problemi, e deve essere ridotta.<\/p>\n<h3>Quali vantaggi offre il Partitioning?<\/h3>\n<p>\n<strong>Partizionamento delle tabelle<\/strong>. Spesso sono file separati sul disco. Il piano delle query seleziona in modo pi\u00f9 ottimale una partizione. Di solito, il partizionamento viene effettuato per intervallo \u2014 anche per Zabbix \u00e8 cos\u00ec. Utilizziamo il \u00abtimestamp\u00bb \u2014 il tempo dall'inizio dell'epoca. Qui sono numeri normali. Definisci l'inizio e la fine della giornata \u2014 questa \u00e8 la partizione.<\/p>\n<p><strong>Eliminazione rapida<\/strong> \u2014 <code>DELETE<\/code>. Si seleziona un file\/sub-tabella, invece di selezionare righe per la cancellazione.<\/p>\n<p><strong>Accelera notevolmente l'accesso ai dati<\/strong> <code>SELECT<\/code> \u2014 utilizza una o pi\u00f9 partizioni, non l'intera tabella. Se richiedi dati risalenti a due giorni fa, questi vengono recuperati dal database pi\u00f9 rapidamente, perch\u00e9 \u00e8 necessario caricare in cache ed emettere solo un file, invece di una grande tabella.<\/p>\n<p>Spesso molte BDs ottimizzano anche <code>INSERT<\/code> \u2014 le inserzioni nella tabella figlia.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nPer la versione 4.2, ci siamo concentrati su TimescaleDB. \u00c8 un'estensione per PostgreSQL con un'interfaccia nativa. Questa estensione funziona efficacemente con i dati time series, senza perdere i vantaggi dei database relazionali. TimescaleDB partiziona automaticamente.<\/p>\n<p>In TimescaleDB esiste il concetto di <strong>iper-tabella<\/strong> (hypertable), che crei. Al suo interno ci sono <strong>chunk<\/strong> \u2014 partizioni. I chunk sono frammenti dell'iper-tabella gestiti automaticamente, che non influenzano altri frammenti. Ogni chunk ha il proprio intervallo temporale.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/91a24560ff12aa17f98689e3445f50e1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB vs PostgreSQL<\/h3>\n<p>\nTimescaleDB funziona davvero in modo efficiente. I produttori dell'estensione sostengono di utilizzare un algoritmo di elaborazione delle richieste pi\u00f9 efficace, in particolare per gli &lt;code&gt;inserts&lt;\/code&gt;. Man mano che le dimensioni delle dataset di inserimento crescono, l'algoritmo mantiene prestazioni costanti.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDopo 200 milioni di righe, PostgreSQL di solito inizia a rallentare significativamente, perdendo prestazioni fino a 0. TimescaleDB consente di inserire 'inserts' in modo efficace, indipendentemente dal volume di dati.<\/p>\n<h3>Installazione<\/h3>\n<p>\nInstallare TimescaleDB \u00e8 abbastanza semplice per tutti i pacchetti. Nel <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">documentazione<\/a><\/noindex> tutto \u00e8 descritto in dettaglio \u2014 dipende dai pacchetti ufficiali di PostgreSQL. TimescaleDB pu\u00f2 anche essere compilato e assemblato manualmente.<\/p>\n<p>Per il DB Zabbix attiviamo semplicemente l'estensione:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nAttivi <code>l'estensione<\/code> e la crei per il DB Zabbix. L'ultima fase consiste nella creazione della ipertabella.<\/p>\n<h3>Migrazione delle tabelle storiche su TimescaleDB<\/h3>\n<p>\nEsiste una funzione specifica per questo <code>create_hypertable<\/code>:<\/p>\n<pre><code class=\"sql\">SELECT create_hypertable('history', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_log', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_text', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('history_str', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('trends', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nSELECT create_hypertable('trends_unit', 'clock', chunk_time_interval =&gt; 86400, migrate_data =&gt; true);\nUPDATE config SET db_extension='timescaledb', hk_history_global=1, hk_trends_global=1<\/code><\/pre>\n<p>\nLa funzione ha tre parametri. Il primo \u00e8<strong> la tabella nel DB<\/strong>, per la quale deve essere creata l'ipertabella. Il secondo \u00e8 <strong>campo<\/strong>, in base al quale deve essere creato <code>chunk_time_interval<\/code> \u2014 l'intervallo dei chunk delle partizioni da utilizzare. Nel mio caso l'intervallo \u00e8 di un giorno \u2014 86.400.<\/p>\n<p>Il terzo parametro \u00e8 <code><strong>migrare_dati<\/strong><\/code>. Se impostato <code>true<\/code>, tutti i dati attuali vengono trasferiti in chunk pre-creati. L'ho usato di persona <code>migrare_dati<\/code>. Avevo circa 1 TB, che ha impiegato pi\u00f9 di un'ora. Anche in alcuni casi durante i test ho eliminato dati storici di tipo carattere che non erano necessari per il trasferimento.<\/p>\n<p>L'ultimo passo \u00e8\u00a0<code><strong>UPDATE<\/strong><\/code>: in <code>db_extension<\/code> impostiamo <code>timescaledb<\/code>, affinch\u00e9 il DB comprenda che esiste questa estensione. Zabbix la attiva e utilizza correttamente la sintassi e le query gi\u00e0 sul DB \u2014 le funzionalit\u00e0 necessarie per TimescaleDB.<\/p>\n<h2>Configurazione hardware<\/h2>\n<p>\nHo utilizzato due server. Il primo \u00e8 <strong>una macchina VMware<\/strong>. \u00c8 abbastanza piccola: 20 processori Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2.20GHz, 16 GB di RAM e un disco SSD da 200 GB.<\/p>\n<p>Ho installato PostgreSQL 10.8 su un sistema operativo Debian 10.8-1.pgdg90+1 e filesystem xfs. Ho eseguito tutte le configurazioni minime necessarie per utilizzare questo database, a parte ci\u00f2 che user\u00e0 Zabbix stesso.<\/p>\n<p>Su questa stessa macchina c'era il server Zabbix, PostgreSQL e <strong>agenti di carico<\/strong>. Avevo 50 agenti attivi che utilizzavano <code>LoadableModule<\/code>, per generare molto rapidamente vari risultati: numeri, stringhe. Ho riempito il database con una grande quantit\u00e0 di dati.<\/p>\n<p>Inizialmente la configurazione conteneva <strong>5.000 elementi<\/strong> dati per ogni host. Quasi ogni elemento conteneva un trigger per simulare installazioni reali. In alcuni casi c'erano pi\u00f9 di un trigger. Ogni nodo della rete aveva <strong>3.000-7.000 trigger<\/strong>.<\/p>\n<p>Intervallo di aggiornamento degli elementi dei dati \u2014 <strong>4-7 secondi<\/strong>. Ho regolato il carico stesso utilizzando non solo 50 agenti, ma aggiungendone altri. Inoltre, ho regolato dinamicamente il carico tramite gli elementi dei dati e ho ridotto l'intervallo di aggiornamento a 4 secondi.<\/p>\n<h3>PostgreSQL. 35.000 nvps<\/h3>\n<p>\nIl primo avvio su questo hardware \u00e8 avvenuto su PostgreSQL pulito \u2014 35.000 valori al secondo. Come si pu\u00f2 vedere, l'inserimento dei dati richiede frazioni di secondo \u2014 tutto bene e veloce. L'unica cosa \u00e8 che l'SSD da 200 GB si riempie rapidamente.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto \u00e8 il dashboard delle prestazioni standard di Zabbix \u2014 server.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl primo grafico blu \u2014 numero di valori al secondo. Il secondo grafico a destra \u2014 carico dei processi di raccolta. Il terzo \u2014 carico dei processi interni di raccolta: history syncers e Housekeeper, che qui ha funzionato per un tempo sufficiente.<\/p>\n<p>Il quarto grafico mostra l'uso di HistoryCache. Questo \u00e8 un buffer prima dell'inserimento nel database. Il quinto grafico verde mostra l'uso di ValueCache, cio\u00e8 quante hits ha avuto ValueCache per i trigger \u2014 si tratta di diverse migliaia di valori al secondo.<\/p>\n<h3>PostgreSQL. 50.000 nvps<\/h3>\n<p>\nPoi ho aumentato il carico a 50.000 valori al secondo su questa stessa macchina.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDurante il caricamento con Housekeeper, l'inserimento di 10.000 valori richiedeva 2-3 secondi.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper inizia gi\u00e0 a interferire con il lavoro.<\/em><\/p>\n<p>Dal terzo grafico si vede che, in generale, il carico dei trapper e degli history syncer \u00e8 ancora al 60%. Nel quarto grafico, HistoryCache inizia gi\u00e0 a riempirsi piuttosto attivamente durante il lavoro di Housekeeper. Si \u00e8 riempito al 20% \u2014 circa 0,5 GB.<\/p>\n<h3>PostgreSQL. 80.000 nvps<\/h3>\n<p>\nPoi ho aumentato il carico a 80.000 valori al secondo. Si tratta di circa 400.000 elementi di dati e 280.000 trigger.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>L'inserimento con un carico di trenta history syncer \u00e8 gi\u00e0 piuttosto alto.<\/em><\/p>\n<p>Ho anche aumentato vari parametri: history syncer, cache.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSul mio hardware, il carico degli history syncer \u00e8 aumentato al massimo. HistoryCache si \u00e8 rapidamente riempito di dati \u2014 nel buffer si sono accumulati dati da elaborare.<\/p>\n<p>Per tutto questo tempo ho osservato come vengono utilizzati la CPU, la RAM e altri parametri di sistema e ho scoperto che l'utilizzo dei dischi era al massimo.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo raggiunto un utilizzo <strong>massimo delle capacit\u00e0 del disco<\/strong> su questo hardware e su questa macchina virtuale. Con un'intensit\u00e0 simile, PostgreSQL ha iniziato a scaricare i dati piuttosto attivamente, e il disco non era pi\u00f9 in grado di gestire contemporaneamente scrittura e lettura.<\/p>\n<h3>Secondo server<\/h3>\n<p>\nHo preso un altro server, che gi\u00e0 aveva 48 processori e 128 GB di RAM. L'ho ottimizzato \u2014 ho installato 60 history syncer, e ho raggiunto una velocit\u00e0 accettabile.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn realt\u00e0, questo \u00e8 gi\u00e0 il limite delle prestazioni, dove \u00e8 necessario fare qualcosa.<\/p>\n<h3>TimescaleDB. 80.000 nvps<\/h3>\n<p>\nIl mio compito principale \u00e8 testare le capacit\u00e0 di TimescaleDB sotto il carico di Zabbix. 80 mila valori al secondo \u2014 sono molti, con una frequenza di raccolta delle metriche (tranne Yandex, ovviamente) e un \"setup\" piuttosto grande.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSu ogni grafico c'\u00e8 un calo \u2014 quello \u00e8 proprio il momento della migrazione dei dati. Dopo i cali nel server Zabbix, il profilo del carico dell'history syncer \u00e8 cambiato drasticamente \u2014 \u00e8 diminuito di tre volte.<\/p>\n<blockquote><p>TimescaleDB consente di inserire dati praticamente tre volte pi\u00f9 velocemente e di utilizzare meno HistoryCache.<\/p><\/blockquote>\n<p>\nDi conseguenza, i dati verranno forniti in modo tempestivo.<\/p>\n<h3>TimescaleDB. 120.000 nvps<\/h3>\n<p>\nIn seguito, ho aumentato il numero di elementi dei dati a 500.000. L'obiettivo principale era testare le capacit\u00e0 di TimescaleDB: ho ottenuto un valore stimato di 125.000 valori al secondo.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesta \u00e8 una configurazione funzionante che pu\u00f2 operare a lungo. Tuttavia, poich\u00e9 il mio disco aveva solo 1,5 TB, l'ho riempito in pochi giorni.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa cosa pi\u00f9 importante \u00e8 che, nel frattempo, venivano create nuove partizioni in TimescaleDB.<\/p>\n<p>Per le prestazioni, questo \u00e8 completamente invisibile. Quando le partizioni vengono create in MySQL, ad esempio, \u00e8 completamente diverso. Di solito, avviene di notte, perch\u00e9 blocca l'inserimento generale, il lavoro con le tabelle e pu\u00f2 causare degrado del servizio. In caso di TimescaleDB, questo non avviene.<\/p>\n<p>Per esempio, mostrer\u00f2 un grafico di molti nella community. Nell'immagine \u00e8 incluso TimescaleDB, grazie al quale il carico derivante dall'uso di io.weight sulla CPU \u00e8 diminuito. Anche l'uso degli elementi dei processi interni \u00e8 diminuito. Si tratta di una normale macchina virtuale su dischi tradizionali, non su SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Elevate prestazioni e partizionamento nativo: Zabbix con il supporto di TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusioni<\/h2>\n<p>\n<strong>TimescaleDB \u00e8 una buona soluzione per piccole configurazioni.<\/strong>, che limitano le prestazioni del disco. Questo permetter\u00e0 di continuare a lavorare bene fino alla migrazione del DB su hardware pi\u00f9 veloce.<\/p>\n<p>TimescaleDB \u00e8 facile da configurare, offre un incremento delle prestazioni ed \u00e8 ben integrato con Zabbix e <strong>ha vantaggi rispetto a PostgreSQL.<\/strong>.<\/p>\n<p>Se stai utilizzando PostgreSQL e non hai intenzione di cambiarlo, ti consiglio di <strong>utilizzare PostgreSQL con l'estensione TimescaleDB in combinazione con Zabbix.<\/strong>Questa soluzione funziona efficacemente fino a configurazioni medie.<\/p>\n<blockquote>\n<p>Quando parliamo di \u00abalte prestazioni\u00bb intendiamo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. Non \u00e8 necessario aspettare per conoscere le tecnologie e le pratiche che consentono ai servizi di gestire milioni di utenti. Abbiamo gi\u00e0 stilato un elenco di <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">relazioni<\/a><\/noindex> per il 7 e 8 novembre, e ci sono ancora <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">meetup<\/a><\/noindex> che possono essere proposti.<\/p>\n<p>Iscriviti alla nostra <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">newsletter<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, in cui sveliamo le caratteristiche della conferenza imminente e scopri come trarre il massimo vantaggio.<\/p>\n<\/blockquote>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/470902\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29204,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38927","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:26:48+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Elevata prestazione e partizionamento nativo: Zabbix con supporto per TimescaleDB | ProHoster","description":"Zabbix \u00e8 un sistema di monitoraggio. Come qualsiasi altro sistema, deve affrontare tre problemi principali di tutti i sistemi di monitoraggio: raccolta e elaborazione dei dati, archiviazione della storia e sua pulizia. Le fasi di acquisizione, elaborazione e registrazione dei dati richiedono tempo. Poco, ma per un sistema di grande dimensione, questo pu\u00f2 tradursi in ritardi significativi. Il problema dell'archiviazione riguarda l'accesso ai dati. Essi","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Zabbix \u0441 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 TimescaleDB | ProHoster","og:description":"Zabbix \u2014 \u044d\u0442\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041a\u0430\u043a \u0438 \u043b\u044e\u0431\u0430\u044f \u0434\u0440\u0443\u0433\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430, \u043e\u043d\u0430 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0441 \u0442\u0440\u0435\u043c\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c\u0438 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430\u043c\u0438 \u0432\u0441\u0435\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430: \u0441\u0431\u043e\u0440 \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0434\u0430\u043d\u043d\u044b\u0445, \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0441\u0442\u043e\u0440\u0438\u0438, \u0435\u0435 \u043e\u0447\u0438\u0441\u0442\u043a\u0430. \u042d\u0442\u0430\u043f\u044b \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f, \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 \u0432\u0440\u0435\u043c\u044f. \u041d\u0435\u043c\u043d\u043e\u0433\u043e, \u043d\u043e \u0434\u043b\u044f \u043a\u0440\u0443\u043f\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u044d\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0432\u044b\u043b\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438. \u041f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u2014 \u044d\u0442\u043e \u0432\u043e\u043f\u0440\u043e\u0441 \u0434\u043e\u0441\u0442\u0443\u043f\u0430 \u043a \u0434\u0430\u043d\u043d\u044b\u043c. \u041e\u043d\u0438","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:26:48+00:00","article:modified_time":"2019-10-31T19:26:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38927","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 21:14:06","updated":"2026-01-23 23:59:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}