{"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\/es\/blog\/administrirovanie\/ispolzovanie-partitsionirovaniya-v-mysql-dlya-zabbix-s-bolshim-kolichestvom-obektov-monitoringa","title":{"rendered":"Uso de particionamiento en MySQL para Zabbix con un gran n\u00famero de objetos de monitoreo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Para la supervisi\u00f3n de servidores y servicios, hemos utilizado durante mucho tiempo, y a\u00fan seguimos utilizando con \u00e9xito, una soluci\u00f3n combinada basada en Nagios y Munin. Sin embargo, esta combinaci\u00f3n tiene una serie de desventajas, por lo que nosotros, al igual que muchos otros, explotamos activamente Zabbix<\/a><\/noindex>. En este art\u00edculo, hablaremos de c\u00f3mo se puede resolver el problema de rendimiento con un esfuerzo m\u00ednimo a medida que aumenta el n\u00famero de m\u00e9tricas recopiladas y el crecimiento de las bases de datos MySQL.
\n<\/a><\/noindex><\/p>\n

Problemas del uso de bases de datos MySQL junto con Zabbix<\/h3>\n

\nMientras la base de datos era peque\u00f1a y el n\u00famero de m\u00e9tricas almacenadas era reducido, todo funcionaba estupendamente. El proceso integrado housekeeper, que ejecuta el propio Zabbix Server, eliminaba con \u00e9xito los registros obsoletos de la base de datos, evitando que creciera. Sin embargo, cuando el n\u00famero de m\u00e9tricas recopiladas creci\u00f3 y el volumen de la base de datos alcanz\u00f3 un cierto tama\u00f1o, todo empeor\u00f3. El housekeeper dej\u00f3 de poder eliminar datos en el tiempo asignado, quedando datos antiguos en la base de datos. Durante la operaci\u00f3n del housekeeper, hab\u00eda una carga aumentada en el Zabbix Server, que podr\u00eda persistir durante mucho tiempo. Se hizo evidente que hab\u00eda que encontrar una soluci\u00f3n a la situaci\u00f3n.<\/p>\n

Este es un problema conocido; pr\u00e1cticamente todos los que han trabajado con grandes vol\u00famenes de monitoreo en Zabbix se han encontrado con esto. Tambi\u00e9n hubo varias soluciones: por ejemplo, cambiar MySQL por PostgreSQL o incluso Elasticsearch, pero la soluci\u00f3n m\u00e1s simple y probada fue la transici\u00f3n al particionamiento de las tablas que almacenan datos de m\u00e9tricas en la base de datos MySQL. Decidimos ir precisamente por este camino.<\/p>\n

Transici\u00f3n de tablas MySQL normales a particionadas<\/h3>\n

\nZabbix est\u00e1 bien documentado y las tablas donde almacena m\u00e9tricas son conocidas. Estas tablas son: history<\/code>, donde se almacenan valores float, history_str<\/code>, donde se almacenan valores de cadena cortos, history_text<\/code>, donde se almacenan valores de texto largos y history_uint<\/code>, donde se almacenan valores enteros. Tambi\u00e9n hay una tabla trends<\/code>, que almacena la din\u00e1mica de los cambios, pero decidimos no tocarla, ya que su tama\u00f1o es peque\u00f1o y m\u00e1s tarde volveremos a ella.<\/p>\n

En general, era claro qu\u00e9 tablas deb\u00edan ser procesadas. Decidimos hacer particiones semanales, excepto la \u00faltima, bas\u00e1ndonos en los n\u00fameros del mes, es decir, cuatro particiones por mes: del 1 al 7, del 8 al 14, del 15 al 21 y del 22 al 1 (del mes siguiente). La dificultad radicaba en que ten\u00edamos que convertir las tablas necesarias en particionadas \"al vuelo\", sin interrumpir el funcionamiento de Zabbix Server y la recolecci\u00f3n de m\u00e9tricas.<\/p>\n

Curiosamente, la propia estructura de los datos de las tablas nos ayud\u00f3 en esto. Por ejemplo, la tabla history <\/code>tiene la siguiente estructura:<\/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
\nen la que<\/p>\n
KEY `history_1` (`itemid`,`clock`)<\/code><\/pre>\n
\nComo podemos ver, cada m\u00e9trica se registra en la tabla con dos campos muy importantes y convenientes para nosotros, itemid<\/b> y clock<\/b>. De esta manera, podemos crear una tabla temporal, por ejemplo, llamada history_tmp<\/code>, configurar la partici\u00f3n para ella y luego volcar todos los datos de la tabla history<\/code>, y despu\u00e9s renombrar la tabla history<\/code> en history_old<\/code>, y la tabla history_tmp<\/code> en history<\/code>, despu\u00e9s de lo cual a\u00f1adimos los datos que nos faltan de history_old<\/code> en history <\/code>y eliminamos history_old<\/code>. Esto se puede hacer de manera absolutamente segura, no perderemos nada, ya que los campos mencionados anteriormente itemid <\/b>y clock <\/b>aseguran la vinculaci\u00f3n de una m\u00e9trica espec\u00edfica a un tiempo concreto, no a un n\u00famero de orden.<\/p>\n
El propio procedimiento de transici\u00f3n<\/h3>\n
<\/p>\n
\u00a1Atenci\u00f3n! Es muy recomendable, antes de realizar alguna acci\u00f3n, hacer una copia de seguridad completa de la base de datos. Todos somos humanos y podemos cometer errores en la introducci\u00f3n de comandos, lo que podr\u00eda llevar a la p\u00e9rdida de datos. S\u00ed, una copia de seguridad no garantizar\u00e1 la m\u00e1xima actualidad, pero es mejor tener una que no tener ninguna.<\/p><\/blockquote>\n
 As\u00ed que no apagamos ni detenemos nada. Lo principal es que en el servidor MySQL haya suficiente espacio libre en disco, es decir, que para cada una de las tablas mencionadas anteriormente history<\/code>, history_text<\/code>, history_str<\/code>, history_uint<\/code>, haya como m\u00ednimo espacio suficiente para crear una tabla con el sufijo \"_tmp\", considerando que tendr\u00e1 el mismo volumen que la tabla original.<\/p>\n
No vamos a describir todo varias veces para cada una de las tablas mencionadas y lo consideraremos solo con el ejemplo de una de ellas: la tabla history<\/code>.<\/p>\n
As\u00ed que, creamos una tabla vac\u00eda history_tmp <\/code>basada en la estructura de la tabla history<\/code>.<\/p>\n
CREATE TABLE `history_tmp` LIKE `history`;<\/code><\/pre>\n
\nCreamos las particiones que necesitamos. Para este ejemplo, haremos esto para un mes. Cada partici\u00f3n se crea en base a la regla de particionamiento basada en el valor del campo clock<\/b>, que estamos comparando con la marca de tiempo:<\/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
\nEste operador a\u00f1ade particionamiento a la tabla que hemos creado. history_tmp<\/code>Aclaramos que los datos cuyo valor en el campo clock <\/b>es menor a \"2019-02-01 00:00:00\" ir\u00e1n a la partici\u00f3n p20190201<\/i>, luego los datos cuyo valor en el campo clock<\/b> es mayor a \"2019-02-01 00:00:00\" pero menor a \"2019-02-07 00:00:00\" ir\u00e1n a la partici\u00f3n p20190207 <\/i>y as\u00ed sucesivamente.<\/p>\n
Una nota importante:<\/b> \u00bfQu\u00e9 suceder\u00e1 si en nuestra tabla particionada aparecen datos cuyo valor en el campo clock sea mayor o igual a \"2019-03-01 00:00:00\"? Dado que no hay una partici\u00f3n adecuada para estos datos, no llegar\u00e1n a la tabla y se perder\u00e1n. Por lo tanto, es necesario recordar crear particiones adicionales a tiempo para evitar tales p\u00e9rdidas de datos (como se menciona a continuaci\u00f3n).<\/p><\/blockquote>\n
 Bien, la tabla temporal est\u00e1 preparada. Cargamos los datos. El proceso puede tardar bastante tiempo, pero afortunadamente no bloquea otras consultas, as\u00ed que s\u00f3lo hay que tener paciencia:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history;<\/code><\/pre>\n
\nLa palabra clave IGNORE durante la carga inicial no es obligatoria, ya que no hay datos en la tabla, sin embargo, ser\u00e1 necesaria al cargar datos posteriormente. Adem\u00e1s, puede ser \u00fatil si tuviste que interrumpir el proceso de carga y empezarlo de nuevo.<\/p>\n
As\u00ed que, despu\u00e9s de un tiempo (posiblemente incluso varias horas), se complet\u00f3 la primera carga de datos. Como entender\u00e1s, ahora la tabla history_tmp <\/code>contiene no todos los datos de la tabla history<\/code>, sino solo aquellos que estaban en ella en el momento de iniciar la consulta. Aqu\u00ed, de hecho, tienes una elecci\u00f3n: podemos hacer otro pase (si el proceso de carga fue largo), o pasar directamente a renombrar las tablas, como se mencion\u00f3 anteriormente. Hablemos primero del segundo pase. Para comenzar, necesitamos entender el tiempo de la \u00faltima inserci\u00f3n en history_tmp<\/code>:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupongamos que obtuviste: 1551045645<\/b>Ahora utilizamos el valor obtenido en el segundo paso de la carga de datos:<\/p>\n
INSERT IGNORE INTO `history_tmp` SELECT * FROM history WHERE clock>=1551045645;<\/code><\/pre>\n
\nEste paso deber\u00eda terminar significativamente m\u00e1s r\u00e1pido. Pero si el primer paso tom\u00f3 horas y el segundo tambi\u00e9n toma un tiempo prolongado, puede ser correcto hacer un tercer paso que se ejecute de manera exactamente igual al segundo.<\/p>\n
Al final, volvemos a realizar la operaci\u00f3n para obtener el tiempo de la \u00faltima inserci\u00f3n del registro en history_tmp<\/code>, ejecutando:<\/p>\n
SELECT max(clock) FROM history_tmp;<\/code><\/pre>\n
\nSupongamos que has obtenido 1551085645<\/b>. Guarda este valor, ya que lo necesitaremos para la carga adicional.<\/p>\n
Y ahora, en efecto, cuando la carga inicial de datos en history_tmp <\/code>ha terminado, procedemos a renombrar las tablas:<\/p>\n
BEGIN;\nRENAME TABLE history TO history_old;\nRENAME TABLE history_tmp TO history;\nCOMMIT;<\/code><\/pre>\n
\nHemos estructurado este bloque como una transacci\u00f3n para evitar el momento de inserci\u00f3n de datos en una tabla inexistente, ya que despu\u00e9s del primer RENAME y antes de ejecutar el segundo RENAME, la tabla history <\/code>no existir\u00e1. Pero incluso si durante las operaciones RENAME llegan algunos datos a la tabla y la tabla a\u00fan no existir\u00e1 (debido al cambio de nombre), tendremos un peque\u00f1o n\u00famero de errores de inserci\u00f3n que se pueden ignorar (tenemos monitoreo, no es un banco). history <\/code>Ahora tenemos una nueva tabla<\/p>\n
con particionamiento, pero carece de datos que fueron obtenidos durante el \u00faltimo paso de inserci\u00f3n de datos en la tabla history<\/code> . Pero esos datos los tenemos en la tabla history_tmp<\/code>y los vamos a agregar desde all\u00ed ahora. Para esto, necesitaremos el valor guardado anteriormente 1551085645. \u00bfPor qu\u00e9 guardamos este valor en lugar de usar el tiempo m\u00e1ximo de inserci\u00f3n ya de la tabla actual? history_old <\/code>INSERT IGNORE INTO `history` SELECT * FROM history_old WHERE clock>=1551045645; 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
Una vez que esta operaci\u00f3n ha terminado, tenemos en la nueva tabla particionada<\/code><\/pre>\n
\ntodas las datos que estaban en la antigua, m\u00e1s los que ya llegaron despu\u00e9s de renombrar la tabla. La tabla history <\/code>ya no es necesaria. Se puede eliminar de inmediato, o se puede hacer una copia de seguridad antes de eliminarla (si tienes paranoia). history_old <\/code>Todo el proceso descrito anteriormente debe repetirse para las tablas<\/p>\n
Qu\u00e9 ajustes deben corregirse en la configuraci\u00f3n de Zabbix Server history_str<\/code>, history_text <\/code>y history_uint<\/code>.<\/p>\n
\u00bfQu\u00e9 se necesita corregir en la configuraci\u00f3n de Zabbix Server?<\/h3>\n
\nAhora, el mantenimiento de la base de datos en lo que respecta a la historia de datos recae en nosotros. Esto significa que Zabbix ya no debe eliminar datos antiguos; nosotros nos encargaremos de eso. Para que el servidor Zabbix no intente limpiar los datos por s\u00ed mismo, debe acceder a la interfaz web de Zabbix, seleccionar en el men\u00fa 'Administraci\u00f3n', luego el submen\u00fa 'General', y despu\u00e9s en el desplegable de la derecha seleccionar 'Limpiar historial'. En la p\u00e1gina que aparece, debe desmarcar todas las casillas para el grupo 'Historia' y hacer clic en el bot\u00f3n 'Actualizar'. Esto evitar\u00e1 la limpieza innecesaria de las tablas. historia*<\/code> a trav\u00e9s de housekeeper.<\/p>\n
Preste atenci\u00f3n en esta misma p\u00e1gina al grupo 'Din\u00e1mica de cambios'. Esta es exactamente la tabla trends<\/code>, a la que prometimos volver. Si tambi\u00e9n se ha vuelto demasiado grande y necesita particionarse, desmarque las casillas en este grupo, y luego procese esta tabla de la misma manera que se hizo con las tablas historia*<\/code>.<\/p>\n
Mantenimiento adicional de la base de datos<\/h3>\n
\nComo se mencion\u00f3 anteriormente, para un funcionamiento normal en tablas particionadas, es necesario crear particiones a tiempo. Esto se puede hacer as\u00ed:<\/p>\n
ALTER TABLE `history` ADD PARTITION (PARTITION p20190307 VALUES LESS THAN (UNIX_TIMESTAMP(\"2019-03-07 00:00:00\")));<\/code><\/pre>\n
\nAdem\u00e1s, dado que hemos creado tablas particionadas y prohibido que el servidor Zabbix las limpie, la eliminaci\u00f3n de datos antiguos ahora es nuestra responsabilidad. Afortunadamente, aqu\u00ed no hay ning\u00fan problema en absoluto. Esto se realiza simplemente eliminando la partici\u00f3n cuyos datos han dejado de ser \u00fatiles para nosotros. <\/p>\n
Por ejemplo:<\/p>\n
ALTER TABLE history DROP PARTITION p20190201;<\/code><\/pre>\n
\nA diferencia de los operadores DELETE FROM con un rango de fechas, DROP PARTITION se ejecuta en unos pocos segundos, no carga en absoluto servidor<\/a> y funciona de manera igualmente fluida en caso de ser utilizado en la replicaci\u00f3n de MySQL.<\/p>\n
Conclusi\u00f3n<\/h3>\n
\nLa soluci\u00f3n descrita ha sido probada en el tiempo. El volumen de datos crece, pero no se ha observado una desaceleraci\u00f3n notable en el rendimiento.
\n
Fuente: 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\udd47Uso de particionamiento en MySQL para Zabbix con un gran n\u00famero de objetos de monitoreo | ProHoster","description":"Para el monitoreo de servidores y servicios, hemos utilizado con \u00e9xito durante mucho tiempo una soluci\u00f3n combinada basada en Nagios y Munin.","canonical_url":"https:\/\/prohoster.info\/es\/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":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/53966","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=53966"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/53966\/revisions"}],"predecessor-version":[{"id":172868,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/53966\/revisions\/172868"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=53966"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=53966"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=53966"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}