{"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\/nl\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","title":{"rendered":"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Zabbix is een monitoringsysteem. Net als elk ander systeem, heeft het te maken met drie belangrijke problemen die bij alle monitoringsystemen voorkomen: het verzamelen en verwerken van gegevens, het opslaan van geschiedenis en het opruimen daarvan.<\/p>\n<p>De stappen voor het verkrijgen, verwerken en opslaan van gegevens kosten tijd. Een beetje, maar voor een groot systeem kan dit leiden tot aanzienlijke vertragingen. Het probleem van opslag betreft de toegang tot gegevens. Deze worden gebruikt voor rapporten, controles en triggers. Vertragingen bij de toegang tot gegevens be\u00efnvloeden ook de prestaties. Wanneer databases groeien, moeten verouderde gegevens worden verwijderd. Verwijderen is een zware operatie die ook een deel van de middelen verbruikt.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/9b7aa23705cd32b4d8d858ad78b181fd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nProblemen met vertragingen bij het verzamelen en opslaan in Zabbix worden opgelost door caching: verschillende soorten caches, caching in de database. Voor het oplossen van het derde probleem is caching niet geschikt, daarom is TimescaleDB toegepast in Zabbix. Hierover zal <strong>Andrey Gushchin<\/strong> \u2014 technisch ondersteuningsingenieur <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/zabbix\/\">Zabbix SIA<\/a><\/noindex>. Andrey werkt al meer dan 6 jaar bij de ondersteuning van Zabbix en heeft direct te maken met prestaties.<\/p>\n<p>Hoe werkt TimescaleDB, welke prestaties kan het bieden in vergelijking met gewone PostgreSQL? Welke rol speelt Zabbix voor de TimescaleDB-database? Hoe start je vanaf nul en hoe migreer je van PostgreSQL, en welke configuratie presteert beter? Dit alles onder de cat.<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=\"Video afspelen\" 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>Prestatie-uitdagingen<\/h2>\n<p>\nElke monitoringsysteem heeft te maken met bepaalde prestatie-uitdagingen. Ik zal het hebben over drie ervan: het verzamelen en verwerken van gegevens, opslag, en het opruimen van geschiedenis.<\/p>\n<p><strong>Snelle verzameling en verwerking van gegevens. <\/strong>Een goed monitoringsysteem moet in staat zijn om snel alle gegevens te verzamelen en deze te verwerken volgens triggeruitdrukkingen \u2014 op basis van eigen criteria. Na verwerking moet het systeem deze gegevens ook snel opslaan in de database, zodat ze later gebruikt kunnen worden.<\/p>\n<p><strong>Opslaan van geschiedenis. <\/strong>Een goed monitoringsysteem moet de geschiedenis in de database opslaan en gemakkelijke toegang tot de metrics bieden. De geschiedenis is nodig om te gebruiken in rapporten, grafieken, triggers, drempelwaarden en berekende gegevensitems voor waarschuwingen.<\/p>\n<p><strong>Opruimen van geschiedenis. <\/strong>Soms komt er een dag dat je geen metrics meer hoeft op te slaan. Waarom zou je gegevens van vijf jaar geleden, een maand of twee nodig hebben: sommige knooppunten zijn verwijderd, sommige hosts of metrics zijn niet meer nodig omdat ze verouderd zijn en niet meer worden verzameld. Een goed monitorsysteem moet historische gegevens opslaan en deze van tijd tot tijd verwijderen zodat de database niet te groot wordt.<\/p>\n<blockquote><p>Het verwijderen van verouderde gegevens is een cruciaal vraagstuk dat een grote impact heeft op de prestaties van de database.<\/p><\/blockquote>\n<p><\/p>\n<h2>Caching in Zabbix<\/h2>\n<p>\nIn Zabbix worden de eerste en tweede oproep opgelost met behulp van caching. Voor het verzamelen en verwerken van gegevens wordt het RAM-geheugen gebruikt. Voor opslag zijn er de geschiedenis in triggers, grafieken en berekende datapunten. Aan de databasekant is er bepaalde caching voor de belangrijkste selecties, bijvoorbeeld voor grafieken.<\/p>\n<p>Caching aan de kant van de Zabbix-server zelf is:<\/p>\n<ul>\n<li>ConfigurationCache;<\/li>\n<li>ValueCache;<\/li>\n<li>HistoryCache;<\/li>\n<li>TrendsCache.<\/li>\n<\/ul>\n<p>\nLaten we ze in meer detail bekijken.<\/p>\n<h3>ConfigurationCache<\/h3>\n<p>\nDit is de belangrijkste cache waarin we metrics, hosts, datapunten, triggers - alles wat nodig is voor preprocessing en gegevensverzameling - opslaan.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/122708198f6cd136fbd0420876c06e9c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDit alles wordt opgeslagen in de ConfigurationCache om extra aanvragen aan de database te vermijden. Na de start van de server vernieuwen we deze cache, maken we configuraties aan en werken we deze regelmatig bij.<\/p>\n<h3>Gegevensverzameling<\/h3>\n<p>\nHet schema is vrij groot, maar het belangrijkste daarin is <strong>de verzamelaars.<\/strong>. Dit zijn verschillende \"pollers\" - verzamelprocessen. Ze zijn verantwoordelijk voor verschillende soorten verzamelen: ze verzamelen gegevens via SNMP, IPMI, en dragen dit allemaal over naar preprocessing.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/deff5d9ff358f1b04b505d18c7770f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><em>De verzamelaars zijn omrand met een oranje lijn.<\/em><\/p>\n<p>In Zabbix zijn er berekende aggregatie datapunten die nodig zijn om controles te aggregeren. Als we die hebben, halen we gegevens voor hen direct uit de ValueCache.<\/p>\n<h3>PreProcessing HistoryCache<\/h3>\n<p>\nAlle verzamelaars gebruiken de ConfigurationCache om opdrachten te verkrijgen. Vervolgens dragen ze deze over naar preprocessing.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/116e25100ebdf9ed209a9b04fa6fa156.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPreprocessing gebruikt de ConfigurationCache om de stappen voor preprocessing te verkrijgen. Het verwerkt deze gegevens op verschillende manieren.<\/p>\n<p>Na het verwerken van gegevens via preprocessing, worden ze opgeslagen in de HistoryCache, om te worden verwerkt. Hier eindigt de gegevensverzameling en gaan we over naar het belangrijkste proces in Zabbix - <strong>history syncer,<\/strong>, aangezien dit een monolithische architectuur is.<\/p>\n<p><em>Opmerking: Preprocessing is een vrij zware operatie. Sinds v 4.2 is het verplaatst naar de proxy. Als je een zeer grote Zabbix hebt met een groot aantal datapunten en verzamelingsfrequentie, verlicht dit de workload aanzienlijk.<\/em><\/p>\n<h3>ValueCache, geschiedenis &amp; trends cache<\/h3>\n<p><\/p>\n<blockquote><p>History syncer is het belangrijkste proces dat elk gegevenselement atomair verwerkt, dat wil zeggen elke waarde.<\/p><\/blockquote>\n<p>\nHistory syncer haalt waarden uit HistoryCache en controleert in de Configuration op triggers voor berekeningen. Als ze er zijn, dan rekent hij deze uit.<\/p>\n<p>History syncer cre\u00ebert een gebeurtenis, een escalatie om meldingen te genereren indien vereist door de configuratie, en schrijft deze op. Als er triggers zijn voor verdere verwerking, onthoudt hij deze waarde in ValueCache, zodat hij niet in de geschiedenis tabel hoeft te kijken. Zo wordt ValueCache gevuld met gegevens die nodig zijn voor de berekening van triggers en berekende elementen.<\/p>\n<p>History syncer schrijft alle gegevens naar de database, en deze naar de schijf. Het verwerkingsproces eindigt hier.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4d74195381fda7756b0250982f6896be.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Caching in de database<\/h3>\n<p>\nAan de databasezijde zijn er verschillende caches wanneer je grafieken of rapporten over gebeurtenissen wilt bekijken:<\/p>\n<ul>\n<li><code>Innodb_buffer_pool<\/code> aan de MySQL-zijde;<\/li>\n<li><code>shared_buffers<\/code> aan de PostgreSQL-zijde;<\/li>\n<li><code>effective_cache_size<\/code> aan de Oracle-zijde;<\/li>\n<li><code>shared_pool<\/code> aan de DB2-zijde.<\/li>\n<\/ul>\n<p>\nEr zijn nog veel andere caches, maar dit zijn de belangrijkste voor alle databases. Ze maken het mogelijk om gegevens die vaak nodig zijn voor aanvragen in het RAM te houden. Ze hebben hun eigen technologie\u00ebn hiervoor.<\/p>\n<h3>Databaseprestaties zijn van cruciaal belang<\/h3>\n<p>\nDe Zabbix-server verzamelt constant gegevens en schrijft deze op. Bij herstart leest hij ook uit de geschiedenis om ValueCache te vullen. Hij gebruikt <strong>de Zabbix API<\/strong>, die is gebaseerd op de webinterface. De Zabbix API maakt verbinding met de database en haalt de benodigde gegevens op voor grafieken, rapporten, evenementenlijsten en recente problemen.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/dd0efdc4e57c1197d448ce453012091e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoor visualisatie \u2014 <strong>Grafana<\/strong>. Dit is een populaire oplossing onder onze gebruikers. Hij kan rechtstreeks aanvragen indienen via de Zabbix API en in de database, en cre\u00ebert een bepaalde concurrentie voor het ophalen van gegevens. Daarom is een fijnere en betere databaseconfiguratie nodig om te voldoen aan de snelle output van resultaten en tests.<\/p>\n<h2>Housekeeper<\/h2>\n<p>\nDe derde prestatie-uitdaging in Zabbix is het opruimen van geschiedenis met behulp van Housekeeper. Hij houdt zich aan alle instellingen \u2014 in de gegevensitems staat aangegeven hoe lang de dynamiek van veranderingen (trends) in dagen bewaard moet blijven.<\/p>\n<p>TrendsCache berekenen we on-the-fly. Wanneer gegevens binnenkomen, aggregeren we deze over een uur en schrijven ze naar tabellen voor de dynamiek van veranderingen in trends.<\/p>\n<p>Housekeeper wordt gestart en verwijdert informatie uit de database met behulp van gewone 'selects'. Dit is niet altijd effici\u00ebnt, wat je kunt begrijpen aan de prestatiediagrammen van interne processen.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/a3af1badd14b1092bc26e0b53845ae04.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe rode grafiek toont aan dat de History syncer continu bezig is. De oranje grafiek bovenaan is de Housekeeper, die constant draait. Hij wacht op de database om alle rijen te verwijderen die hij heeft opgegeven.<\/p>\n<p>Wanneer moet je de Housekeeper uitschakelen? Bijvoorbeeld, als er een 'Item ID' is en je moet de laatste 5.000 rijen verwijderen over een bepaalde tijd. Natuurlijk gebeurt dit op basis van indexen. Maar meestal is de dataset zeer groot, en de database leest toch van de schijf en laadt in het cachegeheugen. Dit is altijd een zeer dure operatie voor de database en, afhankelijk van de grootte van de database, kan dit leiden tot prestatieproblemen.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/0778318b539fbe33318e8a7310f8a89b.jpg\" style=\"display:block;margin: 0 auto;\" \/> <\/p>\n<p>Je kunt de Housekeeper eenvoudig uitschakelen. In de webinterface is er een instelling onder 'Administratie algemeen' voor de Housekeeper. We schakelen de interne housekeeping voor de interne trendgeschiedenis uit en hij beheert dit niet meer.<\/p>\n<p>De Housekeeper is uitgeschakeld, de grafieken zijn gelijkgetrokken \u2014 wat voor problemen kunnen er in dit geval zijn en wat kan helpen bij het oplossen van de derde prestatieoproep?<\/p>\n<h2>Partitioning \u2014 partitionering of sectieindeling<\/h2>\n<p>\nGewoonlijk wordt partitionering op verschillende manieren ingesteld op elke relationele database die ik heb opgesomd. Elke database heeft zijn eigen technologie, maar ze zijn in het algemeen vergelijkbaar. Het aanmaken van een nieuwe partitie leidt vaak tot bepaalde problemen.<\/p>\n<p>Gewoonlijk worden partities ingesteld op basis van de 'setup' \u2014 de hoeveelheid gegevens die per dag wordt aangemaakt. In de regel wordt partitionering ingesteld op \u00e9\u00e9n dag, dit is het minimum. Voor trends wordt een nieuwe partitie ingesteld op basis van 1 maand.<\/p>\n<p>De waarden kunnen veranderen in het geval van een zeer grote 'setup'. Als de kleine 'setup' tot 5.000 nvps (nieuwe waarden per seconde) is, gemiddeld van 5.000 tot 25.000, dan is de grote meer dan 25.000 nvps. Dit zijn grote en zeer grote installaties die zorgvuldige afstemming van de database vereisen.<\/p>\n<p>Op zeer grote installaties kan een segment van \u00e9\u00e9n dag niet optimaal zijn. Ik heb partities van 40 GB of meer per dag op MySQL gezien. Dit is een zeer grote hoeveelheid gegevens, wat kan leiden tot problemen, en het moet verminderd worden.<\/p>\n<h3>Wat biedt partitionering?<\/h3>\n<p>\n<strong>Tabelpartitionering<\/strong>. Vaak zijn dit afzonderlijke bestanden op de schijf. Het uitvoeringsplan voor de aanvraag kiest optimaler \u00e9\u00e9n partitie. Gewoonlijk wordt partitionering gedaan op basis van bereiken \u2014 dit geldt ook voor Zabbix. We gebruiken daar 'timestamp' \u2014 tijd sinds het begin van het tijdperk. Voor ons zijn dit gewone getallen. Je stelt het begin en het einde van de dag in \u2014 dat is de partitie.<\/p>\n<p><strong>Snelle verwijdering<\/strong> \u2014 <code>HEAD<\/code>Er wordt \u00e9\u00e9n bestand\/subtabel geselecteerd, niet een selectie van rijen voor verwijdering.<\/p>\n<p><strong>Versnelt de selectie van gegevens merkbaar.<\/strong> <code>SELECT<\/code> \u2014 gebruikt \u00e9\u00e9n of meer partities, niet de volledige tabel. Als u gegevens van twee dagen geleden opvraagt, worden deze sneller uit de database opgehaald, omdat er slechts \u00e9\u00e9n bestand moet worden geladen in de cache in plaats van een grote tabel.<\/p>\n<p>Vaak versnelt dit ook vele databases. <code>INSERT<\/code> \u2014 invoegingen in de child-tabel.<\/p>\n<h2>TimescaleDB<\/h2>\n<p>\nVoor versie 4.2 hebben we gekeken naar TimescaleDB. Deze uitbreiding voor PostgreSQL heeft een native interface. De uitbreiding werkt effici\u00ebnt met tijdreeksgegevens, zonder de voordelen van relationele databases te verliezen. TimescaleDB partitioneert ook automatisch.<\/p>\n<p>In TimescaleDB bestaat het concept van <strong>hypertabel,<\/strong> die u cre\u00ebert. Hierin bevinden zich <strong>chunks,<\/strong> \u2014 partities. Chunks zijn automatisch beheerde fragmenten van de hypertabel, die geen invloed hebben op andere fragmenten. Voor elke chunk geldt een eigen tijdsbereik.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor 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 werkt echt effici\u00ebnt. De ontwikkelaars van de uitbreiding beweren dat zij een betere algoritme gebruiken voor het verwerken van aanvragen, in het bijzonder voor <code>inserts<\/code>. Wanneer de grootte van de dataset-invoegingen toeneemt, behoudt het algoritme constante prestaties.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/52f042018180ffd2cb6a2cf4a3af603e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNa 200 miljoen rijen begint PostgreSQL meestal aanzienlijk te vertragen en verliest het zijn prestaties tot 0. TimescaleDB maakt effici\u00ebnte invoegingen mogelijk bij elke hoeveelheid gegevens.<\/p>\n<h3>Installatie<\/h3>\n<p>\nTimescaleDB installeren is vrij eenvoudig voor alle pakketten. In <noindex><a rel=\"nofollow\" href=\"https:\/\/docs.timescale.com\/v1.3\/getting-started\">de documentatie<\/a><\/noindex> wordt alles in detail beschreven \u2013 het hangt af van de offici\u00eble PostgreSQL-pakketten. TimescaleDB kan ook handmatig worden samengesteld en gecompileerd.<\/p>\n<p>Voor de Zabbix database activeren we eenvoudig de uitbreiding:<\/p>\n<pre><code class=\"sql\">echo \"CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;\" | sudo -u postgres psql zabbix<\/code><\/pre>\n<p>\nU activeert de <code>uitbreiding<\/code> en cre\u00ebert deze voor de Zabbix database. De laatste stap is het cre\u00ebren van de hypertabel.<\/p>\n<h3>Migratie van historische tabellen naar TimescaleDB.<\/h3>\n<p>\nHiervoor is er een speciale functie, <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>\nDe functie heeft drie parameters. De eerste is<strong> de tabel in de database<\/strong>, waarvoor een hypertable moet worden aangemaakt. De tweede is <strong>veld<\/strong>, waarop de moet worden aangemaakt <code>chunk_time_interval<\/code> \u2014 het tijdsinterval voor de partitiechunk die moet worden gebruikt. In mijn geval is het interval \u00e9\u00e9n dag \u2014 86.400.<\/p>\n<p>De derde parameter is <code><strong>migrate_data<\/strong><\/code>. Als je dit instelt op <code>true<\/code>, worden alle huidige gegevens overgebracht naar de vooraf aangemaakte chunks. Ikzelf heb gebruikt <code>migrate_data<\/code>. Ik had ongeveer 1 TB, wat meer dan een uur kostte. Zelfs in sommige gevallen, tijdens het testen, verwijderde ik niet-noodzakelijke historische gegevens van tekenreekstypen om deze niet over te brengen.<\/p>\n<p>De laatste stap is\u00a0<code><strong>UPDATE<\/strong><\/code>: in <code>db_extension<\/code> zetten we <code>timescaledb<\/code>, zodat de database begrijpt dat deze uitbreiding bestaat. Zabbix activeert dit en gebruikt de syntaxis en de queries correct voor de database \u2014 die functies die nodig zijn voor TimescaleDB.<\/p>\n<h2>Configuratie van de hardware<\/h2>\n<p>\nIk gebruikte twee servers. De eerste is <strong>een VMware-machine<\/strong>. Deze is vrij klein: 20 processoren Intel\u00ae Xeon\u00ae CPU E5-2630 v4 @ 2,20 GHz, 16 GB RAM en een SSD-schijf van 200 GB.<\/p>\n<p>Ik heb PostgreSQL 10.8 ge\u00efnstalleerd met Debian 10.8-1.pgdg90+1 en het xfs-bestandssysteem. Alles is minimaal ingesteld om deze specifieke database te gebruiken, behalve dat wat door Zabbix zelf zal worden gebruikt.<\/p>\n<p>Op deze machine stond ook de Zabbix-server, PostgreSQL en <strong>belastingagents<\/strong>. Ik had 50 actieve agents, die gebruik maakten van <code>LoadableModule<\/code>, om zeer snel verschillende resultaten te genereren: getallen, strings. Ik vulde de database met een grote hoeveelheid gegevens.<\/p>\n<p>Oorspronkelijk bevatte de configuratie <strong>5.000 gegevensitems<\/strong> per host. Bijna elk item bevatte een trigger, zodat het leek op echte installaties. In sommige gevallen waren er meer dan \u00e9\u00e9n trigger. Voor \u00e9\u00e9n netwerknode waren er <strong>3.000-7.000 triggers<\/strong>.<\/p>\n<p>De updatefrequentie van de gegevensitems is <strong>4-7 seconden<\/strong>Ik reguleerde de belasting door niet alleen 50 agents te gebruiken, maar ik voegde er meer toe. Ook met behulp van data-elementen reguleerde ik dynamisch de belasting en verlaagde ik het update-interval tot 4 seconden.<\/p>\n<h3>PostgreSQL. 35.000 nvps<\/h3>\n<p>\nDe eerste uitvoering op deze hardware was met een schone PostgreSQL \u2014 35.000 waarden per seconde. Zoals te zien is, neemt het invoegen van gegevens fracties van een seconde in beslag \u2014 alles verloopt goed en snel. Het enige is dat de SSD-schijf van 200 GB snel vol raakt.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e84b2eb0f6fbbd902c5feab367c750ee.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDit is het standaard Zabbix-prestatie-dashboard voor servers.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/c3afe021acf8e272813b8d8c2f82e762.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe eerste blauwe grafiek toont het aantal waarden per seconde. De tweede grafiek aan de rechterkant toont de belasting van de verzamelprocessen. De derde grafiek toont de belasting van interne verzamelprocessen: history syncers en Housekeeper, die hier lange tijd actief was.<\/p>\n<p>De vierde grafiek toont het gebruik van HistoryCache. Dit is een soort buffer voor het invoegen in de database. De groene vijfde grafiek toont het gebruik van ValueCache, oftewel hoeveel hits ValueCache voor triggers \u2014 dit zijn enkele duizenden waarden per seconde.<\/p>\n<h3>PostgreSQL. 50.000 nvps<\/h3>\n<p>\nDaarna verhoogde ik de belasting tot 50.000 waarden per seconde op deze zelfde hardware.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/8f10944486d5502b57d36059382d551b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBij het laden met Housekeeper werd het invoegen van 10.000 waarden geregistreerd binnen 2-3 seconden.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/5228c1735f0ee2da7f827093f3c7b1f9.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>Housekeeper begint al in de weg te zitten.<\/em><\/p>\n<p>Uit de derde grafiek blijkt dat de belasting van de trapper- en history syncers tot nu toe op niveau van 60% ligt. In de vierde grafiek begint HistoryCache tijdens het werken met Housekeeper al vrij actief vol te lopen. Het is met 20% gevuld \u2014 dat is ongeveer 0,5 GB.<\/p>\n<h3>PostgreSQL. 80.000 nvps<\/h3>\n<p>\nVervolgens verhoogde ik de belasting tot 80.000 waarden per seconde. Dit is ongeveer 400.000 data-elementen en 280.000 triggers.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/f6c6b0d6793f96523f7406e68f98c608.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<em>De invoeging bij een belasting van dertig history syncers is al behoorlijk hoog.<\/em><\/p>\n<p>Ook verhoogde ik verschillende parameters: history syncers, caches.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/6ca7edd76aea6fdec00a61a0a6dc34e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOp mijn hardware steeg de belasting van de history syncers tot het maximum. HistoryCache vulde zich snel met gegevens \u2014 in de buffer verzamelden zich gegevens voor verwerking.<\/p>\n<p>De hele tijd observeerde ik hoe de CPU, RAM en andere systeemparameters werden gebruikt en ontdekte ik dat de schijfutilisatie maximaal was.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/e964a000156b561accd23b4e1644f4a8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIk bereikte het gebruik van <strong>de maximale capaciteiten van de schijf<\/strong> op deze hardware en op deze virtuele machine. Bij deze intensiteit begon PostgreSQL de gegevens vrij actief te flushen, en de schijf kon niet meer effectief lezen en schrijven.<\/p>\n<h3>Tweede server<\/h3>\n<p>\nIk heb een andere server genomen, die al 48 processors en 128 GB RAM had. Ik heb hem getuned - ik installeerde 60 history syncers en bereikte acceptabele prestaties.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/591fc759b336d5fb2091460036b136bf.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEigenlijk is dit al de grens van de prestaties, waar iets gedaan moet worden.<\/p>\n<h3>TimescaleDB. 80.000 nvps<\/h3>\n<p>\nMijn belangrijkste taak is om de mogelijkheden van TimescaleDB onder belasting vanuit Zabbix te testen. 80.000 waarden per seconde is veel, de frequentie van het verzamelen van metrics (behalve Yandex, natuurlijk) en een behoorlijk grote 'setup'.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/aa569847e7bc31baab91661db1ee78a2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOp elke grafiek is er een dip - dat is precies de migratie van gegevens. Na de dips in de Zabbix-server veranderde het laadprofiel van de history syncer drastisch - het viel met een factor drie.<\/p>\n<blockquote><p>TimescaleDB stelt je in staat om gegevens bijna drie keer sneller in te voegen en minder HistoryCache te gebruiken.<\/p><\/blockquote>\n<p>\nDaarom ontvang je tijdig je gegevens.<\/p>\n<h3>TimescaleDB. 120.000 nvps<\/h3>\n<p>\nDaarna verhoogde ik het aantal gegevens tot 500.000. De belangrijkste taak was om de mogelijkheden van TimescaleDB te testen - ik kreeg een geschat aantal van 125.000 waarden per seconde.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/4770ca4030e1c086f2fd9305a12496bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDit is een werkende 'setup' die lang kan draaien. Maar omdat mijn schijf slechts 1,5 TB was, vulde ik deze in een paar dagen.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/1ad521b909a22a7db81a9ed802d348e7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHet belangrijkste is dat op dat moment nieuwe TimescaleDB-partities werden aangemaakt.<\/p>\n<p>Voor de prestaties is dit helemaal niet merkbaar. Wanneer partities in MySQL worden aangemaakt, is het heel anders. Dit gebeurt meestal 's nachts omdat het de algemene invoer blokkeert, de werkzaamheden met tabellen verstoort en service-afbraakin kan veroorzaken. Dit is niet het geval met TimescaleDB.<\/p>\n<p>Als voorbeeld laat ik een grafiek zien uit de vele in de community. De afbeelding bevat TimescaleDB, waardoor de belasting op het gebruik van io.weight op de processor is gedaald. Het gebruik van interne proces-elementen is ook verminderd. Dit is overigens een gewone virtuele machine op normale schijven en geen SSD.<\/p>\n<p><img decoding=\"async\" alt=\"Hoge prestaties en native partitionering: Zabbix met ondersteuning voor TimescaleDB\" src=\"\/wp-content\/uploads\/2019\/10\/bea0cd0f1448e1d1b3a5f979d51ce61c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Conclusies<\/h2>\n<p>\n<strong>TimescaleDB is een goede oplossing voor kleine 'setups'<\/strong>, die vastlopen op de schijfprestaties. Het stelt je in staat om redelijk door te blijven werken tot de database naar snellere hardware migreert.<\/p>\n<p>TimescaleDB is eenvoudig in te stellen, biedt prestatieverbeteringen, werkt goed met Zabbix en <strong>heeft voordelen ten opzichte van PostgreSQL.<\/strong>.<\/p>\n<p>Als je PostgreSQL gebruikt en niet van plan bent het te wijzigen, raad ik aan <strong>PostgreSQL met de TimescaleDB-extensie in combinatie met Zabbix<\/strong>. Deze oplossing werkt effectief tot middelgrote 'setups'.<\/p>\n<blockquote>\n<p>Als we 'hoge prestaties' zeggen, bedoelen we <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\">HighLoad++<\/a><\/noindex>Het duurt niet lang meer om kennis te maken met de technologie\u00ebn en praktijken die services in staat stellen miljoenen gebruikers te bedienen. Lijst <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/abstracts\">van rapporten<\/a><\/noindex> voor 7 en 8 november hebben we al samengesteld, maar <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/moscow\/2019\/meetups\">meetups<\/a><\/noindex> kunnen nog worden voorgesteld.<\/p>\n<p>Volg onze <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/VYVaf\">de nieuwsbrief<\/a><\/noindex> en <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/HighLoadChannel\">telegram<\/a><\/noindex>, waarin we de geheimen van de aankomende conferentie onthullen en ontdek hoe je er het meeste uit kunt halen.<\/p>\n<\/blockquote>\n<p>Bron: <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\/nl\/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=\"nl_NL\" \/>\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\/nl\/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\udd47Hoge prestaties en native partionering: Zabbix met ondersteuning voor TimescaleDB | ProHoster","description":"Zabbix is een monitoringsysteem.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie-zabbix-s-podderzhkoj-timescaledb","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/38927","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=38927"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/38927\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/29204"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=38927"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=38927"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=38927"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}