{"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\/it\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","title":{"rendered":"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Il principio di indeterminazione di Heisenberg afferma che non \u00e8 possibile misurare simultaneamente la posizione di un oggetto e la sua velocit\u00e0. Se un oggetto si muove, non ha una posizione definita. E se ha una posizione, significa che non ha velocit\u00e0.<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/617ace5f892b62652b404b24585537b0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPer quanto riguarda i microservizi sulla piattaforma Red Hat OpenShift (e gestiti da Kubernetes), grazie al software open source appropriato possono riportare sia sulle loro prestazioni che sul loro stato di funzionamento. Questo, naturalmente, non contraddice il vecchio Heisenberg, ma elimina l'indeterminatezza nel lavoro con le applicazioni cloud. Istio facilita il tracciamento e il monitoraggio di tali applicazioni, mantenendo tutto sotto controllo.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Definiamo la terminologia<\/h3>\n<p>\nSotto <b>tracciamento<\/b> (Tracing) intendiamo la registrazione delle attivit\u00e0 di sistema. Sembra piuttosto generico, ma in realt\u00e0 una delle regole principali qui \u00e8 quella di scaricare i dati di tracciamento nel rispettivo archivio, senza preoccuparsi del loro formato. Tutto il lavoro di ricerca e analisi dei dati ricade sul consumatore. In Istio viene utilizzato il sistema di tracciamento Jaeger, che implementa il modello dati OpenTracing.<\/p>\n<p><b>Tracce<\/b> (Traces, e la parola \"tracce\" qui \u00e8 usata nel senso di \"impronte\", come ad esempio nella perizia balistica) noi ci riferiamo ai dati che descrivono completamente il passaggio di una richiesta o di un'unit\u00e0 di lavoro, cosiddetto, \"dall'inizio alla fine\". Ad esempio, tutto ci\u00f2 che accade dal momento in cui un utente preme un pulsante sulla pagina web fino al momento in cui vengono restituiti i dati, incluso tutti i microservizi coinvolti. Si pu\u00f2 dire che una traccia descrive completamente (o modella) il passaggio della richiesta da e verso. Nell'interfaccia di Jaeger, le tracce vengono scomposte in componenti lungo l'asse temporale, un po' come una catena pu\u00f2 essere scomposta in singoli anelli. Solo che invece di anelli, la traccia \u00e8 composta da quelli che vengono chiamati span.<\/p>\n<p><b>Span<\/b> \u2013 \u00e8 l'intervallo dall'inizio dell'esecuzione di un'unit\u00e0 di lavoro fino al suo completamento. Proseguendo con l'analogia, si pu\u00f2 dire che ogni span rappresenta un singolo anello della catena. Uno span pu\u00f2 avere (o non avere) uno o pi\u00f9 span figli. Di conseguenza, lo span di livello pi\u00f9 alto (root span) avr\u00e0 la stessa durata complessiva della traccia a cui appartiene.<\/p>\n<p><b>Monitoraggio<\/b> \u2013 questa \u00e8, in sostanza, l'osservazione del vostro sistema \u2013 attraverso la UI o via strumenti di automazione. La base del monitoraggio sono i dati di tracciamento. In Istio, il monitoraggio \u00e8 realizzato con Prometheus e ha una UI corrispondente. Prometheus supporta il monitoraggio automatico utilizzando avvisi Alerts e Alert Managers.<\/p>\n<h3>Lasciamo segni<\/h3>\n<p>\nPer abilitare il tracciamento, l'applicazione deve creare una collezione di span. Dopodich\u00e9, devono essere esportati in Jaeger, affinch\u00e9 quest'ultimo crei una rappresentazione visiva del tracciamento. Tra l'altro, questi span etichettano il nome dell'operazione, nonch\u00e9 i timestamp di inizio e fine. La trasmissione degli span avviene reindirizzando gli header HTTP delle richieste entranti verso quelle uscenti per Jaeger. A seconda del linguaggio di programmazione utilizzato, potrebbe essere necessaria una piccola modifica del codice sorgente dell'applicazione. Di seguito \u00e8 fornito un esempio di codice Java (utilizzando il framework Spring Boot) che aggiunge gli header B3 (stile Zipkin) alla vostra richiesta nella classe di configurazione di Spring:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/2314e2d156dc9b9fdb299af2dac01f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nVengono utilizzate le seguenti impostazioni degli header:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/18f0a13af27665ec2d154ff4cff48157.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSe state usando Java, non \u00e8 necessario modificare il codice ma basta aggiungere alcune righe al file POM di Maven e definire le variabili d'ambiente. Ecco le righe da aggiungere al file POM.XML per implementare il Jaeger Tracer Resolver:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/a63a634c2c22fc09a237cafc4873855d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLe relative variabili d'ambiente sono definite nel Dockerfile:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/7fe9046242d7e628342a6266e4a2f743.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTutto qui, ora \u00e8 tutto configurato e i nostri microservizi inizieranno a generare dati di tracciamento.<\/p>\n<h3>Un'occhiata generale<\/h3>\n<p>\nIstio include un semplice pannello di controllo basato su Grafana. Quando tutto \u00e8 configurato e funziona sulla piattaforma Red Hat OpenShift PaaS (nel nostro esempio Red Hat OpenShift e Kubernetes sono stati implementati su minishift), questo pannello viene avviato con il seguente comando:<\/p>\n<pre><code class=\"plaintext\">apri \"$(minishift openshift service grafana -u)\\\/d\\\/1\\\/istio-dashboard?refresh=5&amp;ord;Id=1\"\n<\/code><\/pre>\n<p>\nIl pannello Grafana consente di valutare rapidamente le prestazioni del sistema. Un frammento di questo pannello \u00e8 mostrato nell'immagine sottostante:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/2c10cd23fd5166f437c2b3c1d50c6a18.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nQui si vede che il microservizio customer chiama il microservizio preference v1, e quest'ultimo a sua volta chiama i microservizi recommendation v1 e v2. Nel pannello Grafana c'\u00e8 un blocco Dashboard Row per metriche di alto livello, come il volume totale delle richieste (Global Request Volume), la percentuale delle richieste riuscite (success rates), e gli errori 4xx. Inoltre, c'\u00e8 una visualizzazione Server Mesh con grafici per ogni servizio e un blocco Services Row per visualizzare dettagli specifici per ogni contenitore di ciascun servizio.<\/p>\n<h3>Ora approfondiamo<\/h3>\n<p>\nCon un tracciamento Istio ben configurato, si pu\u00f2, per cos\u00ec dire, esplorare l'analisi delle prestazioni del sistema direttamente 'out of the box'. Nella UI di Jaeger \u00e8 possibile visualizzare le tracce e vedere quanto profondamente e lontano si estendono, oltre a identificare visivamente i colli di bottiglia nelle prestazioni. Utilizzando Red Hat OpenShift sulla piattaforma minishift, si avvia la UI di Jaeger con il seguente comando:<\/p>\n<pre><code class=\"plaintext\">minishift openshift service jaeger-query --in-browser\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/074fea646ad191f819a9a67a3f311c8f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nCosa si pu\u00f2 dire sul tracciamento in questo schermo:<\/p>\n<ul>\n<li>\u00c8 suddiviso in 7 span.<\/li>\n<li>Il tempo totale di esecuzione \u00e8 di 6.99 ms.<\/li>\n<li>Il microservizio recommendation, che \u00e8 l'ultimo nella catena, impiega 0.69 ms.<\/li>\n<\/ul>\n<p>\nDiagrammi di questo tipo permettono di comprendere rapidamente la situazione quando le prestazioni dell'intero sistema sono compromesse a causa di un servizio singolo che non funziona correttamente.<\/p>\n<p>E ora complicheremo il compito avviando due istanze del microservizio recommendation:v2 con il comando oc scale \u2014replicas=2 deployment\\\/recommendation-v2. Ecco quali pod avremo dopo:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/0ecb8d78d6967d0392de67be6553b870.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSe ora torniamo su Jaeger e espandiamo lo span per il servizio recommendation, vedremo a quale pod vengono instradate le richieste. In questo modo, possiamo facilmente localizzare i rallentamenti a livello di un singolo pod. Bisogna prestare attenzione al campo node_id:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/474da66c581692cd11070a1732ac5458.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>Dove e come si distribuiscono le richieste<\/h3>\n<p>\nPassiamo ora all'interfaccia Prometheus e, come ci si aspettava, vediamo che le richieste tra la seconda e la prima versione del servizio recommendation sono ripartite in un rapporto di 2:1, in base al numero di pod attivi. Inoltre, questo grafico cambier\u00e0 dinamicamente durante il ridimensionamento dei pod, il che sar\u00e0 particolarmente utile durante il Canary Deployment (analizzeremo pi\u00f9 a fondo questo schema di distribuzione la prossima volta).<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/c080fffd2398b0a2eac3e63665bdb0a7.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>\u00c8 solo l'inizio<\/h3>\n<p>\nIn realt\u00e0, oggi abbiamo solo toccato leggermente il tesoro di informazioni utili su Jaeger, Grafana e Prometheus. In effetti, questo \u00e8 stato il nostro obiettivo: indirizzarvi nella giusta direzione e aprire le prospettive su Istio.<\/p>\n<p>E ricordate, tutto questo \u00e8 gi\u00e0 integrato in Istio. Utilizzando alcuni linguaggi di programmazione (ad esempio, Java) e framework (come Spring Boot), tutto questo pu\u00f2 essere realizzato senza toccare il codice delle applicazioni. S\u00ec, sar\u00e0 necessario modificare leggermente il codice se utilizzate altri linguaggi, in particolare Node.js o C#. Ma poich\u00e9 la tracciabilit\u00e0 (leggi, \"tracciamento\") \u00e8 una delle condizioni essenziali per costruire sistemi cloud affidabili, dovrete comunque modificare il codice, che abbiate o meno Istio. Allora perch\u00e9 non investire i vostri sforzi in modo pi\u00f9 produttivo?<\/p>\n<p>Almeno per poter rispondere sempre alle domande \"dove?\" e \"quanto velocemente?\" con il 100% di certezza.<\/p>\n<h3>Chaos engineering in Istio: era cos\u00ec che era stato previsto<\/h3>\n<p><\/p>\n<h3>Saper rompere le cose aiuta a far s\u00ec che non si rompano.<\/h3>\n<p>\nIl testing del software \u00e8 qualcosa di non solo complesso, ma anche importante. Allo stesso tempo, il testing della correttezza (ad esempio, se una funzione restituisce il risultato corretto) \u00e8 una cosa, mentre testare in condizioni di rete inaffidabile \u00e8 un compito completamente diverso (si tende a pensare che la rete funzioni sempre senza interruzioni, e questo \u00e8 il primo dei tre errori pi\u00f9 comuni relativi al calcolo distribuito). Una delle difficolt\u00e0 nel risolvere questo problema riguarda il modo di simulare i guasti nel sistema o di introdurli deliberatamente, eseguendo quello che si chiama fault injection. Questo pu\u00f2 essere fatto modificando il codice sorgente dell'applicazione. Ma in tal caso non testerete pi\u00f9 il vostro codice originale, bens\u00ec una sua versione specificamente progettata per simulare guasti. Di conseguenza, rischiate di cadere nelle mortali braccia del fault injection e di imbattersi nei gaisemberg \u2013 guasti che scompaiono al tentativo di scoprirli.<\/p>\n<p>Adesso vi mostreremo come Istio aiuta a gestire queste difficolt\u00e0 in un batter d'occhio.<\/p>\n<h3>Com'\u00e8 tutto quando va tutto bene.<\/h3>\n<p>\nConsideriamo il seguente scenario: abbiamo due pod per il nostro microservizio di raccomandazione, che abbiamo preso dal manuale di Istio. Un pod \u00e8 contrassegnato come v1 e l'altro come v2. Come possiamo vedere, per ora funziona tutto perfettamente:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/c50387b7cfd12298cfab8123f13b2ca4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n(A proposito, il numero a destra \u00e8 semplicemente un contatore delle chiamate per ogni pod.)<\/p>\n<p>Ma ci\u00f2 di cui abbiamo bisogno non \u00e8 affatto questo, giusto? Beh, proviamo a rompere tutto senza toccare il codice sorgente.<\/p>\n<h3>Stiamo causando interruzioni nel funzionamento del microservizio<\/h3>\n<p>\nDi seguito \u00e8 fornito un file yaml per la regola di routing Istio, che in met\u00e0 dei casi restituir\u00e0 un errore (fallimento <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/it\/server\/dts-los-angeles\/\"   title=\"server\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"3597\">server<\/a> 503):<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/8fb3ed7f16ed7fd1a57b27dfc3bfd2da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSi prega di notare che specifichiamo chiaramente che in met\u00e0 dei casi deve essere restituito un errore 503.<\/p>\n<p>Ecco come apparir\u00e0 uno screenshot del comando curl in esecuzione in un ciclo dopo aver attivato questa regola per simulare i fallimenti. Come vediamo, met\u00e0 delle richieste restituisce un errore 503, indipendentemente dal pod a cui vengono inviate, sia esso v1 o v2:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/3d9760cf5abc7480ad3aab826c274766.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPer ripristinare il normale funzionamento, \u00e8 sufficiente rimuovere questa regola, nel nostro caso con il comando istioctl delete routerule recommendation-503 -n tutorial. Qui Tutorial \u00e8 il nome del progetto Red Hat OpenShift in cui si trova il nostro tutorial su Istio.<\/p>\n<h3>Introduciamo ritardi artificiali<\/h3>\n<p>\nGli errori 503 artificiali aiutano a testare il sistema per la resilienza ai guasti, ma la capacit\u00e0 di prevedere e gestire i ritardi dovrebbe impressionarti ancora di pi\u00f9. E i ritardi nella vita reale si verificano pi\u00f9 frequentemente dei guasti. Un microservizio che lavora lentamente \u00e8 un cancro che danneggia l'intero sistema. Grazie a Istio, \u00e8 possibile testare il codice relativo alla gestione dei ritardi senza modificarlo. Per iniziare, mostreremo come farlo nel caso di ritardi di rete introdotti artificialmente.<\/p>\n<p>Si prega di notare che dopo un test di questo tipo, potrebbe essere necessario (o desiderare) rivedere il proprio codice. La buona notizia qui \u00e8 che, in tal caso, agirete in modo proattivo, non reattivo. \u00c8 cos\u00ec che dovrebbe essere costruito il ciclo di sviluppo: codifica-test-feedback-codifica-test...<\/p>\n<p>Ecco come appare la regola che... Anche se sapete cosa? Istio \u00e8 cos\u00ec semplice e questo file yaml \u00e8 cos\u00ec chiaro che tutto in questo esempio parla da s\u00e9, basta dare un'occhiata:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/e077e891cbccc66ebc4d4c7b67a0f1ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nNel met\u00e0 dei casi avremo un ritardo di 7 secondi. E questo non \u00e8 affatto lo stesso che se avessimo inserito nel codice sorgente il comando sleep, poich\u00e9 Istio ritarda realmente la richiesta di 7 secondi. Poich\u00e9 Istio supporta il tracciamento Jaeger, questo ritardo \u00e8 chiaramente visibile nell'interfaccia utente di Jaeger, come mostrato nello screenshot qui sotto. Nota la lunga richiesta in alto a destra del diagramma: la sua durata \u00e8 di 7,02 secondi:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/97a7b33fb7e0455973c7fd1b2aefadf3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nQuesto scenario consente di testare il codice in condizioni di ritardo di rete. Ed \u00e8 chiaro che, eliminando questa regola, rimuoveremo il ritardo artificiale. Ripetiamoci, ma abbiamo fatto tutto ci\u00f2 senza toccare il codice sorgente.<\/p>\n<h3>Non ritirarsi e non arrendersi<\/h3>\n<p>\nUn'altra funzione utile di Istio per il chaos engineering \u00e8 il numero di tentativi di interazione con il servizio. Il senso qui \u00e8 quello di non fermarsi quando la prima richiesta termina con un errore 503 \u2014 e cos\u00ec, forse, al N-esimo tentativo avremo successo. Forse il servizio ha semplicemente bisogno di una breve pausa per un motivo o per un altro. S\u00ec, quella causa andrebbe indagata e risolta. Ma quello sar\u00e0 da fare dopo, per ora cerchiamo di far funzionare il sistema.<\/p>\n<p>Quindi, vogliamo che il servizio restituisca occasionalmente un errore 503, e Istio dopo questo prover\u00e0 a riconnettersi. E qui \u00e8 chiaramente necessario un modo per generare un errore 503, senza toccare il codice stesso...<\/p>\n<p>Fermo, aspetta! Lo abbiamo appena fatto.<\/p>\n<p>Questo file far\u00e0 in modo che il servizio recommendation-v2 restituisca un errore 503 nel 50% dei casi:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/f446528f9c968e40cc2cf318cf0acde9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n\u00c8 evidente che parte delle richieste terminer\u00e0 con un errore:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/f998513746604beda241b8d6de2ed727.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nE ora attiviamo la funzione Retry di Istio:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/32e210b6ecbf4c1ecf121ee73e64ba35.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nQuesta regola di instradamento effettua tre tentativi con intervalli di due secondi e dovrebbe ridurre (ideale sarebbe eliminarle del tutto) gli errori 503:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/7f9711c52949072b823399e59141cb64.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nRiassumendo: abbiamo fatto in modo che Istio, da un lato, generasse un errore 503 per met\u00e0 delle richieste. E dall'altro, lo stesso Istio esegue tre tentativi di riconnettersi al servizio in caso di errore 503. Di conseguenza, tutto funziona semplicemente alla grande. Cos\u00ec, utilizzando la funzione Retry, abbiamo mantenuto la nostra promessa di non ritirarci e non arrenderci.<\/p>\n<p>E s\u00ec, l'abbiamo fatto di nuovo, senza toccare il codice. Tutto ci\u00f2 di cui avevamo bisogno erano due regole di instradamento di Istio:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/c21a1cfd2d78ae4145a57d1cefcc6c59.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>Come non deludere l'utente o sette aspettano un solo<\/h3>\n<p>\nE adesso capovolgiamo la situazione e consideriamo uno scenario in cui non vale la pena ritirarsi o arrendersi solo per un periodo di tempo fisso. E poi bisogna semplicemente interrompere i tentativi di elaborare la richiesta, per non far aspettare tutti un servizio che sta causando ritardi. In altre parole, non proteggeremo una posizione persa, ma ci ritireremo su una linea di riserva, per non deludere l'utente del sito e non costringerlo a vagare nell'incertezza.<\/p>\n<p>In Istio, \u00e8 possibile impostare un timeout per l'esecuzione della richiesta. Se il servizio supera questo timeout, viene restituito un errore 504 (Gateway Timeout) \u2013 tutto questo avviene tramite la configurazione di Istio. Ma dovremo aggiungere nel codice sorgente del servizio un comando sleep (e poi, naturalmente, eseguire un rebuild e un redeploy), per simulare il funzionamento lento del servizio. Purtroppo, non c'\u00e8 altro modo.<\/p>\n<p>Quindi, abbiamo inserito un sleep di tre secondi nel codice del servizio recommendation v2, ricostruito l'immagine corrispondente e effettuato il redeploy del contenitore, e ora aggiungiamo un timeout utilizzando la seguente regola di instradamento di Istio:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/c03fc452b98dd875a8a7d3ac561893ca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nNello screenshot sopra, si vede che smettiamo di tentare di contattare il servizio recommendation se non riceviamo una risposta entro un secondo, ovvero ancora prima che si verifichi l'errore 504. Dopo aver applicato questa regola di instradamento (e aver aggiunto un sleep di tre secondi nel codice del servizio recommendation:v2), otteniamo quanto segue:<\/p>\n<p><img decoding=\"async\" alt=\"Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza\" src=\"\/wp-content\/uploads\/2020\/01\/ed6e80052c67254718b1fde2bd873e71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nRipetiamo, ma il timeout pu\u00f2 essere impostato senza toccare il codice sorgente. Un ulteriore vantaggio qui \u00e8 che ora puoi modificare il tuo codice in modo che risponda al timeout, e testare facilmente queste modifiche con Istio.<\/p>\n<h3>E adesso tutto insieme<\/h3>\n<p>\nAggiungere un po' di caos tramite Istio \u00e8 un ottimo modo per testare il tuo codice e l'affidabilit\u00e0 del tuo sistema in generale. I modelli di fallback, bulkhead e circuit breaker, i meccanismi per creare guasti e ritardi artificiali, nonch\u00e9 i retry e i timeout saranno molto utili nella creazione di sistemi cloud resilienti. In combinazione con Kubernetes e Red Hat OpenShift, questi strumenti aiuteranno ad affrontare il futuro con sicurezza.<br \/>\n<br \/>Fonte: <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.1.1 - 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\/it\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47Tracciamento e monitoraggio in Istio: microservizi e principio di indeterminatezza | ProHoster","description":"Il principio di indeterminatezza di Heisenberg afferma che non \u00e8 possibile misurare contemporaneamente la posizione di un oggetto e la sua velocit\u00e0. Se l'oggetto si muove, allora non ha una posizione.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/55700","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=55700"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/55700\/revisions"}],"predecessor-version":[{"id":162124,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/55700\/revisions\/162124"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=55700"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=55700"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=55700"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}