Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Monitorización moderna de aplicaciones

Monitorización moderna de aplicaciones

En esta documento os muestro toda la teoría de monitorización y observación. Tratamos las bases de cualquier proyecto Cloud-Native.

Jose María Flores Zazo

July 16, 2021
Tweet

More Decks by Jose María Flores Zazo

Other Decks in Technology

Transcript

  1. Arquitectura de sistema de
    monitorización para aplicaciones
    Cloud Native

    View Slide

  2. Bienvenidos
    Acerca de…
    ¡Hola! Gracias por entrar en
    “Arquitectura de 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

    View Slide

  3. ¿Te gustan los misterios?
    Presentación
    Si tuviese que resumir lo 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

    View Slide

  4. Índice
    Presentación
    Sección I
    Introducción a la Monitorización
    Sección II
    Observabilidad

    View Slide

  5. Índice
    Presentación
    Sección IV
    Herramientas Open Source y
    Azure
    Sección III
    Arquitectura de Monitorización

    View Slide

  6. Sección I
    Introducción la
    Monitorización

    View Slide

  7. Monitorización
    Introducción
    Con los cambios de los últimos años y 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

    View Slide

  8. Una breve introducción
    Microservicios(1/3)
    Estoy seguro de que te cansa 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

    View Slide

  9. Una breve introducción
    Microservicios(2/3)
    UI
    Lógica
    de Negocio
    Capa
    de Datos
    UI
    Microservice Microservice Microservice Microservice
    Microservice
    Arquitectura de Monolito Arquitectura de Microservicios

    View Slide

  10. Una breve introducción
    Microservicios(3/3)
    A nodo de resumen:
    Si queremos 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).

    View Slide

  11. Una breve introducción
    Contenedores(1/3)
    Estoy seguro de que te también 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

    View Slide

  12. Una breve introducción
    Contenedores(2/3)
    La anterior imagen muestra la abstracción 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.

    View Slide

  13. Una breve introducción
    Contenedores(3/3)
    Si hacemos un símil para una 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.

    View Slide

  14. Una breve introducción
    Serverless
    Y el tercer termino que define 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

    View Slide

  15. Introducción
    Monitorización(1/25)
    Se refiere al proceso de obtener visión y 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

    View Slide

  16. Introducción
    Monitorización(2/25)
    1. Recibir alertas proactivas de posibles problemas del 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.

    View Slide

  17. Sobre personas y roles
    Monitorización(3/25)
    En mis inicios como desarrollador, 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.

    View Slide

  18. Sobre personas y roles
    Monitorización(4/25)
    Alinearse con los principios de 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:

    View Slide

  19. No pierdas la perspectiva de que un SREs es un 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

    View Slide

  20. Entornos
    Monitorización(6/25)
    Si estas interesando en el concepto SRE ve 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.

    View Slide

  21. Entornos
    Monitorización(7/25)
    Los Entornos difieren en alcance y mecanismos, esto 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.

    View Slide

  22. Entornos
    Monitorización(8/25)
    La anterior separación nos lleva a una pirámide 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.

    View Slide

  23. Entornos
    Monitorización(9/25)
    Algunos indicadores que podríamos usar en el ejemplo 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.

    View Slide

  24. Entornos
    Monitorización(10/25)
    Inferface de Usuario
    En este ámbito, podemos medir 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.

    View Slide

  25. Una nueva filosofía de monitorización
    Monitorización(11/25)
    Existen herramientas como Nagios 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

    View Slide

  26. Una nueva filosofía de monitorización
    Monitorización(12/25)
    Vincular a ambas partes 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.

    View Slide

  27. Herramientas
    Monitorización(13/25)
    Monitorizar es recopilar información de
    diferente módulos o 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

    View Slide

  28. ¿Por qué necesitamos monitorizar?
    Monitorización(14/25)
    Antes hemos visto la importancia 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

    View Slide

  29. ¿Por qué necesitamos monitorizar?
    Monitorización(16/25)
    Medir el rendimiento
    Otro caso 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.

    View Slide

  30. Características de un sistema de monitorización
    Monitorización(16/25)
    En esencia sistema 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

    View Slide

  31. Características de un sistema de monitorización
    Monitorización(17/25)
    Colaboración
    En una 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.

    View Slide

  32. Características de un sistema de monitorización
    Monitorización(18/25)
    Descubrir
    La nube 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.

    View Slide

  33. Características de un sistema de monitorización
    Monitorización(19/25)
    Podemos resumir el ciclo de vida de la monitorización de la siguiente forma:
    Generar
    Recolectar
    Monitorizar
    Analizar
    Reportar

    View Slide

  34. Características de un sistema de monitorización
    Monitorización(20/25)
    Entre las características 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.

    View Slide

  35. Paradigmas
    Monitorización(21/25)
    Los sistemas de monitorización tradicionales tienen una pieza 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

    View Slide

  36. Paradigmas
    Monitorización(22/25)
    Un sistema moderno se basa en los mecanismos 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.

    View Slide

  37. Paradigmas
    Monitorización(23/25)
    Un sistema basado en Pull enfatiza su trabajo 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.

    View Slide

  38. IA
    Monitorización(24/25)
    Cada vez más la IA se está metiendo 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

    View Slide

  39. A cada arquitectura sus herramientas
    Monitorización(25/25)
    Tanto si trabajas con 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

    View Slide

  40. Ciclo de un incidente
    Resumen(1/2)
    Detectada una
    alerta
    Quejas externas:
    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

    View Slide

  41. Plan de comunicación de un incidente
    Resumen(2/2)
    IC
    Incident Commander
    OL
    Operations Lead
    PL
    Planning Lead
    CL
    Communication Lead
    Primary
    Responder
    Secondary
    Responder
    Stakeholders

    View Slide

  42. Sección II
    Observabilidad

    View Slide

  43. Introducción
    Observabilidad(1/8)
    Cuando los entornos son tan complejos, como sucede 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

    View Slide

  44. Introducción
    Observabilidad(2/8)
    Dos son los objetivos principales de una plataforma 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.

    View Slide

  45. Pilares
    Observabilidad(3/8)
    Las Metricas (junto a los eventos), los logs 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

    View Slide

  46. Pilares
    Observabilidad(4/8)
    Los eventos han de ser un punto importante 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.

    View Slide

  47. Pilares
    Observabilidad(5/8)
    Del mismo modo que existen herramientas para las 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.

    View Slide

  48. Pilares: Métricas
    Observabilidad(6/8)

    View Slide

  49. Pilares: Trazas
    Observabilidad(7/8)

    View Slide

  50. Pilares: Logs
    Observabilidad(8/8)

    View Slide

  51. Incluso debes ser gris
    Observabilidad: resumen
    A modo de resumen 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

    View Slide

  52. Un estudio en profundidad
    Metricas(1/15)
    Os advierto que esta secció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

    View Slide

  53. Un estudio en profundidad
    Metricas(2/15)
    Las métricas aportan observación puntual 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

    View Slide

  54. Un estudio en profundidad
    Metricas(3/15)
    Las métricas generalmente se recopilan 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

    View Slide

  55. Un estudio en profundidad
    Metricas(4/15)
    Por tanto, nuestra estrategia debe 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).

    View Slide

  56. Un estudio en profundidad
    Metricas(5/15)
    Es algo de vital importancia 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

    View Slide

  57. Un estudio en profundidad
    Metricas(6/15)
    Las etiquetas en las herramientas 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

    View Slide

  58. Un estudio en profundidad
    Metricas(7/15)
    Se pueden clasificar en términos 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

    View Slide

  59. Un estudio en profundidad
    Metricas(8/15)
    Rendimiento
    Es una medida absoluta 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

    View Slide

  60. Un estudio en profundidad
    Metricas(9/15)
    USE Method
    La metodología de 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

    View Slide

  61. Un estudio en profundidad
    Metricas(10/15)
    Volviendo a Google, https://sre.google/books/ nos 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

    View Slide

  62. Un estudio en profundidad
    Metricas(11/15)
    Medir un dato y no 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

    View Slide

  63. Un estudio en profundidad
    Metricas(12/15)
    Contadores, es una representación de 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.

    View Slide

  64. Un estudio en profundidad
    Metricas(13/15)
    Histogramas, al final son resúmenes. 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, …

    View Slide

  65. Un estudio en profundidad
    Metricas(14/15)
    Sumarizaciones, realmente se trata de combinar diversas medidas en una sola y representarlos con un grafico de barras,
    de calor, etc.

    View Slide

  66. Un estudio en profundidad
    Metricas(15/15)
    Y en definitiva se trata 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

    View Slide

  67. Deben ser SMART, inteligentes
    Metricas: resumen
    specific
    específico
    S
    measurable
    medible
    M
    achievable
    alcanzables
    A
    relevant
    relevantes
    R
    time bound
    duración
    determinada
    T

    View Slide

  68. Un poco de información al respecto
    Eventos
    Capturamos métricas que 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

    View Slide

  69. Sección III
    Arquitectura de
    Monitorización

    View Slide

  70. Lo que vamos a ver
    Introducción(1/2)
    Vamos a intentar ver 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

    View Slide

  71. Lo que vamos a ver
    Introducción(2/2)
    El ciclo de vida 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.

    View Slide

  72. Introducción
    Arquitectura de Monitorización(1/8)
    arquitectura abstracta de un sistema de 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

    View Slide

  73. Como podéis observar la anterior arquitectura es una explicación genérica 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)

    View Slide

  74. Volviendo al diagrama anterior, puedes observar que los datos de 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)

    View Slide

  75. Tambien se pueden crear alertas, más bien se deben crear 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)

    View Slide

  76. ¿Cómo recolectamos datos?
    Los datos a recolectar básicamente proceden de 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)

    View Slide

  77. O dejo un enlace de lo que es la recolección 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)

    View Slide

  78. Solo mencionaros que este tipo de base datos viene acompañada 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)

    View Slide

  79. ¿Visualización de datos?
    Tal y como hemos adelantado antes con 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)

    View Slide

  80. Rascamos un poco sobre la superficie de:
    Sistema de Alertas(1/4)
    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

    View Slide

  81. Rascamos un poco sobre la superficie de:
    Sistema de Alertas(2/4)
    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.

    View Slide

  82. Rascamos un poco sobre la superficie de:
    Sistema de Alertas(3/4)
    ¿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).

    View Slide

  83. Rascamos un poco sobre la superficie de:
    Sistema de Alertas(4/4)
    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.

    View Slide

  84. Rascamos un poco sobre la superficie de:
    Logs(1/3)
    Aunque luego 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

    View Slide

  85. Rascamos un poco sobre la superficie de:
    Logs(2/3)
    Y es 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

    View Slide

  86. Rascamos un poco sobre la superficie de:
    Logs(3/3)
    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.

    View Slide

  87. Ejemplos
    Arquitectura de Monitorización(1/4)
    arquitectura de la aplicación
    Use Case #1 – Kubernetes / K8s, genérico independiente de la nube
    Kubernetes API Prometheus
    Server
    Alert
    Manager
    Node Node Node
    Pull
    Pull
    Push

    View Slide

  88. Ejemplos
    Arquitectura de Monitorización(2/4)
    Esta definición de una arquitectura clásica 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.

    View Slide

  89. Ejemplos
    Arquitectura de Monitorización(3/4)
    arquitectura de la aplicación
    Use Case #2 – Serverless en Azure

    View Slide

  90. Ejemplos
    Arquitectura de Monitorización(4/4)
    En el mundo Serverless con Azure, 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.

    View Slide

  91. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(1/13)
    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

    View Slide

  92. Metricas para Kubernetes Descripción
    Resumen Nodos Nº Total de nodos 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)

    View Slide

  93. Metricas para Kuberenetes Descripción
    Nodo Utilización de la CPU por 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)

    View Slide

  94. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(5/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:

    View Slide

  95. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(6/13)

    View Slide

  96. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(7/13)
    Como estas Metricas ya están out-the-box y tienes la posibilidad de ir a una parte en concreto y comenzar a probar:

    View Slide

  97. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(8/13)
    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.

    View Slide

  98. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(9/13)
    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.

    View Slide

  99. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(10/13)
    Como el tema del Serverless hablo de Azure, os muestro que es un Dahsboard con una pequeña captura:

    View Slide

  100. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(11/13)
    Frente a uno generado con Grafana:

    View Slide

  101. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(12/13)
    Como se ve a vista de pájaro una consulta KQL contra logs y lo que puedes hacer:

    View Slide

  102. Lo mínimo para asegurar la confianza
    ¿Qué se debe monitorizar?(13/13)
    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.

    View Slide

  103. Algunos enlaces de interés
    ¿Más información?
    Sí, solo he rascado 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í

    View Slide

  104. Sección IV
    Herramientas
    Open Source y Azure

    View Slide

  105. Un pequeño listado
    Herramientas(1/2)
    Ya vimos al principio que puedes 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

    View Slide

  106. Un pequeño listado
    Herramientas(2/2)
    Y en el ámbito del pago, 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.

    View Slide

  107. AZURE WELL ARCHITECTED FRAMEWORK

    View Slide

  108. ¡Gracias!
    Puedes encontrarme buscando por jmfloreszazo en
    https://jmfloreszazo.com

    View Slide