{"id":33632,"date":"2019-10-31T21:53:52","date_gmt":"2019-10-31T18:53:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/eshhe-odna-sistema-monitoringa\/"},"modified":"2019-10-31T21:53:52","modified_gmt":"2019-10-31T18:53:52","slug":"eshhe-odna-sistema-monitoringa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","title":{"rendered":"\u0415\u0449\u0435 \u043e\u0434\u043d\u0430 \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"\u0415\u0449\u0435
\n16 modemov, 4 mobilna operaterja = Izhodna hitrost 933,45 Mbit\/s<\/em> <\/p>\n

<\/p>\n

Uvod<\/h2>\n

<\/p>\n

Pozdravljeni! Ta \u010dlanek govori o tem, kako smo zase razvili nov sistem za spremljanje. Od obstoje\u010dih se razlikuje po mo\u017enosti visoko frekven\u010dnega sinhroniziranega pridobivanja metrik in zelo majhni porabi virov. Frekvenca anketiranja lahko dose\u017ee 0,1 milisekunde z natan\u010dnostjo sinhronizacije med metrikami 10 nanosekund. Vse binarne datoteke zasedajo 6 megabajtov. <\/p>\n

<\/a><\/noindex><\/p>\n

O projektu<\/h2>\n

<\/p>\n

Imamo precej specifi\u010den izdelek. Ustvarjamo celovito re\u0161itev za zdru\u017eevanje pasovne \u0161irine in odpornosti omre\u017enih povezav. To pomeni, da imamo ve\u010d povezav, recimo Operater1 (40 Mbit\/s) + Operater2 (30 Mbit\/s) + \u0161e kaj (5 Mbit\/s), kar na koncu daje en stabilen in hiter kanal, katerega hitrost bo pribli\u017eno taka: (40+30+5)\u00d70.92=75\u00d70.92=69 Mbit\/s. <\/p>\n

<\/p>\n

Tovrstne re\u0161itve so iskane tam, kjer zmogljivost katerega koli enega kanala ni zadostna. Na primer, v transportu, video nadzornih sistemih in prenosu video vsebin v realnem \u010dasu, prenosu neposrednih televizijskih in radijskih oddaj, in v vseh pode\u017eelskih objektih, kjer so na voljo le predstavniki velike \u010detvorke in hitrosti na enem modemu\/kanalu niso dovolj.
\nZa vsako od teh usmeritev izdamo posebno linijo naprav, vendar je programski del skoraj enak in kakovosten sistem spremljanja - eden od glavnih modulov, brez pravilne implementacije katerega izdelek ne bi bil mogo\u010d.<\/p>\n

<\/p>\n

V zadnjih nekaj letih nam je uspelo ustvariti ve\u010dstopenjski hiter, ve\u010dplatformski in lahek sistem spremljanja. Temu \u017eelimo deliti z ob\u010dinstvom.<\/p>\n

<\/p>\n

Definisanje zadatka<\/h2>\n

<\/p>\n

Sistem spremljanja zagotavlja pridobivanje metrik dveh temeljno razli\u010dnih razredov: metrike v realnem \u010dasu in vse ostale. Za sistem spremljanja so bili le naslednji zahteve:<\/p>\n

<\/p>\n

    \n
  1. Visoko frekven\u010dno sinhronizirano pridobivanje metrik v realnem \u010dasu in njihovo posredovanje v sistem za obvladovanje komunikacij brez zamud.
    \nVisoka frekvenca in sinhronizacija razli\u010dnih metrik ni le pomembna, temve\u010d je \u017eivljenjsko pomembna za analizo entropije prenosnih kanalov. \u010ce je povpre\u010dna zakasnitev v enem prenosnem kanalu 30 milisekund, napaka v sinhronizaciji z ostalimi metriki zgolj eno milisekundo privede do degradacije hitrosti kon\u010dnega kanala pribli\u017eno za 5%. \u010ce naredimo napako v sinhronizaciji za 1 milisekundo v 4 kanalah, lahko degradacija hitrosti enostavno pade do 30%. Poleg tega se entropija v kanalih zelo hitro spreminja, zato \u010de jo merimo redkeje kot enkrat na 0.5 milisekunde, bomo na hitrih kanalih z majhno zakasnitvijo prejeli visoko degradacijo hitrosti. Seveda to\u010dno tak\u0161na natan\u010dnost ni potrebna za vse metrike in ne v vseh pogojih. Ko bo zakasnitev v kanalu 500 milisekund, in delamo tudi s tak\u0161nimi, bo napaka 1 milisekundo skoraj neopazna. Prav tako za metrike sistemov za zagotavljanje \u017eivljenjskih funkcij zadostuje frekvenca anketiranja in sinhronizacije 2 sekundi, vendar mora sama sistemska nadzorna orodja obvladovati izjemno visoke frekvence anketiranja in izjemno natan\u010dno sinhronizacijo metrik.<\/li>\n
  2. Minimorna poraba virov in enoten kup.
    \nKon\u010dno napravo lahko predstavlja tako mo\u010dan vgrajen kompleks, ki lahko analizira situacijo na cesti ali izvaja biometri\u010dno registracijo ljudi, kot tudi enotna plo\u0161\u010da velikosti dlani, ki jo nosi vojak posebnih enot pod jopi\u010dem, da bi v realnem \u010dasu prena\u0161al video v pogojih slabe povezave. Kljub tak\u0161ni raznolikosti arhitektur in ra\u010dunalni\u0161ke mo\u010di bi \u017eeleli imeti enak programerski kup.<\/li>\n
  3. De\u017enik arhitektura
    \nMetri\u010dne podatke je treba zbirati in agregirati na kon\u010dni napravi, imeti lokalni sistem shranjevanja in vizualizacijo v realnem \u010dasu ter retrospektivno. V primeru povezave je treba prenesti podatke v centralni sistem nadzora. Ko povezave ni, mora biti vrsta za prenos nalo\u017eena in ne sme porabljati delovne spomina. <\/li>\n
  4. API za integracijo v sistem nadzora naro\u010dnika, ker nih\u010de ne potrebuje mnogih sistemov nadzora. Naro\u010dnik mora zbirati podatke iz vseh naprav in omre\u017eij v enoten nadzor.<\/li>\n<\/ol>\n

    <\/p>\n

    \u0160ta je postignuto<\/h2>\n

    <\/p>\n

    Da ne bi optere\u0107ivali ve\u0107 obimnu analizu, ne\u0107u navoditi primere i mere svih sistema za nadzor. To bi zahtevalo jo\u0161 jedan \u010dlanak. Samo \u0107u re\u0107i da nismo uspeli da prona\u0111emo sistem za nadzor koji mo\u017ee da prati dve metrike istovremeno uz gre\u0161ku manju od 1 milisekunde i koji jednako efikasno funkcioni\u0161e na ARM arhitekturi sa 64MB RAM-a i na x86_64 arhitekturi sa 32GB RAM-a. Stoga smo odlu\u010dili da napi\u0161emo sopstveni, koji mo\u017ee sve to. Evo \u0161ta smo postigli:<\/p>\n

    <\/p>\n

    Sabrati propusnost tri kanala za razli\u010dite topologije mre\u017ee<\/h3>\n

    \n

    \r\n \"Predvajaj\r\n
    <\/div>\r\n <\/div><\/center>
    \n
    \r\n \"Predvajaj\r\n
    <\/div>\r\n <\/div><\/center><\/p>\n

    Vizualizacija nekih klju\u010dnih metrika<\/h3>\n

    \n\"\u0415\u0449\u0435
    \n\"\u0415\u0449\u0435
    \n\"\u0415\u0449\u0435
    \n\"\u0415\u0449\u0435<\/p>\n

    Arhitektura<\/h2>\n

    <\/p>\n

    Kao glavni programski jezik, kako na ure\u0111aju, tako i u podatkovnom centru, koristimo Golang. On zna\u010dajno olak\u0161ava \u017eivot svojom implementacijom vi\u0161ezadatnosti i mogu\u0107no\u0161\u0107u da se dobije jedan stati\u010dki povezani izvr\u0161ni binarni fajl za svaku uslugu. Kao rezultat, zna\u010dajno \u0161tedimo u resursima, metodama i saobra\u0107aju pri implementaciji usluge na krajnje ure\u0111aje, kao i vreme razvoja i otklanjanja gre\u0161aka u kodu. <\/p>\n

    <\/p>\n

    Sistem je realizovan po klasi\u010dnom modularnom principu i sadr\u017ei nekoliko podsistema:<\/p>\n

    <\/p>\n

      \n
    1. Registracija metrika.
      \nSvaka metrika se poslu\u017euje vlastitom niti i sinhronizuje putem kanala. Uspeli smo da postignemo ta\u010dnost sinhronizacije do 10 nanosekundi.<\/li>\n
    2. Skladi\u0161tenje metrika
      \nIzbrali smo med tem, da bi razvili svoje shranjevanje za \u010dasovne vrste in uporabo \u017ee obstoje\u010dega. Podatkovna baza je potrebna za retrospektivne podatke, ki jih bomo kasneje vizualizirali. To pomeni, da nima podatkov o zakasnitvah v kanalu vsakih 0,5 milisekunde ali o napakah v transportnem omre\u017eju, temve\u010d bele\u017ei hitrost na vsakem vmesniku vsakih 500 milisekund. Poleg visokih zahtev za medplatformno zdru\u017eljivost in nizko porabo virov je zame izjemno pomembno, da lahko obdelamo podatke tam, kjer so shranjeni. To izjemno prihrani ra\u010dunalni\u0161ke vire. Od leta 2016 uporabljamo DBMS Tarantool v tem projektu in zaenkrat ne vidimo nobene zamenjave. Fleksibilen, z optimalno porabo virov in z ve\u010d kot zadovoljivo tehni\u010dno podporo. V Tarantoolu je tudi GIS modul. Seveda ni tako zmogljiv kot PostGIS, vendar zadostuje za na\u0161e potrebe shranjevanja nekaterih metrike povezanih z lokacijo (kar je aktualno za transport). <\/li>\n
    3. Vizualizacija metrik
      \nTukaj je vse relativno preprosto. Vzamemo podatke iz shranjevanja in jih prika\u017eemo bodisi v realnem \u010dasu bodisi retrospektivno. <\/li>\n
    4. Sinhronizacija podatkov s centralnim sistemom za nadzor.
      \nOsrednji sistem za nadzor sprejema podatke iz vseh naprav, jih shranjuje z dolo\u010denim \u010dasovnim okvirom in preko API-jev jih posreduje v sistem nadzora naro\u010dnika. V nasprotju s klasi\u010dnimi sistemi nadzora, kjer 'glava' zbira podatke, imamo obratno shemo. Naprave same po\u0161iljajo podatke, ko je povezava na voljo. To je zelo pomemben vidik, saj omogo\u010da pridobivanje podatkov iz naprave v \u010dasovnih obdobjih, ko ta ni bila na voljo, in ne obremenjuje kanalov in virov, ko naprava ni dostopna. Kot osrednji sistem za nadzor uporabljamo Influx monitoring server. V nasprotju s podobnimi re\u0161itvami zna uvoziti retrospektivne podatke (tj. s \u010dasovno oznako, ki se razlikuje od trenutka pridobitve metrike). Zbrane metrike vizualizira dodelana Grafana. Ta standarden sklad je bil izbran tudi zato, ker ima pripravljene API integracije prakti\u010dno z vsakim sistemom nadzora naro\u010dnika.<\/li>\n
    5. Sinhronizacija podatkov s centralnim sistemom za upravljanje naprav.
      \nUpravljalski sistem naprav izvaja Zero Touch Provisioning (posodobitev programske opreme, konfiguracije itd.) in se za razliko od sistema spremljanja osredoto\u010da le na te\u017eave naprav. To so spro\u017eilci delovanja vgrajenih strojnih servisov in vse metrike sistemov, ki zagotavljajo \u017eivljenje: temperatura CPU in SSD, obremenitev CPU, prosti prostor in S.M.A.R.T zdravje diskov. Shranjevanje podnabora je prav tako zgrajeno na Tarantoolu. To nam zagotavlja znatno hitrost pri agregaciji \u010dasovnih vrst po tiso\u010dih naprav, prav tako pa v celoti re\u0161uje vpra\u0161anje sinhronizacije podatkov s temi napravami. Tarantool ima vgrajen odli\u010den sistem \u010dakalnih vrst in zagotovljene dostave. To pomembno funkcijo smo dobili kar iz \u0161katle, odli\u010dno!<\/li>\n<\/ol>\n

      <\/p>\n

      Sistem upravljanja omre\u017eja<\/h3>\n

      \n\"\u0415\u0449\u0435<\/p>\n

      Kaj naprej<\/h2>\n

      <\/p>\n

      Trenutno je na\u0161a najs \u0161ibkej\u0161a povezava osrednji sistem spremljanja. Uresni\u010dena je 99,9 % na standardni tehnologiji in ima vrsto pomanjkljivosti:<\/p>\n

      <\/p>\n

        \n
      1. InfluxDB izgublja podatke ob izpadu napajanja. Na splo\u0161no naro\u010dnik hitro sprejme vse, kar pride z naprav, in v sami bazi ni podatkov starej\u0161ih od 5 minut, vendar bi to v prihodnosti lahko predstavljalo te\u017eavo.<\/li>\n
      2. Grafana ima vrsto te\u017eav z agregacijo podatkov in sinhronizacijo njihovega prikaza. Najpogostej\u0161a te\u017eava je, ko v bazi obstaja \u010dasovna vrsta z intervalom 2 sekundi, ki se za\u010dne recimo ob 00:00:00, Grafana pa za\u010dne prikazovati podatke v agregaciji s +1 sekundo. Posledi\u010dno uporabnik vidi pritiskajo\u010di graf.<\/li>\n
      3. Prekomerna koli\u010dina kode za API integracijo s tretjimi sistemi spremljanja. Lahko bi bilo veliko bolj kompaktno in seveda prepisano v Go.<\/li>\n<\/ol>\n

        <\/p>\n

        Menim, da ste vsi videli, kako izgleda Grafana, in brez mene poznate njene te\u017eave, zato ne bom preobremenjeval objave s slikami.<\/p>\n

        <\/p>\n

        Zaklju\u010dek<\/h2>\n

        <\/p>\n

        Zavedno nisem podrobno opisoval tehni\u010dnih podrobnosti, temve\u010d sem le opisal osnovno zasnovo tega sistema. Prvi\u010d, za tehni\u010dno popoln opis sistema bi potrebovali \u0161e en \u010dlanek. Drugi\u010d, dale\u010d ne bo vsem to zanimivo. V komentarjih mi sporo\u010dite, katere tehni\u010dne podrobnosti vas zanimajo. <\/p>\n

        <\/p>\n

        \u010ce imate kakr\u0161na koli vpra\u0161anja izven tega \u010dlanka, me lahko kontaktirate na naslov a.rodin @ qedr.com<\/p>\n

        Izvor: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

        16 \u043c\u043e\u0434\u0435\u043c\u043e\u0432, 4 \u0441\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430= \u0418\u0441\u0445\u043e\u0434\u044f\u0449\u0430\u044f \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c 933.45 \u041c\u0431\u0438\u0442\/\u0441 \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0442! \u042d\u0442\u043e \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u0440\u043e \u0442\u043e, \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u043f\u0438\u0441\u0430\u043b\u0438 \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043d\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041e\u0442 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043e\u043d\u0430 \u043e\u0442\u043b\u0438\u0447\u0430\u0435\u0442\u0441\u044f \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0432\u044b\u0441\u043e\u043a\u043e\u0447\u0430\u0441\u0442\u043e\u0442\u043d\u043e\u0433\u043e \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u043e\u0433\u043e \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f \u043c\u0435\u0442\u0440\u0438\u043a \u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u043c \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u0435\u043d\u0438\u0435\u043c \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0427\u0430\u0441\u0442\u043e\u0442\u0430 \u043e\u043f\u0440\u043e\u0441\u0430 \u043c\u043e\u0436\u0435\u0442 \u0434\u043e\u0441\u0442\u0438\u0433\u0430\u0442\u044c 0.1 \u043c\u0438\u043b\u043b\u0438\u0441\u0435\u043a\u0443\u043d\u0434\u044b \u0441 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c\u044e \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0435\u0442\u0440\u0438\u043a\u0430\u043c\u0438 \u0432 10 \u043d\u0430\u043d\u043e\u0441\u0435\u043a\u0443\u043d\u0434. \u0412\u0441\u0435 \u0431\u0438\u043d\u0430\u0440\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u044b \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25323,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33632","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u0160e en sistem spremljanja | ProHoster","description":"16 modemov, 4 mobilni operaterji = Izhodna hitrost 933,45.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\u0415\u0449\u0435 \u043e\u0434\u043d\u0430 \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 | ProHoster","og:description":"16 \u043c\u043e\u0434\u0435\u043c\u043e\u0432, 4 \u0441\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430= \u0418\u0441\u0445\u043e\u0434\u044f\u0449\u0430\u044f \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c 933.45.","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:53:52+00:00","article:modified_time":"2019-10-31T18:53:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33632","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-21 16:05:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:19:51","updated":"2026-01-21 16:05:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/33632","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=33632"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/33632\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/25323"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=33632"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=33632"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=33632"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}