{"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\/es\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","title":{"rendered":"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>El principio de incertidumbre de Heisenberg establece que no se puede medir simult\u00e1neamente la posici\u00f3n de un objeto y su velocidad. Si un objeto se est\u00e1 moviendo, no tiene una ubicaci\u00f3n precisa. Y si hay una ubicaci\u00f3n determinada, entonces no tiene velocidad.<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/617ace5f892b62652b404b24585537b0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn lo que respecta a los microservicios en la plataforma Red Hat OpenShift (y bajo Kubernetes), gracias al software de c\u00f3digo abierto, pueden informar simult\u00e1neamente sobre su rendimiento y estado. Esto no refuta al viejo Heisenberg, pero elimina la incertidumbre en el trabajo con aplicaciones en la nube. Istio facilita la organizaci\u00f3n del seguimiento y monitoreo de estas aplicaciones para mantener todo bajo control.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Definamos la terminolog\u00eda<\/h3>\n<p>\nPor <b>trazado<\/b> (Tracing) entendemos el registro de la actividad del sistema. Suena bastante general, pero en realidad una de las reglas principales aqu\u00ed es que los datos de trazado se env\u00eden a un almacenamiento correspondiente sin preocuparse por su formato. Todo el trabajo de b\u00fasqueda y an\u00e1lisis de datos recae en el consumidor. En Istio, se utiliza el sistema de trazado Jaeger, que implementa el modelo de datos OpenTracing.<\/p>\n<p><b>Trazas<\/b> (Traces, y el t\u00e9rmino \u2018trazas\u2019 se utiliza aqu\u00ed con el significado de \u2018huellas\u2019, como en la bal\u00edstica) llamaremos a los datos que describen completamente el paso de una solicitud o unidad de trabajo, es decir, desde el origen hasta el final. Por ejemplo, todo lo que ocurre desde el momento en que un usuario presiona un bot\u00f3n en una p\u00e1gina web hasta que se devuelven los datos, incluidos todos los microservicios involucrados. Se puede decir que una trazas describe completamente (o modela) el paso de la solicitud de ida y vuelta. En la interfaz de Jaeger, las trazas se descomponen en componentes a lo largo del tiempo, al igual que una cadena puede descomponerse en eslabones individuales. Solo que en lugar de eslabones, la traza consiste en lo que se llama span.<\/p>\n<p><b>Span<\/b> \u2013 es el intervalo desde el inicio hasta la finalizaci\u00f3n de una unidad de trabajo. Siguiendo la analog\u00eda, se puede decir que cada span representa un eslab\u00f3n individual de la cadena. Un span puede tener (o no tener) uno o varios spans secundarios. Como consecuencia, el span de m\u00e1s alto nivel (root span) tendr\u00e1 la misma duraci\u00f3n total que la traza a la que se refiere.<\/p>\n<p><b>Monitoreo<\/b> \u2013 es, en esencia, la observaci\u00f3n de su sistema, ya sea a trav\u00e9s de la interfaz de usuario o mediante herramientas de automatizaci\u00f3n. La base del monitoreo reside en los datos de trazado. En Istio, el monitoreo se implementa a trav\u00e9s de Prometheus y cuenta con una interfaz de usuario correspondiente. Prometheus soporta el monitoreo autom\u00e1tico utilizando alertas y gestores de alertas.<\/p>\n<h3>Hacemos marcas<\/h3>\n<p>\nPara que el trazado sea posible, la aplicaci\u00f3n debe crear una colecci\u00f3n de spans. Luego, deben exportarse a Jaeger, que a su vez generar\u00e1 una representaci\u00f3n visual del trazado. Entre otras cosas, estos spans etiquetan el nombre de la operaci\u00f3n, as\u00ed como las marcas de tiempo de inicio y finalizaci\u00f3n. La transmisi\u00f3n de spans se realiza redirigiendo los encabezados HTTP destinados a Jaeger de las solicitudes entrantes a las salientes. Dependiendo del lenguaje de programaci\u00f3n utilizado, puede ser necesaria una peque\u00f1a modificaci\u00f3n en el c\u00f3digo fuente de las aplicaciones. A continuaci\u00f3n, se presenta un ejemplo de c\u00f3digo en Java (utilizando el marco de trabajo Spring Boot), que agrega encabezados B3 (al estilo Zipkin) a su solicitud en la clase de configuraci\u00f3n de Spring:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/2314e2d156dc9b9fdb299af2dac01f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPara esto se utilizan las siguientes configuraciones de encabezados:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/18f0a13af27665ec2d154ff4cff48157.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSi utiliza Java, no es necesario modificar el c\u00f3digo, simplemente agregue algunas l\u00edneas en el archivo POM de Maven y defina las variables de entorno. Estas son las l\u00edneas que deben a\u00f1adirse al archivo POM.XML para integrar el Resolvedor de Tracer de Jaeger:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/a63a634c2c22fc09a237cafc4873855d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nY las variables de entorno correspondientes se definen en el Dockerfile:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/7fe9046242d7e628342a6266e4a2f743.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nListo, ahora todo est\u00e1 configurado y nuestros microservicios comenzar\u00e1n a generar datos de trazado.<\/p>\n<h3>Observemos en t\u00e9rminos generales<\/h3>\n<p>\nIstio incluye un panel de control sencillo basado en Grafana. Cuando todo est\u00e1 configurado y funcionando en la plataforma Red Hat OpenShift PaaS (en nuestro ejemplo, Red Hat OpenShift y Kubernetes est\u00e1n desplegados en minishift), este panel se inicia con el siguiente comando:<\/p>\n<pre><code class=\"plaintext\">abre \"$(minishift openshift service grafana -u)\/d\/1\/istio-dashboard?refresh=5&amp;ord;Id=1\"\n<\/code><\/pre>\n<p>\nEl panel de Grafana permite evaluar r\u00e1pidamente el rendimiento del sistema. Un fragmento de este panel se muestra en la imagen abajo:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/2c10cd23fd5166f437c2b3c1d50c6a18.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAqu\u00ed se puede ver que el microservicio customer llama al microservicio preference v1, y este a su vez llama a los microservicios recommendation v1 y v2. En el panel de Grafana hay un bloque Dashboard Row para m\u00e9tricas de alto nivel, como el n\u00famero total de solicitudes (Global Request Volume), la tasa de solicitudes exitosas (success rates) y errores 4xx. Adem\u00e1s, hay una representaci\u00f3n de Server Mesh con gr\u00e1ficos para cada servicio y un bloque Services Row para ver detalles espec\u00edficos de cada contenedor para cada servicio.<\/p>\n<h3>Ahora profundicemos un poco m\u00e1s<\/h3>\n<p>\nCon un rastreo correctamente configurado en Istio, que literalmente permite profundizar en el an\u00e1lisis del rendimiento del sistema desde el primer momento. En la interfaz de Jaeger se pueden ver los rastreos y observar cu\u00e1n lejos y profundo llegan, as\u00ed como localizar visualmente los cuellos de botella en el rendimiento. Al usar Red Hat OpenShift en la plataforma minishift, puedes lanzar la interfaz de Jaeger con el siguiente comando:<\/p>\n<pre><code class=\"plaintext\">minishift openshift service jaeger-query --in-browser\n<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/074fea646ad191f819a9a67a3f311c8f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nQu\u00e9 se puede decir sobre el rastreo en esta captura:<\/p>\n<ul>\n<li>Se divide en 7 spans.<\/li>\n<li>El tiempo total de ejecuci\u00f3n es de 6.99 ms.<\/li>\n<li>Se gastan 0.69 ms en el microservicio recommendation, que es el \u00faltimo en la cadena.<\/li>\n<\/ul>\n<p>\nDiagramas de este tipo permiten entender r\u00e1pidamente la situaci\u00f3n cuando el rendimiento de todo el sistema se ve afectado por un \u00fanico servicio mal funcionando.<\/p>\n<p>Ahora vamos a complicar la tarea y lanzaremos dos instancias del microservicio recommendation:v2 con el comando oc scale \u2014replicas=2 deployment\/recommendation-v2. As\u00ed quedar\u00e1n nuestros pods despu\u00e9s de esto:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/0ecb8d78d6967d0392de67be6553b870.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nSi ahora regresamos a Jaeger y desplegamos el span para el servicio recommendation, veremos a qu\u00e9 pod se enrutan las solicitudes. De este modo, podemos localizar f\u00e1cilmente los retardos en el nivel de un pod espec\u00edfico. Hay que prestar atenci\u00f3n al campo node_id:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/474da66c581692cd11070a1732ac5458.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>A d\u00f3nde y c\u00f3mo va todo<\/h3>\n<p>\nAhora pasemos a la interfaz de Prometheus y, como era de esperar, vemos que las solicitudes entre la segunda y la primera versi\u00f3n del servicio recommendation se dividen en una proporci\u00f3n de 2:1, estrictamente seg\u00fan la cantidad de pods en funcionamiento. Adem\u00e1s, este gr\u00e1fico cambiar\u00e1 din\u00e1micamente al escalar los pods hacia arriba o hacia abajo, lo que ser\u00e1 especialmente \u00fatil en un Canary Deployment (discutiremos este tipo de despliegue en m\u00e1s detalle la pr\u00f3xima vez).<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/c080fffd2398b0a2eac3e63665bdb0a7.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>Todo apenas comienza<\/h3>\n<p>\nEn realidad, hoy hemos apenas tocado la vasta fuente de informaci\u00f3n sobre Jaeger, Grafana y Prometheus. Esa era nuestra intenci\u00f3n: guiarte en la direcci\u00f3n correcta y mostrarte las perspectivas de Istio.<\/p>\n<p>Y recuerda, todo esto ya est\u00e1 integrado en Istio. Al usar ciertos lenguajes de programaci\u00f3n (como Java) y frameworks (como Spring Boot), se puede implementar todo esto sin modificar el c\u00f3digo de las aplicaciones. S\u00ed, necesitar\u00e1s hacer algunas modificaciones si utilizas otros lenguajes, principalmente Node.js o C#. Pero dado que la trazabilidad es uno de los requisitos esenciales para construir sistemas en la nube robustos, de cualquier manera tendr\u00e1s que ajustar el c\u00f3digo, ya tengas Istio o no. As\u00ed que, \u00bfpor qu\u00e9 no dedicar tus esfuerzos de manera m\u00e1s efectiva?<\/p>\n<p>Al menos para poder responder siempre a las preguntas \"\u00bfd\u00f3nde?\" y \"\u00bfqu\u00e9 tan r\u00e1pido?\" con un 100% de certeza.<\/p>\n<h3>Ingenier\u00eda de caos en Istio: as\u00ed fue dise\u00f1ado.<\/h3>\n<p><\/p>\n<h3>Saber romper cosas ayuda a que no se rompan.<\/h3>\n<p>\nLas pruebas de software son no solo complicadas, sino tambi\u00e9n importantes. Al mismo tiempo, las pruebas de correcci\u00f3n (por ejemplo, verificar si una funci\u00f3n devuelve el resultado correcto) son una cosa, mientras que las pruebas en condiciones de red poco confiables son un desaf\u00edo completamente diferente (a menudo se asume que la red siempre funciona sin falla, y este es el primer mito de los ocho en relaci\u00f3n con la computaci\u00f3n distribuida). Una de las dificultades para abordar este problema es c\u00f3mo simular fallas en el sistema o introducirlas de manera intencionada mediante lo que se conoce como inyecci\u00f3n de fallas. Esto puede hacerse modificando el c\u00f3digo fuente de la aplicaci\u00f3n. Pero entonces estar\u00e1s probando no tu c\u00f3digo original, sino una versi\u00f3n que simula fallas. Como resultado, corres el riesgo de caer en los peligros de la inyecci\u00f3n de fallas y enfrentarte a los \"geisenbugs\" \u2014 fallas que desaparecen al intentar detectarlas.<\/p>\n<p>Ahora te mostraremos c\u00f3mo Istio ayuda a manejar estas complejidades de manera r\u00e1pida.<\/p>\n<h3>As\u00ed es como se ve todo cuando funciona perfectamente.<\/h3>\n<p>\nConsideremos el siguiente escenario: tenemos dos pods para nuestro microservicio de recomendaciones, que tomamos del tutorial de Istio. Un pod est\u00e1 etiquetado como v1 y el otro como v2. Como podemos ver, todo funciona perfectamente.<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/c50387b7cfd12298cfab8123f13b2ca4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n(Por cierto, el n\u00famero de la derecha es simplemente un contador de llamadas para cada pod.)<\/p>\n<p>Pero no necesitamos eso, \u00bfverdad? Bien, intentemos romper todo sin tocar el c\u00f3digo fuente.<\/p>\n<h3>Causamos interrupciones en el microservicio<\/h3>\n<p>\nA continuaci\u00f3n se muestra el archivo yaml para la regla de enrutamiento de Istio, que fallar\u00e1 en la mitad de los casos (error) <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/es\/server\/dts-los-angeles\/\"   title=\"servidores\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"3597\">servidores<\/a> 503):<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/8fb3ed7f16ed7fd1a57b27dfc3bfd2da.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTenga en cuenta que especificamos claramente que en la mitad de los casos debe devolverse un error 503.<\/p>\n<p>As\u00ed es como se ver\u00e1 una captura de pantalla del comando curl ejecut\u00e1ndose en un ciclo despu\u00e9s de activar esta regla para simular fallos. Como se puede ver, la mitad de las solicitudes devuelven un error 503, independientemente de a qu\u00e9 pod \u2013 v1 o v2 \u2013 se env\u00eden:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/3d9760cf5abc7480ad3aab826c274766.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nPara restaurar el funcionamiento normal, simplemente elimine esta regla, en nuestro caso con el comando istioctl delete routerule recommendation-503 -n tutorial. Aqu\u00ed, Tutorial es el nombre del proyecto Red Hat OpenShift en el que se desarrolla nuestro tutorial de Istio.<\/p>\n<h3>Introducimos retrasos artificiales<\/h3>\n<p>\nLos errores 503 artificiales ayudan a probar el sistema en cuanto a su resistencia a fallos, pero la capacidad de prever y manejar los retrasos debe impresionarle a\u00fan m\u00e1s. De hecho, los retrasos en la vida real ocurren con m\u00e1s frecuencia que los fallos. Un microservicio que funciona lentamente es un veneno del cual sufre todo el sistema. Con Istio se puede probar el c\u00f3digo relacionado con el manejo de retrasos sin necesidad de modificarlo. Para empezar, mostraremos c\u00f3mo hacerlo en el caso de retrasos de red introducidos artificialmente.<\/p>\n<p>Tenga en cuenta que despu\u00e9s de dicha prueba, es posible que necesite (o desee) ajustar su c\u00f3digo. La buena noticia aqu\u00ed es que, en este caso, actuar\u00e1 de manera proactiva en lugar de reactiva. As\u00ed es como debe construirse el ciclo de desarrollo: codificaci\u00f3n-pruebas-retroalimentaci\u00f3n-codificaci\u00f3n-pruebas\u2026<\/p>\n<p>As\u00ed es como se ve la regla, que\u2026 Aunque, \u00bfsabe qu\u00e9? Istio es tan simple, y este archivo yaml es tan comprensible, que todo en este ejemplo habla por s\u00ed mismo, solo observe:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/e077e891cbccc66ebc4d4c7b67a0f1ec.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEn la mitad de los casos, experimentaremos un retraso de 7 segundos. Y esto no es lo mismo que si hubi\u00e9ramos insertado un comando sleep en el c\u00f3digo fuente, ya que Istio realmente retrasa la solicitud por 7 segundos. Dado que Istio admite el rastreo de Jaeger, este retraso se observa claramente en la interfaz de usuario de Jaeger, como se muestra en la captura de pantalla a continuaci\u00f3n. Presta atenci\u00f3n a la larga solicitud en la esquina superior derecha del gr\u00e1fico: su duraci\u00f3n es de 7.02 segundos:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/97a7b33fb7e0455973c7fd1b2aefadf3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEste escenario permite probar el c\u00f3digo en condiciones de retrasos en la red. Y est\u00e1 claro que, al eliminar esta regla, eliminaremos el retraso artificial. Lo repetimos, pero nuevamente hicimos todo esto sin tocar el c\u00f3digo fuente.<\/p>\n<h3>No rendirse ni ceder<\/h3>\n<p>\nOtra funci\u00f3n \u00fatil para la ingenier\u00eda del caos en Istio es la reintento de consultas a un servicio un n\u00famero determinado de veces. La idea aqu\u00ed es no dejar de intentar cuando la primera solicitud termina con un error 503 \u2013 y as\u00ed, tal vez en el intento N, tengamos suerte. Puede ser que el servicio simplemente se haya ca\u00eddo temporalmente por alguna raz\u00f3n. S\u00ed, esa raz\u00f3n debe ser investigada y solucionada. Pero eso es despu\u00e9s; por ahora, intentemos que el sistema siga funcionando.<\/p>\n<p>As\u00ed que queremos que el servicio ocasionalmente emita un error 503, y que Istio despu\u00e9s intente comunicarse nuevamente. Y aqu\u00ed claramente necesitamos una manera de generar un error 503 sin tocar el c\u00f3digo mismo...<\/p>\n<p>\u00a1Espera, espera! \u00a1Acabamos de hacer esto!<\/p>\n<p>Este archivo har\u00e1 que el servicio recommendation-v2 ocasionalmente emita un error 503:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/f446528f9c968e40cc2cf318cf0acde9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEs evidente que algunas solicitudes fallar\u00e1n:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/f998513746604beda241b8d6de2ed727.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAhora activemos la funci\u00f3n Retry de Istio:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/32e210b6ecbf4c1ecf121ee73e64ba35.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEsta regla de enrutamiento realiza tres reintentos con un intervalo de dos segundos y deber\u00eda reducir (y en ideal, eliminar del radar) los errores 503:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/7f9711c52949072b823399e59141cb64.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEn resumen: hemos hecho que Istio, por un lado, genere un error 503 para la mitad de las solicitudes. Y por otro lado, el mismo Istio realiza tres intentos de volver a conectarse al servicio en caso de un error 503. Como resultado, todo funciona simplemente de maravilla. As\u00ed, utilizando la funci\u00f3n Retry, cumplimos nuestra promesa de no rendirnos ni ceder.<\/p>\n<p>Y s\u00ed, lo hicimos nuevamente, sin tocar en absoluto el c\u00f3digo. Todo lo que necesit\u00e1bamos eran dos reglas de enrutamiento de Istio:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/c21a1cfd2d78ae4145a57d1cefcc6c59.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>C\u00f3mo no decepcionar al usuario o siete no esperan<\/h3>\n<p>\nAhora invirtamos la situaci\u00f3n y consideremos un escenario en el que no retroceder y no rendirse vale la pena solo durante un tiempo fijo. Luego, simplemente debemos dejar de intentar procesar la solicitud para no hacer esperar a todos a un servicio que causa retrasos. En otras palabras, no defenderemos una posici\u00f3n perdida, sino que retrocederemos a una l\u00ednea de seguridad para no decepcionar al usuario del sitio y no forzarlo a permanecer en la incertidumbre.<\/p>\n<p>En Istio se puede establecer un tiempo de espera para la ejecuci\u00f3n de la solicitud. Si el servicio supera este tiempo de espera, devuelve un error 504 (Gateway Timeout), y todo esto se realiza a trav\u00e9s de la configuraci\u00f3n de Istio. Pero tendremos que a\u00f1adir en el c\u00f3digo fuente del servicio un comando sleep (y luego, por supuesto, realizar un rebuild y redeploy) para simular el funcionamiento lento del servicio. Lamentablemente, de otra manera no se puede hacer.<\/p>\n<p>As\u00ed que hemos insertado un sleep de tres segundos en el c\u00f3digo del servicio recommendation v2, hemos reconstruido la imagen correspondiente y hemos hecho el redeploy del contenedor, y ahora a\u00f1adiremos un tiempo de espera mediante la siguiente regla de enrutamiento de Istio:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/c03fc452b98dd875a8a7d3ac561893ca.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEn la imagen de arriba se puede ver que dejamos de intentar comunicarnos con el servicio recommendation si no recibimos respuesta en un segundo, es decir, incluso antes de que ocurra el error 504. Despu\u00e9s de aplicar esta regla de enrutamiento (y a\u00f1adir el sleep de tres segundos en el c\u00f3digo del servicio recommendation:v2), obtendremos lo siguiente:<\/p>\n<p><img decoding=\"async\" alt=\"Trazado y monitoreo en Istio: microservicios y el principio de incertidumbre\" src=\"\/wp-content\/uploads\/2020\/01\/ed6e80052c67254718b1fde2bd873e71.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nUna vez m\u00e1s, repetimos, pero el tiempo de espera se puede establecer sin tocar el c\u00f3digo fuente. Un beneficio adicional aqu\u00ed es que ahora puedes modificar tu c\u00f3digo para que responda al tiempo de espera y probar f\u00e1cilmente estas mejoras con Istio.<\/p>\n<h3>Y ahora todo junto<\/h3>\n<p>\nIntroducir un poco de caos con Istio es una excelente manera de probar tu c\u00f3digo y la robustez de tu sistema en general. Los patrones de fallback, bulkhead y circuit breaker, los mecanismos para crear fallos y retrasos artificiales, as\u00ed como los reintentos y los tiempos de espera, ser\u00e1n muy \u00fatiles en la creaci\u00f3n de sistemas en la nube resistentes a fallos. Combinados con Kubernetes y Red Hat OpenShift, estas herramientas ayudar\u00e1n a enfrentar el futuro con confianza.<br \/>\n<br \/>Fuente: <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.2 - 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\/es\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\/es\/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\udd47Trazabilidad y monitoreo en Istio: microservicios y principio de incertidumbre | ProHoster","description":"El principio de incertidumbre de Heisenberg establece que no se puede medir simult\u00e1neamente la posici\u00f3n de un objeto y su velocidad. Si el objeto est\u00e1 en movimiento, no tiene una ubicaci\u00f3n espec\u00edfica.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/trassirovka-i-monitoring-v-istio-mikroservisy-i-printsip-neopredelennosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/55700","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=55700"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/55700\/revisions"}],"predecessor-version":[{"id":162124,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/55700\/revisions\/162124"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=55700"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=55700"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=55700"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}