{"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\/es\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix es un sistema de monitoreo. Al igual que cualquier otro sistema, enfrenta tres problemas principales comunes a todos los sistemas de monitoreo: recopilaci\u00f3n y procesamiento de datos, almacenamiento de historial y su limpieza.<\/p>\n<p>Las etapas de obtenci\u00f3n, procesamiento y grabaci\u00f3n de datos llevan tiempo. Un poco, pero para un sistema grande puede traducirse en grandes retrasos. El problema del almacenamiento es una cuesti\u00f3n de acceso a los datos. Se utilizan para informes, verificaciones y disparadores. Los retrasos en el acceso a los datos tambi\u00e9n afectan el rendimiento. A medida que las bases de datos crecen, los datos obsoletos deben eliminarse. La eliminaci\u00f3n es una operaci\u00f3n pesada que tambi\u00e9n consume parte de los recursos.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLos problemas de retrasos en la recopilaci\u00f3n y almacenamiento en Zabbix se resuelven mediante la cach\u00e9: varios tipos de cach\u00e9s, cach\u00e9 en la base de datos. Para solucionar el tercer problema, la cach\u00e9 no es adecuada, por lo que en Zabbix se ha utilizado TimescaleDB. De esto hablar\u00e1 <strong>Andrey Gushchin<\/strong> \u2014 ingeniero de soporte t\u00e9cnico <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrey tiene m\u00e1s de 6 a\u00f1os en el soporte de Zabbix y se enfrenta directamente al rendimiento.<\/p>\n<p>\u00bfC\u00f3mo funciona TimescaleDB? \u00bfQu\u00e9 rendimiento puede ofrecer en comparaci\u00f3n con PostgreSQL com\u00fan? \u00bfQu\u00e9 papel juega Zabbix para las bases de datos de TimescaleDB? \u00bfC\u00f3mo iniciar desde cero y c\u00f3mo migrar desde PostgreSQL y qu\u00e9 configuraci\u00f3n rinde mejor? Sobre todo esto, a continuaci\u00f3n.<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=\"Reproducir 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>Desaf\u00edos de rendimiento<\/h2>\n<p>\nCada sistema de monitoreo se enfrenta a desaf\u00edos de rendimiento espec\u00edficos. Hablar\u00e9 sobre tres de ellos: recopilaci\u00f3n y procesamiento de datos, almacenamiento, limpieza del historial.<\/p>\n<p><strong>Recopilaci\u00f3n y procesamiento de datos r\u00e1pidos. <\/strong>Un buen sistema de monitoreo debe recibir todos los datos r\u00e1pidamente y procesarlos seg\u00fan las expresiones de disparo \u2014 segun sus criterios. Despu\u00e9s del procesamiento, el sistema tambi\u00e9n debe guardar estos datos en la base de datos de manera r\u00e1pida para su posterior uso.<\/p>\n<p><strong>Almacenamiento del historial. <\/strong>Un buen sistema de monitoreo debe almacenar el historial en la base de datos y proporcionar acceso conveniente a las m\u00e9tricas. El historial es necesario para utilizarlo en informes, gr\u00e1ficos, disparadores, umbrales y elementos de datos calculados para alertas.<\/p>\n<p><strong>Limpieza del historial. <\/strong>A veces llega el d\u00eda en que no necesitas almacenar m\u00e9tricas. \u00bfPara qu\u00e9 necesitas datos recopilados hace 5 a\u00f1os, un mes o dos? Algunos nodos han sido eliminados, algunos anfitriones o m\u00e9tricas ya no son necesarios porque est\u00e1n obsoletos y dejaron de recopilarse. Un buen sistema de monitoreo debe almacenar datos hist\u00f3ricos y eliminarlos de vez en cuando para que la base de datos no crezca descontroladamente.<\/p>\n<blockquote><p>La limpieza de datos obsoletos es un tema cr\u00edtico que impacta significativamente en el rendimiento de la base de datos.<\/p><\/blockquote>\n<p><\/p>\n<h2>Caching en Zabbix<\/h2>\n<p>\nEn Zabbix, el primer y segundo llamado se resuelven mediante caching. Para la recopilaci\u00f3n y procesamiento de datos se utiliza la memoria RAM. Para el almacenamiento \u2014 historia en disparadores, gr\u00e1ficos y elementos de datos computados. En el lado de la base de datos hay cierto caching para las principales consultas, por ejemplo, gr\u00e1ficos.<\/p>\n<p>El caching en el propio servidor Zabbix es:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nVeamos esto en detalle.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nEste es el cache principal donde almacenamos m\u00e9tricas, anfitriones, elementos de datos, disparadores \u2014 todo lo necesario para el PreProcessing y la recopilaci\u00f3n de datos.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTodo esto se almacena en ConfigurationCache para evitar crear solicitudes innecesarias en la base de datos. Despu\u00e9s de iniciar el servidor, actualizamos este cache, creamos y actualizamos configuraciones peri\u00f3dicamente.<\/p>\n<h3>Recopilaci\u00f3n de datos<\/h3>\n<p>\nEl esquema es bastante grande, pero lo principal en \u00e9l es <strong>los recolectores<\/strong>. Son varios \"pollers\" \u2014 procesos de recopilaci\u00f3n. Son responsables de diferentes tipos de recopilaci\u00f3n: recopilan datos a trav\u00e9s de SNMP, IPMI, y transmiten todo esto al PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>Los recolectores est\u00e1n delimitados por una l\u00ednea naranja.<\/em><\/p>\n<p>En Zabbix hay elementos de datos de agregaci\u00f3n computados que son necesarios para agregar verificaciones. Si los tenemos, tomamos los datos para ellos directamente de ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nTodos los recolectores utilizan ConfigurationCache para obtener tareas. Luego las pasan al PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl PreProcessing utiliza ConfigurationCache para obtener los pasos de PreProcessing. Procesa estos datos de diversas maneras.<\/p>\n<p>Despu\u00e9s de procesar los datos mediante PreProcessing, los guardamos en HistoryCache para ser procesados. En este punto finaliza la recopilaci\u00f3n de datos y pasamos al proceso principal en Zabbix \u2014 <strong>history syncer<\/strong>, dado que esta es una arquitectura monol\u00edtica.<\/p>\n<p><em>Nota: El PreProcessing es una operaci\u00f3n bastante pesada. A partir de la versi\u00f3n 4.2, se ha trasladado al proxy. Si tienes un Zabbix muy grande con una gran cantidad de elementos de datos y frecuencia de recopilaci\u00f3n, esto facilita mucho el trabajo.<\/em><\/p>\n<h3>ValueCache, historial y tendencias de cach\u00e9<\/h3>\n<p><\/p>\n<blockquote><p>El sincronizador de historial es el proceso principal que procesa at\u00f3micamente cada elemento de datos, es decir, cada valor.<\/p><\/blockquote>\n<p>\nEl sincronizador de historial toma valores de HistoryCache y verifica la existencia de disparadores en la Configuraci\u00f3n para c\u00e1lculos. Si los hay, los calcula.<\/p>\n<p>El sincronizador de historial crea un evento, una escalaci\u00f3n, para generar alertas, si es necesario seg\u00fan la configuraci\u00f3n, y lo registra. Si hay disparadores para un procesamiento posterior, recuerda este valor en ValueCache para no consultar la tabla de historial. As\u00ed, ValueCache se llena con los datos necesarios para el c\u00e1lculo de disparadores y elementos calculados.<\/p>\n<p>El sincronizador de historial registra todos los datos en la base de datos, y esta en el disco. El proceso de procesamiento termina aqu\u00ed.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Cach\u00e9 en la base de datos<\/h3>\n<p>\nDel lado de la base de datos hay varios cach\u00e9s cuando deseas ver gr\u00e1ficos o informes sobre eventos:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> del lado de MySQL;<\/li>\n<li><code>shared_buffers<\/code> del lado de PostgreSQL;<\/li>\n<li><code>effective_cache_size<\/code> del lado de Oracle;<\/li>\n<li><code>shared_pool<\/code> del lado de DB2.<\/li>\n<\/ul>\n<p>\nHay muchos otros cach\u00e9s, pero estos son los principales para todas las bases de datos. Permiten mantener en memoria los datos que son necesarios frecuentemente para las consultas. Tienen sus propias tecnolog\u00edas para ello.<\/p>\n<h3>El rendimiento de la base de datos es cr\u00edticamente importante<\/h3>\n<p>\nEl servidor Zabbix recopila constantemente datos y los registra. Al reiniciarse, tambi\u00e9n lee desde el historial para llenar el ValueCache. Utiliza scripts e informes <strong>Zabbix API<\/strong>, que se basa en la interfaz web. Zabbix API consulta la base de datos y obtiene los datos necesarios para gr\u00e1ficos, informes, listas de eventos y problemas recientes.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPara visualizaci\u00f3n \u2014 <strong>Grafana<\/strong>. Entre nuestros usuarios, esta es una soluci\u00f3n popular. Puede enviar directamente consultas a trav\u00e9s de Zabbix API y en la base de datos, creando cierta concurrencia para obtener datos. Por lo tanto, se necesita una configuraci\u00f3n m\u00e1s matizada y adecuada de la base de datos para cumplir con la r\u00e1pida entrega de resultados y pruebas.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nLa tercera llamada de rendimiento en Zabbix es la limpieza de historial a trav\u00e9s de Housekeeper. Cumple con todas las configuraciones \u2014 en los elementos de datos se indica cu\u00e1ntos d\u00edas almacenar la din\u00e1mica de cambios (tendencias).<\/p>\n<p>TrendsCache lo calculamos al instante. Cuando llegan datos, los agregamos durante una hora y los registramos en tablas para la din\u00e1mica de cambios en tendencias.<\/p>\n<p>Housekeeper se inicia y elimina informaci\u00f3n de la base de datos mediante consultas \u00abselect\u00bb. Esto no siempre es eficiente, como se puede ver en los gr\u00e1ficos de rendimiento de los procesos internos.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEl gr\u00e1fico rojo muestra que el History syncer est\u00e1 constantemente ocupado. El gr\u00e1fico naranja en la parte superior es el Housekeeper, que se inicia constantemente. Est\u00e1 esperando que la base de datos elimine todas las filas que ha solicitado.<\/p>\n<p>\u00bfCu\u00e1ndo deber\u00eda desactivar el Housekeeper? Por ejemplo, si hay un \u00abItem ID\u00bb y se necesitan eliminar las \u00faltimas 5,000 filas de un periodo determinado. Por supuesto, esto ocurre a trav\u00e9s de los \u00edndices. Pero generalmente, el conjunto de datos es muy grande y la base de datos sigue leyendo desde el disco y cargando en cach\u00e9. Esta siempre es una operaci\u00f3n muy costosa para la base de datos y, dependiendo del tama\u00f1o de la misma, puede causar problemas de rendimiento.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Se puede desactivar f\u00e1cilmente el Housekeeper. En la interfaz web hay una configuraci\u00f3n en \u00abAdministraci\u00f3n general\u00bb para el Housekeeper. Desactivamos el mantenimiento interno para el historial interno de tendencias y este ya no lo gestiona.<\/p>\n<p>Se desactiv\u00f3 el Housekeeper, los gr\u00e1ficos se alinearon. \u00bfCu\u00e1les podr\u00edan ser los problemas en este caso y qu\u00e9 podr\u00eda ayudar a resolver la tercera llamada de rendimiento?<\/p>\n<h2>Partitioning \u2014 particionamiento o seccionamiento<\/h2>\n<p>\nGeneralmente, el particionamiento se configura de diversas maneras en cada base de datos relacional que he mencionado. Cada una tiene su propia tecnolog\u00eda, pero son similares, en t\u00e9rminos generales. Crear una nueva partici\u00f3n a menudo conlleva ciertos problemas.<\/p>\n<p>Generalmente, las particiones se configuran seg\u00fan el \u00absetup\u00bb \u2014 la cantidad de datos que se generan por d\u00eda. Por lo general, el Partitioning se establece para un d\u00eda, que es el m\u00ednimo. Para las tendencias, una nueva partici\u00f3n se establece por un mes.<\/p>\n<p>Los valores pueden variar en caso de un \u00absetup\u00bb muy grande. Si un \u00absetup\u00bb peque\u00f1o es de hasta 5,000 nvps (nuevos valores por segundo), mediano es de 5,000 a 25,000, entonces grande es superior a 25,000 nvps. Estas son instalaciones grandes y muy grandes que requieren una cuidadosa configuraci\u00f3n de la base de datos.<\/p>\n<p>En instalaciones muy grandes, un segmento de un d\u00eda puede no ser \u00f3ptimo. He visto en MySQL particiones de 40 GB o m\u00e1s por d\u00eda. Este es un volumen de datos muy grande que puede causar problemas y debe reducirse.<\/p>\n<h3>\u00bfQu\u00e9 ofrece el Partitioning?<\/h3>\n<p>\n<strong>Particionamiento de tablas<\/strong>. A menudo, estos son archivos separados en el disco. El plan de consultas selecciona de manera m\u00e1s \u00f3ptima una partici\u00f3n. Por lo general, la partici\u00f3n se utiliza por rango, lo que tambi\u00e9n es cierto para Zabbix. All\u00ed utilizamos \"timestamp\" \u2014 tiempo desde el inicio de la era. Para nosotros, son n\u00fameros comunes. Usted establece el inicio y el final del d\u00eda \u2014 esta es la partici\u00f3n.<\/p>\n<p><strong>Eliminaci\u00f3n r\u00e1pida<\/strong> \u2014 <code>ELIMINAR<\/code>. Se selecciona un archivo\/subtabla, en lugar de una selecci\u00f3n de filas para eliminar.<\/p>\n<p><strong>Acelera notablemente la selecci\u00f3n de datos<\/strong> <code>SELECCIONAR<\/code> \u2014 utiliza una o m\u00e1s particiones, no toda la tabla. Si solicita datos de hace dos d\u00edas, se seleccionan de la base de datos m\u00e1s r\u00e1pido, porque solo se debe cargar en cach\u00e9 y entregar un solo archivo, en lugar de una gran tabla.<\/p>\n<p>A menudo, muchas bases de datos tambi\u00e9n aceleran <code>INSERTAR<\/code> \u2014 inserciones en la subtabla hija.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nPara v 4.2 hemos prestado atenci\u00f3n a TimescaleDB. Es una extensi\u00f3n para PostgreSQL con una interfaz nativa. La extensi\u00f3n trabaja de manera eficaz con datos de series temporales, sin perder las ventajas de las bases de datos relacionales. TimescaleDB tambi\u00e9n particiona autom\u00e1ticamente.<\/p>\n<p>En TimescaleDB existe el concepto de <strong>hiper tabla<\/strong> (hypertable), que usted crea. En ella se encuentran <strong>fragmentos<\/strong> \u2014 particiones. Los fragmentos son partes de la hiper tabla gestionadas autom\u00e1ticamente, lo que no afecta a otros fragmentos. Cada fragmento tiene su propio rango temporal.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para 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 realmente funciona de manera eficiente. Los creadores de la extensi\u00f3n afirman que utilizan un algoritmo de procesamiento de consultas m\u00e1s adecuado, en particular, <code>inserts<\/code>. Cuando aumentan los tama\u00f1os de los conjuntos de datos de inserci\u00f3n, el algoritmo mantiene un rendimiento constante.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDespu\u00e9s de 200 millones de filas, PostgreSQL generalmente comienza a decaer significativamente y pierde rendimiento hasta 0. TimescaleDB permite insertar \"inserts\" de manera eficiente sin importar el volumen de datos.<\/p>\n<h3>Instalaci\u00f3n<\/h3>\n<p>\nInstalar TimescaleDB es bastante simple para cualquier paquete. En <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">la documentaci\u00f3n<\/a><\/noindex> se describe todo en detalle \u2014 depende de los paquetes oficiales de PostgreSQL. TimescaleDB tambi\u00e9n se puede construir y compilar manualmente.<\/p>\n<p>Para la base de datos Zabbix, simplemente activamos la extensi\u00f3n:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nUsted activa <code>la extensi\u00f3n<\/code> y la crea para la base de datos Zabbix. El \u00faltimo paso es crear la hiper tabla.<\/p>\n<h3>Migraci\u00f3n de tablas de historial a TimescaleDB<\/h3>\n<p>\nPara esto hay una funci\u00f3n especial <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 funci\u00f3n tiene tres par\u00e1metros. Primero \u2014<strong> la tabla en la base de datos<\/strong>, para la que se necesita crear la hiperatabla. Segundo \u2014 <strong>el campo<\/strong>, por el que se debe crear <code>chunk_time_interval<\/code> \u2014 el intervalo de chunk de las particiones a utilizar. En mi caso, el intervalo es de un d\u00eda \u2014 86,400.<\/p>\n<p>El tercer par\u00e1metro \u2014 <code><strong>migrar_datos<\/strong><\/code>. Si se establece <code>true<\/code>, todos los datos existentes se trasladan a los chunks creados de antemano. Yo mismo utilic\u00e9 <code>migrar_datos<\/code>. Ten\u00eda alrededor de 1 TB, lo que tom\u00f3 m\u00e1s de una hora. Incluso en algunos casos, durante las pruebas, elimin\u00e9 datos hist\u00f3ricos de tipo car\u00e1cter innecesarios para no transferirlos.<\/p>\n<p>El \u00faltimo paso \u2014\u00a0<code><strong>ACTUALIZAR<\/strong><\/code>: en <code>db_extension<\/code> colocamos <code>timescaledb<\/code>, para que la base de datos entienda que existe esta extensi\u00f3n. Zabbix la activa y utiliza correctamente la sintaxis y las consultas hacia la base de datos \u2014 las funciones necesarias para TimescaleDB.<\/p>\n<h2>Configuraci\u00f3n de hardware<\/h2>\n<p>\nUtilic\u00e9 dos servidores. Primero \u2014 <strong>una m\u00e1quina VMware<\/strong>. Es bastante peque\u00f1a: 20 procesadores Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2.20GHz, 16 GB de RAM y un disco SSD de 200 GB.<\/p>\n<p>Instal\u00e9 PostgreSQL 10.8 en ella con el sistema operativo Debian 10.8-1.pgdg90+1 y el sistema de archivos xfs. Todo configur\u00e9 de forma m\u00ednima para utilizar exactamente esta base de datos, excepto lo que usar\u00e1 Zabbix.<\/p>\n<p>En esta misma m\u00e1quina se encontraba el servidor de Zabbix, PostgreSQL y <strong>los agentes de carga<\/strong>. Ten\u00eda 50 agentes activos que utilizaban <code>LoadableModule<\/code>, para generar r\u00e1pidamente diferentes resultados: n\u00fameros, cadenas. Llen\u00e9 la base de datos con una gran cantidad de datos.<\/p>\n<p>Inicialmente, la configuraci\u00f3n conten\u00eda <strong>5,000 elementos<\/strong> de datos por cada host. Casi cada elemento conten\u00eda un disparador, para que se pareciera a instalaciones reales. En algunos casos hab\u00eda m\u00e1s de un disparador. Por cada nodo de la red hab\u00eda <strong>3,000-7,000 disparadores.<\/strong>.<\/p>\n<p>El intervalo de actualizaci\u00f3n de los elementos de datos \u2014 <strong>4-7 segundos.<\/strong>. Regule la carga utilizando no solo 50 agentes, sino que tambi\u00e9n a\u00f1ad\u00ed m\u00e1s. Adem\u00e1s, mediante elementos de datos din\u00e1micos, regul\u00e9 la carga y reduje el intervalo de actualizaci\u00f3n a 4 s.<\/p>\n<h3>PostgreSQL. 35,000 nvps<\/h3>\n<p>\nEl primer inicio en este hardware fue con PostgreSQL en limpio \u2014 35,000 valores por segundo. Como se puede ver, la inserci\u00f3n de datos toma fracciones de segundo \u2014 todo va bien y r\u00e1pido. La \u00fanica desventaja es que el disco SSD de 200 GB se llena r\u00e1pidamente.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste es el dashboard de rendimiento est\u00e1ndar de Zabbix \u2014 servidores.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa primera gr\u00e1fica azul muestra la cantidad de valores por segundo. La segunda gr\u00e1fica a la derecha muestra la carga de procesos de recopilaci\u00f3n. La tercera \u2014 carga de procesos internos de recopilaci\u00f3n: history syncers y Housekeeper, que aqu\u00ed se ejecut\u00f3 durante suficiente tiempo.<\/p>\n<p>La cuarta gr\u00e1fica muestra el uso de HistoryCache. Este es un tipo de buffer antes de la inserci\u00f3n en la base de datos. La quinta gr\u00e1fica verde muestra el uso de ValueCache, es decir, cu\u00e1ntos hits de ValueCache para disparadores \u2014 esto son varios miles de valores por segundo.<\/p>\n<h3>PostgreSQL. 50,000 nvps<\/h3>\n<p>\nLuego aument\u00e9 la carga a 50,000 valores por segundo en el mismo hardware.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAl cargar con Housekeeper, la inserci\u00f3n de 10,000 valores se registr\u00f3 en 2-3 s.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper ya est\u00e1 empezando a interferir en el trabajo.<\/em><\/p>\n<p>En la tercera gr\u00e1fica se puede ver que, en general, la carga de los trapper y history syncers todav\u00eda est\u00e1 en el 60%. En la cuarta gr\u00e1fica, HistoryCache durante el trabajo de Housekeeper ya comienza a llenarse activamente. Se llen\u00f3 en un 20% \u2014 esto es alrededor de 0.5 GB.<\/p>\n<h3>PostgreSQL. 80,000 nvps<\/h3>\n<p>\nLuego aument\u00e9 la carga a 80,000 valores por segundo. Esto son aproximadamente 400,000 elementos de datos y 280,000 disparadores.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>La inserci\u00f3n con la carga de treinta history syncers ya es bastante alta.<\/em><\/p>\n<p>Tambi\u00e9n aument\u00e9 varios par\u00e1metros: history syncers, caches.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn mi hardware, la carga de history syncers aument\u00f3 al m\u00e1ximo. HistoryCache se llen\u00f3 r\u00e1pidamente de datos \u2014 se acumularon datos en el buffer para su procesamiento.<\/p>\n<p>Durante todo este tiempo observ\u00e9 c\u00f3mo se utilizaba la CPU, la memoria RAM y otros par\u00e1metros del sistema, y descubr\u00ed que la utilizaci\u00f3n de los discos era m\u00e1xima.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLogr\u00e9 utilizar <strong>las capacidades m\u00e1ximas del disco<\/strong> en este hardware y en esta m\u00e1quina virtual. Con tal intensidad, PostgreSQL comenz\u00f3 a descartar datos de manera activa, y el disco ya no pod\u00eda seguir trabajando en la escritura y lectura.<\/p>\n<h3>Segundo servidor<\/h3>\n<p>\nTom\u00e9 otro servidor que ya ten\u00eda 48 procesadores y 128 GB de memoria RAM. Lo ajust\u00e9 y le puse 60 history syncers, logrando un rendimiento aceptable.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe hecho, esto ya es el l\u00edmite de rendimiento, donde se necesita hacer algo.<\/p>\n<h3>TimescaleDB. 80,000 nvps<\/h3>\n<p>\nMi principal tarea es probar las capacidades de TimescaleDB bajo la carga de Zabbix. 80 mil valores por segundo es mucho, la frecuencia de recolecci\u00f3n de m\u00e9tricas (excepto Yandex, por supuesto) y es un 'setup' bastante grande.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn cada gr\u00e1fico hay un baj\u00f3n, que es justo durante la migraci\u00f3n de datos. Despu\u00e9s de los bajones en el servidor Zabbix, el perfil de carga del history syncer cambi\u00f3 dr\u00e1sticamente: cay\u00f3 tres veces.<\/p>\n<blockquote><p>TimescaleDB permite insertar datos pr\u00e1cticamente tres veces m\u00e1s r\u00e1pido y utilizar menos HistoryCache.<\/p><\/blockquote>\n<p>\nPor lo tanto, los datos se entregar\u00e1n a tiempo.<\/p>\n<h3>TimescaleDB. 120,000 nvps<\/h3>\n<p>\nLuego aument\u00e9 la cantidad de elementos de datos a 500 mil. La tarea principal era probar las capacidades de TimescaleDB, obtuve un valor calculado de 125 mil valores por segundo.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste es un 'setup' funcional que puede operar durante mucho tiempo. Pero dado que mi disco era solo de 1.5 TB, lo llen\u00e9 en un par de d\u00edas.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLo m\u00e1s importante es que al mismo tiempo se estaban creando nuevas particiones en TimescaleDB.<\/p>\n<p>Para el rendimiento, esto es completamente imperceptible. Cuando se crean particiones en MySQL, por ejemplo, todo es diferente. Por lo general, sucede por la noche, porque bloquea la inserci\u00f3n general, el trabajo con tablas y puede causar degradaci\u00f3n del servicio. En el caso de TimescaleDB, esto no ocurre.<\/p>\n<p>Como ejemplo, mostrar\u00e9 un gr\u00e1fico de los muchos en la comunidad. En la imagen, TimescaleDB est\u00e1 habilitado, gracias a ello la carga por uso de io.weight en el procesador ha disminuido. El uso de los elementos de procesos internos tambi\u00e9n ha bajado. De hecho, es una m\u00e1quina virtual est\u00e1ndar con discos tradicionales, no SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusiones<\/h2>\n<p>\n<strong>TimescaleDB es una buena soluci\u00f3n para peque\u00f1os 'setups'<\/strong>, que se ven limitados por el rendimiento del disco. Permite seguir funcionando bien hasta la migraci\u00f3n de la base de datos a un hardware m\u00e1s r\u00e1pido.<\/p>\n<p>TimescaleDB es f\u00e1cil de configurar, proporciona un aumento de rendimiento, funciona bien con Zabbix y <strong>tiene ventajas sobre PostgreSQL.<\/strong>.<\/p>\n<p>Si usas PostgreSQL y no planeas cambiarlo, te recomiendo <strong>usar PostgreSQL con la extensi\u00f3n TimescaleDB junto con Zabbix.<\/strong>Esta soluci\u00f3n funciona eficazmente hasta 'setups' medianos.<\/p>\n<blockquote>\n<p>Cuando decimos 'alto rendimiento', nos referimos a <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++.<\/a><\/noindex>. No falta mucho para conocer las tecnolog\u00edas y pr\u00e1cticas que permiten a los servicios atender a millones de usuarios. Lista <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">de informes<\/a><\/noindex> para los d\u00edas 7 y 8 de noviembre ya hemos preparado, pero <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">los meetups<\/a><\/noindex> a\u00fan se pueden proponer.<\/p>\n<p>Suscr\u00edbanse a nuestro <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">bolet\u00edn<\/a><\/noindex> y <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, en el que revelamos detalles sobre la pr\u00f3xima conferencia y descubran c\u00f3mo obtener el m\u00e1ximo beneficio.<\/p>\n<\/blockquote>\n<p>Fuente: <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\/es\/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=\"es_ES\" \/>\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\/es\/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\udd47 Alto rendimiento y particionamiento nativo: Zabbix con soporte para TimescaleDB | ProHoster","description":"Zabbix es un sistema de monitoreo.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","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\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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/38927","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=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}