{"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\/da\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix er et overv\u00e5gningssystem. Ligesom ethvert andet system st\u00e5r det over for tre hovedproblemer, som alle overv\u00e5gningssystemer har: indsamling og behandling af data, opbevaring af historik samt oprydning af denne.<\/p>\n<p>Faserne for indsamling, behandling og lagring af data tager tid. En smule, men for et stort system kan det f\u00f8re til betydelige forsinkelser. Problemet med opbevaring handler om adgangen til data. De bruges til rapporter, kontroller og triggere. Forsinkelser i adgangen til data p\u00e5virker ogs\u00e5 ydeevnen. N\u00e5r databaser vokser, skal for\u00e6ldede data slettes. Sletning er en ressourcekr\u00e6vende operation, som ogs\u00e5 bruger en del af systemressourcerne.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nProblemerne med forsinkelser ved indsamling og opbevaring i Zabbix l\u00f8ses med caching: flere typer caches, caching i databasen. For at l\u00f8se det tredje problem er caching ikke tilstr\u00e6kkeligt, derfor har Zabbix implementeret TimescaleDB. Det vil blive pr\u00e6senteret af <strong>Andrej Gushchin<\/strong> \u2014 supportingeni\u00f8r <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrej har arbejdet i Zabbix-supporten i over 6 \u00e5r og har direkte erfaring med ydeevne.<\/p>\n<p>Hvordan fungerer TimescaleDB, hvilken ydeevne kan det give sammenlignet med almindelig PostgreSQL? Hvilken rolle spiller Zabbix for TimescaleDB? Hvordan starter man fra bunden, og hvordan migrerer man fra PostgreSQL, og hvilken konfiguration giver bedre ydeevne? Alt dette finder du nedenfor.<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=\"Afspil 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>Ydelsesudfordringer<\/h2>\n<p>\nHvert overv\u00e5gningssystem st\u00e5r over for visse ydelsesudfordringer. Jeg vil tale om tre af dem: indsamling og behandling af data, lagring og oprydning af historik.<\/p>\n<p><strong>Hurtig indsamling og behandling af data. <\/strong>Et godt overv\u00e5gningssystem skal hurtigt indsamle alle data og behandle dem i henhold til triggerbetingelserne \u2014 efter sine egne kriterier. Efter behandling skal systemet ogs\u00e5 hurtigt gemme disse data i databasen, s\u00e5 de senere kan anvendes.<\/p>\n<p><strong>Opbevaring af historik. <\/strong>Et godt overv\u00e5gningssystem skal opbevare historik i databasen og give nem adgang til metrikker. Historik er n\u00f8dvendig for at kunne anvende den i rapporter, grafer, triggere, t\u00e6rskelv\u00e6rdier og beregnede datapotentialer til advarsler.<\/p>\n<p><strong>Oprydning af historik. <\/strong>Nogle gange kommer der en dag, hvor du ikke beh\u00f8ver at opbevare metrikker. Hvorfor have data indsamlet for 5 \u00e5r siden, et m\u00e5ned eller to: nogle noder er fjernet, nogle v\u00e6rter eller metrikker er ikke l\u00e6ngere n\u00f8dvendige, fordi de er for\u00e6ldede og ikke l\u00e6ngere indsamles. Et godt monitoreringssystem b\u00f8r bevare historiske data og med j\u00e6vne mellemrum fjerne dem, s\u00e5 databasen ikke vokser un\u00f8digt.<\/p>\n<blockquote><p>Rydning af for\u00e6ldede data er et kritisk sp\u00f8rgsm\u00e5l, der har stor indvirkning p\u00e5 databaseydelsen.<\/p><\/blockquote>\n<p><\/p>\n<h2>Caching i Zabbix<\/h2>\n<p>\nI Zabbix l\u00f8ses den f\u00f8rste og anden kald ved hj\u00e6lp af caching. RAM bruges til indsamling og behandling af data. Historikken opbevares i triggere, diagrammer og beregnede dataelementer. P\u00e5 databasesiden er der et bestemt cache for de prim\u00e6re foresp\u00f8rgsler, s\u00e5som diagrammer.<\/p>\n<p>Caching p\u00e5 Zabbix-serverens side er:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nLad os se n\u00e6rmere p\u00e5 dem.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nDette er den prim\u00e6re cache, hvor vi opbevarer metrikker, v\u00e6rter, dataelementer, triggere - alt, hvad der er n\u00f8dvendigt for PreProcessing og dataindsamling.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAlt dette gemmes i ConfigurationCache for at undg\u00e5 un\u00f8dvendige foresp\u00f8rgsler til databasen. Efter serverens opstart opdaterer vi denne cache, opretter og opdaterer konfigurationerne regelm\u00e6ssigt.<\/p>\n<h3>Dataindsamling<\/h3>\n<p>\nSkemaet er temmelig stort, men det vigtigste i det er <strong>indsamlerne<\/strong>. Dette er forskellige \"pollers\" - indsamling processer. De er ansvarlige for forskellige typer indsamling: de indsamler data via SNMP, IPMI og sender alt dette til PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>Indsamlerne er indrammet med orange linje.<\/em><\/p>\n<p>I Zabbix findes der beregnede aggregationsdataelementer, der er n\u00f8dvendige for at aggregere tjek. Hvis vi har dem, henter vi data til dem direkte fra ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nAlle indsamlerne bruger ConfigurationCache for at f\u00e5 opgaver. Derefter sender de dem til PreProcessing.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPreProcessing bruger ConfigurationCache for at f\u00e5 PreProcessing-trin. Den behandler disse data p\u00e5 forskellige m\u00e5der.<\/p>\n<p>Efter databehandling med PreProcessing, gemmer vi dem i HistoryCache for at kunne bearbejde dem. P\u00e5 dette tidspunkt slutter datainsamlingen, og vi g\u00e5r videre til den prim\u00e6re proces i Zabbix - <strong>history syncer<\/strong>, da det er en monolitisk arkitektur.<\/p>\n<p><em>Bem\u00e6rk: PreProcessing er en ret ressourcekr\u00e6vende operation. Fra v 4.2 er den flyttet til proxy. Hvis du har en meget stor Zabbix med mange dataelementer og indsamling frekvenser, s\u00e5 letter det arbejdet betydeligt.<\/em><\/p>\n<h3>ValueCache, history &amp; trends cache<\/h3>\n<p><\/p>\n<blockquote><p>Historik synkronisator - det er den prim\u00e6re proces, der atomisk behandler hvert datav\u00e6rdi, det vil sige hver v\u00e6rdi.<\/p><\/blockquote>\n<p>\nHistorik synkronisator henter v\u00e6rdier fra HistoryCache og tjekker konfigurationen for triggere til beregninger. Hvis der er nogle - beregner den.<\/p>\n<p>Historik synkronisator skaber et event, en eskalering, for at generere alarm, hvis det kr\u00e6ves af konfigurationen, og skriver det ned. Hvis der er triggere til efterf\u00f8lgende behandling, gemmer den denne v\u00e6rdi i ValueCache, s\u00e5 den ikke skal tilg\u00e5 historiktabellen. S\u00e5dan fyldes ValueCache med de data, der er n\u00f8dvendige for beregning af triggere og beregnede elementer.<\/p>\n<p>Historik synkronisator skriver alle data til databasen, og den skriver til disken. Behandlingsprocessen afsluttes her.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching i databasen<\/h3>\n<p>\nP\u00e5 databasesiden findes der forskellige caches, n\u00e5r du \u00f8nsker at se grafer eller rapporter om begivenheder:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> p\u00e5 MySQL-siden;<\/li>\n<li><code>shared_buffers<\/code> p\u00e5 PostgreSQL-siden;<\/li>\n<li><code>effective_cache_size<\/code> p\u00e5 Oracle-siden;<\/li>\n<li><code>shared_pool<\/code> p\u00e5 DB2-siden.<\/li>\n<\/ul>\n<p>\nDer er mange andre caches, men disse er de vigtigste for alle databaser. De tillader at holde de data, der ofte er n\u00f8dvendige for foresp\u00f8rgsler, i RAM. De har deres egne teknologier til dette.<\/p>\n<h3>Databasens ydeevne er kritisk<\/h3>\n<p>\nZabbix-serveren indsamler konstant data og skriver dem. Ved genstart l\u00e6ser den ogs\u00e5 fra historikken for at fylde ValueCache. Den bruger <strong>Zabbix API<\/strong>, som er bygget p\u00e5 webgr\u00e6nsefladen. Zabbix API tilg\u00e5r databasen og henter de n\u00f8dvendige data til grafer, rapporter, begivenhedslister og seneste problemer.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTil visualisering - <strong>Grafana<\/strong>. Blandt vores brugere er dette en popul\u00e6r l\u00f8sning. Den er i stand til direkte at sende foresp\u00f8rgsler via Zabbix API og til databasen, hvilket skaber en vis konkurrence for at hente data. Derfor kr\u00e6ves der en finere og bedre ops\u00e6tning af databasen for at opfylde hurtige resultater og tests.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nDen tredje pr\u00e6stationsudfordring i Zabbix er oprydning af historikken ved hj\u00e6lp af Housekeeper. Den overholder alle indstillinger - i dataelementerne er det angivet, hvor mange dage dynamik\u00e6ndringer (trends) skal opbevares.<\/p>\n<p>Vi beregner TrendsCache i realtid. N\u00e5r dataene kommer ind, aggregerer vi dem i timen og skriver dem til tabeller for dynamik\u00e6ndringer af trends.<\/p>\n<p>Housekeeper startes og fjerner information fra databasen med almindelige 'selects'. Dette er ikke altid effektivt, hvilket kan ses p\u00e5 pr\u00e6stationsgraferne for interne processer.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen r\u00f8de graf viser, at History syncer konstant er aktiv. Den orange graf ovenfor er Housekeeper, som konstant k\u00f8rer. Den venter p\u00e5 databasen med at slette alle de r\u00e6kker, den har anmodet om.<\/p>\n<p>Hvorn\u00e5r skal man deaktivere Housekeeper? For eksempel, hvis der er et 'Item ID', og man indser, at de sidste 5.000 r\u00e6kker skal slettes i en bestemt periode. Dette sker selvf\u00f8lgelig efter indekserne. Men normalt er datas\u00e6ttet meget stort, og databasen l\u00e6ser stadig fra disken og henter det i cache. Dette er altid en meget dyr operation for databasen og kan, afh\u00e6ngigt af databasens st\u00f8rrelse, f\u00f8re til pr\u00e6stationsproblemer.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Housekeeper kan helt enkelt deaktiveres. I webgr\u00e6nsefladen er der en indstilling i 'Administration general' for Housekeeper. Vi deaktiverer den interne housekeeping for den interne trendhistorik, og den styrer ikke dette l\u00e6ngere.<\/p>\n<p>Housekeeper er deaktiveret, grafikerne er blevet justeret \u2014 hvilke problemer kan opst\u00e5 i dette tilf\u00e6lde, og hvad kan hj\u00e6lpe med at l\u00f8se tredje gang pr\u00e6stationsproblemet?<\/p>\n<h2>Partitionering \u2014 sektionering eller parcellering<\/h2>\n<p>\nPartitionering konfigureres normalt p\u00e5 forskellige m\u00e5der i hver relationel database, som jeg har n\u00e6vnt. Hver har sin egen teknologi, men de ligner generelt set hinanden. Oprettelse af en ny partition f\u00f8rer ofte til bestemte problemer.<\/p>\n<p>Partitioner konfigureres normalt afh\u00e6ngigt af 'setup' \u2014 hvor meget data der genereres p\u00e5 en dag. Som regel s\u00e6ttes partitioneringen til en dag, det er minimum. For trends er den nye partition typisk sat til 1 m\u00e5ned.<\/p>\n<p>V\u00e6rdierne kan \u00e6ndre sig i tilf\u00e6lde af et meget stort 'setup'. Hvis et lille 'setup' er op til 5.000 nvps (nye v\u00e6rdier per sekund), er det gennemsnitlige fra 5.000 til 25.000, og stort er over 25.000 nvps. Det er store og meget store installationer, som kr\u00e6ver grundig konfiguration af selve databasen.<\/p>\n<p>For meget store installationer kan intervallet p\u00e5 en dag ikke v\u00e6re optimalt. Jeg har set MySQL-partitioner p\u00e5 40 GB eller mere om dagen. Det er en meget stor m\u00e6ngde data, der kan f\u00f8re til problemer, og det skal reduceres.<\/p>\n<h3>Hvad giver partitionering?<\/h3>\n<p>\n<strong>Partitionering af tabeller<\/strong>. Ofte er det separate filer p\u00e5 disken. Sp\u00f8rgselsplaner v\u00e6lger mere optimalt \u00e9n partition. Partitionering bruges normalt efter interval \u2014 det g\u00e6lder ogs\u00e5 for Zabbix. Vi bruger 'timestamp' \u2014 tid siden epoken. Her er det almindelige tal. Du angiver starten og slutningen p\u00e5 dagen \u2014 det er partitionen.<\/p>\n<p><strong>Hurtig sletning<\/strong> \u2014 <code>DELETE<\/code>En enkelt fil\/subtabel v\u00e6lges, og ikke en r\u00e6kkeudtr\u00e6k til sletning.<\/p>\n<p><strong>Afg\u00f8rende hurtigere dataudtr\u00e6k.<\/strong> <code>SELECT<\/code> \u2014 bruger en eller flere partitioner og ikke hele tabellen. Hvis du henter data fra for to dage siden, hentes de hurtigere fra databasen, fordi man kun skal indl\u00e6se \u00e9n fil i cachen og ikke en stor tabel.<\/p>\n<p>Ofte forbedrer mange databaser ogs\u00e5 hastigheden. <code>INSERT<\/code> \u2014 inds\u00e6ttelser i child-tabellen.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nFor version 4.2 har vi set p\u00e5 TimescaleDB. Dette er en udvidelse til PostgreSQL med et nativt interface. Udvidelsen fungerer effektivt med tidsserie data, samtidig med at den bevarer fordelene ved relationelle databaser. TimescaleDB partitionerer ogs\u00e5 automatisk.<\/p>\n<p>I TimescaleDB findes begrebet <strong>hypertabel<\/strong> som du opretter. Denne indeholder <strong>chunks<\/strong> \u2014 partitioner. Chunks er automatisk styrede fragmenter af hypertabellen, som ikke p\u00e5virker andre fragmenter. Hver chunk har sit eget tidsinterval.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til 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 fungerer faktisk effektivt. Producenterne af udvidelsen p\u00e5st\u00e5r, at de bruger en mere korrekt algoritme til foresp\u00f8rgselsbehandling, specielt for <code>inds\u00e6ttelser<\/code>. N\u00e5r st\u00f8rrelsen p\u00e5 dataset-indl\u00e6sninger stiger, opretholder algoritmen konstant ydeevne.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEfter 200 millioner r\u00e6kker begynder PostgreSQL typisk at falde meget ned og mister ydeevne til 0. TimescaleDB muligg\u00f8r effektiv inds\u00e6ttelse af \"inds\u00e6ttelser\" uanset datast\u00f8rrelse.<\/p>\n<h3>Installation<\/h3>\n<p>\nAt installere TimescaleDB er ret enkelt for alle pakker. I <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">dokumentationen<\/a><\/noindex> er alt beskrevet i detaljer \u2014 det afh\u00e6nger af de officielle PostgreSQL-pakker. TimescaleDB kan ogs\u00e5 samles og kompilere manuelt.<\/p>\n<p>For Zabbix databasen aktiverer vi blot udvidelsen:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nDu aktiverer <code>udvidelsen<\/code> og opretter den for Zabbix databasen. Det sidste skridt er at oprette hypertabellen.<\/p>\n<h3>Migration af historietabeller til TimescaleDB<\/h3>\n<p>\nDer er en s\u00e6rlig funktion til dette. <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>\nFunktionen har tre parametre. Den f\u00f8rste \u2014<strong> tabellen i databasen<\/strong>, som skal have oprettet en hypertabel. Den anden \u2014 <strong>feltet<\/strong>, efter hvilken det skal oprettes <code>chunk_time_interval<\/code> \u2014 intervallet for de chunks, der skal bruges. I mit tilf\u00e6lde er intervallet \u00e9n dag \u2014 86 400.<\/p>\n<p>Den tredje parameter \u2014 <code><strong>migrere_data<\/strong><\/code>. Hvis du s\u00e6tter <code>true<\/code>, s\u00e5 overf\u00f8res alle nuv\u00e6rende data til de forudoprettede chunks. Jeg brugte selv <code>migrere_data<\/code>. Jeg havde omkring 1 TB, hvilket tog mere end en time. Selv i nogle tilf\u00e6lde under testning fjernede jeg un\u00f8dvendige historiske data af tegntype for ikke at overf\u00f8re dem.<\/p>\n<p>Det sidste trin \u2014\u00a0<code><strong>OPDATERING<\/strong><\/code>: i <code>db_extension<\/code> s\u00e6tter vi <code>timescaledb<\/code>, s\u00e5 databasen forst\u00e5r, at denne udvidelse findes. Zabbix aktiverer det og bruger den rigtige syntaks og foresp\u00f8rgsler til databasen \u2014 de funktioner, der er n\u00f8dvendige for TimescaleDB.<\/p>\n<h2>Hardwarekonfiguration<\/h2>\n<p>\nJeg brugte to servere. Den f\u00f8rste \u2014 <strong>VMware-maskine<\/strong>. Den er ret lille: 20 processorer Intel\u00ae Xeon\u00ae CPU E5-2630 v 4 @ 2.20GHz, 16 GB RAM og en SSD-disk p\u00e5 200 GB.<\/p>\n<p>Jeg installerede PostgreSQL 10.8 p\u00e5 den med Debian 10.8-1.pgdg90+1 og filsystemet xfs. Jeg lavede minimale indstillinger for at bruge netop denne database, bortset fra hvad Zabbix selv vil bruge.<\/p>\n<p>P\u00e5 denne maskine var der ogs\u00e5 en Zabbix-server, PostgreSQL og <strong>belastningsagenter<\/strong>. Jeg havde 50 aktive agenter, der brugte <code>LoadableModule<\/code>, til hurtigt at generere forskellige resultater: tal, strenge. Jeg fyldte databasen med store m\u00e6ngder data.<\/p>\n<p>Oprindeligt indeholdt konfigurationen <strong>5 000 datategn<\/strong> pr. v\u00e6rt. N\u00e6sten hvert element havde en trigger for at g\u00f8re det mere ligesom virkelige installationer. I nogle tilf\u00e6lde var der mere end \u00e9n trigger. P\u00e5 \u00e9n netv\u00e6rksnode kom der <strong>3 000-7 000 triggers<\/strong>.<\/p>\n<p>Opdateringsintervallet for datategn \u2014 <strong>4-7 sekunder<\/strong>Jeg regulerede belastningen ved ikke kun at bruge 50 agenter, men ogs\u00e5 ved at tilf\u00f8je flere. Derudover regulerede jeg belastningen dynamisk ved hj\u00e6lp af datavariabler og reducerede opdateringsintervallet til 4 sekunder.<\/p>\n<h3>PostgreSQL. 35.000 nvps<\/h3>\n<p>\nDen f\u00f8rste opstart p\u00e5 dette hardware var med en ren PostgreSQL - 35.000 v\u00e6rdier per sekund. Som det ses, tager inds\u00e6ttelse af data br\u00f8kdele af et sekund - alt g\u00e5r hurtigt og godt. Den eneste ting er, at SSD-disket p\u00e5 200 GB hurtigt bliver fyldt.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette er den standard pr\u00e6stationsdashboard for Zabbix - servere.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDen f\u00f8rste bl\u00e5 graf - antallet af v\u00e6rdier per sekund. Den anden graf til h\u00f8jre - belastningen p\u00e5 opbyggelsesprocesserne. Den tredje - belastningen p\u00e5 de interne opbyggelsesprocesser: history syncers og Housekeeper, som her har v\u00e6ret aktiv i noget tid.<\/p>\n<p>Den fjerde graf viser brugen af HistoryCache. Dette er en slags buffer f\u00f8r inds\u00e6ttelse i databasen. Den gr\u00f8nne femte graf viser brugen af ValueCache, alts\u00e5 hvor mange hits ValueCache for triggere - det er flere tusinde v\u00e6rdier per sekund.<\/p>\n<h3>PostgreSQL. 50.000 nvps<\/h3>\n<p>\nDerefter \u00f8gede jeg belastningen til 50.000 v\u00e6rdier per sekund p\u00e5 det samme hardware.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVed indl\u00e6sning med Housekeeper blev 10.000 v\u00e6rdier indsat p\u00e5 2-3 sekunder.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper begynder allerede at forstyrre arbejdet.<\/em><\/p>\n<p>Af den tredje graf kan vi se, at den samlede belastning af trapperne og history syncers stadig er p\u00e5 60%. P\u00e5 den fjerde graf begynder HistoryCache, mens Housekeeper arbejder, at blive fyldt ret aktivt. Den blev fyldt op til 20% - det er omkring 0,5 GB.<\/p>\n<h3>PostgreSQL. 80.000 nvps<\/h3>\n<p>\nHerefter \u00f8gede jeg belastningen til 80.000 v\u00e6rdier per sekund. Det svarer til cirka 400.000 datavaerter og 280.000 triggere.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Inds\u00e6ttelsen ved belastning af tretti history syncers er allerede ret h\u00f8j.<\/em><\/p>\n<p>Jeg har ogs\u00e5 \u00f8get forskellige parametre: history syncers, caches.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00e5 mit hardware blev belastningen p\u00e5 history syncers \u00f8get til maksimum. HistoryCache blev hurtigt fyldt med data - bufferen har opsamlet data til behandling.<\/p>\n<p>Hele tiden overv\u00e5gede jeg, hvordan CPU, RAM og andre systemparametre blev brugt, og opdagede, at diskudnyttelsen var maksimal.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJeg opn\u00e5ede udnyttelse <strong>af diskens maksimale kapacitet<\/strong> p\u00e5 dette hardware og p\u00e5 denne virtuelle maskine. Ved s\u00e5 h\u00f8j intensitet begyndte PostgreSQL aktivt at smide data, og disken kunne ikke f\u00f8lge med til skrivning og l\u00e6sning.<\/p>\n<h3>Anden server<\/h3>\n<p>\nJeg tog en anden server, som allerede havde 48 processorer og 128 GB RAM. Jeg tunede den \u2014 satte 60 history syncer op, og opn\u00e5ede en acceptabel ydelse.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFaktisk, dette er allerede gr\u00e6nsen for ydeevne, hvor der skal g\u00f8res noget.<\/p>\n<h3>TimescaleDB. 80.000 nvps<\/h3>\n<p>\nMin prim\u00e6re opgave er at teste TimescaleDB's kapacitet under Zabbix-belastning. 80.000 v\u00e6rdier pr. sekund \u2014 det er meget, og frekvensen for indsamling af metrics (undtagen Yandex, selvf\u00f8lgelig) og et ret stort 'setup'.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nP\u00e5 hver graf er der et hul \u2014 det er netop data migrationen. Efter hullerne i Zabbix-serveren \u00e6ndrede profilen for belastning af history syncer sig meget \u2014 faldt med tre gange.<\/p>\n<blockquote><p>TimescaleDB tillader inds\u00e6ttelse af data n\u00e6sten tre gange hurtigere og bruger mindre HistoryCache.<\/p><\/blockquote>\n<p>\nDerfor vil data blive leveret rettidigt.<\/p>\n<h3>TimescaleDB. 120.000 nvps<\/h3>\n<p>\nDerefter \u00f8gede jeg antallet af dataelementer til 500.000. Den prim\u00e6re opgave var at teste TimescaleDB's kapacitet \u2014 jeg fik et beregnet resultat p\u00e5 125.000 v\u00e6rdier pr. sekund.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette er et arbejds 'setup', der kan fungere i lang tid. Men da min disk kun var 1,5 TB, fyldte jeg den op p\u00e5 et par dage.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDet vigtigste er, at nye partitioner i TimescaleDB ogs\u00e5 blev oprettet p\u00e5 samme tid.<\/p>\n<p>For ydeevnen er det helt usynligt. N\u00e5r partitioner oprettes i MySQL, for eksempel, er alt anderledes. Dette sker normalt om natten, fordi det blokerer for den samlede inds\u00e6ttelse, arbejdet med tabellerne og kan skabe serviceforringelse. I tilf\u00e6lde af TimescaleDB er det ikke tilf\u00e6ldet.<\/p>\n<p>Som eksempel vil jeg vise \u00e9n graf ud af mange i community. P\u00e5 billedet er TimescaleDB aktiveret, hvilket har f\u00e5et belastningen af io.weight p\u00e5 processoren til at falde. Brugen af interne proceselementer er ogs\u00e5 faldet. Faktisk er dette en almindelig virtuel maskine med almindelige b\u00e6lte-diske, ikke SSD.<\/p>\n<p><img decoding=\"async\" alt=\"H\u00f8j ydeevne og nativ partitionering: Zabbix med support til TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Konklusioner<\/h2>\n<p>\n<strong>TimescaleDB er en god l\u00f8sning for sm\u00e5 'setup'<\/strong>, som st\u00f8der p\u00e5 diskens ydeevne. Det vil tillade at forts\u00e6tte arbejdet indtil opgradering af databasen til hurtigere hardware.<\/p>\n<p>TimescaleDB er nem at konfigurere, giver ydelsesforbedringer, fungerer godt med Zabbix, og <strong>har fordele i forhold til PostgreSQL.<\/strong>.<\/p>\n<p>Hvis du bruger PostgreSQL og ikke planl\u00e6gger at skifte, anbefaler jeg <strong>at bruge PostgreSQL med TimescaleDB som en udvidelse i forbindelse med Zabbix.<\/strong>Denne l\u00f8sning fungerer effektivt indtil middelstore 'setup'.<\/p>\n<blockquote>\n<p>N\u00e5r vi taler om 'h\u00f8j ydelse' \u2014 mener vi <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>. Det er ikke l\u00e6nge til, at vi vil pr\u00e6sentere teknologier og metoder, der g\u00f8r det muligt for tjenester at betjene millioner af brugere. Listen <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">over rapporter<\/a><\/noindex> til den 7. og 8. november er allerede lavet, men <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">meetups<\/a><\/noindex> kan der stadig foresl\u00e5s.<\/p>\n<p>Tilmeld dig vores <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">nyhedsbrevet<\/a><\/noindex> og <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, hvor vi afsl\u00f8rer tips til den kommende konference, og l\u00e6r hvordan du f\u00e5r det maksimale ud af det.<\/p>\n<\/blockquote>\n<p>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\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\/da\/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\udd47H\u00f8j ydeevne og native partitionering: Zabbix med TimescaleDB-support | ProHoster","description":"Zabbix er et overv\u00e5gningssystem.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/38927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}