{"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\/da\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","title":{"rendered":"D\u00f8r overv\u00e5gning? \u2014 Leve overv\u00e5gning","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"D\u00f8r overv\u00e5gning? \u2014 Leve overv\u00e5gning\" src=\"\/wp-content\/uploads\/2019\/04\/13453bb7025a6bf3d1c7a3dc6d038d16.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVores virksomhed har siden 2008 arbejdet prim\u00e6rt med at administrere infrastrukturer og d\u00f8gnet rundt teknisk support til webprojekter: vi har over 400 kunder, hvilket udg\u00f8r cirka 15% af e-handel i Rusland. Derfor er der meget forskelligartet arkitektur i vores support. Hvis noget falder ned, er vi forpligtet til at ordne det inden for 15 minutter. Men for at forst\u00e5, at en n\u00f8dsituation er opst\u00e5et, er det n\u00f8dvendigt at overv\u00e5ge projektet og reagere p\u00e5 h\u00e6ndelser. Men hvordan g\u00f8r man det? <\/p>\n<p>Jeg mener, at i organisationen af det rette overv\u00e5gningssystem opst\u00e5r der problemer. Hvis der ikke var problemer, ville mit opl\u00e6g best\u00e5 af \u00e9t punkt: \u00abInstaller venligst Prometheus + Grafana og plugins 1, 2, 3\u00bb. Desv\u00e6rre fungerer det ikke l\u00e6ngere s\u00e5dan. Og det prim\u00e6re problem er, at alle forts\u00e6tter med at tro p\u00e5 noget, der eksisterede i 2008, hvad ang\u00e5r softwarekomponenter. <\/p>\n<p>N\u00e5r det kommer til organisering af overv\u00e5gningssystemet, t\u00f8r jeg sige, at... der ikke findes projekter med ordentlig overv\u00e5gning. Og situationen er s\u00e5 d\u00e5rlig, at hvis noget falder ned, er der en risiko for, at det forbliver uset \u2014 alle er jo overbeviste om, at \u00abalt overv\u00e5ges\u00bb.<br \/>\nM\u00e5ske overv\u00e5ges alt. Men hvordan? <\/p>\n<p>Vi har alle v\u00e6ret i en lignende situation: en devops, en admin, og s\u00e5 kommer et udviklerteam og siger - \u00abvi har release, nu skal du overv\u00e5ge\u00bb. Hvad skal overv\u00e5ges? Hvordan fungerer det?<\/p>\n<p>Okay. Vi overv\u00e5ger p\u00e5 gammeldags m\u00e5de. Men det \u00e6ndrer sig allerede, og det viser sig, at du har overv\u00e5get service A, som er blevet service B, som interagerer med service C. Men udviklerteamet siger til dig: \u00abS\u00e6t softwaren op, den skal overv\u00e5ge alt!\u00bb<\/p>\n<p>Hvad er \u00e6ndret? - Alt er \u00e6ndret!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>2008. Alt er fantastisk.<\/h4>\n<p>\nDer er et par udviklere, \u00e9n server, \u00e9n database server. Herfra starter det hele. Vi har nogle oplysninger, vi installerer Zabbix, Nagios, Cacti. Og derefter opretter vi forst\u00e5elige alarmer for CPU, for diskens arbejde, for plads p\u00e5 diskene. Vi laver ogs\u00e5 et par manuelle tjek for at sikre, at hjemmesiden svarer, og at ordrer kommer ind i databasen. Og det er det - vi er mere eller mindre beskyttede. <\/p>\n<p>Sammenlignet med den arbejdsbyrde, som systemadministratoren tidligere udf\u00f8rte for at sikre overv\u00e5gning, var 98% af det automatiseret: en person, der besk\u00e6ftiger sig med overv\u00e5gning, skal forst\u00e5, hvordan man installerer Zabbix, hvordan man konfigurerer det og indstiller alarmer. De resterende 2% handler om eksterne kontroller: om siden svarer og foretager foresp\u00f8rgsler til databasen, og om nye bestillinger er kommet.<\/p>\n<p><img decoding=\"async\" alt=\"D\u00f8r overv\u00e5gning? \u2014 Leve overv\u00e5gning\" src=\"\/wp-content\/uploads\/2019\/04\/3563dda4d025fd18200d6410d7d065ed.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>2010. Belastningen stiger.<\/h4>\n<p>\nVi begynder at skalere websiderne, tilf\u00f8jer en s\u00f8gemaskine. Vi vil v\u00e6re sikre p\u00e5, at produktkataloget indeholder alle varer. Og at produkt s\u00f8gningen fungerer. At databasen fungerer, at ordrer bliver oprettet, at siden svarer eksternt og svarer korrekt. <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/da\/server\/\"   title=\"servere\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1314\">servere<\/a> Og brugeren ikke bliver smidt af siden, mens den genbalanceres til en anden server, osv. Antallet af enheder vokser. <\/p>\n<p>Derudover forbliver enheden, der relaterer til infrastrukturen, stadig den st\u00f8rste i administratorens hoved. Ideen om, at personen der g\u00f8r overv\u00e5gning, er den, der installerer Zabbix og kan konfigurere det, sidder stadig fast.<\/p>\n<p>Men der opst\u00e5r ogs\u00e5 opgaver i forbindelse med udf\u00f8relse af eksterne kontroller, oprettelse af et s\u00e6t scripts til foresp\u00f8rgsler for s\u00f8geindeksering, et s\u00e6t scripts til at kontrollere, at s\u00f8gningen \u00e6ndrer sig under indeksering, et s\u00e6t scripts, som kontrollerer, at varer bliver sendt til leveringsservice osv.<\/p>\n<p><img decoding=\"async\" alt=\"D\u00f8r overv\u00e5gning? \u2014 Leve overv\u00e5gning\" src=\"\/wp-content\/uploads\/2019\/04\/afa94a3156a24a81ab359b430341f27d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nBem\u00e6rk: Jeg har skrevet \"s\u00e6t scripts\" tre gange. Det vil sige, at den ansvarlige for overv\u00e5gning ikke l\u00e6ngere bare er den, der installerede Zabbix. Det er en person, der begynder at kode. Men i teamet \u00e6ndrer man stadig ikke tankegang. <\/p>\n<p>Til geng\u00e6ld \u00e6ndrer verden sig og bliver mere kompleks. Lag af virtualisering tilf\u00f8jes, flere nye systemer. De begynder at interagere med hinanden. Hvem sagde \"det lugter af mikroservices?\" Men hver service ser stadig ud som en separat hjemmeside. Vi kan kontakte den og forst\u00e5, at den leverer de n\u00f8dvendige oplysninger og fungerer af sig selv. Og hvis du er administrator og konstant arbejder med et projekt, der udvikler sig i 5-7-10 \u00e5r, akkumuleres disse viden: et nyt niveau - du forst\u00e5r det, et andet niveau - du forst\u00e5r det... <\/p>\n<p><img decoding=\"async\" alt=\"D\u00f8r overv\u00e5gning? \u2014 Leve overv\u00e5gning\" src=\"\/wp-content\/uploads\/2019\/04\/3578182594d012732afde7849b75322a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMen sj\u00e6ldent er der nogen, der f\u00f8lger et projekt i 10 \u00e5r.<\/p>\n<h3>Resume for overv\u00e5gningsmanden.<\/h3>\n<p>\nForestil dig, at du er kommet ind i en ny startup, der straks har samlet 20 udviklere, skrevet 15 mikrotjenester, og du er administratoren, der f\u00e5r at vide: \"Byg CI\/CD. V\u00e6r s\u00e5 venlig.\" Du har bygget CI\/CD og pludselig h\u00f8rer du: \"Det er sv\u00e6rt for os at arbejde med produktionen i 'kuben', uden at forst\u00e5, hvordan applikationen vil fungere der. Lav en sandkasse i denne samme 'kube'.<br \/>\n Du laver en sandkasse i denne kube. De siger straks: \"Vi vil have en stage-database, der opdateres hver dag fra produktionen, s\u00e5 vi kan forst\u00e5, at det fungerer p\u00e5 databasen, men ikke \u00f8del\u00e6gger produktionsdatabasen.\"<\/p>\n<p>Du lever i alt dette. Der er 2 uger tilbage til udgivelsen, og de siger: \"Nu skal alt dette overv\u00e5ges...\" Det vil sige, overv\u00e5ge den klustrede infrastruktur, overv\u00e5ge mikrotjenestearkitekturen, overv\u00e5ge arbejdet med eksterne tjenester... <\/p>\n<p>Kollegerne tr\u00e6kker en velkendt skema op af hatten og siger: \"S\u00e5 her er alt klart! S\u00e6t et program op, der kan overv\u00e5ge det hele.\" Ja, ja: Prometheus + Grafana + plugins. <br \/>\nOg de tilf\u00f8jer samtidig: \"Du har to uger, s\u00f8rg for, at alt er p\u00e5lideligt.\"<\/p>\n<p>I en hel r\u00e6kke projekter, som vi ser, tildeles \u00e9n person overv\u00e5gning. Forestil dig, at vi \u00f8nsker at ans\u00e6tte en person i 2 uger, der skal fokusere p\u00e5 overv\u00e5gning, og vi laver et CV til ham. Hvilke f\u00e6rdigheder skal denne person have, hvis man tager alt det, vi tidligere har sagt, i betragtning?<\/p>\n<ul>\n<li>Han skal forst\u00e5 overv\u00e5gning og specifikationen for den fysiske infrastruktur.<\/li>\n<li>Han skal forst\u00e5 overv\u00e5gningens specifikationer for Kubernetes (og alle vil have det i 'kuben', fordi man kan abstrahere fra alting, gemme sig, for resten klarer administratoren) - selve Kubernetes, dets infrastruktur, og forst\u00e5, hvordan man overv\u00e5ger applikationer indeni.<\/li>\n<li>Han skal forst\u00e5, at tjenester kommunikerer p\u00e5 s\u00e6rlige m\u00e5der, og vide om de specifikke interaktioner mellem tjenesterne. Det er fuldt ud muligt at se et projekt, hvor nogle tjenester kommunikerer synkront, fordi det ikke kan g\u00f8res p\u00e5 andre m\u00e5der. For eksempel, backend g\u00e5r via REST, via gRPC til katalogtjenesten, henter en liste over varer og returnerer det. Her kan man ikke vente. Men med andre tjenester arbejder han asynkront. Overf\u00f8re en bestilling til leveringstjenesten, sende en e-mail osv.<br \/>\nDu er m\u00e5ske allerede faldet af hele dette? Og administratoren, der skal overv\u00e5ge det, er endnu mere forvirret. <\/li>\n<li>Han skal kunne planl\u00e6gge og planl\u00e6gge korrekt \u2014 da arbejdet bliver mere og mere. <\/li>\n<li>Han skal derfor skabe en strategi for den oprettede service for at forst\u00e5, hvordan man konkret overv\u00e5ger den. Han har brug for en forst\u00e5else af projektets arkitektur og dets udvikling + forst\u00e5else for de teknologier, der bruges i udviklingen. <\/li>\n<\/ul>\n<p>\nLad os huske et absolut normalt tilf\u00e6lde: en del services p\u00e5 php, en del services p\u00e5 Go, en del services p\u00e5 JS. De arbejder p\u00e5 en eller anden m\u00e5de sammen. Heraf kommer termen \u00abmikroservice\u00bb: antallet af separate systemer er blevet s\u00e5 stort, at udviklerne ikke kan forst\u00e5 projektet som helhed. En del af teamet skriver services p\u00e5 JS, som fungerer uafh\u00e6ngigt og ikke ved, hvordan resten af systemet fungerer. En anden del skriver services p\u00e5 Python og involverer sig ikke i, hvordan de andre services fungerer, de er isolerede inden for deres omr\u00e5de. Den tredje del skriver services p\u00e5 php eller noget andet. <br \/>\nAlle disse 20 personer er delt op i 15 services, og der er kun \u00e9n admin, der skal forst\u00e5 alt dette. Stop! Vi har lige opdelt systemet i 15 mikroservices, fordi 20 personer ikke kan forst\u00e5 hele systemet. <\/p>\n<p>Men det skal overv\u00e5ges p\u00e5 en eller anden m\u00e5de...<\/p>\n<p>Hvad er resultatet? Resultatet er, at der er \u00e9n person, der forst\u00e5r alt, hvad et helt team af udviklere ikke kan forst\u00e5, og samtidig skal han ogs\u00e5 vide og kunne det, vi har angivet ovenfor \u2014 den fysiske infrastruktur, Kubernetes-infrastrukturen osv.<\/p>\n<p>Hvad kan man sige... Houston, vi har et problem.<\/p>\n<h3>Overv\u00e5gning af et moderne softwareprojekt er et softwareprojekt i sig selv.<\/h3>\n<p>\nFra en falsk sikkerhed om, at overv\u00e5gning er software, opst\u00e5r der en tro p\u00e5 mirakler. Og s\u00e5danne mirakler er desv\u00e6rre ikke til. Man kan ikke bare installere Zabbix og forvente, at alt fungerer. Der er ikke nogen mening i at installere Grafana og h\u00e5be, at alt bliver fint. St\u00f8rstedelen af tiden vil blive brugt p\u00e5 at organisere tjek af, hvordan services fungerer, og deres interaktion med hinanden, samt tjek af, hvordan eksterne systemer fungerer. Faktisk vil 90% af tiden g\u00e5 ikke p\u00e5 at skrive scripts, men p\u00e5 udviklingen af software. Og det skal udf\u00f8res af et team, der forst\u00e5r projektets arbejde. <br \/>\nHvis man i denne situation kaster \u00e9n person over overv\u00e5gningen, vil der ske en katastrofe. Og det sker overalt.<\/p>\n<p>For eksempel er der flere tjenester, der kommunikerer med hinanden gennem Kafka. En bestilling kommer ind, vi sender besked om bestillingen til Kafka. Der er en tjeneste, der lytter til informationen om bestillingen og h\u00e5ndterer forsendelsen af varerne. Der er en tjeneste, der lytter til informationen om bestillingen og sender en e-mail til brugeren. Og s\u00e5 dukker der flere tjenester op, og vi begynder at forvirre os.<\/p>\n<p>Og hvis du ogs\u00e5 overdrager dette til administratoren og udviklerne i en fase, hvor der kun er kort tid tilbage til udgivelsen, skal personen forst\u00e5 hele dette protokol. Det vil sige, et projekt af denne skala tager betydelig tid, og det skal tages i betragtning i systemets udvikling. <br \/>\nMen meget ofte, is\u00e6r i starten af opstartsfirmaer, ser vi, hvordan overv\u00e5gningen bliver udskudt. \"Lad os f\u00f8rst lave et Proof of Concept, lade os lancere det, s\u00e5 lad det falde \u2013 vi er villige til at ofre det. Og s\u00e5 vil vi overv\u00e5ge det hele.\" N\u00e5r (eller hvis) projektet begynder at generere indt\u00e6gter, \u00f8nsker virksomheden at udvikle endnu flere funktioner \u2014 fordi det allerede fungerer, s\u00e5 der skal tjenes mere! Og du befinder dig p\u00e5 et punkt, hvor du f\u00f8rst skal overv\u00e5ge alt det tidligere, hvilket tager mere end 1% af tiden, men betydeligt mere. Og for resten kr\u00e6ver overv\u00e5gningen udviklere, og det er nemmere at lade dem fokusere p\u00e5 nye funktioner. I sidste ende skrives nye funktioner, alt kompliceres, og du er i en uendelig deadlock.<\/p>\n<p>Hvordan kan man overv\u00e5ge et projekt fra starten, og hvad skal man g\u00f8re, hvis du har f\u00e5et et projekt, der skal overv\u00e5ges, men du ikke ved, hvor du skal begynde?<\/p>\n<p>For det f\u00f8rste skal man planl\u00e6gge. <\/p>\n<p><i>En lyrisk afvigelse: man begynder ofte med at overv\u00e5ge infrastrukturen. For eksempel har vi Kubernetes. Lad os starte med at installere Prometheus med Grafana, installere plugins til overv\u00e5gning af 'kuben'. Ikke kun udviklerne, men ogs\u00e5 administratorerne har en beklagelig praksis: \"Vi installerer denne plugin, og den ved sikkert, hvordan man g\u00f8r det.\" Folk elsker at starte med enkle og forst\u00e5elige ting, snarere end med vigtige handlinger. Og overv\u00e5gning af infrastrukturen er bare det.<\/i><\/p>\n<p>For starters, decide what and how you want to monitor, and then choose a tool, because other people can't think for you. And should they? Others have thought about themselves, about a universal system \u2014 or didn't think at all when they wrote this plugin. Just because this plugin has 5,000 users does not mean it provides any value. You might become the 5001st simply because there were already 5000 people before you. <\/p>\n<p>If you have started monitoring the infrastructure and the backend of your application stops responding, all users will lose connection to the mobile app. An error will pop up. People will come to you and say, \"The app isn't working, what are you doing here?\" \u2014 \"We are monitoring.\" \u2014 \"How are you monitoring if you don't see that the app isn't working?!\" <\/p>\n<ol>\n<li>I believe that monitoring should start right from the user's entry point. If the user doesn't see that the app is working \u2014 that's a failure. And the monitoring system should warn about this first and foremost. <\/li>\n<li>Only after that can we monitor the infrastructure. Or do it in parallel. Monitoring infrastructure is easier \u2014 here we can finally just set up Zabbix. <\/li>\n<li>And now we need to dig into the application's roots to understand where things are not working.<\/li>\n<\/ol>\n<p>\nMy main point is that monitoring should run parallel to the development process. If you pull the monitoring team onto other tasks (like creating CI\/CD, sandboxes, reorganizing infrastructure), monitoring will start to lag behind and you may never catch up with development (or sooner or later, you'll have to stop it).<\/p>\n<h3>Everything in levels<\/h3>\n<p>\nHere's how I see the organization of the monitoring system.<\/p>\n<p>1) Application level:<\/p>\n<ul>\n<li>monitoring business logic of the application;<\/li>\n<li>monitoring health metrics of services;<\/li>\n<li>integration monitoring.<\/li>\n<\/ul>\n<p>\n2) Infrastructure level:<\/p>\n<ul>\n<li>monitoring the orchestration level;<\/li>\n<li>monitoring system software;<\/li>\n<li>monitoring hardware level.<\/li>\n<\/ul>\n<p>\n3) Again, the application level \u2014 but now as an engineering product:<\/p>\n<ul>\n<li>collecting and observing application logs;<\/li>\n<li>APM;<\/li>\n<li>tracing.<\/li>\n<\/ul>\n<p>\n4) Alerting:<\/p>\n<ul>\n<li>organization of the notification system;<\/li>\n<li>organization of the duty system;<\/li>\n<li>organization of the knowledge base and incident handling workflow.<\/li>\n<\/ul>\n<p>\n<b>Det er vigtigt<\/b>: Vi g\u00e5r ikke til alerting efterf\u00f8lgende, men straks! Det er ikke n\u00f8dvendigt at starte overv\u00e5gningen og t\u00e6nke p\u00e5, hvem der skal modtage alerterne senere. For hvad er form\u00e5let med overv\u00e5gning: at forst\u00e5, hvor i systemet noget ikke fungerer som det skal, og informere de relevante personer. Hvis det overlades til sidst, vil de relevante personer kun h\u00f8re om, at noget er galt, n\u00e5r de f\u00e5r et opkald med beskeden: 'vores system fungerer ikke'.<\/p>\n<h3>Applikationsniveau \u2014 overv\u00e5gning af forretningslogik<\/h3>\n<p>\nHer taler vi om at kontrollere, om applikationen fungerer for brugeren.<\/p>\n<p>Dette niveau skal etableres i udviklingsfasen. For eksempel har vi en hypotetisk Prometheus: den henter data fra serveren, som udf\u00f8rer kontroller, kalder endpointet, og endpointet g\u00e5r videre med at kontrollere API'en.<\/p>\n<p>N\u00e5r man ofte beder om at overv\u00e5ge forsiden for at sikre, at hjemmesiden fungerer, tilbyder programm\u00f8rer et endpoint, som kan kaldes hver gang man skal bekr\u00e6fte, at API'en fungerer. Samtidig begynder programm\u00f8rer ogs\u00e5 at skrive \/api\/test\/helloworld. <br \/>\nDen eneste m\u00e5de at sikre, at alt fungerer? \u2014 Nej!<\/p>\n<ul>\n<li>At oprette s\u00e5danne kontroller er i det v\u00e6sentlige udviklernes opgave. Unit-tests skal skrives af programm\u00f8rer, der skriver koden. For hvis du overlader det til en administrator med besked om: 'Hey, her er en liste over API-protokoller for alle 25 funktioner, venligst overv\u00e5g alt!' \u2014 vil det ikke fungere. <\/li>\n<li>Hvis du skriver print 'hello world', vil ingen nogensinde vide, at API'en skal og faktisk fungerer. Hver \u00e6ndring af API'en skal medf\u00f8re en tilsvarende \u00e6ndring i kontrollerne. <\/li>\n<li>Hvis du allerede st\u00e5r i denne situation - stop funktionerne og tildel udviklere til at skrive disse kontroller, eller resign\u00e9r med tabene, acceptere at intet bliver kontrolleret, og at der vil ske nedbrud.<\/li>\n<\/ul>\n<p>\nTekniske r\u00e5d:<\/p>\n<ul>\n<li>S\u00f8rg for at organisere en ekstern server til kontrollerne - du skal v\u00e6re sikker p\u00e5, at dit projekt er tilg\u00e6ngeligt for omverdenen.<\/li>\n<li>Organiser kontrol p\u00e5 hele API-protokollen, ikke kun p\u00e5 enkelte endpoints.<\/li>\n<li>Opret et prometheus-endpoint med resultaterne af kontrollerne.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Applikationsniveau \u2014 overv\u00e5gning af sundhedsmetrikker<\/h3>\n<p>\nNu handler det om eksterne sundhedsmetrikker for tjenester. <\/p>\n<p>Vi har besluttet, at vi overv\u00e5ger alle \"endpoints\" i applikationen ved hj\u00e6lp af eksterne kontroller, som vi kalder fra et eksternt overv\u00e5gningssystem. Men det er netop de \"endpoints\", som brugeren \"ser\". Vi vil gerne v\u00e6re sikre p\u00e5, at vores tjenester fungerer. Her ser det bedre ud: i K8s er der health checks, s\u00e5 i det mindste kan \"boksen\" bekr\u00e6fte, at tjenesten fungerer. Men halvdelen af de checks, jeg har set, er det samme print \"hello world\". Det vil sige, den hiver \u00e9n gang efter deployment, og hvis den f\u00e5r et svar om, at alt er godt \u2013 s\u00e5 er det det. Men for en service, der udleverer sit API via REST, er der et stort antal indgange til det samme API, som ogs\u00e5 skal overv\u00e5ges, fordi vi vil vide, at det fungerer. Og vi overv\u00e5ger det allerede indefra. <\/p>\n<p>Hvordan implementeres dette teknisk korrekt: hver service tilvejebringer en endpoint om sin nuv\u00e6rende funktionalitet, og i graferne i Grafana (eller en hvilken som helst anden applikation) ser vi status for alle tjenester.<\/p>\n<ul>\n<li>Hver \u00e6ndring af API'et skal f\u00f8re til en \u00e6ndring af kontrollerne. <\/li>\n<li>Opret nye tjenester straks med health-metrics.<\/li>\n<li>En administrator kan henvende sig til udviklerne og bede om \"tilf\u00f8j et par funktioner, s\u00e5 jeg kan forst\u00e5 det hele og tilf\u00f8je information til mit overv\u00e5gningssystem\". Men udviklerne svarer normalt: \"Vi vil ikke tilf\u00f8je noget to uger f\u00f8r udgivelsen.\"<br \/>\nLad udviklingslederne vide, at der vil v\u00e6re s\u00e5danne tab, og lad ogs\u00e5 udviklingsledernes ledelse vide besked. Fordi n\u00e5r alt g\u00e5r ned, vil der altid v\u00e6re nogen, der ringer og kr\u00e6ver overv\u00e5gning af den \"stadig-nedlagte service\". <\/li>\n<li>For resten, s\u00f8rg for at afs\u00e6tte udviklere til at skrive plugins til Grafana \u2013 det vil v\u00e6re en stor hj\u00e6lp til administratorerne.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Applikationsniveau \u2013 Integrationsoverv\u00e5gning<\/h3>\n<p>\nIntegrationsoverv\u00e5gning fokuserer p\u00e5 overv\u00e5gning af kommunikationen mellem kritiske forretningssystemer.<\/p>\n<p>For eksempel er der 15 tjenester, der kommunikerer med hinanden. Det er ikke l\u00e6ngere separate sites. Det vil sige, vi kan ikke bare kalde en service, f\u00e5 \/helloworld og bekr\u00e6fte, at tjenesten fungerer. Fordi webtjenesten til ordreplacering skal sende oplysninger om ordren til bus-systemet \u2013 fra bus-systemet skal lagertjenesten modtage denne besked og arbejde videre med den. E-mail-service skal behandle dette p\u00e5 en eller anden m\u00e5de og s\u00e5 videre. <\/p>\n<p>Derfor kan vi ikke forst\u00e5, n\u00e5r vi trykker p\u00e5 hver enkelt tjeneste, hvordan det hele fungerer. Fordi vi har en slags bus, som alt kommunikerer og interagerer gennem.<br \/>\nS\u00e5 dette trin skal markere testen af tjenester i forhold til deres interaktion med andre tjenester. Man kan ikke, kun ved at overv\u00e5ge meddelelsesbroker, organisere overv\u00e5gning af kommunikationen. Hvis der er en tjeneste, der udsender data, og en anden, der modtager dem, vil vi i overv\u00e5gningen af broker kun se de data, der flyver frem og tilbage. Selvom vi er lykkedes med at overv\u00e5ge interaktionen af disse data \u2014 at en eller anden producerer data, og nogen l\u00e6ser dem, mens str\u00f8mmen forts\u00e6tter i Kafka \u2014 vil det stadig ikke give os information, hvis den ene tjeneste sendte meddelelsen i en version, og den anden tjeneste ikke forventede denne version og derfor gik glip af den. Det vil vi ikke finde ud af, da vores tjenester siger, at alt fungerer. <\/p>\n<p>S\u00e5dan anbefaler jeg at g\u00f8re:<\/p>\n<ul>\n<li>For synkron kommunikation: endpointet udf\u00f8rer anmodninger til relaterede tjenester. Det vil sige, at vi tager dette endpoint, k\u00f8rer et lille script inden i tjenesten, som g\u00e5r gennem alle punkterne og siger: \u00abjeg kan tage fat der, og der, jeg kan tage fat\u2026\u00bb<\/li>\n<li>For asynkron kommunikation: indg\u00e5ende meddelelser \u2014 endpointet tjekker busserne for testmeddelelser og giver en status for behandlingen. <\/li>\n<li>For asynkron kommunikation: udg\u00e5ende meddelelser \u2014 endpointet sender testmeddelelser til busserne.<\/li>\n<\/ul>\n<p>\nSom det s\u00e6dvanligvis sker: vi har en tjeneste, der skyder data til bussen. Vi kommer ind i denne tjeneste og beder om at f\u00e5 at vide om dens integrationsstatus. Og hvis tjenesten skal producere en meddelelse et eller andet sted (WebApp), s\u00e5 producerer den denne testmeddelelse. Og hvis vi tr\u00e6kker tjenesten fra siden af OrderProcessing, s\u00e5 poster den f\u00f8rst det, som den kan poste uafh\u00e6ngigt, og hvis der er nogle afh\u00e6ngige ting \u2014 s\u00e5 l\u00e6ser den fra bussen en r\u00e6kke testmeddelelser, forst\u00e5r hvad den kan h\u00e5ndtere, meddeler det, og om n\u00f8dvendigt poster dem videre, og s\u00e5 siger den \u2014 alt er fint, jeg er i live. <\/p>\n<p>Vi h\u00f8rer ofte sp\u00f8rgsm\u00e5let: \"hvordan kan vi teste dette p\u00e5 produktionsdata?\" For eksempel handler det om den samme bestillingstjeneste. Ordren sender meddelelser til lageret, hvor varer bliver afskrevet: vi kan ikke teste dette p\u00e5 produktionsdata, fordi \"jeg f\u00e5r varerne afskrevet!\" L\u00f8sningen: planl\u00e6g hele denne test i de tidlige faser. Du har enhedstest, der laver mocks. S\u00e5 det skal g\u00f8res p\u00e5 et dybere niveau, hvor du har en kommunikationskanal, der ikke skader forretningen. <\/p>\n<h3>Infrastruktur niveau<\/h3>\n<p>\nOverv\u00e5gning af infrastruktur er noget, der l\u00e6nge har v\u00e6ret anset som selve overv\u00e5gningen. <\/p>\n<ul>\n<li>Overv\u00e5gning af infrastruktur kan og b\u00f8r starte som en separat proces.<\/li>\n<li>Det er ikke en god id\u00e9 at starte overv\u00e5gningen af infrastrukturen p\u00e5 et aktivt projekt, selvom man har lyst. Dette er et problem for alle DevOps. \"F\u00f8rst overv\u00e5ger jeg klyngen, derefter overv\u00e5ger jeg infrastrukturen\" \u2013 det vil sige, man overv\u00e5ger f\u00f8rst det, der ligger nederst, men g\u00e5r ikke ind i applikationen. For applikationen er en uklar ting for DevOps. Det blev givet til ham, og han forst\u00e5r ikke, hvordan det fungerer. Men han forst\u00e5r infrastrukturen og starter der. Men nej \u2013 man skal altid overv\u00e5ge applikationen f\u00f8rst. <\/li>\n<li>Overdriv ikke med antallet af advarsler. Givet kompleksiteten i moderne systemer, kommer advarslerne konstant, og man skal finde en m\u00e5de at leve med denne bunke af advarsler p\u00e5. Og en on-call person, der ser p\u00e5 hundrede nye advarsler, vil t\u00e6nke \"jeg vil ikke t\u00e6nke p\u00e5 det.\" Advarsler b\u00f8r kun informere om kritiske ting. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Applikationsniveau som forretningsenhed<\/h3>\n<p>\nN\u00f8glepunkter:<\/p>\n<ul>\n<li>ELK. Dette er industristandard. Hvis du ikke aggregerer logs af en eller anden grund, s\u00e5 begynd med det straks.<\/li>\n<li>APM. Eksterne APM som en hurtig m\u00e5de at lukke overv\u00e5gningen af applikationen (NewRelic, BlackFire, Datadog). Du kan midlertidigt installere dette for at f\u00e5 en forst\u00e5else af, hvad der sker. <\/li>\n<li>Tracing. I dusinvis af mikrotjenester skal du trace alt, fordi foresp\u00f8rgslen ikke lever alene. At tilf\u00f8je det senere er meget sv\u00e6rt, s\u00e5 det er bedre at planl\u00e6gge tracing tidligt i udviklingen \u2013 det er et arbejde og et v\u00e6rkt\u00f8j for udviklerne. Hvis det ikke er implementeret endnu \u2013 s\u00e5 implementer det! Se Jaeger\/Zipkin.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Advarsel<\/h3>\n<p><\/p>\n<ul>\n<li>Organisering af varslingssystemet: under monitoreringen af mange ting skal der v\u00e6re et samlet system til udsendelse af varsler. Det kan g\u00f8res i Grafana. I Vesten bruger alle PagerDuty. Varslerne skal v\u00e6re klare (for eksempel, hvor de kommer fra\u2026). Og det er \u00f8nskeligt at kontrollere, at varslerne virkelig n\u00e5r frem. <\/li>\n<li>Organisering af vagtordninger: alerter m\u00e5 ikke sendes til alle (ellers vil alle reagere i flok, eller ingen vil reagere). Oncall skal v\u00e6re for udviklerne: definer tydeligt ansvarsomr\u00e5der, lav klare instruktioner, og skriv i dem, hvem der konkret skal kontaktes om mandagen og om onsdagen, og hvem om tirsdagen og om fredagen (ellers vil ingen kontakte dem, selv i tilf\u00e6lde af en stor n\u00f8dsituation \u2014 de vil v\u00e6re bange for at forstyrre: folk elsker generelt ikke at ringe og v\u00e6kke andre, is\u00e6r om natten). Og forklar, at det at bede om hj\u00e6lp ikke er et tegn p\u00e5 inkompetence (\"jeg beder om hj\u00e6lp \u2014 s\u00e5 er jeg en d\u00e5rlig medarbejder\"); opmuntrer til anmodninger om hj\u00e6lp.<\/li>\n<li>Organisering af \"vidensbasen\" og arbejdsgangen ved h\u00e5ndtering af h\u00e6ndelser: for hver alvorlig h\u00e6ndelse skal der planl\u00e6gges en postmortem, som en midlertidig foranstaltning skal de handlinger, der l\u00f8ser h\u00e6ndelsen, dokumenteres. Indf\u00f8r en praksis, hvor gentagne alerter er en synd; de skal rettes i koden eller infrastrukturarbejdet. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Teknologisk stack<\/h3>\n<p>\nLad os forestille os, at vores stack er f\u00f8lgende: <\/p>\n<ul>\n<li>dataindsamling \u2014 Prometheus + Grafana;<\/li>\n<li>loganalyse \u2014 ELK;<\/li>\n<li>til APM eller Tracing \u2014 Jaeger (Zipkin).<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"D\u00f8r overv\u00e5gning? \u2014 Leve overv\u00e5gning\" src=\"\/wp-content\/uploads\/2019\/04\/af26d3c0ba781cd856d220515788b5eb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nValgmulighederne er ikke kritiske. Fordi, hvis du i starten forstod, hvordan du skulle overv\u00e5ge systemet og lagde en plan, s\u00e5 begynder du derefter at v\u00e6lge v\u00e6rkt\u00f8jer efter dine behov. Sp\u00f8rgsm\u00e5let er, hvad du valgte at overv\u00e5ge i begyndelsen. Fordi det kan v\u00e6re, at det v\u00e6rkt\u00f8j, du valgte i starten, slet ikke opfylder dine krav. <\/p>\n<p>Nogle tekniske punkter, som jeg ser overalt for tiden:<\/p>\n<p><i>Prometheus presses ind i Kubernetes \u2014 hvem fandt p\u00e5 det?!<\/i> Hvis din klynge falder, hvad vil du s\u00e5 g\u00f8re? Hvis du har en kompleks klynge indeni, s\u00e5 skal der v\u00e6re et eller andet overv\u00e5gningssystem indeni klyngen, og et andet \u2014 udenfor, som samler data fra indersiden af klyngen. <\/p>\n<p><i>Inden i klyngen samler vi logs og alt andet.<\/i> Men systemet til overv\u00e5gning skal v\u00e6re udenfor. Meget ofte i et cluster, hvor der er Promtheus installeret indeni, st\u00e5r der ogs\u00e5 systemer, der udf\u00f8rer eksterne checks af webstedets drift. Og hvis dine forbindelser til omverdenen falder, og applikationen ikke fungerer? S\u00e5 er alt godt indeni, men det hj\u00e6lper ikke brugerne.<\/p>\n<h3>Konklusioner<\/h3>\n<p><\/p>\n<ul>\n<li>Udviklingen af overv\u00e5gning er ikke installation af v\u00e6rkt\u00f8jer, men udvikling af et softwareprodukt. 98% af den nuv\u00e6rende overv\u00e5gning er kodning. Kodning i tjenester, kodning af eksterne kontroller, kontrol af eksterne tjenester, og alt muligt andet. <\/li>\n<li>Spar ikke tid for udviklerne p\u00e5 overv\u00e5gning: det kan tage op til 30% af deres arbejde, men det er det v\u00e6rd.<\/li>\n<li>DevOps, v\u00e6r ikke bekymret over, at du ikke kan overv\u00e5ge noget, for nogle ting er en helt anden tankegang. Du har ikke v\u00e6ret programm\u00f8r, og overv\u00e5gningsarbejdet er netop deres arbejde.<\/li>\n<li>Hvis projektet allerede k\u00f8rer og ikke er overv\u00e5get (og du er leder) \u2014 afs\u00e6t ressourcer til overv\u00e5gning.<\/li>\n<li>Hvis produktet allerede er i produktion, og du er DevOps, der har f\u00e5et besked om \"at ops\u00e6tte overv\u00e5gning\" \u2014 pr\u00f8v at forklare ledelsen det, jeg har skrevet om.<\/li>\n<\/ul>\n<p>\n<i>Dette er en udvidet version af pr\u00e6sentationen p\u00e5 konferencen Saint Highload++.<\/i><\/p>\n<p>Hvis du er interesseret i mine id\u00e9er og tanker om it og relaterede emner, s\u00e5 kan du <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/eapotapov_channel\">l\u00e6re at l\u00e6se kanalen <\/a><\/noindex>\ud83d\ude42<br \/>\n<br \/>Kilde: <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.3 - 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\/da\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\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\/da\/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\udd47Overv\u00e5gning d\u00f8d? \u2014 Leve overv\u00e5gningen | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/31864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=31864"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/31864\/revisions"}],"predecessor-version":[{"id":158558,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/31864\/revisions\/158558"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/23731"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=31864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=31864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=31864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}