{"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":"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 di 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 considerevoli. Il problema della memorizzazione \u00e8 una questione di accesso ai dati. Questi sono utilizzati per report, verifiche e trigger. I ritardi nell'accesso ai dati influenzano anche le prestazioni. Man mano che i database crescono, i dati obsoleti devono essere rimossi. La rimozione \u00e8 un'operazione pesante, che consuma anche parte delle risorse.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 con la cache: diversi tipi di cache, caching nel database. Per affrontare il terzo problema, il caching non \u00e8 sufficiente, quindi in Zabbix \u00e8 stato implementato TimescaleDB. Di questo 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 \u00e8 nel supporto di Zabbix da oltre 6 anni e si occupa direttamente delle prestazioni.<\/p>\n<p>Come funziona TimescaleDB, quali prestazioni pu\u00f2 offrire rispetto a PostgreSQL ordinario? Che ruolo gioca 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 di 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=\"Guarda il 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 si trova di fronte a determinate sfide prestazionali. Parler\u00f2 di tre di esse: raccolta e elaborazione dei dati, archiviazione, pulizia della cronologia.<\/p>\n<p><strong>Raccolta ed elaborazione rapida dei dati. <\/strong>Un buon sistema di monitoraggio deve acquisire rapidamente tutti i dati e elaborarli in base alle espressioni trigger \u2014 secondo i propri criteri. Dopo l'elaborazione, il sistema deve anche salvare rapidamente questi dati nel database, per poterli utilizzare successivamente.<\/p>\n<p><strong>Archiviazione della cronologia. <\/strong>Un buon sistema di monitoraggio deve memorizzare la cronologia nel database e fornire un accesso conveniente alle metriche. La storia \u00e8 necessaria per utilizzarla in report, grafici, trigger, valori soglia ed elementi dati calcolati per le notifiche.<\/p>\n<p><strong>Pulizia della cronologia. <\/strong>A volte arriva un giorno in cui non \u00e8 necessario conservare le metriche. Perch\u00e9 dovresti avere dati raccolti 5 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 smettono di essere raccolti. Un buon sistema di monitoraggio dovrebbe conservare i dati storici e di tanto in tanto eliminarli, per evitare che il database cresca troppo.<\/p>\n<blockquote><p>La pulizia dei dati obsoleti \u00e8 una questione critica che ha un forte impatto sulle prestazioni del database.<\/p><\/blockquote>\n<p><\/p>\n<h2>Cache in Zabbix<\/h2>\n<p>\nIn Zabbix, la prima e la seconda invocazione vengono gestite tramite caching. La memoria operativa \u00e8 utilizzata per raccogliere e trattare i dati. Per la memorizzazione ci sono storie nei trigger, nei grafici e negli elementi di dati calcolati. A livello di database esiste un certo caching per le principali query, come i grafici.<\/p>\n<p>Caching lato server Zabbix:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nEsaminiamoli pi\u00f9 nel dettaglio.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nQuesto \u00e8 il cache principale in cui memorizziamo metriche, host, elementi di dati, trigger - tutto ci\u00f2 che \u00e8 necessario per il PreProcessing e la raccolta dei dati.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTutto questo \u00e8 conservato in ConfigurationCache, per evitare richieste superflue al database. Dopo l'avvio del server, aggiorniamo questo cache, creiamo e aggiorniamo periodicamente le configurazioni.<\/p>\n<h3>Raccolta dati<\/h3>\n<p>\nLo schema \u00e8 abbastanza grande, ma la cosa principale \u00e8 che ci sono <strong>raccoltori<\/strong>. Sono diversi \"poller\" - processi di raccolta. Sono responsabili di diversi tipi di raccolta: raccolgono dati tramite SNMP, IPMI, e trasmettono tutto al PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 li abbiamo, preleviamo i dati per loro direttamente da ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nTutti i raccoglitori utilizzano ConfigurationCache per ricevere incarichi. Successivamente, li trasferiscono al PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl PreProcessing utilizza ConfigurationCache per ottenere i passi del PreProcessing. Elabora questi dati in vari modi.<\/p>\n<p>Dopo l'elaborazione dei dati tramite il PreProcessing, li memorizziamo in HistoryCache per ulteriori elaborazioni. Qui termina la raccolta dei dati e passiamo al processo principale in Zabbix - <strong>history syncer<\/strong>, poich\u00e9 si tratta di un'architettura monolitica.<\/p>\n<p><em>Nota: il PreProcessing \u00e8 un'operazione piuttosto pesante. A partire da v 4.2 \u00e8 stato spostato su proxy. Se hai un Zabbix molto grande con un elevato numero di elementi di dati e frequenza di raccolta, questo facilita notevolmente il lavoro.<\/em><\/p>\n<h3>ValueCache, cronologia e cache delle tendenze<\/h3>\n<p><\/p>\n<blockquote><p>History syncer \u00e8 il processo principale che elabora atomicamente ogni elemento di dati, ovvero ogni valore.<\/p><\/blockquote>\n<p>\nHistory syncer prende i valori da HistoryCache e verifica nella Configurazione la presenza di trigger per i calcoli. Se ci sono, esegue il calcolo.<\/p>\n<p>History syncer crea un evento, un'escalation, per generare allerta se richiesto dalla configurazione, e registra. Se ci sono trigger per un'elaborazione successiva, questo valore viene memorizzato in ValueCache, per non dover accedere alla tabella della cronologia. Cos\u00ec ValueCache si riempie di dati necessari per il calcolo dei trigger e degli elementi calcolati.<\/p>\n<p>History syncer registra tutti i dati nel DB e questo li scrive su disco. Il processo di elaborazione si conclude qui.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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>\nSul lato del DB ci sono vari cache quando si desidera visualizzare grafici o rapporti sugli eventi:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> sul lato di MySQL;<\/li>\n<li><code>shared_buffers<\/code> sul lato di PostgreSQL;<\/li>\n<li><code>effective_cache_size<\/code> sul lato di Oracle;<\/li>\n<li><code>shared_pool<\/code> sul lato di 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 spesso necessari per le query. Hanno le proprie tecnologie per questo.<\/p>\n<h3>Le prestazioni del DB sono critiche<\/h3>\n<p>\nIl server Zabbix raccoglie continuamente dati e li registra. Durante il riavvio, legge anche dalla cronologia per riempire ValueCache. Utilizza <strong>Zabbix API<\/strong>, che si basa sull'interfaccia Web. Zabbix API accede al database e ottiene i dati necessari per grafici, rapporti, liste di eventi e ultimi problemi.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 \u00e8 una soluzione popolare. \u00c8 in grado di inviare direttamente richieste tramite Zabbix API sia al DB, creando una certa concorrenza per ottenere dati. Pertanto, \u00e8 necessaria una configurazione pi\u00f9 fine e accurata del DB per garantire un rapido rilascio dei risultati e test.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nLa terza chiamata di prestazione in Zabbix \u00e8 la pulizia della cronologia tramite Housekeeper. Rispetta tutte le impostazioni \u2014 nei dati \u00e8 indicato quanto conservare la dinamica delle modifiche (tendenze) in giorni.<\/p>\n<p>TrendsCache lo calcoliamo al volo. Quando arrivano i dati, li aggregiamo per un'ora e li registriamo nelle tabelle per la dinamica delle modifiche delle tendenze.<\/p>\n<p>Housekeeper si avvia ed elimina informazioni dal DB utilizzando normali \u00abselect\u00bb. Questo non \u00e8 sempre efficiente, come si pu\u00f2 comprendere dai grafici delle prestazioni dei processi interni.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 in alto \u00e8 il Housekeeper, che si avvia continuamente. Aspetta che il DB elimini tutte le righe che ha impostato.<\/p>\n<p>Quando \u00e8 opportuno disattivare il Housekeeper? Ad esempio, se ci sono \u00abItem ID\u00bb e si devono eliminare le ultime 5.000 righe in un determinato periodo di tempo. Certamente, ci\u00f2 avviene attraverso gli indici. Ma di solito il dataset \u00e8 molto grande e il DB continua a leggere dal disco e a caricare nella cache. Questa \u00e8 sempre un'operazione molto costosa per il DB e, a seconda delle dimensioni del database, pu\u00f2 portare a problemi di prestazioni.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Disattivare semplicemente il Housekeeper. Nell'interfaccia Web esiste un'impostazione in \u00abAdministration general\u00bb per il Housekeeper. Disattiviamo il housekeeping interno per la cronologia interna delle tendenze e non gestisce pi\u00f9 questo.<\/p>\n<p>Il Housekeeper \u00e8 stato disattivato, i grafici si sono allineati \u2014 quali potrebbero essere i problemi in questo caso e cosa potrebbe aiutare a risolvere la terza chiamata alle prestazioni?<\/p>\n<h2>Partizionamento \u2014 sezione oppure partizionamento<\/h2>\n<p>\nDi solito, il partizionamento viene configurato in modi diversi su ciascun DB 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 quantit\u00e0 di dati creati in un giorno. In generale, il Partizionamento viene impostato per un giorno, questo \u00e8 il minimo. Per le tendenze le nuove partizioni \u2014 per 1 mese.<\/p>\n<p>I valori possono variare in caso di \u00absetup\u00bb molto grande. Se il \u00absetup\u00bb \u00e8 piccolo \u2014 fino a 5.000 nvps (nuovi valori al secondo), medio \u2014 da 5.000 a 25.000, grande \u2014 oltre 25.000 nvps. Queste sono installazioni grandi e molto grandi, che richiedono una configurazione attenta proprio del database.<\/p>\n<p>In installazioni molto grandi, un intervallo di un giorno potrebbe non essere ottimale. Ho visto su MySQL partizioni di 40 GB o pi\u00f9 al giorno. Questo \u00e8 un volume di dati molto grande, che pu\u00f2 portare a problemi, e deve essere ridotto.<\/p>\n<h3>Quali vantaggi offre il Partizionamento?<\/h3>\n<p>\n<strong>Partizionamento delle tabelle<\/strong>. Spesso si tratta di file separati sul disco. Il piano delle query sceglie in modo pi\u00f9 ottimale una partizione. Di solito, la partizione viene utilizzata per intervallo: questo \u00e8 vero anche per Zabbix. Utilizziamo l\u00ec \u00abtimestamp\u00bb \u2014 il tempo dall'inizio dell'epoca. Per noi sono numeri normali. Si impostano l'inizio e la fine del giorno \u2014 questa \u00e8 la partizione.<\/p>\n<p><strong>Eliminazione rapida<\/strong> \u2014 <code>DELETE<\/code>. Viene scelto un file\/sottotabella, e non un campione di righe da eliminare.<\/p>\n<p><strong>Accelera notevolmente l'estrazione dei dati<\/strong> <code>SELECT<\/code> \u2014 utilizza una o pi\u00f9 partizioni, e non l'intera tabella. Se si richiedono dati di due giorni fa, vengono estratti dal database pi\u00f9 rapidamente, perch\u00e9 \u00e8 necessario caricare in cache e restituire solo un file, e non un grande tavolo.<\/p>\n<p>Spesso molte banche dati accelerano anche <code>INSERISCI<\/code> \u2014 le inserzioni nella tabella child.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nPer la versione 4.2, abbiamo prestato attenzione a TimescaleDB. Questo \u00e8 un'estensione per PostgreSQL con un'interfaccia nativa. L'estensione funziona in modo efficace con dati time series, senza perdere i vantaggi delle banche dati relazionali. TimescaleDB partiziona automaticamente.<\/p>\n<p>In TimescaleDB c'\u00e8 il concetto di <strong>iper-tabella<\/strong> (hypertable), che si crea. In essa ci sono <strong>chunk<\/strong> \u2014 partizioni. I chunk sono frammenti della iper-tabella gestiti automaticamente, il che non influisce su altri frammenti. Per ogni chunk c'\u00e8 un intervallo di tempo proprio.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 affermano di utilizzare un algoritmo di elaborazione delle query pi\u00f9 corretto, in particolare, <code>inserts<\/code>. Quando le dimensioni delle inserzioni del dataset aumentano, l'algoritmo mantiene prestazioni costanti.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 e perde prestazione fino a 0. TimescaleDB consente di inserire 'inserts' in modo efficace con qualsiasi volume di dati.<\/p>\n<h3>Installazione<\/h3>\n<p>\nInstallare TimescaleDB \u00e8 abbastanza semplice per qualsiasi pacchetto. In <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">documentazione<\/a><\/noindex> tutto \u00e8 descritto dettagliatamente \u2014 dipende dai pacchetti ufficiali di PostgreSQL. TimescaleDB pu\u00f2 anche essere assemblato e compilato manualmente.<\/p>\n<p>Per il database 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 database Zabbix. L'ultimo passaggio \u00e8 la creazione dell'iper-tabella.<\/p>\n<h3>Migrazione delle tabelle storiche su TimescaleDB<\/h3>\n<p>\nA tal fine c'\u00e8 una funzione speciale <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 \u2014<strong> la tabella nel DB<\/strong>, per la quale \u00e8 necessario creare una hypertable. Il secondo \u2014 <strong>il campo<\/strong>, su cui deve essere creata <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 \u2014 <code><strong>migrare_dati<\/strong><\/code>. Se impostato <code>true<\/code>, tutti i dati correnti vengono spostati nei chunk creati in anticipo. Io ho utilizzato <code>migrare_dati<\/code>. Avevo circa 1 TB, il che ha richiesto pi\u00f9 di un'ora. Anche in alcuni casi durante il test ho cancellato i dati storici non necessari di tipo stringa per non trasferirli.<\/p>\n<p>L'ultimo passo \u2014\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 al DB \u2014 quelle funzioni necessarie per TimescaleDB.<\/p>\n<h2>Configurazione hardware<\/h2>\n<p>\nHo utilizzato due server. Il primo \u2014 <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>Vi ho installato PostgreSQL 10.8 con sistema operativo Debian 10.8-1.pgdg90+1 e filesystem xfs. Ho effettuato tutte le configurazioni minime per utilizzare proprio questo database, tranne per il fatto che verr\u00e0 utilizzato da Zabbix.<\/p>\n<p>Sulla stessa macchina era installato il server Zabbix, PostgreSQL e <strong>gli agenti di carico<\/strong>. Avevo 50 agenti attivi, che utilizzavano <code>LoadableModule<\/code>, per generare molto rapidamente risultati vari: 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> di dati per ogni host. Quasi ogni elemento conteneva un trigger, per essere simile a installazioni reali. In alcuni casi c'erano pi\u00f9 di un trigger. Su un nodo della rete c'erano <strong>3.000-7.000 trigger<\/strong>.<\/p>\n<p>L'intervallo di aggiornamento degli elementi dati \u00e8 di <strong>4-7 secondi<\/strong>. Ho regolato il carico non solo utilizzando 50 agenti, ma aggiungendone anche altri. Inoltre, grazie agli elementi dei dati, ho regolato dinamicamente il carico e ho ridotto l'intervallo di aggiornamento a 4 secondi.<\/p>\n<h3>PostgreSQL. 35.000 nvps<\/h3>\n<p>\nIl primo avvio su questa macchina \u00e8 stato con PostgreSQL puro \u2014 35.000 valori al secondo. Come si pu\u00f2 vedere, l'inserimento dei dati richiede frazioni di secondo \u2014 tutto va bene e veloce. L'unica cosa \u00e8 che il disco SSD da 200 GB si riempie rapidamente.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto \u00e8 il dashboard standard delle prestazioni di Zabbix \u2014 server.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl primo grafico blu mostra il numero di valori al secondo. Il secondo grafico a destra mostra il carico dei processi di raccolta. Il terzo \u2014 il carico dei processi interni di raccolta: history syncers e Housekeeper, che qui \u00e8 stato eseguito per un tempo sufficiente.<\/p>\n<p>Il quarto grafico mostra l'utilizzo di HistoryCache. Questo \u00e8 un buffer prima dell'inserimento nel DB. Il quinto grafico verde mostra l'utilizzo di ValueCache, cio\u00e8 quanti colpi di ValueCache ci sono per i trigger \u2014 si tratta di alcune migliaia di valori al secondo.<\/p>\n<h3>PostgreSQL. 50.000 nvps<\/h3>\n<p>\nPoi ho aumentato il carico fino a 50.000 valori al secondo su questa stessa macchina.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 \u00e8 stato registrato in 2-3 secondi.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper inizia a interferire con il lavoro.<\/em><\/p>\n<p>Dal terzo grafico si pu\u00f2 vedere che, in generale, il carico di trappole e history syncers \u00e8 ancora al 60%. Nel quarto grafico, HistoryCache inizia 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 fino a 80.000 valori al secondo. Questo corrisponde a circa 400.000 elementi di dati e 280.000 trigger.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>L'inserimento con un caricamento di trenta history syncers \u00e8 gi\u00e0 piuttosto elevato.<\/em><\/p>\n<p>Inoltre, ho aumentato vari parametri: history syncers, cache.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSulla mia macchina, il carico degli history syncers \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 venivano utilizzati la CPU, la memoria RAM e altri parametri di sistema, e ho scoperto che l'utilizzo dei dischi era massimo.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHo raggiunto l'utilizzo <strong>delle massime capacit\u00e0 del disco<\/strong> su questa macchina e su questa macchina virtuale. Con tale intensit\u00e0, PostgreSQL ha iniziato a svuotare i dati piuttosto attivamente, e il disco non riusciva pi\u00f9 a gestire le operazioni di scrittura e lettura.<\/p>\n<h3>Secondo server<\/h3>\n<p>\nHo preso un altro server, che aveva gi\u00e0 48 processori e 128 GB di memoria RAM. L'ho ottimizzato \u2014 ho messo 60 history syncer, e ho raggiunto un'adeguata velocit\u00e0 di esecuzione.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn effetti, questo \u00e8 gi\u00e0 il limite delle prestazioni, dove \u00e8 necessario prendere misure.<\/p>\n<h3>TimescaleDB. 80.000 nvps<\/h3>\n<p>\nIl mio obiettivo principale \u00e8 verificare le capacit\u00e0 di TimescaleDB sotto il carico di Zabbix. 80.000 valori al secondo sono molti, la frequenza di raccolta delle metriche (a parte Yandex, ovviamente) e un 'setup' piuttosto grande.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIn ogni grafico c'\u00e8 un calo \u2014 questo \u00e8 proprio il momento della migrazione dei dati. Dopo i cali, nel server Zabbix, il profilo di 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 saranno forniti in tempo utile.<\/p>\n<h3>TimescaleDB. 120.000 nvps<\/h3>\n<p>\nPoi ho aumentato il numero di elementi dati a 500.000. L'obiettivo principale era testare le capacit\u00e0 di TimescaleDB \u2014 ho ottenuto un valore stimato di 125.000 valori al secondo.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesto \u00e8 un 'setup' operativo, che pu\u00f2 funzionare a lungo. Ma poich\u00e9 il mio disco era solo di 1,5 TB, l'ho riempito in pochi giorni.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 sono state create nuove partizioni TimescaleDB.<\/p>\n<p>Per le prestazioni ci\u00f2 \u00e8 completamente invisibile. Quando le partizioni vengono create in MySQL, ad esempio, tutto \u00e8 diverso. Di solito avviene di notte, perch\u00e9 blocca l'inserimento complessivo, il lavoro con le tabelle e pu\u00f2 causare degradazione del servizio. Nel caso di TimescaleDB, questo non avviene.<\/p>\n<p>Per esempio, mostrer\u00f2 un grafico tra i tanti nella community. Nell'immagine \u00e8 attivato TimescaleDB, grazie al quale il carico sullo utilizzo di io.weight della CPU \u00e8 diminuito. Anche l'uso degli elementi dei processi interni \u00e8 sceso. Inoltre, si tratta di una normale macchina virtuale con normali dischi a piatto, non SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Alte prestazioni e partizionamento nativo: Zabbix con supporto per 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 piccoli 'setup'<\/strong>, che si bloccano sulle prestazioni del disco. Permetter\u00e0 di continuare a lavorare bene fino alla migrazione del database su hardware pi\u00f9 veloce.<\/p>\n<p>TimescaleDB \u00e8 semplice da configurare, offre un aumento delle prestazioni, funziona bene con Zabbix e <strong>ha vantaggi rispetto a PostgreSQL<\/strong>.<\/p>\n<p>Se utilizzate PostgreSQL e non prevedete di cambiarlo, consiglio di <strong>utilizzare PostgreSQL con l'estensione TimescaleDB in combinazione con Zabbix<\/strong>. Questa soluzione funziona efficacemente fino a 'setup' di media dimensione.<\/p>\n<blockquote>\n<p>Parlando di \"alta prestazione\" \u2014 intendiamo <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. Aspettare di conoscere le tecnologie e le pratiche che permettono ai servizi di gestire milioni di utenti non richieder\u00e0 molto tempo. Elenco <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">dei rapporti<\/a><\/noindex> per il 7 e 8 novembre lo abbiamo gi\u00e0 preparato, ma <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">meetup<\/a><\/noindex> possono essere ulteriormente proposti.<\/p>\n<p>Seguiteci nel nostro <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 novit\u00e0 della conferenza in arrivo e scopri come ottenere il massimo beneficio.<\/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 5.0.2 - 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.\" \/>\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) 5.0.2\" \/>\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.\" \/>\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 performance e partizionamento nativo: Zabbix con supporto per TimescaleDB | ProHoster","description":"Zabbix \u00e8 un sistema di monitoraggio.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}