sistemas de monitorización para aplicaciones Cloud Native”. Espero poder aportarte los conocimientos mínimos y necesarios con este curso para que puedas ponerlo en práctica. Jose María Flores Zazo, autor
que vamos a ver en este curso con una sola palabra sería: Cluedo. Las aplicaciones de hoy en día están compuestas de muchos elementos, más, muchos más, cuando se trata de aplicaciones 100% nativas en la nube. Encontrar un problema puede convertirse en algo complejo y exasperante. Imagina que tu aplicación falla y dejas sin servicio a cientos o miles de usuarios. ¿Cómo resuelve el problema? Con las mismas técnicas que usan los detectives, por ejemplo, si has leído a Sherlock Holmes: fijándote en los detalles, a través de la lógica, con deducciones y con herramientas. La intención es ir un paso más más allá; la anterior explicación del detective es ser reactivo. Además de las técnicas de análisis forense, vamos a aprender cómo usar técnicas para ser proactivos y evitar o más bien minimizar cualquier situación crítica. En este curso os enseñaré la terminología y los conceptos relacionados con la monitorización, usando herramientas de codigo abierto y como aquellas disponibles en Azure. Gracias a este conocimiento generarás la confianza suficiente para el trabajo diario de la aplicación y que Operaciones puedan responder rápidamente a las eventualidades de tu marco de trabajo DevOps. Cluedo – Juego de misterios y detectives publicado en 1948 y creado por Anthony Pratt
las migraciones a la nube han provocado una transformación digital muy importante en el mundo del IT. Estos cambios han afectado a dos campos fundamentalmente: ▪ El desarrollo de aplicaciones. ▪ La infraestructura. Los cambios han remodelado la forma en la que interactuamos, por ejemplo, los pagos electrónicos, hogares inteligentes, contenido bajo demanda, IoT, etc. Esta transformación digital, esta generando millones de transacciones por segundo de forma concurrente que deben se lo suficientemente estables y confiables para mantener este avance de los sistemas que los soportan. Dos cambios fundamentales han impactado en el desarrollo he implementación del software: la llegada de los microservicios y contenedores. Sin ellos esa remodelación no habría tenido lugar. Estos paradigmas han introducido terminologías, técnicas, roles, herramientas, etc. Que veremos a continuación, además hablare de como esta modernización a influido en la monitorización tradicional, y aunque no uses microservicios o contenedores puedas aprovechar todo el conocimiento para tus monolitos o como quiera que se llame la arquitectura de tu aplicación. Transformación – La transformación digital y la nube han cambiado es escenario de IT
escuchar este concepto una y otra vez, si esa sí, salta esta subsección, no te aportaré nada nuevo. En caso contrario, si no lo conoces o necesitas un refresco, continúa leyendo esta subsección. Tradicionalmente las aplicaciones han estado separadas en 3 niveles: interfaces graficas (web), logica (aplicación de backend) y base de datos (almacenamiento). Para cambiar una arreglar un error o introducir una nueva funcionalidad, el codigo por completo debe volverse a desplegar. Esto generalmente provoca una inactividad temporal si el código se rompe en producción con el consiguiente esfuerzo titánico de los equipos de desarrollo para tener lo antes posible el producto en producción. El esfuerzo va desde localizar/añadir el cambio hasta el despliegue, que en numero reales he visto tardar hasta 36 horas. Esto provoca retrasos y por tanto dinero para la empresa. La anterior filosofía creó un estándar de roll-up de facto en la industria de 6 meses para grandes despliegues. Como resultado directo de la transformación, las empresas necesitan ciclos mas cortos de lanzamiento, lo que significa que nuevas funcionalidades y correcciones deben estar inmediatamente disponibles. Ya sea por requerimientos del usuario o por necesidades de mercado (actualmente es muy dinámico). Para acelerar el ciclo de lanzamiento, es obvio que el codigo de la aplicación monolítica se separe en fragmentos más pequeños que puedan trabajar entre ellos. Es decir, las funcionalidades de la aplicación se dividen en diferentes servicios independiente llamados microservicios. Microservices – Frente a Monolito
añadir un nuevo método de pago en un monolito debemos desplegar todo y provocar una inactividad temporal: perdida de dinero e insatisfacción por parte de los usuarios. Sin embargo, en microservicios, solamente tocamos la pieza de los pagos y si esta muy atomizado, dentro de los pagos una pequeña parte del servicio: los usuarios continúan comprando por los medios habituales y no existe parada del servicio. Los microservicios son un enfoque que desgrana la aplicación en un conjunto de servicios desplegados de forma independiente y débilmente acoplados (este concepto os lo explico mejor en mi otro curso de Clean Architecture), muchas veces desarrollados por equipos completamente independientes. Esto ayuda a que se entregue valor muy rápida y frecuentemente. Muchas empresas suelen entregar valor varias veces al día. Entiéndase valor como: nuevas funcionalidades y errores que hacen que el Product Owner (PO) vea beneficios continuamente. Es decir, que el PO rápidamente esta proporcionando respuesta a su audiencia y, por tanto, generar más ingresos o responder más rápido a las inquietudes de sus clientes (esto incide en la retención de los mismo).
has escuchado muchas veces y sabes perfectamente que son los contenedores. Con total libertad puedes pasar a la siguiente subsección. Los contenedores proporcionan una capa de abstracción que nos permite desarrollar, desplegar y ejecutar aplicaciones bajo unos mismos recursos que aíslan el producto. Es decir , que podemos empaqueta la aplicación junto a las runtime, librerías, binarios, configuración, etc. Proporcionado a los desarrolladores un enfoque en el negocio sin pesar tanto en las dependencias del entorno donde se despliega el codigo. A continuación, la diferencia entre una maquina virtual y un contenedor: Fuente de la imagen: https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/containers-vs-vm Containers – Entorno aislado Container VM
y aislamiento, los contenedores se parecen mucho a las VM; sin embargo, a diferencia de las VM, en un contenedor se empaqueta lo necesario, los elementos esenciales para que se ejecute y no con todo le sistema operativo, por ejemplo. Hoy en día cada vez más somos los desarrolladores que consumimos contendores basados en la nube, ya sean privados o públicos, tanto para probar como para implementar aplicaciones. Esto a dado lugar a un conceto Cloud Native (nativo de la nube), que es un termino que abarca de forma amplia los entornos que se ejecutan de forma nativa en la nube. Según la CNCF (Cloud Native Computing Foundation): Las tecnologías nativas de la nube permiten a las organizaciones crear y ejecutar aplicaciones escalables en entornos modernos y dinámicos, como nubes publicas, híbridas y privadas. Contenedores, más allá de servicios, microservicios, infraestructura inmutable y API declarativas ejemplifican este enfoque. Estas técnicas habilitan sistemas débilmente acoplados que son resistentes, manejables y observable. Combinados con una robusta automatización, permiten a los ingenieros realizar cambios de alto impacto con frecuencia y de manera predecible con un mínimo esfuerzo. Los contenedores llevan ya bastante tiempo con nosotros, pero han ganado fuerza y visibilidad con el cambio de arquitecturas, sobre todo con los microservicios. Hacer microservicios no exige tener contenedores.
economía familiar media: ▪ Un vehículo, un coche, debe ser tratado con cuidado y mimo, además obliga a un mantenimiento. Suele se unico en el ambiente familiar y aun que es remplazable, supone un gran desembolso economico. ▪ Un objeto de decoración del hogar del IKEA, se cuida, pero sin esmero ni miramientos. Son fácilmente reemplazables y el gasto economico es mínimo, apenas es un impacto en nuestra economía. El ejemplo no valdría, ya que ocurre todo lo contrarío con una pieza de Lladró. Es decir, si un sistema que no este basado en contenedores de nuestra organización no la tratamos como un vehículo, las consecuencias económicas son elevadas y la perdida puede ocasionar un impacto directo en la organización. Sin embargo, los contenedores los cuales pueden ser destruidos cuando van mal y recrearlos en apenas minutos, es como un objeto del IKEA, no suponen apenas impacto economico no hace falta tratarlos como si fueran únicos. Esto incide directamente en el beneficio de una organización. Este ejemplo de contenedores es aplicable a las arquitecturas serverless. En un sistema pequeño manejar contenedores es una tarea sencilla pero cuando van creciendo debe entra en juego lo que se conoce como orquestadores, por ejemplo, veremos Kubernetes. Que ya he tratado en anteriores workshops de Microservicios y puedes ver en mi web: http//jmfloreszazo.com.
la modernización de aplicaciones que esta estrechamente relacionado con lo que he explicado de los microservicios, pero se contrapone a los contenedores. Digamos que esta breve explicación estaría a la altura del Contenedor. Modernizar con contenedores, no es tan nuevo, los contenedores existen desde hace tiempo; sin embargo, el concepto serverless no lleva tanto tiempo como los contenedores. Vienen a facilitarnos la vida a la hora de trabajar con microservicios, pero son igualmente validos para los monolitos, una Web App, por ejemplo. La diferencia es en esencia con la monitorización, usar tecnología Serverless depende mucho, aunque se puede obviar, con la nube en la que trabajamos. Habitualmente en los clientes en los que trabajo, cuando me piden que usar si contenedores o serverless, siempre les planteo la siguiente pregunta: ¿vas a querer migrar la nube en la que trabajas? La respuesta suele se si, lo quiero todo y por tanto no te queda más remedio que ir al contenedor, pero tienes que hacer ver al cliente que nunca, pasa como antiguamente con las bases de datos, terminará por dar el paso y migrar de una nube a otra, ten cuidado con este planteamiento ya que además de otros factores, la arquitectura de la monitorización sufrirá un impacto directo. Serverless – Sin servidor
estado de un sistema. Esto incluye un sistema de medición bien definido para poder verificar el comportamiento previsto y notificar rápidamente a las entidades involucradas de un comportamiento que se desvía del previsto. No ayuda a identificar comportamientos anómalos y a rectificarlos para evitar posibles problemas. El proceso de monitorizar tiene que ver mucho con las tecnicas que se utilizan en la estadística, concretamente con el muestreo. Se resume en recopilar, procesar, agregar y mostrar datos cuantitativos en tiempo real sobre un sistema. La monitorización es de vital importancia. Y nos ayuda a: ▪ Identificar el uso y capacidad de un ecosistema durante un período de tiempo. ▪ A tomar decisiones en base a unos datos históricos y adoptar decisiones a futuro. ▪ A rediseñar la arquitectura de una aplicación. ▪ A mejorar la calidad y disponibilidad del servicio, ya que nos permite descubrir de forma preventiva comportamientos anómalos antes de que se conviertan en problemas. ▪ Y la más importante, a tener una visión 360 del funcionamiento de un sistema. A grades rasgos: los sistemas emiten datos a intervalos de tiempo reculares de forma automática o cuando ocurre un evento. Aprovechando estos datos con la ayuda de un sistema de monitorización adecuado podemos: Monitoring – Monitorización
sistema. 2. Analizar y solucionar rápidamente un problema ya ocurrido. 3. Determinar la salud de nuestro ecosistema. Por tanto, capturar estos datos es de una importancia extrema para mantener el correcto funcionamiento de los sistemas y las aplicaciones. No perdamos de vista, que el caso de uso principal de la monitorización es identificar la fuente de un problema. Cuando ocurre un problema, y alguna pieza queda parada (si hablamos de microservicios) o todo el sistema (si estamos en un monolito). Debemos resolver el problema inmediatamente, no disponemos de mucho tiempo para arreglarlo. Debido a esta necesidad los sistemas de monitorización deben ser capaces de procesar y analizar en muy poco tiempo una ingente cantidad de datos complejos y presentarlos de forma eficiente para ser analizados. Una vez analizado, se podrá llegar al problema y arreglarlo. Las tecnicas de monitorización son variadas, están ligadas al procesamiento en tiempo real de los datos (ya se que no existe el tiempo real, pero podemos llegar a acercarnos) y al análisis de datos estadísticos. Esto conlleva a que la visualización (presentación) de los datos jueguen un papel importante, los datos procesados deben ser mostrados de manera significativa y legible para un operador (un humano). La estadística me enseño hace ya mucho tiempo, que existen muchas formas de interpretar los datos, esto nos brinda distintas perspectivas sobre un problema sobre un mismo conjunto de datos. Afortunadamente en este ámbito los datos no están sujetos a sesgos como ocurren en las ciencias sociales; en este caso nos basamos en una ciencia exacta.
siempre he tenido que pensar en como funcionaba una aplicación en producción, sin la necesidad de un equipo de operaciones. Era un producto y obligatoriamente tenía que tener en mente esto. Pero mi caso era una anécdota en el sector. Lo normal era escribir codigo sin preocuparse si funcionaba o no en producción, solo te preocupa tu máquina; y llegaba a operaciones sin ese requisito. El equipo de operaciones, que era responsable de que la aplicación funcionase, inevitablemente acusaba a los desarrolladores cuando cualquier cosa fallaba. Como bien sabéis DevOps surgió como una respuesta para resolver este conflicto entre silos y propuso un conjunto de prácticas para salvar esa brecha que existía entre dev y ops. Por tanto, DevOps es un skill y no un perfil como muchas veces vemos en el sector, ya sea gente que se llama a si mismo “ingeniero de DevOps” o cosas así de rimbombantes, no dejan de introducir una nueva brecha entre Dev y Ops, metiendo esa cuña llamada “ingeniero de DevOps”. Para más información puedes leer esta presentación sobre que es DevOps: http://jmfloreszazo.com/devops-es-cultura/ Imagen: Evolución de DevOps DevOps – La monitorización no solo se engloba en operaciones Devs pujan por poner nuevas funcionalidades Devs pujan por poner nuevas funcionalidades Ops pujan por la estabilidad del sistema Tira y afloja entre Devs y Ops. Por tanto, no es DevOps. Operaciones ayuda a los Devs a lanzar nuevas funcionalidades de forma confiable Devs y Ops trabajan mano a mano. Por tanto, estamos en DevOps.
DevOps y la metodología Agile en las empresas han surgido roles específicos. Reitero, ninguno con el epíteto DevOps. Hace tiempo Google creo el llamado Site Reliability Engineers (SREs), responsables de mantener el sistema en funcionamiento. Los SRE monitorean el sistema para que cumpla los Service-Level Objetive (SLOs), los objetivos del sistema: ▪ Proporcionada información sobre el comportamiento del sistema. ▪ Identificando tendencias de uso y rendimiento. ▪ Notificando y alertando sobre valores atípicos y anomalías. ▪ Diagnosticando problemas. Los SREs tiene la obligación de mantener la confiabilidad del sistema de producción y por tanto han de tener un conocimiento solido de lo servicios que se ejecutan y como han de monitorizarse. Un SRE es un modo de abordar la cultura DevOps, desde mi punto de vista los considero una implementación de DevOps. Ya que es un perfil dentro del equipo de desarrollo que tiene experiencia en operaciones y elimina los problemas de comunicación y flujo del trabajo. Por eso nunca deben considerarse “ingeniero/arquitecto de DevOps” o similares. Resumo los cinco pilares que diferencia DevOps entre SER que aparecen en el libro de Google y en este articulo:
desarrollador con unas responsabilidades diferentes. Con los puntos anteriores y si practicas AML verás que un SRE es una pieza totalmente prescindible, ya que los desarrolladores han de ser SREs en esencia, es un refinamiento más, y lo unico que hace es añadir ruido en una cultura donde se practica ALM. En caso contrario es una buena implementación de DevOps para llegar a un equipo ALM. Sobre personas y roles Monitorización(5/25) 5 Pilares del DevOps DevOps SREs Cultura colaborativa Focalizado en reducir silos entre el equipo de Dev y Ops Focalizado en trabajar junto a los devs para resolver un problema con sus mismas herramientas. Apoyo El sistema esta diseñados y pensados para para ser tolerante a fallos Unan diferentes mecanismos para implementar y equilibrar la disponibilidad ante fallos de cada nueva versión Mediciones Medir todo con instrumentos cuidadosamente definidos Definen diferentes formas de medir la disponibilidad, la actividad y las interrupciones Automatización Herramientas que reducen el trabajo manual Focalizado en añadir valor al sistema minimizando tareas manuales Cultura del cambio Pugna por cambios graduales en los procesos Fomenta el cambio para reducir el coste de los fallos
a https://sre.google/books/ y léete los 3 libros. A continuación, pongo 2 frases que resumen muy bien esta implementación, como apunte a todo lo anterior: ▪ SRE es lo que sucede cuando se pide a un ingeniero de software que diseñe un equipo de operaciones. ▪ Si piensa en DevOps como una interface de un lenguaje de programación, la clase SRE sería la implementación de DevOps. Veis por qué es más acertado que un desarrollador sea la figura de SRE y no alguien de infra o de operaciones. Y otra que sumo yo, por que analíticamente están acostumbrados a pensar en procesos y son capaces de sintetizar cualquier cosa (ver diagrama más adelante). Ahora entenderás la confusión entre un SRE y querer un “ingeniero” de DevOps (qué no existe). Esperemos que poco a poco puedas hacer proselitismo y que este concepto quede claro a reclutadores y personal de mayor nivel. Desde mi experiencia es un error muy grande usar esta implementación SRE de DevOps durante mucho tiempo. Una vez que el equipo se encuentre cómodo, tanto los SRE que vengan de Dev como los que vengan de Ops, han de volver a su antiguo puesto y diluir su responsabilidad en el equipo para que podamos hacer ALM y de este modo ser realmente un equipo de DevOps. Si no, corremos el riesgo de generar un nuevo silo.
impacta en como deben monitorizarse. Los diferentes roles de una organización son responsables de monitorizar diferentes áreas relacionadas con una aplicación y, por lo tanto, diseñan e instrumentan la monitorización para distintas prioridades. Podemos clasificarlas en: ▪ UI, por ejemplo, han de medir tiempo medio de respuesta de la carga de una página o porcentaje de fallos en el frontal. ▪ Aplicación, por ejemplo, tiempo de respuesta o ratio de fallo de una funcionalidad. ▪ Servicios, por ejemplo, porcentaje de tiempo que el servicio esta indisponible, tiempo medio de respuesta de una petición cuando el servicio esta al 90% de su capacidad, numero de repuestas por segundo. ▪ Contenedores, por ejemplo, uso de la CPU, memoria utilizada, paquetes perdidos. ▪ Infraestructura Cloud, por ejemplo, porcentaje de utilización de los recursos, franjas de tiempo en la que los recursos sufren picos. Dominios diferentes – Medidas diferentes En la vida real me han introducido en la parte de operaciones debido a mi experiencia en arquitectura de aplicaciones, para montar una monitorización de un gran sistema que carecía de el (no puedo decir el nombre pero muchos de ustedes tienen sus servicios contratados), en el cual reiteradamente pedí acceso a los Devs por que sin ellos las medidas de UI, Aplicación y Servicios Web solamente podía ser intuidas, la experiencia dicta mucho en este campo, pero se me escapaban que procesos eran críticos y cuales eran de consumo masivo para afinar la monitorización. Evidentemente la razón y grandísima experiencia del arquitecto jefe del producto vio que no era una petición gratuita, si no, una petición completamente lícita, y así poder monitorizar un sistema sin ninguna laguna.
de monitorización que desgranaremos a continuación, empecemos por la base. Infraestructura Cloud Los administradores Cloud, de sistemas y los equipos de operaciones, les interesa medir los recursos, ya sea CPU, memoria, red, almacenamiento, etc. Supervisan los patrones de utilización a lo largo del tiempo para determinar si lo recursos se infra o sobre utilizan. Tambien les interesa si el cambio de utilización es un comportamiento es algo esperado y en caso contrario, indagan a que puede deberse (por ejemplo, un uso inesperado del almacenamiento que se debe a una nueva implementación hace crecer ese almacenamiento). Además de esto, las tendencias de uso son indicadores de futuras demandas y pueden ayudar a determinar con antelación que se debe adquirir y los costes asociados. Contenedores Se debe garantizar la disponibilidad de los contenedores. Se debe monitorizar para buscar parámetros de uso específicos junto a los procesos que se ejecutan en ellos. Esta información puede ayudar a refinar el sistema con la introducción de colas, por ejemplo y garantizar que las solicitudes no bloquen un contenedor o escalando los mismos para que la ingesta sea mayor.
anterior son: numero promedio de mensajes encolados y tiempos del subproceso. El rendimiento de un contenedor no es un elemento aislado al servicio que ofrecen, también debe indagar sobre la infraestructura Cloud sobre la que se implementan. Servicios Como abstracción de una aplicación, supongamos que forma parte de un microservicio, que se ejecuta en contenedores, podemos explorar tanto la salud como el rendimiento interno del servicio. Una de las medidas habituales es ver la latencia de la aplicación o como se distribuyen las solicitudes o como se enrutan. Habitualmente los Service Meshes priorizan la información sobre la salud de un sistema que sobre el servicio en cuestión. Aplicación Aquí se nos preocupamos más sobe el tiempo de respuesta y la tasa de errores de un servicio o todos los servicios. Nos preocupamos más de como responde la base de datos, cuantas consultas por segundo admite, como ponemos con una consulta la memoria del sistema, etc. Esta información sirve para que los devs mejoren y optimicen la aplicación y refinen los procesos, como resultado siempre es una mejora en la experiencia de usuario.
desde la analítica web, que estudia el comportamiento de un usuario y nos permite conocer como ellos interactúan con la aplicación; hasta los errores que se producen en el frontal para que podamos refinar la interface y mejorar el flujo de uso de nuestra aplicación. O incluso nos sirve para focalizar donde debemos añadir funcionalidades y donde no, o incluso donde debemos instruir a los usuarios para que usen ciertas funcionalidades nuevas. En este caso las medidas son muy amplias y muchas de ellas a parte de errores que frustran al usuario son de carácter comercial, marketing, en resumen. KPIs (Key Perfomance Indicators) En estadística esto se conoce como indicadores. Antes éramos los devs quienes medíamos esto y poco o nada sabíamos del impacto comercial o negocio de la aplicación. Ahora es un proceso de retroalimentación muy efectivo que nos ayuda a emitir nuevas funcionalidades o mejorar otras. Como se trata de un tema comercial y de negocio, esta Metricas nos vendrán dadas y solo hemos de generar la información necesaria para que llegue al canal adecuado. Un ejemplo sería: ver cuantos usuarios con terminales móviles tenemos, si nuestra web no es reponsibe, un desarrollador o arquitecto puede levantar la mano y decir que tenemos más usuarios web que escritorio y sería bueno hacer la web responsibe, pero otras medidas como es mejorar un punto del proceso de compra es responsabilidad de marketing optimizarlo para enganchar al usuario, puede que un KPI no diga que en la pantalla de introducir el descuento muchos usuario termine la compra por que no es intuitivo.
que realiza comprobaciones básicas de la CPU, memoria, almacenamiento y parámetros similares para investigar anomalías de forma reactiva. Pero estas herramientas ampliamente extendidas, se han quedado obsoletas por más que se empeñen muchas compañías en extrapolar su uso en el Cloud. Solamente se centran en medir la disponibilidad y capacidades administrativas de los recursos de IT. Actualmente cualquier nube tiene su SLA y las herramientas adecuadas para alertarte sobre cualquier incidencia. Olvidemos que existen esas herramientas, son cosas del pasado y si te ves en la obligación de trabajar con ellas, intenta que tu nube sea el detonante que informe a estos servicios y no te obligues a añadir más ruido en una VM, por ejemplo, instalando el monitor de Nagios. Hablo desde la experiencia. Históricamente había muy pocas opciones tanto para la SLA como para medir la experiencia del usuario, el uso histórico era mantener encendida y activa la infraestructura y servicios de IT. Esto se conoce como monitorización pasiva se denomina monitorización reactiva y es gestionado únicamente por el equipo de operaciones. Ser reactivo obliga a preocuparse de los datos generados por la monitorización para informar de cualquier incidencia. Es decir, que gracias a los datos que se van generando podemos tomar decisiones, pero no brinda ni a Devs ni a Ops más información que la toma de una decisión. Si un recurso tiene la memoria al 90% obliga a infra a aumentar la máquina y a los devs a encontrar una optimización. Este tipo de medición desvincula mucho a Dev y a Ops, ya que solo proporcionan datos a los responsables de ese recurso ya sea servicio o infraestructura, en el mejor de los casos a ambos, pero no crea el vinculo DevOps. Reactivo vs Proactivo – Diferencias
Devs y Ops se hace mediante la proactividad, esto se logra automatizando e instrumentando la monitorización desde el inicio temprano del desarrollo de la aplicación, generando desde el minuto 0 información útil y medible. Esta filosofía coloca a la aplicación en el centro de la diana: mide el rendimiento de la aplicación y los resultados comerciales asociados en lugar de medir las cosas básicas que se suelen medir (CPU, memoria, etc.). Como parte del proceso de supervisión, los datos de rendimiento se recopilan y utilizan frecuentemente, se analizan y se toman decisiones. Ciclo infinito de DevOps. Ser proactivo con las mediciones al final genera una serie de paneles orientados al SLO de cada área: devs, ops, marketing, negocio, … bajo un seguimiento gestionado por un SRE o los mismos Devs u Ops. Según sea tu filosofía de adopción de DevOps, en un caso delegas en un responsable y en otro todos somos responsables (siempre habrá una o varias personas que se tomen más enserio la monitorización). Y hablo de responsables de informar, no de la toma de una decisión. Desde mi experiencia completar un User History, Feature, PBI o lo que uses en tu metodología debería tener en la definición de Done: incluir monitorización con el procedimiento operativo estándar, al igual que haces ya con los test de infra o de servicios, por ejemplo.
herramientas, procesarlas, almacenarla y visualizarla. Existen diferentes sistemas de monitorización, unos se llevan bien con K8s otros no, unos son Open Source otros no, unos se convierten gracia a su uso como un estándar de facto otro a pesar de ser muy buenos, no. Así con todo y recomendar unos u otros o decirte desde mi experiencia que pondría en que situación será un tema que tratemos en la Sección IV. De momento, una pequeña muestra y así me permitiré el desliz de mencionar alguna herramienta en las siguientes páginas. Podéis ver un gran listado de herramientas en: https://landscape.cncf.io/ Muchas herramientas – Herramientas para todo
de la monitorización, ahora veremos la necesidad de un sistema de monitorización. Y lo explicaré con unos casos de uso: Detección temprana de los problemas El objetivo de un sistema de monitorización es identificar rápidamente un problema. Es difícil cuando el entorno es tan dinámico como el que se plantea en el diseño de aplicaciones actual. Lo normal es intentar descubrir el motivo de una interrupción de servicio o un bug que impida continuar con el flujo habitual de la aplicación. En estos casos un buen sistema de monitorización nos ayuda identificar que recursos están afectados y notificar a las entidades relevantes para que investiguen y resuelvan la incidencia. Garantizar la disponibilidad Es un SLO importante y tratamos de reducir el tiempo de inactividad inmediatamente o en el menor tiempo posible o que gracias a la motorización, usando alertas y reacción automática de esa alerta seamos capaces de usar otros recursos para evitar esa interrupción. Si se configura adecuadamente en vez de ser reactivo podemos se proactivos y ante una previsión podemos ir preparando el entorno para que no se vea afectado. Necesidad – Antes vimos la importancia de monitorizar ahora la necesidad
de uso de unas monitorizaciones ayudar a los devs a mejorar el rendimiento de una aplicación. Esto solo se puede hacer cuando se visualizan las tendencias y patrones del rendimiento del área en estudio. Por ejemplo, si analizamos las request y responses de un servicio, podemos estudiar el lag de tiempo que se produce en ciertos momentos del día o durante promociones como el Black Friday. Medir el despliegue de una aplicación Podemos monitorizar proactivamente cualquier despliegue producido y observar si el numero de errores decrece o aumenta con una nueva Feature o Hotfix. Un sistema de monitorización nos garantiza datos objetivos sobre el éxito al arreglar un bug. Desde mi punto de vista, monitorizar no es un trabajo aislado, es un trabajo conjunto. Los beneficios de un sistema de monitorización son más altos cuanto más colaboren los equipos de forma conjunta, se intercambian entre ellos observaciones y tiene claramente asignada su área de responsabilidad. Que todos los equipos usen un único punto de referencia, un único sistema de monitorización con paneles que puedan leer todos, aumenta significativamente la eficacia de la monitorización y por tanto mitigar cualquier incidencia.
de monitorización debe tener las siguientes características: Datos agregados usando etiquetas Etiquetar los datos que se generan es básico para realizar una estadística. Tener etiquetados, enriquecidos los datos, hace que estos sean más fáciles de tratar y por tanto ayudar a los equipos a asumir la responsabilidad. En un sistema distribuido cobra más importancia que en uno en el que solo tenemos 1 solo servidor de APIs, por ejemplo. No soy partidario de la segregación SRE, como habréis intuido anteriormente, por tanto, no voy a decir que un SLO solo les interesa a ellos (razón de más para obviar este concepto), nos interesa a todos conocer la/s etiqueta/s que mide/n un SLO en un servicio unico o distribuido, de aquí importancia de etiquetar, ya que es una métrica que puede involucrar diversas piezas de nuestra arquitectura.. Recopilar todos los datos para medir todo Cuanta más información que podamos medir y recopilar, más relaciones podemos establecer entre los elementos involucrados. Si estamos mirando la latencia a un servicio en particular, es imperativo recopilar información de los contenedores, hardware, vías de comunicación, etc. Creamos una foto completa de la situación relacionando las piezas. En algunas ocasiones es necesario estudiarlo con datos antes y después de la incidencia para investigar si es algo subyacente o era debido a los datos. Un mínimo – Para cualquier sistema
arquitectura distribuida, los servicios están débilmente acoplados: los servicios tienen componentes que depende de otros servicios, habitualmente desarrollados, mantenidos y administrados por un equipo distinto. Por tanto, es imperativo que los equipos colaboren entre ellos para identificar y corregir la incidencia. Actualmente es muy sencillo usando herramientas colaborativas como Teams. Como veis cada vez tiene menos sentido hablar de un perfil SRE puro, debemos hacer ALM, hace 10 años puede (cuando Google describió este perfil) pero hoy en día con las metodologías Agile y los canales de comunicación existentes, poner una cuña entre Devs y Ops es una aproximación a DevOps completamente incoherente con la colaboración. Un perfil no hace colaborar 2 equipos si no coordinarlos. Espero que cada vez más comprendas la necesidad de eliminar esa figura y que todos los componentes del equipo diluyan ese rol en un skill más de su trabajo diario. Notificaciones automáticas Dispara alertas y notificaciones automáticas. Las reglas que establecemos para entornos estáticos son sencillas y a penas han de mantenerse, pero para entornos dinámicos es un trabajo constante y han de ajustarse de forma habitual. Gracias a las modernas herramientas de las que disponemos y a la IA podemos ir relajándonos en este trabajo que antes era un constante cambio y necesitaba constantemente nuestra atención. Solo han de ver la insistente característica que vende cualquier sistema de monitorización con IA: detención de anomalías.
nos permite agregar recursos de forma automática, bajo demanda. Debemos poder añadir de forma automática y simple cualquier recurso para que la telemetría no se pierda. Gracias a las herramientas actuales de monitorización, esto ya no suele ser un problema, de forma automática podemos poner esos recursos bajo el paraguas de nuestra monitorización. Lógicamente si tu sistema es antiguo y no puedes hacer esto, entenderás que es vital dedicar más esfuerzo y recursos a esta pieza que aquellos que están más modernizados.
y el ciclo de vida anteriormente descrito, podemos concluir: De forma tradicional monitorizar se restringía a sistemas individuales, como servidores de aplicaciones, servidores de bases de datos, etc. Los sistemas recolectaban básicamente información de disponibilidad, utilización y desempeño. Esto datos se enviaban a paneles de supervisión del entorno IT. Este tipo de vistas a veces no tenían ninguna relación y relacionar los datos eran meras conjeturas. Es decir, que se crearon para garantizar el SLA de IT: disponibilidad y reducción del tiempo de inactividad. El pasado era reactivo y centrado en problemas predecibles, los responsables de IT trataban de predecir lo que podía salir mal y monitorizaban esos aspectos; construían mecanismos para alertar de parámetros que podían ser rectificados rápidamente. Estos sistemas se construyeron asumiendo que siempre estaría todo disponible inactividad sería cuestión de un tiempo contenido volver a dar respuesta de esa interrupción. Los sistemas modernos son dinámicos y complejos. Están altamente distribuido, son efímeros y diseñados para soportar incidencias. Este cambio, subyacente, ha llevado a la creación e introducción de plataformas de orquestación que nos abstrae de algunas preocupaciones como el estado, corrección automática, autoescalado y equilibro de la carga, sí, estoy hablando de K8s, por ejemplo. Actualmente en vez de buscar comportamientos individuales, debemos centrarnos en la interconexión de los sistemas, comprender su interacción es vital, un problema puede venir disparado desde otro recurso y verse afectado otro. Esto nos obliga a tener una mejor visión del sistema para poder construir una sólida monitorización y a disponer de una serie de herramientas altamente especialidades que nos permitan poner en relación todas y cada una de las piezas del sistema.
que sondea los sistemas en busca de disponibilidad, esta pieza esta fuera del sistema. La anterior practica funciona siempre que exista un número finito de sistemas, pero cuando la cantidad comienza a crecer, obliga a que esta pieza centra se amplíe y crezca para satisfacer la demanda. Hacer crecer este sistema obliga a dos cosas: pasar un tiempo solicitando recursos y otro rediseñando si ya no es capad de aguantar la demanda, por tanto, es un sistema nada o poco reactivo. Y hace que Operaciones se dedique más a administrar sistemas de monitorización que administrar las aplicaciones críticas de negocio y la infraestructura subyacente, objetivo principal de Ops. En la actualidad, la mayoría de los sistemas de supervisión se basan en sondear y extraer. Es decir, que muchos sistemas usan la metodología Pull que adolece de lo anteriormente descrito. Sin embargo, hacer Push, tener una metodología que “impulsa”, logra que cuantos más servicios agregues y más necesidad de escalado necesites, sean los componentes quienes envíen esa información a la herramienta de recopilación. Es decir que tenemos un patrón de emisión y que la supervisión deja de ser un monolito. Push vs Pull – No estamos en un contexto de Git
de transporte de información a su elección y no se ven obligados a usar lo que obligatoriamente utilice la herramienta de monitoreo. Estos datos que se emiten y se ponen a disposición en cuanto se generan a la herramienta de monitorización, nos permite construir soluciones aisladas y modulares. En resumidas cuentas, se trata de una arquitectura de atraer (pull) primero se configura y se establece que supervisar y en una metodología de empujar (push) primero se emite la información y luego se configura que se quiere leer. Esta aproximación es dinámica frente a una estática. Por tanto, cada pieza del servicio es capad de emitir que, cuando, cuanto y a donde se envia la información.
en el SLA, es decir: disponibilidad y tiempo de inactividad. Las alertas se centran en disponibilidades específicas, por ejemplo, que un servidor web deja de funcionar. Resolver esta incidencia es más sencillo que encontrar por qué han aumentado los errores HTTP 500 de forma sistema en un 10%. Centrarse en el SLA en lugar de la calidad y servicio, convierten a IT en meros activos de administración y por tanto dejan de medirse cosas como la calidad y rendimiento. Debemos revertir esta filosofía. Los datos de rendimiento y calidad de un servicio son cruciales tanto para los equipos tecnológicos como comerciales, Un sistema push son los adecuados para medir un SLO y poder sacar información contextual y de desempeño de los componentes. Que una pieza distribuya su información permite que se pueda enviar mucha y sea facil administrarla. Esta información, lo deseable es que sea mucha, permite ser más preciso y nos permite responder rápidamente a muchas preguntas sobre calidad del servicio, rendimiento, disponibilidad, etc. Y lo que para mi es más importante, permite refactorizar y escalar un sistema de monitorización, en un momento de crisis podemos trabajar de forma dinámica sin influir en otras piezas del un modelo y arquitectura de medición, incidiendo directamente en el beneficio del producto. Por eso hago hincapié en este ultimo párrafo, el cual es muchas veces quien ayuda a vender un cambio de arquitectura de monolito a microservicios.
en la vida diaria y la monitorización es un campo donde la IA es un aliado natural. DevOps se puede aprovechar de la IA y concretamente del ML para identificar, prevenir y responder a problemas de forma más rápida y precisa. Usar IA y ML para analizar datos generados por el sistema para predecir posibles problemas, determinar las causas y automatizar las soluciones, no es ciencia ficción, podéis ver Azure Sentinel que nos ayuda con temas de seguridad: que un usuario se conecte al mismo tiempo desde 2 IPs diferentes, esto es monitorizar. Como ayuda la IA: ▪ Ayuda a eliminar ruido y priorizar las alertas. En resumen, clasificación automática. ▪ Detectar de forma proactiva problemas antes de que lleguen a producción. ▪ Alertar y escalar al área al que pertenece el problema. En resumen, gestión eficiente de los recursos. ▪ Y por qué no, dar soluciones automáticas de las incidencias, mejorando notablemente el tiempo medio de resolución (MTTR, mean time to resolution). Un nuevo jugador – Una evolución natural
contenedores como si trabajas con microservicios, no existe una bala de plata que nos diga estas herramientas son las que te ayudarán, estas métricas son las que te ayudaran y monta esta IA por qué con ella el X % de tu trabajo ser verá solucionado. No, no existe, aunque si existen herramientas que pueden usarse tanto para microservicios como para contenedores, pero no usar los sistemas más adecuados por usar un hibrido, lograrán que tu sistema cumpla la excelencia. Tendrás que usar el “depende” para ver que quieres montar y cómo. Y hablando de hibrido, lo mismo ocurre cuando mezclas nubes, o usas nube hibrida o usas on-premise. Existe herramientas que puede aprender y usar como un estándar de facto, pero ni de lejos esas herramientas son las más eficientes. Otra vez depende. Como estamos muy sujetos a “depende” y creo que está intrínsecamente ligado a herramientas y métricas, es mejor ver cada área de forma separada y luego que decidas tu si es bueno centrarse en un estándar de herramientas de facto o usar las dedicas a cada sistema. Así como que métricas son las más adecuadas para una u otra arquitectura. Como os decía no existe una bala de plata. No existe una bala de plata – Nada es perfecto
clientes directo, redes sociales, ... Inspeccionar Alerta o queja Declarar incidente Calificar como incidente Comienza el proceso de mitigación de la incidencia Analizar la fuente original No se clasifica como incidente (focalizar estudio en el por qué se origina una alerta o una queja) Focalizar en prevención a futuro Incidente resuelto Analizar la fuente original
hoy día, el simple hecho de monitorizar los problemas conocidos no resuelve el numero creciente de nuevos problemas que surgen a medida que los servicios escalan para satisfacer la demanda. Es muy difícil determinar desde el principio qué puede ir mal. En la mayoría de los escenarios, las herramientas estándar no son los suficientemente buenas como para iniciar un análisis. Operaciones han ido cambian el enfoque a medida que las aplicaciones actuales han ido ganando en complejidad. Ese enfoque se llama: observar, que no es más que un concepto que se centra en interpretar el funcionamiento interno de un sistema a partir de los parámetros externos disponibles de un sistema. Se podría definir como un mecanismo para recopilar toda la información del sistema, instrumentándola para obtener datos detallados con el fin de reconstruir una imagen completa del estado interno del sistema a tiempo real. Los datos que se obtienen están contextualizados y enriquecidos. Por tanto, nos ayuda a visibilizar los fallos y depurarlos. Por extensión esa relación entre datos y observación nos ayuda a responder a un conjunto de preguntas que no se formularon cuando se implementó el sistema. Observar – Guardar y cumplir exactamente lo que se manda y ordena. Advertir, reparar, atisbar
de observación: ▪ Identificar el desempeño de una aplicación con relación a un base-line. ▪ Restaurar el rendimiento de referencia en el caso de existir un problema que afecte al sistema. Cuando se logra un base-line, un rendimiento de referencia, los desarrolladores siempre queremos mejorarlo para aumentar la satisfacción del cliente. Cuando comenzamos a ver incoherencias en el sistema, ya sean errores, sobrecargas, falta de agilidad en las respuestas, queremos poder volver a estabilizar el sistema para provocar insatisfacción en los clientes. La Observabilidad consiste en generar un conjunto útil de información que es necesaria durante la depuración del sistema en producción. Actualmente no podemos resolver los problemas de un sistema de forma 100% automática, la observación es la única opción actual que nos ayuda a reducir y prevenir los problemas de un sistema.
y las trazas son los tres pilares de la Observabilidad. Combinar estos elementos es la forma que la observabilidad aborda el desafío de la monitorización de aplicaciones. Las Metricas es el pilar fundamental de la observabilidad, ya que es fácil de recopilar y las mas baratas de almacenar. Las métricas son valores numéricos y por tanto fáciles de analizar. Se pueden etiquetar para generar dimensiones o agregar para generar atributos. Son fáciles de dimensionar, mostrar e interpretar. Existen varias formas de recopilar métricas, entre la que destacan la instrumentación del código para recopilarlas o via agente para recopilar métricas de infraestructura. Herramientas para este menester son muchas: Prometheus, Insight, Telegraf, … ya las trataremos más adelante. Habitualmente las métricas se recopilan regularmente en el tiempo (1 minuto, 5 minutos, 10, etc.) y a estas se les de denominan métricas. En contraposición a los eventos que son aquellos que se recuperan en intervalos de tiempo irregulares (2, 3, 9, 17 minutos). Los Eventos son un pilar muy importante, pero generalmente están se combinan con las métricas. Tres pilares – Metricas, logs y trazas
en una estrategia de observabilidad, que no sea uno de los tres pilares, no indica que sean menos importante. La diferencia entre métrica y evento es como hemos dicho el tiempo de recopilación: regular o irregular. Los eventos generalmente se producen para registrar ocurrencias significativas y en si mismo pueden ser indicadores con mucha información. Es decir, pueden ser activaciones de alertas, aletas que avisan sobre una finalización infructuosa de una transacción, cosas que no se producen de forma regular, que avisan cuando ocurren. Los eventos contienen metadatos que enriquecen el contexto y nos brinca la capacidad de analizar en tiempo real. Los logs (registros) son diarios detallados de todo lo que sucede dentro en un sistema en modo texto y guardado de forma estructurada. Son cruciales para realizar un análisis. Nos ayudan a revisar todo lo que sucede con anterioridad a la falla. Como estos ficheros contienen mucha información detallada son vitales a la hora ver que a sucedido. Los registros se imprimen o almacenan a medida que ocurren los eventos y evidentemente se usan para análisis futuros. Nos ayudan en análisis forense. A la hora de guardar la información podemos usar esquemas estándar (habitualmente los servidores web como IIS o Apache) o ad-hoc definidos por la aplicación.
métricas también disponemos de herramientas para los logs: como log4net o sus variantes como log4j, Serilog, Nlog, etc. Las trazas (o seguimientos), nos ayudan a comprender la latencia en sistemas distribuidos, la latencia entre transacciones. No es más que combinar las transacciones de un recurso bajo una logica que generan un rastreo, este nos da una idea del recorrido de la información y el viaje que ha tenido entre recursos, servicios, etc. De un sistema distribuido. Por ejemplo, una traza es una fuente importante para localizar un cuello de botella que nos permitirá optimizar el servicio. Estos tres pilares esta interconectados y nos ayudan a resolver problemas usando uno o más de ellos. La observabilidad requiere que funcionen como un todo ya que nos ayudará a que nuestro sistema se comporte como deseamos. Por ejemplo, una métrica nos puede llevar a un elemento en concreto via una traza y dentro de ese recurso indagar dentro de los logs de registro. Cuando hemos resuelto un problema por la via anterior, siempre podemos añadir nuevas métricas que ataquen al problema que hemos resuelto, de esta forma trabajamos de forma proactiva y regresiva.
clasificaría la monitorización en 2 tipos, que pongo ahora y no antes por qué voy a centrarme en la forma: Black De caja negra aquél que se basa en probar el comportamiento visible según la perspectiva del usuario. No implica ningún detalle técnico. Se basa estrictamente en probar como un consumidor final. Y ampliamente usado de forma reactiva, es decir, tras la ocurrencia de un incidente. A la causa. White De caja blanca aquél que se basa en las Metricas de monitorización. Esa orientado a los síntomas y no tanto a las causas. Como bien he explicado antes y en el que nos hemos centrado, nos permite predecir ya que se basa en los 3 puntos estándar de la observación: métricas, logs y trazas. Black & White – Tipos de monitorización
lleva una gran carga de estadística descriptiva y aunque desarrolle partes para que esta sección no quede coja, alguien que quiera dedicarse a esto no debe ser alguien exclusivamente de Data por que nunca sabrá que es lo que se está midiendo sin un apoyo de desarrollo, infraestructura y operaciones. Vuelvo a hacer hincapié en ALM. Las métricas son la representación numérica de los datos recopilados de monitorización en un momento dado. Una secuencia de métricas recopiladas a intervalos regulares durante un periodo de tiempo puede proporcionar información muy significativa de un sistema. Las métricas al ser una medida dinámica nos brindan información en tiempo real del sistema que estamos monitorizando. Los datos numéricos se pueden recopilar, procesar, almacenar y recuperar fácilmente, por tanto, las métricas nos permiten cocinar esos datos para distintas acciones: análisis de tendencias, detectar anomalías, análisis de patrones, actuar de forma proactiva, etc. Antes de que se produzca una falla que provoque una interrupción real del sistema. Cada métrica consta de una medición llamada valor de datos, una marca de tiempo en la que se registro la medición y un conjunto de etiquetas que la describen. Con esta información podemos crear agregados a lo largo del tiempo que nos ayuda gracias aun gráfico bidimensional, por ejemplo, a estudiar y encontrar significación a los datos bajo el contexto de las etiquetas, es decir, llegar a conclusiones. Una definición más formal – O al menos un intento de ello
de un parámetro en particular y su correspondiente valor. La recopilación de estas observaciones puntuales cuando se espacian en el tiempo se denomina serie temporal. Nos ayuda a identificar un valor atípico en la serie de observaciones y también a comprender la razón subyacente de este valor atípico. Dado que los datos de una serie temporal son esencialmente numéricos (cuantitativos, los cualitativos deberías transformarlos para representarlos) debemos elaborar un análisis estadístico y un pronostico (forecasting que habrás visto muchas veces en ingles). La serie temporal es la representación y reporte más básico que puedes utilizar en un sistema de seguimiento, además es la que de forma más sencilla cualquier foráneo puede obtener alguna conclusión. Y con esta noción básica paramos la explicación. Seguramente este concepto vuelva a aparecer más adelante. Serie temporal – La representación más básica estadísticamente hablando
durante un intervalo de tiempo fijo que se conoce como granularidad o resolución. Estos tiempos oscilan desde segundos a varios minutos. Y permitirme la licencia, esta frase va dedicada a alguien que si lo esta leyendo sabrá que estoy hablando con el o ella (no quiero dar más pistas): Es importante encontrar la granularidad necesaria para observar eficazmente el comportamiento de un sistema. Si por ejemplo fijamos un tiempo de 1 segundo podemos introducir el llamado efecto del observador, que afecta negativamente al rendimiento de un sistema. Sondear cada segundo un sistema incide directamente en los recursos. Introducir demasiados puntos de datos incide en un gran consumo de almacenamiento y posiblemente nuestro sistema no varíe tanto en cada segundo. Y si la granularidad es amplia, cada 10 minutos, seguramente perdamos información valiosa, por tanto, frustración: ya que el propósito para el que medimos no se esta cumpliendo. En muchas ocasiones he visto decir “si tenemos un fantástico sistema de medición y seguro que lo tenemos”, pero al ver la granularidad vemos que hemos perdido el punto que nos interesaba, es decir, no tenemos la información que nos ayudaría a resolver el bug. Granularidad o resolución – Más o menos intervalos agrupados
tener diferentes niveles de granularidad y a su vez distintos para cada recurso del sistema. Por ejemplo, si vamos a lo básico, un sistema de almacenamiento, una granularidad pequeña, cada poco segundo puede destapar un problema de latencia, mientras que una granularidad grande lo enmascara. Como bien sabéis la latencia es el tiempo que necesita un proceso de I/O. Por tanto, si calculamos que percentil de solicitudes cumplen el mínimo (10 ms) podemos sacar % agrupados de aquellas que superan el umbral mínimo y podemos llegar a ver si un % significativo multiplican por 100 la base-line (el mínimo sobre el que decimos que el proceso se comporta adecuadamente).
en la nube, la nube esta continuamente cambiando. Los métodos y procesos tradicionales aplicados a la nube no valen. Se introducen estas etiquetas para que en una métrica podamos ver más valores. No se trata de mostrar una gráfica de latencia o IPS únicamente, cuando pulsemos sobre esa métrica en concreto el sistema debe ser capad de ver más información sin tener que estar solapando otras medidas. Es decir, enriquecemos la información básica que medimos con otras medidas que puedan ayudar al análisis inicial. Veamos un ejemplo que aclara lo que estoy contando. Etiquetas de Metadatos – Metadata tags
suelen llamarse tags o labels, y representan un par valor, es decir: key/value, donde la clave (key) es un contexto de la metrica y el valor (value). En estadística, la clave es la dimensión que se asigna a una métrica. Por ejemplo, “instancia” de un servidor web. Y valor determina los datos de la dimensión, por ejemplo, el valor la IP de esa instancia. Esta relación clave/valor nos permite trabajar con filtros agrupaciones, etc. Esta creación de etiquetas no debe ser manual, se debe instrumentalizar. Veamos la relación entre la métrica y las etiquetas de una forma más visual: Nombre de la Métrica Valor de la Métrica TimeStamp Etiquetas de Metadatos %_CPU_PerSecond 0.15 Mon, 1 Jul 2021 12:00:00 GMT Instance: 127.0.0.1:8081 Group: Production %_CPU_PerSecond 0.16 Mon, 1 Jul 2021 12:00:01 GMT Instance: 127.0.0.1:8081 Group: Production %_CPU_PerSecond 0.60 Mon, 1 Jul 2021 12:00:00 GMT Instance: 127.0.0.1:8082 Group: UAT
generales en métricas de trabajo o de recursos según la información que brinda la métrica. Las métricas de trabajo nos dan información sobre información de todo el sistema o subsistemas. Las métricas de recursos proporcional información sobre los recursos que componen el sistema completo. Las métricas de trabajo se centran en el comportamiento del sistema, mientras que las métricas de recursos se refieren al comportamiento de recursos individuales que forman parte de ese sistema. Las métricas de trabajo incluyen rendimiento, errores, latencias, … mientras que las de recursos saturación, utilización, errores, disponibilidad, … Las métricas de trabajo y recursos conjuntamente ayudan a observar el estado de los servicios y diagnosticar problemas. A continuación, entramos en más detalle. Categorías de métricas – clasificación
de la cantidad de trabajo realizado por un componente por unidad de tiempo. En caso de una aplicación, el rendimiento es la medida del número de procesos simultáneos administrados por segundo. De manera similar, para una base de datos el numero de consultas ejecutadas por segundo. Para un servidor web, sería el numero de solicitudes HTTP procesadas por segundo. Ayuda a cuantificar la demanda de un sistema. Éxito Esta medida es la tasa de solicitudes que dieron como resultado un éxito por unidad de tiempo. Error Esta medida es la tasa de solicitudes que dieron como resultado un error por unidad de tiempo. Las métricas de error a menudo capturan toda la información de las fuentes que lo han generado potencialmente con el fin de realizar un seguimiento y por tanto tomar medias al respecto (una traza, en resumen). Latencia Mide el tiempo necesario para completar una unida de trabajo. Se recomienda medir siempre esto para las solicitudes tanto de éxito como de error. Métricas de trabajo – work metrics
utilización, saturación y errores (en ingles utilization, saturation and errors, USE) se usa para analizar el rendimiento del sistema midiendo la utilización, saturación y errores del sistema. Por cada recurso, se comprueba su utilización, saturación y errores. ¿Por qué? ▪ Utilización, nos mide el tiempo medio de ocupación del servicio. ▪ Saturación, nos da la medida del trabajo extra que debe soportar el servicio y no puede ofrecer, normalmente se encola y afecta a la latencia o el uso de CPU. ▪ Errores, evidentemente los errores que se generan. Formalmente explicado por Brendan Gregg. RED Method Son los acrónimos en ingles de ratio, errores y duración (ratio, errors, duration). Este método estudia las solicitudes no los recursos. Y estadísticamente se miden distribuciones no promedios como USE. Formalmente explicado por Tom Wilkie. USE y RED no son excluyentes, muchas veces se usa el método USERED. Metodologías de Métricas – formalizaciones
explica estas cuatro medidas. En resumen, ya que si quieres profundizar, ya he dejado los enlaces para que amplíes información: ▪ Latencia, mide el tiempo que se toma en completar una request. Es importante examinar este valor en las request fallidas. Es como la saturación anterior del método RED. ▪ Trafico, es la medida de las solicitudes enviadas a un sistema. En un servicio HTTP, son las solicitudes por segundo. ▪ Errores, media de las solicitudes que fallan, si estamos en HTTP, por ejemplo, los 500 o un 200 donde dentro se pone un error, ¡por favor mandar mensaje acorde!, cuantas veces hemos visto esto. ▪ Saturación: medida de que nos da los recursos del sistema. Muchos sistemas se degradan por sobrepasar el objetivo inicial, como hemos contado antes una latencia alta, señal de saturación. Las 4 señales de oro – Latencia, trafico, error y saturación
representarlo adecuadamente genera ruido, ya que por muy bien que midas y por una mala representación, hemos creado la bomba perfecta: puedes alertar de un problema e interpretarlo de otra… esto hace perder tiempo, asustar a gente y desconfiar de tu sistema de observación. Por tanto, vamos a ver que representaciones nos ayudan a mostrar adecuadamente una métrica (muchas capturas de los gráficos serán copiadas de la documentación de Grafana): Gauges, es una representación puntual en el tiempo de una métrica, que proporciona un solo número, podría decirse que es el valor actual de esa métrica. Tipos de métricas – Y como representarlas
un punto a lo largo del tiempo. Una medida interesante es el numero de sesiones por segundo de los usuarios de una aplicación o la fluctuación de la CPU a lo largo del tiempo. En un eje x siempre medimos el tiempo y en un eje Y los usuarios o un % de CPU.
Proporcionan una representación aproximada de a una distribución de observaciones individuales (por ejemplo, tiempos de respuesta) de un evento. Se pueden representar en las columnas, medias, acumulados, totales, recuentos, …
de usar las herramientas estadísticas descriptivas que aporten el valor y la claridad a los datos. Que pueden ser tan espectaculares como un panal donde vemos el uso de la CPU de toda una serie de VMs
se recopilan a intervalos regulares, pero también debemos capturar eventos (tal y como os comenté con anterioridad). Estos eventos ocurren con poca frecuencia, pero proporcionan un contexto crucial para entender un comportamiento de un sistema. Un evento puede ser generado con el cambio de una versión y usarlo como marca de tiempo para medir una serie de errores, así sabremos si hemos arreglado el error o hemos introducido nuevos. Nos ayudan las alertas, ya que estos eventos deben ocurrir de forma no regular. Y los eventos cuando suceden, suelen activar el mecanismo de escalado de sistemas, por ejemplo. Dado que los eventos se capturan cuando suceden, podemos convertirlos en datos cuantitativos, cocinarlos y hacer agregados, etc. Cuidado con los eventos, no debemos guardar todo, ya que esto generaría una ingente cantidad de datos, pero si los etiquetamos como: error, warning, verbose, information, debug, podemos activarlos y recopilar la información para cuando la necesitamos. Un log de eventos es una herramienta inmutable y por eso mismo sus datos son vitales para asociar correlaciones entre errores. Por tanto, convertimos eventos en métricas al convertirlos en datos cuantitativos. Metricas y eventos – Regulares e irregulares
los componentes individuales de la monitorización, entender sus funciones y como encaja cada una de ellas en el sistema general. Voy a mostrar una arquitectura end-2-end basada en K8s y otra en Serverless, estas arquitecturas nos permitirán identificar los problemas mínimos que afectan a cada sistema y avisar de ellos de la forma más rápida posible. Espero que puedas obtener una base sólida, desde la comprensión del sistema general y su marco de trabajo, lo que debe incluir un diseño, la jerga y conceptos habituales. Cuando diseñamos una arquitectura, lo primer paso es identificar los componentes individuales que conforman la arquitectura y luego de forma individual que herramientas de monitorización convienen a esa pieza. Cuando hablo de componentes individuales, hablo de: ▪ Como recopilar datos. ▪ Como almacenar los datos. ▪ Que motor de análisis y consulta usar. ▪ Como visualizar los datos. ▪ Como integrar y establecer los logs, Metricas y trazas, que vimos anteriormente ▪ Como Alertar. Ejemplo E2E – Vamos a ver dos ejemplos de extremo a extremo
de los datos de monitorización pasa por cada uno de los anteriores componentes. Al final, si conoces el mundo de los datos, no deja de ser un ETL o un ELT o un hibrido (ingresar, transformar y cargar, ingresar, cargar y transforma, o una mezcla) para posteriormente visualizarlos en una herramienta de BI (inteligencia empresarial). Dependiendo del tipo de dato el proceso anterior de ingresar, transformar y cargar nos obliga a utilizar una herramienta determinada, no por ello exento de estandarización, muchas veces estas herramientas no son las mejores para el 100% de los datos y debemos consensuar o, mejor dicho, asumir que, para un porcentaje mínimo, las herramientas usadas no son las más efectivas, pero lo que no podemos hacer es tener cientos de herramientas, ya que al final la monitorización se vuelve farragosa e inútil. Las arquitecturas para los casos de uso que nosotros vamos a usar están más que definidas y estandarizadas, vamos a ver la arquitectura a un alto nivel y que piezas necesitamos para cada fase.
monitorización moderno MMSA – Modern Monitoring System Architecture Apps 1 Apps n Librerías Kubernetes Infraestructura Servicios Cloud Agente Base de Datos Ficheros Logs Consultas Alertas Visualizacion
y extrapolable a cualquier arquitectura Cloud. Generalmente constará de los elementos del diagrama. Nuestra decisión esta en: ▪ ¿Que herramientas utilizar? ▪ ¿Cuales se adaptan mejor? ▪ ¿Son adecuadas para resolver un problema en particular o son adecuadas de forma generalista?, ¿he de usar una generalista y concretamente una especializada?, ¿Cuál será el beneficio o los impedimentos ante esta estrategia? ▪ ¿Uso Open Source o productos comerciales? Me gustaría decir que la decisión es suya, pero bien es cierto que no, que habrá que pasar, por un comité, en otras ocasiones será imperativo, o quizá tengas la suerte que puedas decidirlo todo tu. Por eso es bueno saber con 2 casos de uso muy comunes, que se suele utilizar en cada pieza de forma abstracta y en la siguiente sección os pondré una lista de herramientas para cada situación: ▪ Caso de Uso 1: K8s independiente de la nube, será genérico. ▪ Caso de Uso 2: Serverless en Azure. Ambos representarán la capa de arquitectura de un frontend en ReactJS, un backend en NodeJS o C# y persistencia contra un SQL Server o MySQL. Y quizá pasado unos días o un tiempo de esta publicación desarrolle los ejemplos en GitHub para mayor comprensión de los mismo, pasando de arquitectura a dev. Introducción Arquitectura de Monitorización(2/8)
telemetría se pueden recopilar de las aplicaciones (mediante instrumentación de con diversas bibliotecas), de los clústeres de K8s, de la infraestructura (gracias a los agentes) y directamente con servicios en la nube. En ciertos escenarios, los servicios de la nube pueden necesitar infraestructura subyacente como los K8s mediante una pieza PaaS o que los servicios SaaS necesiten activar acciones para que podamos tener todo monitorizado. Los datos de la telemetría se deben recopilar y se pueden (no es necesario) almacenar en una base de datos (en bases de datos normales o unas especiales llamadas bases de datos de series temporales). Gracias a un motor de consultas puedes ejecutar consultas sobre esos datos o incluso sobre los archivos de registro (logs) a partir de las fuentes de telemetría. Los resultados consultados se pueden enviar a diversos backend de visualización. Estas plataformas de visualización son capaces de transformar los datos y generar información para cuadros de mando o bien para generar información significativa para los responsables de esta monitorización. Los equipos de operaciones pueden inferir estos datos para comprender el funcionamiento interno del entorno completo y compáralos con un base line (resultados deseados). Introducción Arquitectura de Monitorización(3/8)
alertas, que se activan en caso de que existan patrones de comportamiento inesperados (de aquí que necesites un base line). Una vez que se activa la alerta, se puede notificar a un miembro del equipo de operaciones que previamente hemos asignado para que resuelva el problema, o bien, se puede automatizar la alerta para que ejecute scripts que rectifican el problema sin intervención manual. Además, la generación de trazas de forma distribuida nos ayudará a identificar las áreas que pueden causar el problema, por esa razón muchas veces es una discusión de arquitectura hasta que punto hacemos mini ecosistemas o solo presentamos un ecosistema. Esta arquitectura que hemos tratado de forma abstracta es la que vamos a ver con 2 casos de usos concreto. Como podréis observar, en un proceso muy claro y definido, que es prácticamente el mismo independientemente de la arquitectura de los casos de uso que presentaré. Simplemente estos casos son para que dispongas de un contexto para que puedas comprender mejor todo lo anteriormente descrito. Veamos un poco para que sirve cada pieza. Introducción Arquitectura de Monitorización(4/8)
la infraestructura, de las aplicaciones o del entorno Cloud. Y se recolectan fundamentalmente con: ▪ Instrumentación en el codigo, es decir, librerías específicas del lenguaje que este usando y suelen enviarse via endpoint HTTP. ▪ Via exposición, es decir, exponer Metricas para que un tercero via HTTP consuma los valores. Suele hacerse con bridge (librerias de cliente como la de Prometheus y suelen ser ficheros de texto), parser (librerias puras del lenguaje de programación que intercambian la información directamente como puede ser DataDog o InfluxDB o Azure Insight), finalmente ad-hoc (no deja de ser un desarrollo personalizado entre ambos extremos). ▪ Recolección via agente, se instala en el sistema directamente y via pull/push se obtiene las métricas. Una herramienta muy conocida es el agente de como Nagios, collectd, fluentd o un demonio como StatsD o incluso Telegraf (parte del ecosistema TICK – Telegraf, InfluxDB, Chronograf y Kapacitor), y el propio de las VM de Azure que también se puede instalar on-premise. Existen muchas opciones. Y luego existen pequeños ecosistemas que quieren convertirse en estándar como OpenTelemetry, que no deja de ser una serie de frameworks de observabilidad que puede capturar datos de múltiples orígenes con agentes, librerias, exposiciones. Introducción Arquitectura de Monitorización(5/8)
con OpenTelmetry por qué como os decía es un estándar de facto y merece que estudiéis por vosotros mismo el funcionamiento. En mis otros workshops de microservicios, creo haber hablado de esta tecnología. https://opentelemetry.io/docs/concepts/data-collection/ ¿Almacenamiento de datos? Avanzamos un paso más y nos movemos al punto más complejo den entorno, los datos. Estos puedes almacenarlos en base de datos relaciones como SQL Server o no relacionales como MongoDB. Lo habitual es usar una NoSQL pero con una peculiaridad: base de datos de series temporales. Se generan colecciones de observación para una métrica especifica y en un rango de tiempo, lo que hacen que sean tremendamente útiles al respecto. Un ejemplo puede ser InfluxDB o Azure Application Insight. Como es un tema muy largo y apasionante, que se escapa de este documento, os dejo un enlace donde os van a explicar que es una TSDB: https://www.influxdata.com/time-series-database/ Introducción Arquitectura de Monitorización(6/8)
de un lenguaje especifico para consultas. Como de la que más se es de Azure Application Insight, os puedo hablar de KQL (Kusto Query Languaje), que esta optimizado para realizar: • Filtros. • Agrupaciones. • Agregaciones (concepto básico de NoSQLs). • Rollup. Y uno concepto muy importante el downsampling, que en Azure Insight viene a ser ¿Cuánto te va a costar la broma?, ya en serio, se trata de la resolución de los datos de la serie temporal. Cuando menos granularidad/resolución más economico resulta ser cualquier almacenamiento y más sencillo de procesar las instrucciones de las consultas, pero en cambio menos información para depurar un bug tendrás… cuidado con la relación de este punto ya que puede dar al traste un sistema de monitorización ya sea por: ▪ Es muy caro. ▪ La información no me ayuda. Y si esto esta mal medido, no puedes justificar una inversión en monitorización y observabilidad. Introducción Arquitectura de Monitorización(7/8)
la representación de los datos, a modo de resumen es: • Gráficos. • Mapas. • Tablas. • Infografías. • Dashboards. Y del sistema de alerta. Ya que con los lenguajes de consulta de las TSDB podemos realizar consultas que generen bajo unos umbrales una serie de alerta que informen via mail, Microsoft Teams, una llamada por un robot, o incluso puedes automatizar workbooks para que realicen tareas bien definidas, como reiniciar una maquina virtual, recuperar un backup, etc. Como el sistema de alertas y el de log, es muy importante, voy a dedicar una pequeña sección a cada uno de estos puntos para desarrollarlo un poco más. Introducción Arquitectura de Monitorización(8/8)
Estar mirando graficas, Dashboard, no tiene mucho sentido, si que deber ir mirándolo y si tienes un equipo de SRE lógicamente estará casi el 70% de la jornada mirando estas métricas. Pero cuando practicas ALM no puedes tener a un Dev o alguien de Ops dedicado a mirar nada más que un 10% de la jornada. Por tanto, debemos ver si existen automatizaciones en cualquiera de los supuestos. Y par ello vamos a ver tres conceptos básicos: ▪ Alarma, es un cambio significativo del sistema, normalmente algo indeseado y debido a fluctuaciones en la métrica. ▪ Monitor, son umbrales límites de una alarma. Un monitor, evalúa la serie temporal en busca de limites superados en defecto o exceso durante un rango de tiempo específico. Y cuando esto ocurre un monitor provoca una alarma. ▪ Alerta, es una notificación de la alarma, cuando un sistema fluctuando sobrepasa un umbral durante un tiempo determinado y es detectado por el monitor envia una alerta. Un ejemplo , creamos una alarma que esta configurada para que alerte si el límite de CPU sobrepasa el 80% de uso durante un rango de 10 minutos. El sistema de monitorización va buscando ese hito, cuando sucede se dispara la alarma y la alerta. Puedes configurar ambas, pero al menos una debes tener, o tienes alertas o tienes alarmas. ¿Como puedo configurar un escenario de alertas? este problema lo suelo resolver con tres premisas. Automatizar – Dejemos que otros se encarguen por nosotros
Se deben tener en cuenta muchas variables cuando lo configuras, como podéis ver esta presentación depende mucho de muchas cosas, por eso esta explicado casi todo de forma muy teórica. Cuando configuro alertas, uso estas tres premisas: ▪ Ser conservador, el resultado es que se lanzan mucha alerta y puede ser agotador y contraproducente, ya que se tiende a ser un autómata y descartarla. Cuidado, cuando tienes un equipo ALM y no un SRE (ya sabes las diferencias). ▪ Optimizando mucho los umbrales, ocurre que dejas un sistema muy sensible y puede que te den falsos positivos, o que prácticamente no tengas información y se pierdan problemas. Esto necesita mucha práctica y conocimiento del sistema para que no te pases en exceso o defecto. ▪ Con una amplia cobertura al principio de todas las variables que se me ocurran y luego ir eliminado aquellas que son casos que no aportan información. ▪ Usando un ciclo de mantenimiento, esto es revisar si esta actualizadas las alertas con regularidad por el equipo. Los sistemas actuales presentan retos propios que son complicados de incluir en el modelo de alertas: ▪ La corta vida de recursos Cloud, que pueden ser efímeros como K8s y cuesta mucho luego ver por donde vino la alerta. ▪ Los escenarios cambian, ya que el tema del autoescalado puede cambiar el escenario y cuando llegamos a indagar sobre la alerta, hemos perdido contexto.
¿Cómo debería plantear se la estrategia de las alertas? ▪ Identificar aquellas piezas del sistema que son criticas para el negocio. ▪ Establecer alerta y revisarlas cada poco tiempo para optimizarlas y ajustarlas. ▪ Revisar el ciclo de vida del incidente y realiza una retrospectiva para ver si puedes encontrar una nueva métrica para crear una nueva alerta. ▪ Y por supuesto revisa en tu proceso continuo las alertas, es decir, itera y mejora. Para mis los factores más importantes que debes tener en mente a la hora de crear un sistema efectivo de alertas es: ▪ Primar calidad sobre cantidad. ▪ Tener una lista de alertas que puedan ser desplegadas en un momento de crisis y desconectadas una vez superada. ▪ Usar si puedes un sistema de IA, como puede ocurrir con Azure Sentinel. ▪ Tener un mapa de las dependencias para realizar un análisis y ver que alarmas poner entre estos puntos dependientes. ▪ Automatizar procesos via script y disparados por una alerta. ▪ Colaboración y comunicación (leer las entradas en mi blog al respecto).
Las funcionalidades de alertas se han visto incrementado con las nuevas tecnologías Cloud Native, ya que la cambiar constantemente necesitan una estrategia y gestión muy diferentes a los sistemas on-premise. Una característica, el escalado, obliga a que el sistema de alertas escale igualmente. ▪ Por tanto, usa etiquetas, etiquétalo todo, me reitero mucho en este aspecto, pero es que es obligatorio usar Tags, incluso para los costes. Con etiquetas puedes crear jerarquías (aquí depende de tu ecosistema) de etiquetas y que estas se propaguen a los sistemas que las tiene. ▪ Usa el API del sistema que uses, nos permitirá desplegar alertas automatizadas o en caso contrario con la IaC y así, tendrás todo documentado, generar un documento de alertas, le vale a operaciones para tener una idea de los que se está controlando leyendo cuatro líneas de código. Esto se extrapola los recursos y la IaC, y por tanto a las etiquetas. ▪ Recalco la IaC, en este caso seria Alerts as Code. Tener la alerta y el script que automatiza esa alerta al dispararse es una práctica de auto-documentación sencilla y económica. Y como punto final os recuerdo que a parte es establecer las alertas para recursos y aplicaciones, debe existir en tu sistema de alertas, alertas para los costes y si hablo ahora es por que: si tienes un AKS que genera un log enorme puede llenar tu log con una cantidad de datos ingente y gastarte en Azure tranquilamente 500€ el día, con este ejemplo verás que las alertas van de la mano en un mundo Cloud. En este punto no me explayo, ya que es lógico poner rangos de gastos y ver si no, nos vamos con los costes, esta es otra historia que debe ser contada otro día.
os diga cuatro cosas sobre buenas prácticas, antes incluso de continuar te cuento la más importante: centraliza todos tus logs por qué te permitirá hacer tu trabajo de detective en un solo escenario del crimen y no sobre diversos sitios, es como ir buscando testigos en diversas ciudades y algunos aparecen muy tarde, por haber perdido el tiempo buscando en la ciudad que no esta relacionada con el crimen, o algo así, ya me entendéis. Volviendo al principio, los logs son un pilar fundamental en cualquier sistema de seguimiento, ya lo eran antes (on- premise) y lo seguirán siendo (mundo Cloud). Es un recurso tradicional y muy útiles para depurar problemas y realizar un root cause analysis (RCA). Existen implementaciones para casi cualesquiera cosas desde información del sistema operativo, la infraestructura de un servidor web, a una aplicación de escritorio. Uno de aplicación nos ayuda a comprender el funcionamiento de la misma y uno de infra a ver la información que captura el sistema. Pero como estamos en la nube existen nuevos desafíos: ▪ Los microservicios constan de muchas piezas y por tanto los logs son a una escala muy grandes. ▪ Los microservicios son interdependientes y recopilar logs nos obliga a entrar en la interdependencia de los mismos ficheros. ▪ Suele ocurrir que los logs son diferentes por cada tipo de pieza, un desafío más. ▪ La ejecución de un nodo o varios nodos, generando información en diferentes sitios. ▪ El uso de contenedores que carecen de almacenamiento. Y cuando muere se pierde el log. Como veis a veces un monolito nos hace más felices a todos. Centraliza – Una sola fuente de la verdad
por todo esto que aparece la Log Aggregation Architecture, que en el mundo del open source es similar en muchas herramientas, poco puedo hablar de DataDog, por ejemplo, por que la desconozco. En la siguiente imagen os pongo un ejemplo: Inputs Data Collection Inputs Data Collection Inputs Data Collection Message Queue (Streaming) Data Aggregation and processing pipeline Indexing and distributed storage Indexing and Distributed Storage Visualization & Analysis Ingestion Pipeline
las tuberías de la ingesta de datos. La parte más importante es la ingesta, que puede ir desde lo más básico a lo más complejo que puedas imaginar, depende de los datos de entrada y el formato que tengamos de salida. Como vimos antes, los formatos de los registros pueden ser muy variado. Pero sea como sea, suelen tener estos componentes: ▪ Agentes de recolección de datos, estos se despliegan en los nodos de tu entorno y trabajan enviando metrica y recolectando información. Deben ser ligeros y consumir poca memoria, que la huella sea baja y a ser posible que no generen dependencias. ▪ Por ejemplo, tienes el agente de Nagios o uno muy conocido es Beats de Elastic y que puedes hacer que recopile información según tus necesidades. En el caso de Beats rescopila datos bajo un formato llamado Filebeats y los datos de red en formato Peacketbeat, o de los servicios otro formato llamado Metricbeats, … una colección muy diferente, por eso os pongo este que es un caso particular, otros como Nagios solo usa un formato. ▪ Una cola para los mensajes, que lo almacena en un buffer antes de indexarlos. Esto nos ayuda a balancear una llegar inesperada de mensajes, cuando esto ocurre, ocurre una crisis: bug por doquier. Por ejemplo, puedes usar un Kafka o un Rabbit MQ o un Azure Service Bus. ▪ Agregación y procesamiento de datos, se basa en unos registros estructurados. Una muy bien definida en la que nos permite hacer análisis de los datos. Además, incluirá un contexto a nivel de aplicación y otros detalles para que los datos estén lo más enriquecidos e informativos posibles.
de K8s dirigida por Prometheus, dependiendo del componente que ataque la información viaje con un pull o un push (recordar páginas atrás cuando hablamos de ese concepto). Lo habitual que se monta en un K8s, suele ser Sota, Caballo y Rey, esta muy trillado y prácticamente solo salen cosas que intentar estandarizar de facto, algunas están para que sea de acto, como han de monitorizarse y observarse las arquitecturas montadas bajo este paradigma. Aquí, lo más importante de todo es sin duda la herramienta que menciono, Prometheus, por qué esta desde el inicio (casi) de Kubernetes, muchas veces me he visto involucrado en un empeño en obviarla y saltar a otra cosa, lo cual ni es bueno ni malo, simplemente que puedes entrar en un juego de falta de información, versiones beta que arreglan tal y cual cosa y al final acaban montando un link contra Prometheus de forma rápida y mal. Resumiendo, si puedes no te salgas de la regla y que sea Prometheus quien realice ese Pull/Push a las herramientas que más cómodo se encuentren en tu organización. Y como no hay mucho más que contar si no, complicar o aun simplificar el caso de uso anterior, vamos a por uno que entra en la guerra de serverless si o no, yo os doy las dos opciones para que tengáis los dos casos de uso.
Cloud que tengo bien controlada, por desgracia AWS cada vez menos, existe una dependía tácita entre los recursos y como se monitorizan. Por supuesto que puedes poner un log4net en tu Web App que alimente un InfluxDB, o un Jaeger para traceo distrbuido de tu aplicación o un Grafana que lea de ese InfluxDB, nadie te impide hacer lo que quieras, usar OpenTelemetry en tu Function. Como decía Microsoft te permite hacer lo que quieras, como: AKS contra Prometheus y Grafana, por hablar del ejemplo del caso de uso 1. Aclaro que esa dependencia tácita es por que muchas veces monitorizar con Insight un recurso de Azure es tan simple como poner el Id de la Application Insight correspondiente. No tienes que hacer nada, esto al mismo tiempo te genera el mapa de tracing y con igual facilidad con un simple comando de Azure CLI o desde el UI activar el almacenamiento de la ingesta de logs. El anterior ejemplo que se puede simplificar mucho termina por usar los 3 componentes anteriormente indicado y una parte que no se muestra que es los Dashboard y una herramienta muy potente de Azure Monitor que son los Workbooks.
Principalmente la información que he mostrado antes en los métodos RED, USE y Four Golden Signals, que describen los autores indicados y los libros de Google. Pero para un Caso de Uso #1mínimo debemos monitorizar: Un nexo común – A partir de aquí cualquier dato complementa Metricas para Contenedores Descripción Resumen Contenedores ejecutándose Número total de contenedores en ejecución Uso de la CPU del Host CPU utilizada en el host donde se ejecutan los contenedores Uso del almacenamiento del Host Almacenamiento utilizado en el host donde se ejecutan los contenedores Uso de la memoria del Host Memoria utilizada en el host donde se ejecutan los contenedores CPU % Uso de instantáneo de la CPU por contenedor % de uso instantáneo de la CPU de cada contenedor Uso total de CPU por contenedor y sistema Total de uso de CPU que corresponde al contenedor y al sistema, para cada uno de ellos Memoria Memoria de contenedor utilizada Memoria usada en de cada contenedor % de Memoria usada % de la memoria usada por contenedor Redes Bytes recibidos por contenedor Bytes enviados por cada contenedor Bytes enviados por contendor Bytes recibido por cada contenedor Errores de red por contenedor Errores de red y reset de conexión por contenedor Almacenamiento Uso total de disco Disco utilizado por cada contenedor I/O de disco IOPS de disco usadas por cada contenedor
en un clúster de K8s Pods Nº Total de pods en un clúster de K8s Pod Containers Nº Total de contenedores en un clúster de K8s Namespaces Nº Total de nodos en un namespaces de K8s Media de uso de CPU por Nodo Media de uso de la CPU por cada nodo en % Media de uso de Memoria por Nodo Media de uso de la memoria por cada nodo en % Media de uso de almacenamiento por Nodo Media de uso del almacenamiento por cada nodo en % Uso de memoria del clúster Memoria usada por el clúster de Kubernetes Namespaces Recuento de Pods por Namescpace Numero total de pods en cada namespaces Recuento de contenedores por Namespace Numero total de contenedores en cada namespace Memoria usada por cada namespaces Nº total de Pods Containers en namespace (continua) Lo mínimo para asegurar la confianza ¿Qué se debe monitorizar?(2/13)
nodo % de utilización de la CPU de un nodo Uso de la CPU por nodo Uso de la CPU por nodo Utilización de la Memoria por nodo % de utilización de la Memoria de un nodo Uso de la Memoria por nodo Uso de la Memoria por nodo Ratio de emisión de Bytes por nodo Ratio de bytes recibidos de cada nodo Ratio de recepción de Bytes por nodo Ratio de bytes recibidos de cada nodo % del sistema de ficheros usado % del sistema de ficheros usado por cada nodo Bytes del sistema de ficheros usado Bytes del sistema de ficheros usado por cada nodo Espacio disponible del sistema de ficheros por nodo Bytes disponibles del sistema de ficheros por cada nodo Pods Ratio de CPU usado por cada pod % de uso de la memoria de cada Pod Memoria usada por cada pod Memoria usada por cada Pod Bytes emitidos por cada pod Datos emitidos por cada Pod Bytes recibidos por cada pod Datos recibidos por cada Pod Uso del sistema de ficheros por pod % del sistema de ficheros usado por cada pod Lo mínimo para asegurar la confianza ¿Qué se debe monitorizar?(3/13)
Como bien sabéis cada contenedor puede ser una cosa bien diferente: un servidor web, una redis cache, una base de datos, etc. Como es imposible poner que debe medirse por cada tipo de servicio, vamos a centrarnos en los que están en el Caso de Uso #2. Por tanto, todo lo que aprendas para contenedores y serverless de una, por ejemplo, una Redis Cache, lo podrás llevar de un caso de uso a otro, con la salvedad que en Serverless además debemos medir algunos atributos del recurso en concreto y que la forma de cada Cloud difiere, yo me centraré en Azure. Centrémonos en los dos que componente nuestros casos de uso: ▪ Servicio Web. ▪ Servicio de Base de datos. Para monitoreara un App Service (un servicio Web) debemos partir de la monitorización del Service Plan y como no de Azure Insight. Como Application Insight ya nos da mucha información preconfigurada y también nos la posibilidad de ver casi en tiempo real el comportamiento de nuestra aplicación poco puedo explicar al respecto ya que se trata de una solución prácticamente out-the-box, como las imágenes que pongo a continuación:
Vamos a ver que debemos hacer a grandes rasgos con App Service. Como bien sabéis este depende de un Service Plan y tras varios años trabajando con esto, lo aviso, por que muchas personas monitorizan muy bien, pero se olvidan de Service Plan y sobre todo cuando este contiene varios slots. He visto errores de memoria que vienen de la capa superior y todo el mundo centrado en el App Service. Cuidado, monitoriza las dependencias, cosa que y hemo avisado antes en toda la teoria. Un Service Plan nos ofrece monitorizar: ▪ Cuotas, es decir, límites de recursos que puedes usar. Los limites se definen por el plan que escojas, un plan gratuito quizá admita 100 request y uno de pago ilimitado. Por tanto, si ves que tu aplicación no responde, es por que puedes haberte pasado de la cuota. Lo mismo ocurre con un Service Bus, no llegan los mensajes, pues revisa primero la cuota. ▪ Métricas, como un Service Plan o deja de ser un recurso más, estos también tienen Metricas. ¿Cuáles uso yo habitualmente? • Tiempo de respuesta promedio, es decir lo que tarda en atender a una solicitud. • Tiempo de CPU, cantidad de CPU consumida por la aplicación. • HTTP, recuento de solicitudes y sus diferentes códigos. • Memoria promedio en funcionamiento, cantidad de memoria usada por la aplicación • Conexiones, cantidad de socket enlazados. • Datos de entrada/salida, ancho de banda entrante y saliente de la aplicación • Ensamblados actuales, el numero de ensamblados cargados en todos los Apps Domains en esa aplicación.
Para un SQL Server ocurre lo mismo: ▪ Uso Azure SQL Intelligent Insight, que nos permite monitorizar automáticamente la base de datos. Y puedo detectar problemas, diagnosticarlos y generar logs (RCA). ▪ Uso la configuración automática, que también nos permite arreglar errores de forma automática, etc. (DMVs) Pero si hablamos de Metricas que suelo mirar: ▪ Uso de la CPU, controlamos si llegamos o no al 100%, esto es indicativo que toca subir a un plan más caro, por ejemplo. ▪ Estadísticas de espera: super importante usar sys.dm_os_wait_stats (de T-SQL) para determinar cuanto tardan tus consultas. ▪ Uso de IO, mirar en que límites estamos. ▪ Uso de la memoria. ▪ Errores por permisos. Como podéis ver muchas Metricas al final son las cuatro Golden Rules, como os advertí al principio.
Y para finalizar workbooks, ya tienes modelos para cada tipo de recurso que solo as de modificar, pero digamos que el 50% del trabajo con Azure, si no, el 80% ya lo tienes casi listo frente a contenedores que, aunque estén en Azure te toca meter más trabajo por tu parte.
la superficie, la monitorización y observación es una pieza del gran engranaje de DevOps, pero tan densa como lo puede ser cualquiera de las otras. Por eso os dejo información donde continuar formándose, eso sí casi todo en ingles, por que excepto Microsoft y este documento que tienes entre manos, poca más vas a encontrar en español: ▪ https://docs.microsoft.com/es-es/azure/architecture/best-practices/monitoring ▪ https://www.oreilly.com/library/view/distributed-systems-observability/9781492033431/ch04.html ▪ Un libro que nos da ServiceNow: https://www.servicenow.com/lpebk/enterprise-sre.html ▪ Los que nos da Google: https://sre.google/books/ Con esto ya tienes donde continuar. Solo he rascado la superficie – Aunque te parezca que es mucho lo que ves aquí
entrar el consorcio https://landscape.cncf.io/ que existen muchas open source y muchas de pago. Aquí os pongo un listado de herramientas que usado y open source, de Azure ya no hablo: ▪ https://opentelemetry.io ▪ https://opencensus.io ▪ https://opentracing.io ▪ https://openmetrics.io ▪ https://micrometer.io ▪ https://github.com/prometheus/node_exporter ▪ https://collectd.org ▪ https://github.com/elastic/beats ▪ https://github.com/google/cadvisor ▪ https://www.jaegertracing.io ▪ https://github.com/influxdata/telegraf ▪ https://prometheus.io ▪ https://github.com/openzipkin/zipkin ▪ https://www.influxdata.com ▪ https://github.com/Netflix/atlas ▪ https://thanos.io ▪ https://hbase.apache.org Un sinfín de herramientas – Tabla con herramientas y su uso ▪ https://www.graylog.org ▪ https://github.com/grafana/loki ▪ https://logging.apache.org/log4j/2.x y los port a .NET, etc. ▪ https://serilog.net ▪ https://goaccess.io ▪ https://grafana.com ▪ https://github.com/influxdata/chronograf ▪ https://github.com/elastic/kibana ▪ https://www.nagios.org, version core ▪ https://github.com/timberio/vector ▪ https://github.com/influxdata/kapacitor ▪ https://github.com/influxdata/chronograf ▪ https://github.com/influxdata/telegraf ▪ https://github.com/bbotte/banshee-detection_system ▪ https://facebook.github.io/prophet ▪ https://www.nexclipper.io ▪ https://adtk.readthedocs.io/en/stable ▪ https://skywalking.apache.org
cabe destacar herramientas End-2-End como: ▪ https://www.elastic.co/es/what-is/elasticsearch-monitoring ▪ https://www.datadoghq.com ▪ https://www.nagios.com/solutions/ibm-i-monitoring-with-nagios ▪ https://www.dynatrace.es ▪ https://newrelic.com ▪ https://instrumentalapp.com Como entenderás estas herramientas es complicado hasta obtener una demo, solo las menciono por si te encuentras el nombre en tu organización y no sabes que pertenecia al stack de observabilidad y monitorización.
jmfloreszazo
tomzoh
hagevvashi
martin_lover
os1ma
ohmura
kubomasataka
harukasan
sakitakamachi
potix2
tadayukinakamura
layerx
tkikuchi
orderedlist
kastner
tanoku
jeffersonlam
brettharned
sergeychernyshev
quramy
lara
bluesmoon
matthewcrist
jacobian
chriscoyier
