{"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 numero elevato di oggetti di monitoraggio","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Per il monitoraggio dei server e dei servizi utilizziamo da tempo, e con successo, una soluzione combinata basata su Nagios e Munin. Tuttavia, questa combinazione presenta diversi svantaggi, quindi noi, come molti altri, sfruttiamo attivamente Zabbix<\/a><\/noindex>. In questo articolo parleremo di come, con pochi sforzi, \u00e8 possibile risolvere il problema delle prestazioni legato all'aumento del numero di metriche raccolte e alla crescita delle dimensioni 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 di metriche memorizzate in esso era ridotto, tutto funzionava perfettamente. Il processo standard housekeeper, che viene eseguito dal server Zabbix, eliminava con successo i record obsoleti dal database, impedendone la crescita. Tuttavia, non appena il numero di metriche raccolte \u00e8 aumentato e il volume del database ha raggiunto una certa dimensione, le cose sono cambiate. L'housekeeper ha smesso di riuscire a eliminare i dati entro il tempo assegnato, rimanendo nel database dati obsoleti. Durante il funzionamento dell'housekeeper si \u00e8 generato un carico maggiore sul server Zabbix, che poteva persistere a lungo. \u00c8 diventato chiaro che era necessario risolvere la situazione.<\/p>\n

Questo \u00e8 un problema noto, praticamente chiunque abbia lavorato con grandi volumi di monitoraggio su Zabbix si \u00e8 trovato di fronte alla stessa situazione. Ci sono state diverse soluzioni: ad esempio, sostituire MySQL con PostgreSQL o persino Elasticsearch, ma la soluzione pi\u00f9 semplice e collaudata \u00e8 stata quella di passare alla partizione delle tabelle che memorizzano i dati delle metriche nel database MySQL. Abbiamo deciso di seguire proprio questo percorso.<\/p>\n

Passaggio da tabelle MySQL semplici a tabelle partizionate<\/h3>\n

\nZabbix \u00e8 ben documentato e le tabelle dove memorizza le metriche sono conosciute. Queste tabelle sono: la cronologia<\/code>, dove vengono memorizzati i valori float, history_str<\/code>, dove vengono memorizzati i valori stringa brevi, history_text<\/code>, dove vengono memorizzati i valori di testo lunghi e history_uint<\/code>, dove vengono memorizzati i valori interi. C'\u00e8 anche una tabella trends<\/code>, che memorizza la dinamica delle variazioni, ma abbiamo deciso di non modificarla, poich\u00e9 la sua dimensione \u00e8 contenuta e pi\u00f9 avanti torneremo su di essa.<\/p>\n

In generale, era chiaro quali tabelle dovevamo elaborare. Abbiamo deciso di creare partizioni per ogni settimana, ad eccezione dell'ultima, basandoci sui numeri del mese, ovvero 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 tabelle partizionate \"al volo\", senza interrompere il funzionamento di Zabbix Server e la raccolta delle metriche.<\/p>\n

Stranamente, a darci una mano \u00e8 stata la stessa struttura dei dati delle tabelle. Ad esempio, la tabella la cronologia <\/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
\ninoltre<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nCome possiamo vedere, ogni metrica alla fine viene registrata nella tabella con due campi molto importanti e utili per noi itemid<\/b> e clock<\/b>. In questo modo, possiamo facilmente creare una tabella temporanea, ad esempio, di nome history_tmp<\/code>, configurare la partizionamento per essa e quindi trasferire tutti i dati dalla tabella la cronologia<\/code>, e poi rinominare la tabella la cronologia<\/code> in history_old<\/code>, e la tabella history_tmp<\/code> in la cronologia<\/code>, dopodich\u00e9 possiamo inserire i dati che non abbiamo ancora trasferito da history_old<\/code> in la cronologia <\/code>e rimuovere history_old<\/code>. Facendo questo possiamo farlo in modo completamente sicuro, non perderemo nulla, poich\u00e9 i campi sopra menzionati itemid <\/b>e clock <\/b>garantiscono l'associazione di una metrica specifica a un orario specifico, e non a un numero di sequenza.<\/p>\n
La procedura stessa del passaggio<\/h3>\n
<\/p>\n
Attenzione! \u00c8 molto consigliato, prima di iniziare qualsiasi azione, effettuare un backup completo del database. Siamo tutti persone e possiamo commettere errori nell'immissione dei 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 piuttosto che nessuno.<\/p><\/blockquote>\n
 Quindi, non spegniamo nulla e non fermiamo nulla. L'importante \u00e8 che sul server MySQL ci sia una sufficiente quantit\u00e0 di spazio libero su disco, cio\u00e8 che per ognuna delle tabelle sopra menzionate la cronologia<\/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 essa avr\u00e0 lo stesso volume della tabella originale.<\/p>\n
Non descriveremo tutto pi\u00f9 volte per ciascuna delle tabelle sopra menzionate e considereremo tutto solo per esempio una di esse \u2014 la tabella la cronologia<\/code>.<\/p>\n
Quindi, creiamo una tabella vuota history_tmp <\/code>basata sulla struttura della tabella la cronologia<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nCreiamo le partizioni di cui abbiamo bisogno. Per esempio, faremo questo per un mese. Ogni partizione \u00e8 creata sulla base di una regola di partizionamento, che si basa 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 alla tabella che abbiamo creato. history_tmp<\/code>Precisiamo che i dati il cui valore del campo clock <\/b>\u00e8 inferiore a \u00ab2019-02-01 00:00:00\u00bb andranno nella partizione p20190201<\/i>, poi i dati il cui valore del campo clock<\/b> \u00e8 maggiore di \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 il cui valore del campo clock \u00e8 maggiore o uguale a \u00ab2019-03-01 00:00:00\u00bb? Poich\u00e9 non esiste una partizione adatta per questi dati, non entreranno nella tabella e verranno persi. Pertanto, \u00e8 necessario non dimenticare di creare tempestivamente ulteriori partizioni per evitare tali perdite di dati (di cui si parler\u00e0 pi\u00f9 avanti).<\/p><\/blockquote>\n
 Quindi, la tabella temporanea \u00e8 pronta. Carichiamo i dati. Il processo pu\u00f2 richiedere del tempo, ma fortunatamente non blocca altre richieste, quindi \u00e8 sufficiente avere un po\u2019 di 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 durante il caricamento dei dati successivo. Inoltre, pu\u00f2 essere utile se durante il caricamento dei dati bisogna interrompere il processo e ricominciare.<\/p>\n
Quindi, dopo un po' di tempo (potrebbe volerci anche qualche ora), il primo caricamento dei dati \u00e8 andato a buon fine. Come potete capire, ora la tabella history_tmp <\/code>contiene solo alcuni dei dati dalla tabella la cronologia<\/code>, e solo quelli che erano presenti al momento dell'inizio dell'esecuzione della query. Qui avete essenzialmente due opzioni: o facciamo un altro passaggio (se il processo di caricamento \u00e8 durato a lungo) o passiamo direttamente alla rinomina delle tabelle, di cui si \u00e8 parlato sopra. Iniziamo dal secondo passaggio. Per prima cosa dobbiamo capire l'orario dell'ultima registrazione inserita in history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupponiamo di aver ottenuto: 1551045645<\/b>. Ora usiamo il valore ottenuto nella seconda fase di inserimento dei dati:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nQuesta fase dovrebbe finire significativamente pi\u00f9 velocemente. Ma se la prima fase ha impiegato ore e la seconda sta richiedendo anch'essa molto tempo, potrebbe essere opportuno eseguire una terza fase, che funzioner\u00e0 esattamente come la seconda.<\/p>\n
Alla fine, eseguiamo di nuovo l'operazione per ottenere il tempo dell'ultima registrazione inserita in history_tmp<\/code>, eseguendo:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupponiamo che tu abbia ottenuto 1551085645<\/b>. Salva questo valore: ci servir\u00e0 per l'inserimento aggiuntivo.<\/p>\n
Ora, precisamente, quando il caricamento iniziale dei dati in history_tmp <\/code>\u00e8 terminato, iniziamo a rinominare le tabelle:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nAbbiamo configurato questo blocco come una singola transazione per evitare l'inserimento di dati in una tabella non esistente, poich\u00e9 dopo il primo RENAME e prima dell'esecuzione del secondo RENAME, la tabella la cronologia <\/code>non esister\u00e0 pi\u00f9. Ma anche se tra le operazioni RENAME arrivano alcuni dati e la tabella non esiste ancora (a causa della rinominazione), otterremo un numero limitato di errori di inserimento, che possiamo trascurare (siamo in monitoraggio, non in banca). la cronologia <\/code>Ora abbiamo una nuova tabella<\/p>\n
con partizionamento, ma manca dei dati che sono stati acquisiti durante l'ultimo ciclo di inserimento nella tabella la cronologia<\/code> . Ma questi dati li abbiamo nella tabella history_tmp<\/code>e ora li caricheremo da l\u00ec. Per fare questo, ci serve il valore precedentemente salvato 1551085645. Perch\u00e9 abbiamo salvato questo valore e non abbiamo utilizzato il tempo massimo di inserimento gi\u00e0 dalla tabella attuale history_old <\/code>INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645; la cronologia<\/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
Dopo il termine di questa operazione, abbiamo nella nuova tabella partizionata<\/code><\/pre>\n
\ntutti i dati che erano nella vecchia, pi\u00f9 quelli che sono gi\u00e0 arrivati dopo la rinominazione della tabella. La tabella la cronologia <\/code>non ci serve pi\u00f9. Possiamo eliminarla subito oppure, se sei particolarmente cauto, fare un backup prima di eliminarla. history_old <\/code>\u00c8 necessario ripetere l'intero processo descritto sopra per le tabelle<\/p>\n
Cosa deve essere corretto nelle impostazioni di Zabbix Server history_str<\/code>, history_text <\/code>e history_uint<\/code>.<\/p>\n
Cosa deve essere corretto nelle impostazioni del Zabbix Server<\/h3>\n
\nOra la gestione del database riguardante la storia dei dati ricade sulle nostre spalle. Ci\u00f2 significa che Zabbix non deve pi\u00f9 eliminare i dati obsoleti \u2014 ci penseremo noi. Affinch\u00e9 Zabbix Server non tenti di pulire i dati da solo, devi accedere all'interfaccia web di Zabbix, selezionare nel menu 'Amministrazione', poi il sottomenu 'Generale', quindi nel menu a tendina a destra scegliere 'Pulizia della storia'. Nella pagina che appare, dovrai deselezionare tutte le caselle per il gruppo 'Storia' e cliccare sul pulsante 'Aggiorna'. Questo previene la pulizia non necessaria delle tabelle. history*<\/code> tramite housekeeper.<\/p>\n
Nota anche su questa pagina il gruppo 'Dinamica delle modifiche'. Questa \u00e8 precisamente la tabella trends<\/code>, alla quale ci eravamo promessi di tornare. Se \u00e8 diventata anche essa troppo grande e necessita di partizionamento, deseleziona le caselle anche in questo gruppo, poi gestisci questa tabella esattamente come hai fatto per le tabelle history*<\/code>.<\/p>\n
Ulteriore manutenzione del database<\/h3>\n
\nCome gi\u00e0 accennato, per un funzionamento normale delle tabelle partizionate, \u00e8 necessario creare le partizioni in tempo. Puoi farlo in questo 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, la rimozione dei dati obsoleti \u00e8 ora nostra responsabilit\u00e0. Per fortuna, non ci sono problemi al riguardo. Questo si fa semplicemente eliminando quella partizione, i dati della quale non ci servono pi\u00f9. <\/p>\n
Ad esempio:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nA differenza degli operatori DELETE FROM con specifica dell'intervallo di date, DROP PARTITION viene eseguito in pochi secondi, senza carico eccessivo server<\/a> e funziona altrettanto bene nel caso venga utilizzato nella replica MySQL.<\/p>\n
Conclusione<\/h3>\n
\nLa soluzione descritta \u00e8 collaudata nel tempo. Il volume dei dati cresce, ma non si riscontrano rallentamenti significativi 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}]}}