{"id":31864,"date":"2019-10-31T21:43:33","date_gmt":"2019-10-31T18:43:33","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monitoring-myortv-da-zdravstvuet-monitoring\/"},"modified":"2019-10-31T21:43:33","modified_gmt":"2019-10-31T18:43:33","slug":"monitoring-myortv-da-zdravstvuet-monitoring","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","title":{"rendered":"Monitoring mrtvih? \u2014 Neka \u017eivi monitoring","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Monitoring mrtvih? \u2014 Neka \u017eivi monitoring\" src=\"\/wp-content\/uploads\/2019\/04\/13453bb7025a6bf3d1c7a3dc6d038d16.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNa\u0161a tvrtka od 2008. godine uglavnom se bavi upravljanjem infrastrukturom i 24-satnom tehni\u010dkom podr\u0161kom za web projekte: imamo vi\u0161e od 400 klijenata, \u0161to \u010dini otprilike 15% elektroni\u010dke trgovine u Hrvatskoj. Samim tim, podr\u0161ka ima vrlo raznoliku arhitekturu. Ako ne\u0161to padne, du\u017eni smo to popraviti unutar 15 minuta. No, kako bismo razumjeli da je do\u0161lo do nesre\u0107e, potrebno je nadzirati projekt i reagirati na incidente. Kako to u\u010diniti? <\/p>\n<p>Mislim da u organizaciji ispravnog sustava monitoringa dolazi do problema. Da tih problema nije bilo, moj izlaganje bi se sastojalo od jednog tezisa: \"Molimo vas instalirajte Prometheus + Grafana i dodatke 1, 2, 3\". Na\u017ealost, vi\u0161e to ne funkcioni\u0161e. A glavni problem le\u017ei u tome \u0161to svi nastavljaju vjerovati u ne\u0161to \u0161to je postojalo 2008. godine, s obzirom na softverske komponente. <\/p>\n<p>\u0160to se ti\u010de organizacije sustava monitoringa, riskirao bih re\u0107i da... ne postoji projekata s pravilnim monitoringom. Situacija je toliko lo\u0161a da, ako ne\u0161to padne, postoji rizik da \u0107e ostati nezapa\u017eeno \u2014 svi su uvjereni da se \"sve nadzire\".<br \/>\nMo\u017eda se sve nadzire. Ali kako? <\/p>\n<p>Svi smo se susreli s pri\u010dom sli\u010dnom sljede\u0107oj: radi odre\u0111eni DevOps, neki administrator, a timu developera dolazi i ka\u017ee \u2014 \"objavili smo, sada nadzirite\". \u0160to nadzirati? Kako to radi?<\/p>\n<p>U redu. Nadziremo na stari na\u010din. A ono se ve\u0107 mijenja, i otkriva se da ste nadzirali servis A, koji je postao servis B, koji komunicira sa servisom C. No, tim developera vam ka\u017ee: \"Instalirajte softver, on bi trebao sve nadzirati!\"<\/p>\n<p>\u0160to se promijenilo? \u2014 Sve se promijenilo!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>2008. godina. Sve je bilo savr\u0161eno<\/h4>\n<p>\nIma par developera, jedan server, jedan server BD. Odatle sve i ide. Imamo odre\u0111ene informacije, postavljamo Zabbix, Nagios, Cacti. Potom postavljamo jasne alerte za CPU, rad diskova, prostor na diskovima. Tako\u0111er provodimo nekoliko ru\u010dnih provjera da li web stranica odgovara i da li narud\u017ebe dolaze u bazu. I to je to \u2013 vi\u0161e-manje smo za\u0161ti\u0107eni. <\/p>\n<p>Ako usporedimo obujam posla koji je tada obavljao administrator radi osiguranja nadzora, 98% toga je bilo automatsko: osoba koja se bavi nadzorom mora razumjeti kako postaviti Zabbix, kako ga konfigurirati i postaviti alarme. A 2% \u2014 za vanjske provjere: da li web stranica odgovara i izvr\u0161ava upite u bazu, da li su novi narud\u017ebe stigli.<\/p>\n<p><img decoding=\"async\" alt=\"Monitoring mrtvih? \u2014 Neka \u017eivi monitoring\" src=\"\/wp-content\/uploads\/2019\/04\/3563dda4d025fd18200d6410d7d065ed.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>2010. godina. Raste optere\u0107enje.<\/h4>\n<p>\nPo\u010dinjemo skalirati webove, dodajemo pretra\u017eiva\u010d. \u017delimo biti sigurni da katalog proizvoda sadr\u017ei sve proizvode. I da pretra\u017eivanje proizvoda funkcionira. Da baza radi, da se narud\u017ebe izvr\u0161avaju, da web stranica odgovara vanjskim zahtjevima i odgovara s dva, <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/hr\/server\/\"   title=\"poslu\u017eitelja\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1314\">poslu\u017eitelja<\/a> i da korisnik ne bude izba\u010den sa web stranice dok se prebacuje na drugi poslu\u017eitelj, itd. Broj entiteta raste. <\/p>\n<p>Pri tome, entitet povezan s infrastrukturom i dalje ostaje najve\u0107i u umu menad\u017eera. I dalje u mislima postoji ideja da osoba koja se bavi nadzorom \u2014 to je osoba koja \u0107e postaviti Zabbix i mo\u0107i ga konfigurirati.<\/p>\n<p>Ali istovremeno se pojavljuju poslovi vezani uz izvo\u0111enje vanjskih provjera, stvaranje skupa skripti za upite pretra\u017eiva\u010da, skup skripti za provjeru da se pretra\u017eivanje mijenja tijekom indeksiranja, skup skripti koje provjeravaju da se proizvodi isporu\u010duju slu\u017ebi isporuke, itd.<\/p>\n<p><img decoding=\"async\" alt=\"Monitoring mrtvih? \u2014 Neka \u017eivi monitoring\" src=\"\/wp-content\/uploads\/2019\/04\/afa94a3156a24a81ab359b430341f27d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrimijetite: tri puta sam napisao \"skup skripti\". To jest, odgovorna osoba za nadzor vi\u0161e nije ona koja samo instalira Zabbix. To je osoba koja po\u010dinje programirati. No, u glavama tima zasad se ni\u0161ta ne mijenja. <\/p>\n<p>Me\u0111utim, svijet se mijenja, postaju\u0107i sve slo\u017eeniji. Dodaje se sloj virtualizacije, nekoliko novih sustava. Po\u010dinju me\u0111usobno komunicirati. Tko je rekao \"miri\u0161e na mikroservise?\" No svaki servis jo\u0161 uvijek izgleda kao zasebna web stranica. Mo\u017eemo mu pristupiti i razumjeti da pru\u017ea potrebne informacije i da radi samostalno. I ako ste administrator koji se stalno bavi projektom koji se razvija 5-7-10 godina, ta znanja se akumuliraju: dolazi nova razina \u2014 postali ste je svjesni, dolazi jo\u0161 jedna razina \u2014 postali ste je svjesni\u2026 <\/p>\n<p><img decoding=\"async\" alt=\"Monitoring mrtvih? \u2014 Neka \u017eivi monitoring\" src=\"\/wp-content\/uploads\/2019\/04\/3578182594d012732afde7849b75322a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo rijetko tko odr\u017eava projekt 10 godina.<\/p>\n<h3>Sa\u017eetak za nadzornika<\/h3>\n<p>\nZamislite da ste do\u0161li u novi startup koji je odmah okupio 20 developera, napisao 15 mikroslu\u017ebi, a vi ste admin kojem ka\u017eu: \u201eIzgradi CI\/CD. Molim te.\u201d Izgradili ste CI\/CD i odjednom \u010dujete: \u201eTe\u0161ko nam je raditi s produkcijom u 'kocki', ne razumiju\u0107i kako \u0107e aplikacija funkcionirati u njoj. Napravi nam pij sandbox u toj istoj 'kocki'.<br \/>\n Napravili ste taj sandbox u toj kocki. Odmah vam ka\u017eu: \u201e\u017delimo stage bazu podataka koja \u0107e se svakodnevno a\u017eurirati s produkcije, kako bismo razumjeli da to radi na bazi podataka, ali istovremeno ne \u017eelimo pokvariti produkcijsku bazu podataka.\u201d<\/p>\n<p>\u017divite u svemu tome. Ostale su 2 tjedna do izlaska, i ka\u017eu vam: \u201eSad bi to sve trebalo monitorirati...\u201d Dakle, monitorirati klaster infrastrukturu, monitorirati mikroservisnu arhitekturu, monitorirati rad s vanjskim servisima... <\/p>\n<p>A kolege iznose iz glave uobi\u010dajeni obrazac i govore: \u201ePa ovdje je sve jasno! Stavi program koji \u0107e to sve monitorirati.\u201d Da, da: Prometheus + Grafana + dodaci. <br \/>\nI dodaju pri tome: \u201eIma\u0161 otprilike dva tjedna, u\u010dini da sve bude pouzdano.\u201d<\/p>\n<p>U gomili projekata koje vidimo, na monitoring se dodjeljuje jedna osoba. Zamislite da \u017eelimo unajmiti \u010dovjeka na 2 tjedna koji \u0107e se baviti monitoringom i sastavljamo mu \u017eivotopis. Koje vje\u0161tine bi taj \u010dovjek trebao imati \u2014 uzimaju\u0107i u obzir sve prethodno re\u010deno?<\/p>\n<ul>\n<li>Trebalo bi razumjeti monitoring i specifi\u010dnosti rada hardverske infrastrukture.<\/li>\n<li>Trebao bi razumjeti specifi\u010dnosti monitoringa Kubernetes-a (svi \u017eele u 'kocku', jer se mo\u017ee abstrahirati od svega, skrivaju\u0107i se, jer \u0107e admin rije\u0161iti ostalo) \u2014 samog po sebi, njegove infrastrukture, i razumjeti kako monitorirati aplikacije unutar njega.<\/li>\n<li>Trebalo bi shvatiti da se servisi me\u0111usobno komuniciraju posebnim na\u010dinima i znati specifi\u010dnosti interakcije servisa jedni s drugima. Sasvim je realno vidjeti projekt gdje se dio servisa komunicira sinkrono, jer druga\u010dije ne mo\u017ee. Na primjer, backend ide preko REST-a, preko gRPC do servisa za katalog, dobiva popis proizvoda i vra\u0107a ga natrag. Ovdje se ne mo\u017ee \u010dekati. A s drugim servisima radi asinkrono. Prenijeti narud\u017ebu u slu\u017ebu dostave, poslati e-mail itd.<br \/>\nVjerojatno ste se ve\u0107 izgubili od svega ovog? A admin kojem je potrebno to monitorirati, jo\u0161 vi\u0161e se izgubio. <\/li>\n<li>Mora biti sposoban planirati i pravilno organizirati jer posla je svakim danom sve vi\u0161e. <\/li>\n<li>Stoga mora razviti strategiju iz uslu\u017enog modela kako bi razumio kako to konkretno nadzirati. Potrebno mu je razumijevanje arhitekture projekta i njegovog razvoja + poznavanje tehnologija koje se koriste u razvoju. <\/li>\n<\/ul>\n<p>\nPodsjetimo se na potpuno normalan slu\u010daj: dio usluga je na php-u, dio na Go-u, a dio na JS-u. Oni na neki na\u010din me\u0111usobno sura\u0111uju. Odatle dolazi termin 'mikroservis': postalo je toliko odvojenih sustava da programeri ne mogu shvatiti projekt u cjelini. Jedan dio tima pi\u0161e usluge na JS-u, koje rade same za sebe i ne znaju kako funkcionira ostatak sustava. Drugi dio pi\u0161e usluge na Pythonu i ne zaranja u to kako rade druge usluge, oni su izolirani u svom podru\u010dju. Tre\u0107i - pi\u0161e usluge na php-u ili ne\u010demu drugom. <br \/>\nSva ta 20 osoba podijeljena je na 15 usluga, a postoji samo jedan admin koji sve to treba razumjeti. \u010cekajte! Upravo smo sustav podijelili na 15 mikroservisa, jer 20 ljudi ne mo\u017ee razumjeti cijeli sustav. <\/p>\n<p>Ali treba to nekako nadzirati...<\/p>\n<p>\u0160to na kraju? Na kraju postoji jedna osoba koja shva\u0107a sve \u0161to cjelokupna ekipa programera ne mo\u017ee shvatiti, a pritom jo\u0161 mora znati i mo\u0107i ono \u0161to smo naveli iznad - hardversku infrastrukturu, infrastrukturu Kubernetes itd.<\/p>\n<p>\u0160to re\u0107i... Houston, imamo problem.<\/p>\n<h3>Nadzor modernog programskog projekta - to je samostalan programski projekt.<\/h3>\n<p>\nIz la\u017ene sigurnosti da je nadzor softver, dolazimo do vjere u \u010duda. A \u010duda, na\u017ealost, ne postoje. Ne mo\u017eete jednostavno postaviti zabbix i \u010dekati da sve proradi. Nema smisla postaviti Grafanu i nadati se da \u0107e sve biti u redu. Ve\u0107ina vremena \u0107e biti utro\u0161ena na organizaciju provjera rada usluga i njihovih me\u0111usobnih interakcija, provjere kako rade vanjski sustavi. U stvarnosti, 90% vremena \u0107e se potro\u0161iti ne na pisanje skripti, ve\u0107 na razvoj softvera. A time bi se trebala baviti ekipa koja razumije rad projekta. <br \/>\nAko u ovoj situaciji jednu osobu pustimo da se bavi nadzorom, do\u0107i \u0107e do katastrofe. \u0160to se i doga\u0111a posvuda.<\/p>\n<p>Na primjer, postoje razne usluge koje komuniciraju me\u0111usobno preko Kafke. Primili smo narud\u017ebu, poslali smo poruku o narud\u017ebi u Kafku. Postoji usluga koja slu\u0161a informacije o narud\u017ebi i upravlja otpremom proizvoda. Tu je i usluga koja slu\u0161a informacije o narud\u017ebi i \u0161alje e-mail korisniku. A zatim se pojavljuje jo\u0161 mnogo usluga i po\u010dinjemo se gubiti.<\/p>\n<p>A ako to predate administratoru i developerima u trenutku kada je do lansiranja ostalo malo vremena, osoba \u0107e morati razumjeti cijeli ovaj protokol. Drugim rije\u010dima, projekt ovakvog opsega zahtijeva zna\u010dajno vrijeme, i to bi trebalo biti predvi\u0111eno u razvoju sustava. <br \/>\nNo, vrlo \u010desto, posebno u startupima, vidimo kako se monitoring odga\u0111a. \"Sada \u0107emo napraviti Proof of Concept, pokrenut \u0107emo ga, neka pada \u2013 spremni smo na to. A onda \u0107emo sve to nadzirati.\" Kada (ili ako) projekt po\u010dne donositi novac, biznis \u017eeli dodati jo\u0161 vi\u0161e funkcija \u2014 jer je po\u010delo raditi, zna\u010di treba jo\u0161 napredovati! A vi ste u trenutku kada prvo treba nadzirati sve prethodno, \u0161to ne traje 1% vremena, ve\u0107 znatno vi\u0161e. I, usput re\u010deno, za monitoring \u0107e biti potrebni developeri, a lak\u0161e ih je usmjeriti prema novim funkcijama. Na kraju se pi\u0161u nove funkcije, sve se di\u017ee, a vi ste u beskona\u010dnom deadlocku.<\/p>\n<p>Kako dakle nadzirati projekt od samog po\u010detka, i \u0161to u\u010diniti ako vam je dodijeljen projekt koji treba nadzirati, a ne znate odakle po\u010deti?<\/p>\n<p>Prvo, potrebno je planirati. <\/p>\n<p><i>Lirska digresija: vrlo \u010desto se po\u010dinje s monitoringom infrastrukture. Na primjer, imamo Kubernetes. Po\u010dnimo s postavljanjem Prometheusa s Grafanom, instalirat \u0107emo pluginove za monitoring \"kubika\". Ne samo programeri, ve\u0107 i administratori imaju \u017ealosnu praksu: \"Instalirat \u0107emo ovaj plugin, a plugin zna kako to u\u010diniti.\" Ljudi vole po\u010deti s jednostavnim i razumljivim stvarima, a ne s va\u017enim radnjama. I monitoring infrastrukture je jednostavan.<\/i><\/p>\n<p>Prvo odlu\u010dite \u0161to i kako \u017eelite pratiti, a zatim odaberite alat, jer drugi ljudi ne mogu razmi\u0161ljati umjesto vas. I trebaju li? Drugi ljudi su razmi\u0161ljali o sebi, o univerzalnom sustavu \u2014 ili nisu razmi\u0161ljali uop\u0107e dok su pisali ovu pluginu. I to \u0161to ovaj plugin ima 5000 korisnika, ne zna\u010di da donosi neku korist. Mo\u017eda \u0107ete postati 5001. samo zato \u0161to je prije vas ve\u0107 bilo 5000 ljudi. <\/p>\n<p>Ako ste po\u010deli pratiti infrastrukturu i backend va\u0161e aplikacije prestane odgovarati, svi korisnici \u0107e izgubiti vezu s mobilnom aplikacijom. Pojavit \u0107e se gre\u0161ka. Do\u0107i \u0107e vam i re\u0107i 'Aplikacija ne radi, \u010dime se bavite?' \u2014 'Pratimo.' \u2014 'Kako pratite, ako ne vidite da aplikacija ne radi?!' <\/p>\n<ol>\n<li>Smatram da bi pra\u0107enje trebalo zapo\u010deti upravo s ulazne to\u010dke korisnika. Ako korisnik ne vidi da aplikacija radi \u2014 sve, to je neuspjeh. A sustav pra\u0107enja treba to prvo prijaviti. <\/li>\n<li>Tek tada mo\u017eemo pratiti infrastrukturu. Ili to u\u010diniti paralelno. S infrastrukturom je lak\u0161e \u2014 tu kona\u010dno mo\u017eemo jednostavno postaviti Zabbix. <\/li>\n<li>A sada trebamo i\u0107i u korijene aplikacije kako bismo razumjeli gdje ne\u0161to ne radi.<\/li>\n<\/ol>\n<p>\nMoja glavna misao je \u2013 pra\u0107enje treba i\u0107i paralelno s procesom razvoja. Ako ste odvojili tim za pra\u0107enje za druge zadatke (izrada CI\/CD, sandbox, reorganizacija infrastrukture), pra\u0107enje \u0107e po\u010deti zaostajati i mo\u017eda nikada ne\u0107ete uhvatiti razvoj (ili \u0107e ranije ili kasnije morati stati).<\/p>\n<h3>Sve po razinama<\/h3>\n<p>\nOvako ja vidim organizaciju sustava pra\u0107enja.<\/p>\n<p>1) Razina aplikacije:<\/p>\n<ul>\n<li>pra\u0107enje poslovne logike aplikacije;<\/li>\n<li>pra\u0107enje health-metrika servisa;<\/li>\n<li>integracijsko pra\u0107enje.<\/li>\n<\/ul>\n<p>\n2) Razina infrastrukture:<\/p>\n<ul>\n<li>pra\u0107enje razine orkestracije;<\/li>\n<li>pra\u0107enje sistemskog softvera;<\/li>\n<li>pra\u0107enje razine 'hardvera'.<\/li>\n<\/ul>\n<p>\n3) Ponovno razina aplikacije \u2014 ali ve\u0107 kao in\u017eenjerskog proizvoda:<\/p>\n<ul>\n<li>prikupljanje i pra\u0107enje logova aplikacije;<\/li>\n<li>APM;<\/li>\n<li>tracing.<\/li>\n<\/ul>\n<p>\n4) Upozorenja:<\/p>\n<ul>\n<li>organizacija sustava obavijesti;<\/li>\n<li>organizacija sustava de\u017eurstava;<\/li>\n<li>organizacija 'baze znanja' i workflow obrada incidenata.<\/li>\n<\/ul>\n<p>\n<b>Va\u017eno<\/b>: dolazimo do alertinga ne nakon, ve\u0107 odmah! Ne trebate pokretati monitoring i \u201ekako-tako kasnije\u201c smi\u0161ljati kome \u0107e stizati alerti. Jer u \u010demu je svrha monitoringa: razumjeti gdje u sustavu ne\u0161to ne djeluje ispravno i obavijestiti odgovaraju\u0107e ljude o tome. Ako to ostavite za kraj, odgovaraju\u0107i ljudi saznat \u0107e da ne\u0161to ne \u0161tima tek kada dobiju poziv \u201eni\u0161ta nam ne radi\u201c.<\/p>\n<h3>Razina aplikacije \u2014 monitoring poslovne logike<\/h3>\n<p>\nOvdje se radi o provjerama samog \u010dina da aplikacija radi za korisnika.<\/p>\n<p>Ova razina treba biti postavljena u fazi razvoja. Na primjer, imamo zami\u0161ljeni Prometheus: on pristupa serveru koji se bavi provjerama, poziva endpoint, a endpoint dolazi i provjerava API.<\/p>\n<p>Kad \u010desto tra\u017ee da nadgledaju glavnu stranicu kako bi osigurali da web stranica radi, programeri daju endpoint koji se mo\u017ee pozivati svaki put kada je potrebno potvrditi da API radi. A programeri u tom trenutku tako\u0111er razvijaju \/api\/test\/helloworld. <br \/>\nJedini na\u010din da se uvjerite da sve radi? \u2014 Ne!<\/p>\n<ul>\n<li>Izrada takvih provjera \u2014 u su\u0161tini, zadatak je programera. Unit testove trebaju pisati programeri koji pi\u0161u kod. Jer, ako to date administratoru: \u201e\u010covje\u010de, evo ti popis API protokola svih 25 funkcija, molim te, nadgledaj sve!\u201c \u2014 ni\u0161ta od toga. <\/li>\n<li>Ako napravite print \u201chello world\u201d, nitko nikada ne\u0107e saznati da API treba i zapravo radi. Svaka promjena API-ja treba povu\u0107i promjenu provjera. <\/li>\n<li>Ako ve\u0107 imate takvu situaciju \u2013 obustavite zna\u010dajke i odvojite programere koji \u0107e napisati te provjere, ili se pomirite s gubicima, pomirite se s tim da ni\u0161ta nije provjereno i da \u0107e pasti.<\/li>\n<\/ul>\n<p>\nTehni\u010dki savjeti:<\/p>\n<ul>\n<li>Obavezno organizirajte vanjski server za provjere \u2014 morate biti sigurni da je va\u0161 projekt dostupan vanjskom svijetu.<\/li>\n<li>Organizirajte provjeru cijelog API-ja, a ne samo pojedina\u010dnih endpoint-a.<\/li>\n<li>Kreirajte prometheus-endpoint s rezultatima provjera.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Razina aplikacije \u2014 monitoring health-metra<\/h3>\n<p>\nSada se radi o vanjskim health-metricama usluga. <\/p>\n<p>Odlu\u010dili smo da pratimo sve \"ru\u010dice\" aplikacije pomo\u0107u eksternih provera koje pozivamo iz spoljnog monitoring sistema. No to su zaista \"ru\u010dice\" koje korisnik \"vidi\". \u017delimo da budemo sigurni da nam sami servisi rade. U ovom slu\u010daju, situacija je bolja: u K8s postoje health checkovi koji barem omogu\u0107avaju \"kockici\" da se uveri da servis funkcioni\u0161e. No, polovina provera koje sam video su isti oni print \"hello world\". Tj. on poziva jedanput posle deploy-a, dobije odgovor da je sve u redu \u2014 i to je sve. A kod servisa, koji preko REST-a izla\u017ee svoj API, postoji ogromna koli\u010dina ulaza tog istog API-ja, koji tako\u0111e treba pratiti, jer \u017eelimo znati da funkcioni\u0161e. I njega pratimo iznutra. <\/p>\n<p>Kako to ispravno tehni\u010dki implementirati: svaki servis izla\u017ee endpoint o svom trenutnom radnom stanju, a u grafikonima Grafana (ili bilo koju drugu aplikaciju) vidimo status svih servisa.<\/p>\n<ul>\n<li>Svaka promena API-ja treba da vodi do promene provera. <\/li>\n<li>Novi servis kreirajte odmah sa health metrikama.<\/li>\n<li>Admin mo\u017ee do\u0107i do developera i tra\u017eiti \"dodajte mi par karakteristika da sve razumem i da mogu dodati informacije o tome u svoj monitoring sistem\". Me\u0111utim, developeri obi\u010dno odgovaraju \"Ne\u0107emo dodavati ni\u0161ta dve nedelje pre isporuke.\"<br \/>\nNeka menad\u017eeri razvoja budu svesni da \u0107e biti takvih gubitaka, neka i nadredjeni menad\u017eeri razvoja znaju. Jer, kada sve propadne, neko \u0107e i dalje zvati i zahtevati da se \"stalno padaju\u0107i servis\" (c) prati. <\/li>\n<li>Usput, izdvojite programere za pisanje dodataka za Grafana \u2014 to \u0107e biti velika pomo\u0107 za administratore.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Nivo aplikacije \u2014 Integracijski monitoring<\/h3>\n<p>\nIntegracijski monitoring fokusira se na pra\u0107enje komunikacije izme\u0111u kriti\u010dnih poslovnih sistema.<\/p>\n<p>Na primer, postoji 15 servisa koji me\u0111usobno komuniciraju. To vi\u0161e nisu odvojeni sajtovi. Tj. ne mo\u017eemo pozvati servis sam za sebe, dobiti \/helloworld i shvatiti da servis funkcioni\u0161e. Jer web servis za poru\u010divanje treba da po\u0161alje informacije o porud\u017ebini u magistralu \u2014 iz magistrale slu\u017eba za skladi\u0161tenje treba da primi ovu poruku i dalje raditi s njom. A servis za slanje e-mailova treba da to dalje obradi, itd. <\/p>\n<p>Stoga, ne mo\u017eemo razumjeti, poku\u0161avaju\u0107i svaki pojedini servis, kako sve to funkcionira. Jer imamo neku sabirnicu kroz koju se sve komunicira i me\u0111usobno djeluje.<br \/>\nZbog toga bi ova faza trebala odra\u017eavati fazu testiranja servisa u interakciji s drugim servisima. Nije mogu\u0107e, samo nadgledaju\u0107i posrednika poruka, uspostaviti nadzor komunikacije. Ako postoji servis koji isporu\u010duje podatke, i servis koji ih prima, pri nadzoru posrednika vidjet \u0107emo samo podatke koji putuju s jedne na drugu stranu. \u010cak i ako nekako uspijemo nadgledati interakciju ovih podataka iznutra \u2014 da neki proizvo\u0111a\u010d objavljuje podatke, netko ih \u010dita, taj tok nastavlja te\u0107i u Kafka \u2014 to nam i dalje ne\u0107e pru\u017eiti informacije ako je jedan servis poslao poruku u jednoj verziji, a drugi servis nije o\u010dekivao tu verziju i propustio je. Ne\u0107emo saznati za to, jer \u0107e nam servisi re\u0107i da sve radi. <\/p>\n<p>Kako preporu\u010dujem to raditi:<\/p>\n<ul>\n<li>Za sinkronu komunikaciju: krajnja to\u010dka izvr\u0161ava zahtjeve povezanim servisima. Tj. uzimamo tu krajnju to\u010dku, pokre\u0107emo skriptu unutar servisa koja ide kroz sve to\u010dke i govori 'mogu ovdje povu\u0107i, i ovdje povu\u0107i, mogu ovdje povu\u0107i\u2026'<\/li>\n<li>Za asinkronu komunikaciju: dolazne poruke \u2014 krajnja to\u010dka provjerava sabirnicu na prisutnost testnih poruka i isporu\u010duje status obrade. <\/li>\n<li>Za asinkronu komunikaciju: odlazne poruke \u2014 krajnja to\u010dka \u0161alje testne poruke na sabirnicu.<\/li>\n<\/ul>\n<p>\nKako to obi\u010dno ide: imamo servis koji \u0161alje podatke na sabirnicu. Dolazimo u taj servis i tra\u017eimo da nam ispri\u010da o svom integracijskom zdravlju. I ako servis treba da proda neku poruku negdje dalje (WebApp), on \u0107e tu testnu poruku prodati. A ako zovemo servis s strane OrderProcessing, on prvo objavljuje ono \u0161to mo\u017ee objaviti neovisno, a ako postoje neke ovisne stvari \u2014 onda \u010dita iz sabirnice skup testnih poruka, razumije \u0161to mo\u017ee obraditi, javlja to i, ako treba, objavljuje ih dalje, i o tome javlja \u2014 sve je u redu, \u017eiv sam. <\/p>\n<p>Vrlo \u010desto \u010dujemo pitanje \u201ekako to mo\u017eemo testirati na stvarnim podacima?\u201d Na primjer, radi se o istoj usluzi narud\u017ebi. Narud\u017eba \u0161alje poruke u skladi\u0161te, gdje se proizvodi odbacuju: ne mo\u017eemo to testirati na stvarnim podacima, jer \u201emoji proizvodi \u0107e biti odbijeni!\u201d Rje\u0161enje: u ranoj fazi planirati cijeli ovaj test. Ve\u0107 imate unit testove koji koriste mock-ove. Dakle, to u\u010dinite na dubljoj razini, gdje \u0107e prolaziti kanal komunikacije koji ne\u0107e na\u0161tetiti poslovanju. <\/p>\n<h3>Razina infrastrukture<\/h3>\n<p>\nNadzor infrastrukture \u2013 to je ne\u0161to \u0161to se ve\u0107 dugo smatra samim nadzorom. <\/p>\n<ul>\n<li>Nadzor infrastrukture se mo\u017ee i mora pokrenuti kao zaseban proces.<\/li>\n<li>Ne treba zapo\u010dinjati s nadzorom infrastrukture na aktivnom projektu, \u010dak i ako to jako \u017eelite. To je bolna to\u010dka za sve DevOps-ove. \u201ePrvo \u0107u nadzirati klaster, zatim \u0107u nadzirati infrastrukturu\u201c \u2013 tj. prvo \u0107e nadzirati ono \u0161to je nisko, a u aplikaciju ne\u0107e ulaziti. Jer aplikacija je nejasna stvar za DevOps-a. To mu je prepu\u0161teno, a on ne razumije kako to funkcionira. A infrastrukturu razumije i zapo\u010dinje s njom. No ne \u2013 uvijek trebate prvo nadzirati aplikaciju. <\/li>\n<li>Ne pretjerujte s brojem obavijesti. S obzirom na slo\u017eenost modernih sustava, upozorenja sti\u017eu neprekidno, i s tom gomilom upozorenja treba nekako \u017eivjeti. A osoba koja je na pozivu, pogledav\u0161i stotinu upozorenja, odlu\u010dit \u0107e \u201ene \u017eelim o tome razmi\u0161ljati\u201d. Upozorenja trebaju obavje\u0161tavati samo o kriti\u010dnim stvarima. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Razina aplikacije kao poslovne jedinice<\/h3>\n<p>\nKlju\u010dne to\u010dke:<\/p>\n<ul>\n<li>ELK. To je industrijski standard. Ako iz bilo kojeg razloga ne agregirate logove, odmah to po\u010dnite raditi.<\/li>\n<li>APM. Vanjski APM kao na\u010din brzog zatvaranja nadzora aplikacije (NewRelic, BlackFire, Datadog). Mo\u017eete privremeno postaviti ovaj alat da biste na neki na\u010din razumjeli \u0161to se doga\u0111a. <\/li>\n<li>Tracing. U desetinama mikroservisa morate piti sve, jer zahtjev vi\u0161e ne postoji sam za sebe. Kasnije je vrlo te\u0161ko dodati, stoga je bolje odmah planirati tracing u razvoju \u2014 to je posao i alat programera. Ako jo\u0161 niste implementirali \u2013 implementirajte! Vidi Jaeger\/Zipkin.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Upozorenje<\/h3>\n<p><\/p>\n<ul>\n<li>Organizacija sustava obavijesti: u uvjetima pra\u0107enja velikog broja stvari mora postojati jedinstveni sustav slanja obavijesti. To se mo\u017ee napraviti putem Grafane. Na Zapadu svi koriste PagerDuty. Obavijesti trebaju biti jasne (na primjer, odakle dolaze\u2026). Tako\u0111er, po\u017eeljno je kontrolirati dolaze li obavijesti uop\u0107e. <\/li>\n<li>Organizacija sustava de\u017eurstva: alarmi ne bi trebali dolaziti svima (ili \u0107e svi reagirati u gu\u017evi, ili nitko ne\u0107e). On-call trebaju biti i programeri: obavezno definirajte podru\u010dja odgovornosti, izradite jasne upute i navedite tko konkretno naziva u ponedjeljak i srijedu, a tko u utorak i petak (ina\u010de ne\u0107e zvati niti u slu\u010daju velike nesre\u0107e \u2014 bojat \u0107e se da \u0107e probuditi i uznemiriti: ljudi op\u0107enito ne vole zvati i buditi druge, posebno no\u0107u). Objasnite da tra\u017eenje pomo\u0107i nije znak nesposobnosti (\u201etra\u017eim pomo\u0107 \u2014 zna\u010di lo\u0161 sam radnik\u201d), poti\u010dite zahtjeve za pomo\u0107.<\/li>\n<li>Organizacija \u201ebaze znanja\u201d i workflow obrade incidenata: za svaki ozbiljan incident treba biti zakazan postmortem, kao privremena mjera trebaju biti zabilje\u017eene radnje koje \u0107e rije\u0161iti incident. Uvedite praksu da ponavljaju\u0107i alarmi predstavljaju grijeh; trebaju se rije\u0161iti u kodu ili infrastrukturnim radovima. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Tehnolo\u0161ki stog<\/h3>\n<p>\nZamislimo da imamo sljede\u0107i stog: <\/p>\n<ul>\n<li>prikupljanje podataka \u2014 Prometheus + Grafana;<\/li>\n<li>analiza logova \u2014 ELK;<\/li>\n<li>za APM ili Tracing \u2014 Jaeger (Zipkin).<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Monitoring mrtvih? \u2014 Neka \u017eivi monitoring\" src=\"\/wp-content\/uploads\/2019\/04\/af26d3c0ba781cd856d220515788b5eb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIzbor opcija nije kriti\u010dan. Jer, ako ste na po\u010detku shvatili kako pratiti sustav i izradili plan, kasnije ve\u0107 po\u010dinjete birati alate prema svojim zahtjevima. Pitanje je \u0161to ste odlu\u010dili pratiti na po\u010detku. Jer, mo\u017eda alat koji ste izabrali na po\u010detku nije uop\u0107e prikladan za va\u0161e zahtjeve. <\/p>\n<p>Nekoliko tehni\u010dkih trenutaka koje vidim svuda u posljednje vrijeme:<\/p>\n<p><i>Prometheus se gura unutar Kubernetes-a \u2014 tko je to smislio?!<\/i> Ako vam padne klaster, \u0161to \u0107ete u\u010diniti? Ako imate slo\u017een klaster unutar, trebala bi raditi neka vrsta unutarnjeg sustava pra\u0107enja, i neka vrsta vanjskog, koja \u0107e prikupljati podatke iznutra klastera. <\/p>\n<p><i>Unutar klastera prikupljamo logove i sve ostalo.<\/i> No sustav za nadzor treba biti vani. Vrlo \u010desto u klasteru gdje je Prometheus postavljen unutra, postoje sustavi koji rade vanjske provjere funkcioniranja web stranice. A \u0161to ako vam veza s vanjskim svijetom padne i aplikacija ne radi? Ispada da je unutar sve u redu, ali korisnicima to ne poma\u017ee.<\/p>\n<h3>Zaklju\u010dci<\/h3>\n<p><\/p>\n<ul>\n<li>Razvoj nadzora nije samo instalacija alata, ve\u0107 razvoj softverskog proizvoda. 98% dana\u0161njeg nadzora je kodiranje. Kodiranje u servisima, kodiranje vanjskih provjera, provjere vanjskih servisa i svega ostalog. <\/li>\n<li>Ne \u017ealite vrijeme programera na nadzor: to mo\u017ee zauzeti do 30% njihovog rada, ali isplati se.<\/li>\n<li>Devs, ne brinite se \u0161to ne mo\u017eete ne\u0161to nadzirati, jer neke stvari zahtijevaju potpuno druga\u010diji na\u010din razmi\u0161ljanja. Niste bili programeri, a rad na nadzoru je uistinu njihov posao.<\/li>\n<li>Ako projekt ve\u0107 radi i nije nadziran (a vi ste menad\u017eer) \u2014 osigurajte resurse za nadzor.<\/li>\n<li>Ako je proizvod ve\u0107 u produkciji, a vi ste devops kojem je re\u010deno \u201epostavite nadzor\u201c \u2014 poku\u0161ajte objasniti vodstvu o \u010demu sam sve ovo govorio.<\/li>\n<\/ul>\n<p>\n<i>Ovo je pro\u0161irena verzija izlaganja na konferenciji Saint Highload++.<\/i><\/p>\n<p>Ako vas zanimaju moje ideje i razmi\u0161ljanja o IT-u i sli\u010dnim temama, evo mo\u017eete <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/eapotapov_channel\">pro\u010ditati kanal <\/a><\/noindex>\ud83d\ude42<br \/>\n<br \/>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/448602\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0430\u0448\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f \u0441 2008 \u0433\u043e\u0434\u0430 \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0438\u043c\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435\u043c \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430\u043c\u0438 \u0438 \u043a\u0440\u0443\u0433\u043b\u043e\u0441\u0443\u0442\u043e\u0447\u043d\u043e\u0439 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432: \u0443 \u043d\u0430\u0441 \u0431\u043e\u043b\u0435\u0435 400 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432, \u044d\u0442\u043e \u043f\u043e\u0440\u044f\u0434\u043a\u0430 15% \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043a\u043e\u043c\u043c\u0435\u0440\u0446\u0438\u0438 \u0420\u043e\u0441\u0441\u0438\u0438. \u0421\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043d\u0430 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u043e\u0447\u0435\u043d\u044c \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u0430\u044f \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430. \u0415\u0441\u043b\u0438 \u0447\u0442\u043e-\u0442\u043e \u043f\u0430\u0434\u0430\u0435\u0442, \u043c\u044b \u043e\u0431\u044f\u0437\u0430\u043d\u044b \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 15 \u043c\u0438\u043d\u0443\u0442 \u044d\u0442\u043e \u043f\u043e\u0447\u0438\u043d\u0438\u0442\u044c. \u041d\u043e \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u0430\u0432\u0430\u0440\u0438\u044f \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u0430, \u043d\u0443\u0436\u043d\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u0442\u044c \u043f\u0440\u043e\u0435\u043a\u0442 \u0438 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u044b. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23731,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31864","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.4 - aioseo.com -->\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\/hr\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"hr_HR\" \/>\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\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043c\u0451\u0440\u0442\u0432? \u2014 \u0414\u0430 \u0437\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0435\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring\" \/>\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-31T18:43:33+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:43:33+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\udd47Nadzor mrtav? \u2014 Neka \u017eivi nadzor | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043c\u0451\u0440\u0442\u0432? \u2014 \u0414\u0430 \u0437\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0435\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 | ProHoster","og:url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","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:43:33+00:00","article:modified_time":"2019-10-31T18:43:33+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31864","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-02-09 17:01:09","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:09:27","updated":"2026-02-09 17:01:09","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/31864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=31864"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/31864\/revisions"}],"predecessor-version":[{"id":158558,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/31864\/revisions\/158558"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/23731"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=31864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=31864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=31864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}