{"id":55700,"date":"2020-01-26T00:00:00","date_gmt":"2020-01-25T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti"},"modified":"2020-02-18T14:03:50","modified_gmt":"2020-02-18T11:03:50","slug":"trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","title":{"rendered":"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Het principe van de onzekerheid van Heisenberg stelt dat het onmogelijk is om tegelijkertijd de positie van een object en zijn snelheid te meten. Als een object in beweging is, heeft het geen specifieke positie. En als er een positie is, dan betekent dat dat het geen snelheid heeft.<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/617ace5f892b62652b404b24585537b0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWat betreft microservices op het Red Hat OpenShift-platform (en beheerd door Kubernetes), kunnen ze dankzij de bijbehorende open-source software tegelijkertijd rapporteren over zowel hun prestaties als hun functionaliteit. Dit weerlegt natuurlijk de oude man Heisenberg niet, maar het elimineert de onzekerheid bij het werken met cloudapplicaties. Istio maakt het gemakkelijk om tracering en monitoring van dergelijke applicaties te organiseren, zodat alles onder controle blijft.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Laten we de terminologie vaststellen<\/h3>\n<p>\nOnder <b>tracering<\/b> (Tracing) verstaan we het loggen van systeemactiviteit. Het klinkt vrij algemeen, maar een van de belangrijkste regels hier is om traceergegevens in de juiste opslag te dumpen, zonder je zorgen te maken over hun opmaak. Het volledige werk van het zoeken en analyseren van gegevens ligt bij de gebruiker ervan. In Istio wordt het traceringssysteem Jaeger gebruikt, dat het OpenTracing-datamodel implementeert.<\/p>\n<p><b>Traceringen<\/b> (Traces, en het woord \"traceringen\" wordt hier gebruikt in de betekenis van \"sporen\", zoals bijvoorbeeld in ballistische expertises) noemen we de gegevens die volledig beschrijven hoe een verzoek of een werkunit verloopt, zeg maar, \u201cvan begin tot eind\u201d. Bijvoorbeeld, alles wat er gebeurt vanaf het moment dat een gebruiker op een knop op een webpagina drukt tot het moment dat gegevens worden teruggestuurd, inclusief alle microservices die daarbij betrokken zijn. Je zou kunnen zeggen dat \u00e9\u00e9n tracering volledig beschrijft (of modelleert) hoe een verzoek heen en terug gaat. In de Jaeger-interface worden traceringen opgedeeld in componenten langs de tijdas, zoals je een ketting in aparte schakels kunt opdelen. Maar in plaats van schakels bestaat een tracering uit zogenaamde span's.<\/p>\n<p><b>Span<\/b> \u2013 dit is het interval van het begin van de uitvoering van een werkunit tot de voltooiing ervan. Blijft de analogie behouden, dan kun je zeggen dat elke span een afzonderlijke schakel van de ketting vertegenwoordigt. Een span kan (of kan geen) een of meerdere kindspan's hebben. Als gevolg hiervan zal de span van het hoogste niveau (root span) dezelfde totale duur hebben als de tracering waartoe hij behoort.<\/p>\n<p><b>Monitoring<\/b> \u2013 is, in fact, the observation of your system \u2013 through the UI or via automation tools. Monitoring is based on tracing data. In Istio, monitoring is implemented using Prometheus and has a corresponding UI. Prometheus supports automatic monitoring with alert notifications and Alert Managers.<\/p>\n<h3>We make notches<\/h3>\n<p>\nFor tracing to be possible, the application must create a collection of spans. These must then be exported to Jaeger, which in turn creates a visual representation of the trace. Among other things, these spans mark the operation name and the timestamps of its start and end. The transfer of spans is done by redirecting HTTP headers intended for Jaeger from incoming requests to outgoing requests. Depending on the programming language used, this may require slight modifications to the application source code. Below is an example of code in Java (using the Spring Boot framework) that adds B3 (Zipkin-style) headers to your request in the Spring configuration class:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/2314e2d156dc9b9fdb299af2dac01f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nThe following header settings are used:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/18f0a13af27665ec2d154ff4cff48157.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIf you are using Java, you don't need to change the code; just add a few lines in the Maven POM file and set environment variables. Here are the lines that need to be added to the POM.XML file to implement the Jaeger Tracer Resolver:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/a63a634c2c22fc09a237cafc4873855d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAnd the corresponding environment variables are set in the Dockerfile:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/7fe9046242d7e628342a6266e4a2f743.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nThat's it, everything is set up, and our microservices will start generating trace data.<\/p>\n<h3>Looking at the big picture<\/h3>\n<p>\nIstio includes a simple control panel based on Grafana. When everything is set up and running on the Red Hat OpenShift PaaS platform (in our example, Red Hat OpenShift and Kubernetes are deployed on minishift), this panel is launched with the following command:<\/p>\n<pre><code class=\"plaintext\">open \"$(minishift openshift service grafana -u)\/d\/1\/istio-dashboard?refresh=5&amp;ord;Id=1\"\n<\/code><\/pre>\n<p>\nThe Grafana panel allows for a quick assessment of the system's performance. A fragment of this panel is shown in the image below:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/2c10cd23fd5166f437c2b3c1d50c6a18.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHier zien we dat de microservice customer de microservice preference v1 aanroept, en deze op zijn beurt roept de microservices recommendation v1 en v2 aan. Op het Grafana-paneel is er een Dashboard Row-blok voor high-level metrics, zoals het totale aantal verzoeken (Global Request Volume), het percentage succesvolle verzoeken (success rates) en fouten 4xx. Daarnaast is er een weergave van Server Mesh met grafieken voor elke service en een blok Services Row voor het bekijken van gedetailleerde informatie over elke container voor elke service.<\/p>\n<h3>Laten we dieper graven<\/h3>\n<p>\nBij correct ingestelde tracing van Istio, wat eigenlijk direct uit de doos beschikbaar is, kan je dieper ingaan op de prestatie-analyse van het systeem. In de Jaeger UI kun je traceringen bekijken en zien hoe ver en diep ze gaan, en visueel knelpunten in de prestaties lokaliseren. Wanneer je Red Hat OpenShift op het minishift-platform gebruikt, start je de Jaeger UI met de volgende opdracht:<\/p>\n<pre><code class=\"plaintext\">minishift openshift service jaeger-query --in-browser\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/074fea646ad191f819a9a67a3f311c8f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nWat kunnen we zeggen over de tracing op deze afbeelding:<\/p>\n<ul>\n<li>Het is verdeeld in 7 spans.<\/li>\n<li>De totale uitvoeringstijd bedraagt 6,99 ms.<\/li>\n<li>De microservice recommendation, die de laatste in de keten is, verbruikt 0,69 ms.<\/li>\n<\/ul>\n<p>\nDit type diagrammen maakt het mogelijk om snel te begrijpen wanneer de prestaties van het complete systeem lijden onder een enkel dienst die niet goed functioneert.<\/p>\n<p>Laten we de taak nu ingewikkelder maken en twee instanties van de microservice recommendation:v2 starten met het commando oc scale \u2014replicas=2 deployment\/recommendation-v2. Dit zijn de pod's die we daarna zullen hebben:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/0ecb8d78d6967d0392de67be6553b870.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAls we nu terugschakelen naar Jaeger en de span voor de service recommendation uitvouwen, zien we naar welke pod de verzoeken worden gerouteerd. Hierdoor kunnen we eenvoudig vertragingen lokaliseren op het niveau van een specifieke pod. Kijk hierbij naar het veld node_id:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/474da66c581692cd11070a1732ac5458.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>Waarheen en hoe alles loopt<\/h3>\n<p>\nWe gaan nu naar de Prometheus-interface en zien daar, zoals verwacht, dat de verzoeken tussen de tweede en eerste versies van de service recommendation worden verdeeld in een verhouding van 2:1, strikt op basis van het aantal werkende pods. Dit grafiek zal dynamisch veranderen bij het opschalen van pods omhoog of omlaag, wat bijzonder nuttig zal zijn bij Canary Deployment (we zullen deze implementatiestrategie in de volgende sessie beter bekijken).<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/c080fffd2398b0a2eac3e63665bdb0a7.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>Alles begint pas<\/h3>\n<p>\nEigenlijk hebben we vandaag slechts oppervlakkig een schat aan nuttige informatie over Jaeger, Grafana en Prometheus aangestipt. Dit was ook ons doel \u2013 u in de juiste richting leiden en de mogelijkheden van Istio onthullen.<\/p>\n<p>En onthoud, dit is allemaal al ingebouwd in Istio. Bij het gebruik van bepaalde programmeertalen (zoals Java) en frameworks (zoals Spring Boot) kan dit allemaal worden gerealiseerd zonder de applicatiecode aan te raken. Ja, de code moet enigszins worden aangepast als u andere talen gebruikt, met name Node.js of C#. Maar aangezien traceerbaarheid (lees: \u2018tracering\u2019) een van de vereisten is voor het cre\u00ebren van betrouwbare cloudsystemen, zult u in ieder geval de code moeten aanpassen, of u nu Istio gebruikt of niet. Waarom de inspanning dan niet effectiever inzetten?<\/p>\n<p>Laten we zeggen: om altijd met 100% zekerheid de vragen 'waar?' en 'hoe snel?' te kunnen beantwoorden.<\/p>\n<h3>Chaos-engineering in Istio: zoals het bedoeld was<\/h3>\n<p><\/p>\n<h3>Het vermogen om dingen kapot te maken helpt ervoor te zorgen dat ze niet kapotgaan.<\/h3>\n<p>\nSoftwaretesten is niet alleen een complexe taak, maar ook een belangrijke. Tegelijkertijd is testen op correctheid (bijvoorbeeld of een functie het juiste resultaat teruggeeft) iets anders dan testen onder onbetrouwbare netwerkconditions \u2013 dit wordt vaak verondersteld dat het netwerk altijd zonder onderbrekingen werkt, en dat is het eerste van de acht misvattingen over gedistribueerde computing. Een van de moeilijkheden bij het aanpakken van deze taak is hoe systeemstoringen te simuleren of deze opzettelijk te introduceren door middel van zogenaamde fault injection. Dit kan gedaan worden door de oorspronkelijke code van de applicatie te wijzigen. Maar dan test u niet uw oorspronkelijke code, maar een versie die speciaal is ontworpen om storingen te simuleren. Het resultaat is dat u het risico loopt om in de dodelijke omhelzing van fault injection te belanden en te maken te krijgen met Heisenbugs \u2013 storingen die verdwijnen wanneer men probeert ze te ontdekken.<\/p>\n<p>En nu laten we zien hoe Istio helpt deze complicaties snel op te lossen.<\/p>\n<h3>Hoe alles eruitziet wanneer alles perfect werkt.<\/h3>\n<p>\nLaten we het volgende scenario bekijken: we hebben twee pod\u2019s voor onze recommendation microservice, die we uit de Istio-handleiding hebben gehaald. De ene pod is gemarkeerd als v1 en de andere als v2. Zoals we zien, werkt alles prima tot nu toe:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/c50387b7cfd12298cfab8123f13b2ca4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n(Trouwens, het nummer aan de rechterkant is gewoon een teller voor elke pod.)<\/p>\n<p>Maar we hebben dit echt niet nodig, toch? Laten we proberen alles kapot te maken, zonder de oorspronkelijke code aan te raken.<\/p>\n<h3>We veroorzaken storingen in de microservice.<\/h3>\n<p>\nHieronder staat een yaml-bestand voor de Istio-routeringregel, die in de helft van de gevallen een fout zal geven (foutmelding). <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/nl\/server\/dts-los-angeles\/\"   title=\"de server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"3597\">de server<\/a> 503):<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/8fb3ed7f16ed7fd1a57b27dfc3bfd2da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLet op, we geven expliciet aan dat in de helft van de gevallen een fout 503 moet worden teruggegeven.<\/p>\n<p>Zo ziet een screenshot eruit van de curl-opdracht die in een loop draait, nadat we deze regel hebben geactiveerd om storingen te simuleren. Zoals te zien is, geeft de helft van de aanvragen een fout 503 terug, ongeacht op welke pod \u2013 v1 of v2 \u2013 ze worden verzonden.<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/3d9760cf5abc7480ad3aab826c274766.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nOm de normale werking te herstellen, hoeft u alleen maar deze regel te verwijderen, in ons geval met het commando istioctl delete routerule recommendation-503 -n tutorial. Hier is Tutorial de naam van het Red Hat OpenShift-project waarin onze Istio-tutorial draait.<\/p>\n<h3>We brengen kunstmatige vertragingen aan.<\/h3>\n<p>\nKunstmatige fouten 503 helpen om het systeem op veerkracht tegen storingen te testen, maar het vermogen om vertragingen te voorspellen en ermee om te gaan, zou u nog meer moeten imponeren. Vertragingen komen in het echte leven namelijk vaker voor dan storingen. Een traag werkende microservice is een vergif waar het hele systeem onder lijdt. Met Istio kunnen we de code die met vertragingen omgaat testen, zonder deze te wijzigen. We zullen eerst laten zien hoe dit werkt bij kunstmatig ingevoerde netwerkvertragingen.<\/p>\n<p>Let op, na zo'n test moet u mogelijk (of wilt u) uw code aanpassen. Het goede nieuws is dat u in dit geval proactief zult handelen, in plaats van reactief. Dit is hoe de ontwikkelingscyclus moet worden gebouwd: coderen-testen-feedback-coderen-testen\u2026<\/p>\n<p>Dit is hoe de regel eruitziet, die... Maar weet u wat? Istio is zo eenvoudig, en dit yaml-bestand is zo duidelijk, dat alles in dit voorbeeld voor zich spreekt. Kijk maar:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/e077e891cbccc66ebc4d4c7b67a0f1ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIn de helft van de gevallen zullen we een vertraging van 7 seconden ervaren. Dit is absoluut niet hetzelfde als wanneer we een sleep-commando in de originele code zouden invoegen, omdat Istio daadwerkelijk de aanvraag 7 seconden vertraagt. Aangezien Istio Jaeger-tracering ondersteunt, is deze vertraging duidelijk zichtbaar in de Jaeger UI, zoals te zien is in de onderstaande screenshot. Let op het lange verzoek in de rechterbovenhoek van de grafiek \u2013 de duur is 7,02 seconden:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/97a7b33fb7e0455973c7fd1b2aefadf3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDit scenario maakt het mogelijk om de code te testen onder netwerklatenties. En het is duidelijk dat als we deze regel weghalen, we de kunstmatige vertraging zullen verwijderen. Laten we herhalen dat we dit alles hebben gedaan zonder de originele code aan te raken.<\/p>\n<h3>Niet afwijken en niet opgeven<\/h3>\n<p>\nEen andere nuttige functie van chaos engineering in Istio is de mogelijkheid om meerdere keren een verzoek naar de service te doen binnen een bepaald aantal keren. Het idee hier is om niet te stoppen als de eerste aanvraag eindigt met een foutmelding 503 \u2013 en dan, misschien, hebben we geluk bij de N-de poging. Misschien ligt de service tijdelijk plat om een of andere reden. Ja, deze reden moet worden uitgezocht en opgelost. Maar dat later, laten we nu proberen om het systeem operationeel te houden.<\/p>\n<p>Dus we willen dat de service van tijd tot tijd een fout 503 teruggeeft, en Istio daarna opnieuw probeert contact te maken. En we hebben duidelijk een manier nodig om een fout 503 te genereren zonder de code zelf aan te raken\u2026<\/p>\n<p>Wacht, even wachten! We deden dit net.<\/p>\n<p>Dit bestand zorgt ervoor dat de service recommendation-v2 in de helft van de gevallen een fout 503 zal geven:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/f446528f9c968e40cc2cf318cf0acde9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHet is duidelijk dat een deel van de verzoeken zal falen:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/f998513746604beda241b8d6de2ed727.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLaten we nu de Istio Retry-functie inschakelen:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/32e210b6ecbf4c1ecf121ee73e64ba35.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDeze routeringsregel maakt drie opnieuw pogingen met tussenpozen van twee seconden en zou de 503-fouten moeten verminderen (en idealiter volledig van de radar moeten verwijderen):<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/7f9711c52949072b823399e59141cb64.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSamenvattend: we hebben ervoor gezorgd dat Istio, ten eerste, een fout 503 genereert voor de helft van de verzoeken. Ten tweede, dezelfde Istio probeert drie keer opnieuw contact te maken met de service bij een fout 503. Als gevolg daarvan werkt alles gewoon uitstekend. Door de Retry-functie te gebruiken, hebben we ons beloofde om niet af te wijken en niet op te geven, nagekomen.<\/p>\n<p>En ja, we hebben het opnieuw gedaan, zonder de code aan te raken. Alles wat we nodig hadden, waren twee Istio routeringsregels:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/c21a1cfd2d78ae4145a57d1cefcc6c59.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>Hoe je de gebruiker niet in de steek laat of zeven mensen wachten.<\/h3>\n<p>\nLaten we de situatie omdraaien en het scenario bekijken waarin het alleen gedurende een bepaalde tijd de moeite waard is om niet op te geven of zich niet over te geven. Daarna moeten we gewoon stoppen met het proberen om het verzoek te verwerken, om te voorkomen dat iedereen moet wachten op \u00e9\u00e9n vertraagde service. Met andere woorden, we zullen de verloren positie niet verdedigen, maar ons terugtrekken naar een alternatieve lijn om de gebruiker van de site niet in het ongewisse te laten zitten.<\/p>\n<p>In Istio kun je een timeout voor het uitvoeren van een verzoek instellen. Als de service deze timeout overschrijdt, wordt er een fout 504 (Gateway Timeout) geretourneerd - dit alles gebeurt weer via de configuratie van Istio. Maar we moeten een slaapcommando aan de broncode van de service toevoegen (en vervolgens natuurlijk de rebuild en redeploy uitvoeren), om de trage werking van de service te simuleren. Helaas, anders kan het niet.<\/p>\n<p>Dus, we hebben een drie seconden durende slaap in de code van de service recommendation v2 geplaatst, het bijbehorende image opnieuw opgebouwd en de container opnieuw gedeployed, en nu gaan we een timeout toevoegen met behulp van de volgende Istio-routingregel:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/c03fc452b98dd875a8a7d3ac561893ca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nOp de bovenstaande screenshot is te zien dat we stoppen met het proberen om verbinding te maken met de service recommendation, als we binnen \u00e9\u00e9n seconde geen antwoord krijgen, dat wil zeggen nog voordat de fout 504 optreedt. Na het toepassen van deze routingregel (en het toevoegen van de drie seconden durende slaap in de code van de service recommendation:v2), krijgen we dit:<\/p>\n<p><img decoding=\"async\" alt=\"Tracing en Monitoring in Istio: Microservices en het Onzekerheidsprincipe\" src=\"\/wp-content\/uploads\/2020\/01\/ed6e80052c67254718b1fde2bd873e71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nWe herhalen het opnieuw, maar de timeout kan worden ingesteld zonder de broncode aan te raken. En het extra voordeel hier is dat je nu je code kunt aanpassen zodat deze reageert op de timeout, en deze aanpassingen eenvoudig kunt testen met behulp van Istio.<\/p>\n<h3>En nu alles samen<\/h3>\n<p>\nEen beetje chaos introduceren met behulp van Istio is een geweldige manier om je code en de betrouwbaarheid van je systeem als geheel te testen. Fallback-, bulkhead- en circuit breaker-patronen, mechanismen voor het cre\u00ebren van kunstmatige storingen en vertragingen, evenals herhaalde aanroepen en timeouts zullen zeer nuttig zijn bij het cre\u00ebren van veerkrachtige cloudsystemen. In combinatie met Kubernetes en Red Hat OpenShift zullen deze tools helpen om zelfverzekerd de toekomst tegemoet te treden.<br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/redhatrussia\/blog\/485136\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043d\u0446\u0438\u043f \u043d\u0435\u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0413\u0435\u0439\u0437\u0435\u043d\u0431\u0435\u0440\u0433\u0430 \u0433\u043b\u0430\u0441\u0438\u0442, \u0447\u0442\u043e \u043d\u0435\u043b\u044c\u0437\u044f \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u0438\u0437\u043c\u0435\u0440\u0438\u0442\u044c \u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u043e\u0431\u044a\u0435\u043a\u0442\u0430 \u0438 \u0435\u0433\u043e \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c. \u0415\u0441\u043b\u0438 \u043e\u0431\u044a\u0435\u043a\u0442 \u0434\u0432\u0438\u0436\u0435\u0442\u0441\u044f, \u0442\u043e \u0443 \u043d\u0435\u0433\u043e \u043d\u0435\u0442 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0410 \u0435\u0441\u043b\u0438 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u0435\u0441\u0442\u044c \u2013 \u0437\u043d\u0430\u0447\u0438\u0442 \u0443 \u043d\u0435\u0433\u043e \u043d\u0435\u0442 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u0438. \u0427\u0442\u043e \u043a\u0430\u0441\u0430\u0435\u0442\u0441\u044f \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043e\u0432 \u043d\u0430 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0435 Red Hat OpenShift (\u0438 \u043f\u043e\u0434 \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435\u043c Kubernetes), \u0442\u043e \u0431\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u044e\u0449\u0435\u043c\u0443 \u0441\u043e\u0444\u0442\u0443 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u043e\u043d\u0438 \u043c\u043e\u0433\u0443\u0442 \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u0440\u0430\u043f\u043e\u0440\u0442\u043e\u0432\u0430\u0442\u044c \u043a\u0430\u043a [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55700","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043d\u0446\u0438\u043f \u043d\u0435\u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0413\u0435\u0439\u0437\u0435\u043d\u0431\u0435\u0440\u0433\u0430 \u0433\u043b\u0430\u0441\u0438\u0442, \u0447\u0442\u043e \u043d\u0435\u043b\u044c\u0437\u044f \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u0438\u0437\u043c\u0435\u0440\u0438\u0442\u044c \u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u043e\u0431\u044a\u0435\u043a\u0442\u0430 \u0438 \u0435\u0433\u043e \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c. \u0415\u0441\u043b\u0438 \u043e\u0431\u044a\u0435\u043a\u0442 \u0434\u0432\u0438\u0436\u0435\u0442\u0441\u044f, \u0442\u043e \u0443 \u043d\u0435\u0433\u043e \u043d\u0435\u0442 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0422\u0440\u0430\u0441\u0441\u0438\u0440\u043e\u0432\u043a\u0430 \u0438 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u0432 Istio: \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f \u043d\u0435\u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0441\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043d\u0446\u0438\u043f \u043d\u0435\u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0413\u0435\u0439\u0437\u0435\u043d\u0431\u0435\u0440\u0433\u0430 \u0433\u043b\u0430\u0441\u0438\u0442, \u0447\u0442\u043e \u043d\u0435\u043b\u044c\u0437\u044f \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u0438\u0437\u043c\u0435\u0440\u0438\u0442\u044c \u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u043e\u0431\u044a\u0435\u043a\u0442\u0430 \u0438 \u0435\u0433\u043e \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c. \u0415\u0441\u043b\u0438 \u043e\u0431\u044a\u0435\u043a\u0442 \u0434\u0432\u0438\u0436\u0435\u0442\u0441\u044f, \u0442\u043e \u0443 \u043d\u0435\u0433\u043e \u043d\u0435\u0442 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti\" \/>\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=\"2020-01-25T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:50+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\udd47Tracing en monitoring in Istio: microservices en het onzekerheidsprincipe | ProHoster","description":"Het onzekerheidsprincipe van Heisenberg stelt dat je de positie van een object en zijn snelheid niet tegelijkertijd kunt meten. Als een object beweegt, heeft het geen specifieke locatie.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0440\u0430\u0441\u0441\u0438\u0440\u043e\u0432\u043a\u0430 \u0438 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u0432 Istio: \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u044b \u0438 \u043f\u0440\u0438\u043d\u0446\u0438\u043f \u043d\u0435\u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0441\u0442\u0438 | ProHoster","og:description":"\u041f\u0440\u0438\u043d\u0446\u0438\u043f \u043d\u0435\u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0413\u0435\u0439\u0437\u0435\u043d\u0431\u0435\u0440\u0433\u0430 \u0433\u043b\u0430\u0441\u0438\u0442, \u0447\u0442\u043e \u043d\u0435\u043b\u044c\u0437\u044f \u043e\u0434\u043d\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u043e \u0438\u0437\u043c\u0435\u0440\u0438\u0442\u044c \u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u0435 \u043e\u0431\u044a\u0435\u043a\u0442\u0430 \u0438 \u0435\u0433\u043e \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c. \u0415\u0441\u043b\u0438 \u043e\u0431\u044a\u0435\u043a\u0442 \u0434\u0432\u0438\u0436\u0435\u0442\u0441\u044f, \u0442\u043e \u0443 \u043d\u0435\u0433\u043e \u043d\u0435\u0442 \u043c\u0435\u0441\u0442\u043e\u043f\u043e\u043b\u043e\u0436\u0435\u043d\u0438\u044f.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","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":"2020-01-25T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55700","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:38:32","updated":"2026-02-22 15:29:16","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/55700","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=55700"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/55700\/revisions"}],"predecessor-version":[{"id":162124,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/55700\/revisions\/162124"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=55700"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=55700"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=55700"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}