{"id":53966,"date":"2019-12-14T00:00:00","date_gmt":"2019-12-13T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa"},"modified":"2020-02-18T14:01:55","modified_gmt":"2020-02-18T11:01:55","slug":"ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Utilizzo del partizionamento in MySQL per Zabbix con un ampio numero di oggetti di monitoraggio","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Per il monitoraggio di server e servizi utilizziamo da tempo e con successo una soluzione combinata basata su Nagios e Munin. Tuttavia, questa combinazione presenta alcuni svantaggi, quindi, come molti, stiamo sfruttando attivamente Zabbix<\/a><\/noindex>. In questo articolo parleremo di come risolvere il problema delle prestazioni con minimi sforzi, quando aumenta il numero delle metriche raccolte e cresce il volume del database MySQL
\n<\/a><\/noindex><\/p>\n

Problemi nell'uso del database MySQL insieme a Zabbix<\/h3>\n

\nFino a quando il database era piccolo e il numero delle metriche memorizzate era ridotto, tutto funzionava alla perfezione. Il processo housekeeper, che viene avviato dal server Zabbix, eliminava con successo le registrazioni obsolete dal database, impedendone la crescita. Tuttavia, non appena il numero delle metriche raccolte \u00e8 aumentato e il volume del database ha raggiunto una certa dimensione, la situazione \u00e8 peggiorata. L'housekeeper non riusciva a eliminare i dati nel tempo previsto, lasciando nel database vecchi dati. Durante il funzionamento dell'housekeeper, si verificava un carico eccessivo sul server Zabbix, che poteva durare a lungo. \u00c8 diventato chiaro che era necessario affrontare questa situazione.<\/p>\n

Questo \u00e8 un problema noto; praticamente chiunque abbia lavorato con grandi volumi di monitoraggio su Zabbix ha incontrato la stessa difficolt\u00e0. Anche le soluzioni erano diverse: ad esempio, sostituire MySQL con PostgreSQL o addirittura Elasticsearch, ma la soluzione pi\u00f9 semplice e testata era quella di passare alla partizionatura delle tabelle che memorizzano i dati delle metriche nel database MySQL. Decidemmo di seguire proprio questa strada.<\/p>\n

Transizione da tabelle MySQL standard a tabelle partizionate<\/h3>\n

\nZabbix \u00e8 ben documentato e le tabelle in cui memorizza le metriche sono conosciute. Queste tabelle sono: history<\/code>, dove vengono memorizzati valori float, history_str<\/code>, dove vengono memorizzati valori stringa brevi, history_text<\/code>, dove vengono memorizzati valori di testo lunghi e history_uint<\/code>, dove vengono memorizzati valori interi. C'\u00e8 anche una tabella trends<\/code>, che memorizza l'andamento delle variazioni, ma abbiamo deciso di non toccarla, poich\u00e9 la sua dimensione \u00e8 ridotta e pi\u00f9 avanti ci torneremo.<\/p>\n

In generale, era chiaro quali tabelle dovevano essere trattate. Decidemmo di creare partizioni settimanali, ad eccezione dell'ultima, basate sui numeri del mese, ossia quattro partizioni al mese: dal 1 al 7, dall'8 al 14, dal 15 al 21 e dal 22 al 1 del mese successivo. La difficolt\u00e0 stava nel dover trasformare le tabelle necessarie in partizionate \"al volo\", senza interrompere il funzionamento del server Zabbix e la raccolta delle metriche.<\/p>\n

Stranamente, la struttura dei dati delle tabelle ci \u00e8 stata d'aiuto. Ad esempio, la tabella history <\/code>ha la seguente struttura:<\/p>\n

`itemid` bigint(20) unsigned NOT NULL,\n`clock` int(11) NOT NULL DEFAULT '0',\n`value` double(16,4) NOT NULL DEFAULT '0.0000',\n`ns` int(11) NOT NULL DEFAULT '0',<\/code><\/pre>\n
\ncon<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nCome possiamo vedere, ogni metrica viene infatti inserita nella tabella con due campi molto importanti e utili per noi itemid<\/b> e clock<\/b>. In questo modo, possiamo tranquillamente creare una tabella temporanea, per esempio chiamata history_tmp<\/code>, impostare la partizione per essa e poi trasferire tutti i dati dalla tabella history<\/code>, e successivamente rinominare la tabella history<\/code> in history_old<\/code>, e la tabella history_tmp<\/code> in history<\/code>, dopodich\u00e9 aggiungere nuovamente i dati che ci mancano da history_old<\/code> in history <\/code>e cancellare history_old<\/code>. \u00c8 possibile farlo in modo assolutamente sicuro; non perderemo nulla, poich\u00e9 i campi sopra indicati itemid <\/b>e clock <\/b>garantiscono l'associazione di una specifica metrica a un preciso momento, e non a un qualche numero di ordine.<\/p>\n
Procedura di transizione<\/h3>\n
<\/p>\n
Attenzione! \u00c8 vivamente consigliato, prima di iniziare qualsiasi azione, fare un backup completo del database. Siamo tutti esseri umani e possiamo commettere errori nel set di comandi, il che potrebbe portare alla perdita di dati. S\u00ec, un backup non garantir\u00e0 la massima attualit\u00e0, ma \u00e8 meglio averne uno che niente.<\/p><\/blockquote>\n
 Quindi, non spegniamo n\u00e9 arrestiamo nulla. L'importante \u00e8 che sul server MySQL ci sia un sufficiente spazio libero su disco, cio\u00e8 che per ciascuna delle tabelle elencate sopra history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, ci sia almeno spazio sufficiente per creare una tabella con il suffisso \"_tmp\", considerando che avr\u00e0 lo stesso volume della tabella originale.<\/p>\n
Non descriveremo tutto pi\u00f9 volte per ciascuna delle tabelle menzionate e considereremo il tutto con un esempio solo di una di esse \u2014 la tabella history<\/code>.<\/p>\n
Quindi, creiamo una tabella vuota history_tmp <\/code>basata sulla struttura della tabella history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nCreiamo le partizioni necessarie. Per esempio, facciamolo su base mensile. Ogni partizione viene creata in base a una regola di partizione, basata sul valore del campo clock<\/b>, che confrontiamo con il timestamp:<\/p>\n
ALTER TABLE `history_tmp` PARTITION BY RANGE(clock) (\nPARTITION p20190201 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-01 00:00:00\")),\nPARTITION p20190207 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-07 00:00:00\")),\nPARTITION p20190214 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-14 00:00:00\")),\nPARTITION p20190221 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-02-21 00:00:00\")),\nPARTITION p20190301 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-01 00:00:00\"))\n);<\/code><\/pre>\n
\nQuesto operatore aggiunge la partizione per la tabella che abbiamo creato. history_tmp<\/code>Chiariremo che i dati in cui il valore del campo clock <\/b>\u00e8 inferiore a \u00ab2019-02-01 00:00:00\u00bb andranno nella partizione p20190201<\/i>e poi i dati in cui il valore del campo clock<\/b> \u00e8 superiore a \u00ab2019-02-01 00:00:00\u00bb ma inferiore a \u00ab2019-02-07 00:00:00\u00bb andranno nella partizione p20190207 <\/i>e cos\u00ec via.<\/p>\n
Nota importante:<\/b> Cosa succede se nella nostra tabella partizionata compaiono dati in cui il valore del campo clock \u00e8 maggiore o uguale a \u00ab2019-03-01 00:00:00\u00bb? Poich\u00e9 non esiste una partizione adeguata per questi dati, non verranno inclusi nella tabella e andranno persi. Pertanto, \u00e8 necessario ricordarsi di creare partizioni aggiuntive in tempo per evitare tali perdite di dati (di cui parleremo pi\u00f9 avanti).<\/p><\/blockquote>\n
 Ora la tabella temporanea \u00e8 pronta. Carichiamo i dati. Il processo pu\u00f2 richiedere molto tempo, ma per fortuna non blocca altre query, quindi basta avere pazienza:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nLa parola chiave IGNORE non \u00e8 obbligatoria durante il caricamento iniziale, poich\u00e9 non ci sono dati nella tabella, ma sar\u00e0 necessaria per il caricamento successivo. Inoltre, pu\u00f2 essere utile se il processo di caricamento \u00e8 stato interrotto e deve essere ripreso da capo.<\/p>\n
Quindi, dopo un po' di tempo (potrebbero anche essere diverse ore), il primo caricamento dei dati \u00e8 concluso. Come puoi capire, ora la tabella history_tmp <\/code>contiene solo alcuni dati dalla tabella history<\/code>, e solo quelli che erano presenti al momento dell'esecuzione della query. Qui hai sostanzialmente due opzioni: puoi effettuare un ulteriore passaggio (se il processo di caricamento \u00e8 durato a lungo) o procedere immediatamente con la rinominazione delle tabelle, come accennato prima. Parliamo prima del secondo passaggio. Per prima cosa, dobbiamo determinare l'orario dell'ultima registrazione inserita in history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupponiamo tu abbia ottenuto: 1551045645<\/b>. Ora utilizziamo il valore ottenuto per il secondo passaggio di caricamento dei dati:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nQuesto passaggio dovrebbe concludersi notevolmente pi\u00f9 rapidamente. Ma se il primo passaggio ha richiesto ore e il secondo richiede ancora molto tempo, potrebbe essere corretto eseguire anche un terzo passaggio, eseguito esattamente come il secondo.<\/p>\n
Alla fine, eseguiamo di nuovo l'operazione per ottenere l'orario dell'ultima registrazione inserita in history_tmp<\/code>, eseguendo:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupponiamo tu abbia ottenuto 1551085645<\/b>. Salva questo valore, ci servir\u00e0 per il caricamento successivo.<\/p>\n
E ora, dopo che il caricamento iniziale dei dati in history_tmp <\/code>\u00e8 terminato, procediamo alla rinominazione delle tabelle:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nAbbiamo organizzato questo blocco come una singola transazione per evitare l'inserimento di dati in una tabella inesistente, poich\u00e9 dopo il primo RENAME fino a quando non viene eseguito il secondo RENAME, la tabella history <\/code>non esister\u00e0. Ma anche se durante le operazioni di RENAME arrivano dei dati nella tabella, e la tabella non esister\u00e0 ancora (a causa della rinominazione), avremo solo un numero ridotto di errori di inserimento, che possono essere trascurati (stiamo monitorando, non facendo banca). history <\/code>Ora abbiamo una nuova tabella<\/p>\n
Ora abbiamo una nuova tabella history<\/code> con la partizione, ma mancano i dati che sono stati acquisiti durante l'ultimo passaggio di inserimento dei dati nella tabella history_tmp<\/code>. Ma questi dati li abbiamo nella tabella history_old <\/code>e li caricheremo da l\u00ec. Per questo, avremo bisogno del valore precedentemente salvato, 1551085645. Perch\u00e9 abbiamo salvato questo valore invece di utilizzare il tempo massimo di caricamento gi\u00e0 dalla tabella attuale? history<\/code>? \u041f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043d\u043e\u0432\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u0443\u0436\u0435 \u0432 \u043d\u0435\u0451 \u043f\u043e\u0441\u0442\u0443\u043f\u0430\u044e\u0442 \u0438 \u043c\u044b \u043f\u043e\u043b\u0443\u0447\u0438\u043c \u043d\u0435\u0432\u0435\u0440\u043d\u043e\u0435 \u0432\u0440\u0435\u043c\u044f. \u0418\u0442\u0430\u043a, \u0434\u043e\u0437\u0430\u043b\u0438\u0432\u0430\u0435\u043c \u0434\u0430\u043d\u043d\u044b\u0435:<\/p>\n
INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645;<\/code><\/pre>\n
\nDopo aver completato questa operazione, nella nuova tabella partizionata history <\/code>abbiamo tutti i dati che erano nella precedente, pi\u00f9 quelli che sono gi\u00e0 arrivati dopo la rinominazione della tabella. La tabella history_old <\/code>non \u00e8 pi\u00f9 necessaria. Puoi eliminarla subito o, se sei preoccupato, fare un backup prima di eliminarla.<\/p>\n
L'intero processo descritto sopra deve essere ripetuto per le tabelle history_str<\/code>, history_text <\/code>e history_uint<\/code>.<\/p>\n
Cosa bisogna modificare nelle impostazioni del Zabbix Server<\/h3>\n
\nOra la manutenzione del database riguardante la storicit\u00e0 dei dati ricade su di noi. Ci\u00f2 significa che Zabbix non deve pi\u00f9 eliminare dati obsoleti \u2014 ci occuperemo noi di questo. Affinch\u00e9 Zabbix Server non tenti di pulire i dati autonomamente, \u00e8 necessario accedere all'interfaccia web di Zabbix, selezionare nel menu \"Amministrazione\", quindi il sottomenu \"Generale\", e infine nel menu a discesa a destra selezionare \"Cancellazione della storia\". Nella pagina risultante, deseleziona tutte le caselle per il gruppo \"Storia\" e fai clic sul pulsante \"Aggiorna\". Questo eviter\u00e0 la pulizia non necessaria delle tabelle history*<\/code> tramite il housekeeper.<\/p>\n
Nota anche in questa pagina il gruppo \"Dinamiche di cambiamento\". Questa \u00e8 proprio la tabella trends<\/code>, a cui abbiamo promesso di tornare. Se \u00e8 diventata troppo grande e ha bisogno di partizionamento, deseleziona le caselle in questo gruppo e poi gestisci questa tabella esattamente come hai fatto per le tabelle precedenti. history*<\/code>.<\/p>\n
Ulteriore manutenzione del database<\/h3>\n
\nCome gi\u00e0 accennato, per un corretto funzionamento delle tabelle partizionate, \u00e8 necessario creare partizioni in tempo. Questo pu\u00f2 essere fatto nel seguente modo:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nInoltre, poich\u00e9 abbiamo creato tabelle partizionate e vietato a Zabbix Server di pulirle, ora siamo noi a occuparci della rimozione dei dati obsoleti. Fortunatamente, qui non ci sono problemi. Si fa semplicemente eliminando la partizione i cui dati non ci servono pi\u00f9. <\/p>\n
Ad esempio:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nA differenza delle istruzioni DELETE FROM con intervallo di date, il comando DROP PARTITION viene eseguito in pochi secondi e non genera alcun carico. un server<\/a> Funziona altrettanto bene anche in caso di utilizzo della replica MySQL.<\/p>\n
Conclusione<\/h3>\n
\nLa soluzione descritta \u00e8 collaudata nel tempo. Il volume dei dati aumenta, ma non si nota alcun rallentamento delle prestazioni.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin. \u041e\u0434\u043d\u0430\u043a\u043e \u044d\u0442\u0430 \u0441\u0432\u044f\u0437\u043a\u0430 \u0438\u043c\u0435\u0435\u0442 \u0440\u044f\u0434 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u043e\u0432, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043c\u044b, \u043a\u0430\u043a \u0438 \u043c\u043d\u043e\u0433\u0438\u0435, \u0430\u043a\u0442\u0438\u0432\u043d\u043e \u044d\u043a\u0441\u043f\u043b\u0443\u0430\u0442\u0438\u0440\u0443\u0435\u043c Zabbix. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043c\u0438\u043d\u0438\u043c\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0443\u0441\u0438\u043b\u0438\u044f\u043c\u0438 \u043c\u043e\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443 \u0441 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u0438 \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u0438 \u0447\u0438\u0441\u043b\u0430 \u0441\u043d\u0438\u043c\u0430\u0435\u043c\u044b\u0445 \u043c\u0435\u0442\u0440\u0438\u043a \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53966","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Utilizzo del partizionamento in MySQL per Zabbix con un gran numero di oggetti di monitoraggio | ProHoster","description":"Per il monitoraggio dei server e dei servizi, utilizziamo da tempo e con successo una soluzione combinata basata su Nagios e Munin.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","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\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 MySQL \u0434\u043b\u044f Zabbix \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u043e\u0431\u044a\u0435\u043a\u0442\u043e\u0432 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 | ProHoster","og:description":"\u0414\u043b\u044f \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u0438 \u0441\u043b\u0443\u0436\u0431 \u0443 \u043d\u0430\u0441 \u0434\u0430\u0432\u043d\u043e, \u0438 \u0432\u0441\u0435 \u0435\u0449\u0435 \u0443\u0441\u043f\u0435\u0448\u043d\u043e, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043d\u0430 \u0431\u0430\u0437\u0435 Nagios \u0438 Munin.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","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-12-13T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53966","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-24 09:31:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:14:29","updated":"2026-01-24 09:31:21","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\/53966","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=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}