Recientemente, David O’Brien fundó su propia empresa Xirus (https://xirus.com.au), enfocándose en los productos en la nube de Microsoft Azure Stack. Están diseñados para la creación y ejecución coherente de aplicaciones híbridas en centros de datos, ubicaciones de borde, oficinas remotas y la nube.
David capacita a individuos y empresas en todo lo relacionado con Microsoft Azure y Azure DevOps (anteriormente VSTS) y aún realiza consultorías prácticas e infraestructura como código. Ha sido galardonado durante 5 años con el premio Microsoft MVP (Most Valuable Professional) y recientemente recibió el premio MVP Azure. Como coorganizador de Melbourne Microsoft Cloud y Datacentre Meetup, O’Brien habla regularmente en conferencias internacionales, combinando su interés por viajar por el mundo con su pasión por compartir historias de TI con la comunidad. El blog de David se encuentra en , también publica sus entrenamientos en línea en Pluralsight.
La presentación aborda la importancia de las métricas para comprender qué está sucediendo en su entorno y cómo funciona su aplicación. Microsoft Azure ofrece una manera potente y sencilla de visualizar métricas para todo tipo de cargas de trabajo, y la charla explica cómo se pueden utilizar todas ellas.
A las 3 de la mañana, un domingo, te despierta de repente una alerta de texto: “la aplicación crítica no responde de nuevo”. ¿Qué está pasando? ¿Dónde está el problema de los ‘ralentizaciones’? En esta charla, aprenderás sobre los servicios que Microsoft Azure ofrece a sus clientes para la recolección de logs y, en particular, las métricas de tus cargas de trabajo en la nube. David explicará qué métricas deben interesarte al trabajar en la plataforma en la nube y cómo acceder a ellas. Conocerás herramientas de código abierto y la construcción de paneles de monitoreo, y al final adquirirás suficiente conocimiento para construir tus propios paneles.
Y si a las 3 de la mañana te despierta de nuevo un mensaje sobre la caída de una aplicación crítica, podrás resolver rápidamente la causa.
Buenos días, hoy vamos a hablar sobre métricas. Mi nombre es David O’Brien, soy el cofundador y propietario de una pequeña empresa de consultoría australiana llamada Xirus. Gracias nuevamente por venir a pasar su tiempo conmigo. Entonces, ¿por qué estamos aquí? Para hablar sobre métricas, más bien, yo les contaré sobre ellas, y antes de hacer cualquier cosa, comencemos con la teoría.
Les contaré qué son las métricas, qué se puede hacer con ellas, en qué hay que fijarse, cómo recolectar métricas e integrar la recopilación de métricas en Azure y qué es la visualización de métricas. Les mostraré cómo se ven estas cosas en la nube de Microsoft y cómo trabajar con esta nube.
Antes de comenzar, pediré que levanten la mano aquellos que usan Microsoft Azure. ¿Y quién trabaja con AWS? Veo que son pocos. ¿Y con Google? ¿ALI Cloud? ¡Una persona! Excelente. Entonces, ¿qué son las métricas? La definición oficial del Instituto Nacional de Estándares y Tecnología de EE. UU. es la siguiente: "Una métrica es un estándar de medición que describe las condiciones y reglas para llevar a cabo la medición de alguna propiedad y sirve para comprender los resultados de la medición". ¿Qué significa esto?
Vamos a considerar, por ejemplo, una métrica para el cambio del espacio libre en el disco de una máquina virtual. Por ejemplo, se nos da el número 90, y este número significa porcentajes, es decir, el volumen de espacio libre en el disco es del 90%. Cabe destacar que no es muy interesante leer la descripción de la definición de métricas que ocupa 40 páginas en formato pdf.
Sin embargo, la métrica no indica cómo se obtuvieron los resultados de la medición, solo muestra este resultado. ¿Qué hacemos con las métricas?
Primero, medimos el valor de algo para luego utilizar el resultado de la medición.
Por ejemplo, hemos aprendido sobre el volumen de espacio libre en el disco y ahora podemos utilizarlo, usar esta memoria, etc. Después de obtener el resultado de la métrica, debemos interpretarlo. Por ejemplo, si la métrica da un resultado de 90, debemos saber qué significa este número: ¿el volumen de espacio libre o el volumen de espacio ocupado en el disco en porcentajes o gigabytes, la latencia de la red de 90 ms, y así sucesivamente? Es decir, necesitamos interpretar el significado de los valores de la métrica. Para que las métricas tengan sentido, después de interpretar un valor debemos asegurar la recolección de muchos valores. Esto es muy importante, ya que muchas personas no son conscientes de la necesidad de recolectar métricas. Microsoft ha facilitado mucho el proceso de obtención de métricas, pero usted mismo debe asegurarse de recogerlas. Estas métricas se almacenan solo durante 41 días y en el día 42 desaparecen. Así que, dependiendo de las características de su hardware externo o interno, usted debe preocuparse por cómo almacenar las métricas por más de 41 días —en forma de logs, registros, etc. Así, después de la recolección, debe colocarlas en algún lugar que permita, si es necesario, recuperar toda la estadística de los cambios de resultados de las métricas. Al hacerlo, podrá comenzar a trabajar de manera efectiva con ellas.
Solo después de que obtenga los valores de las métricas, los interprete y los recolecte, podrá crear un SLA —un acuerdo sobre el nivel de servicio proporcionado. Este SLA puede no tener un significado especial para sus clientes, es más importante para sus colegas, gerentes, quienes aseguran el funcionamiento del sistema y se preocupan por su funcionalidad. La métrica puede medir la cantidad de tickets; por ejemplo, recibe 5 tickets al día, y en este caso muestra la velocidad de respuesta a las solicitudes de los usuarios y la rapidez en la resolución de problemas. La métrica no debe simplemente informar que su sitio carga en 20 ms o que la velocidad de respuesta es de 20 ms; la métrica es más que un solo indicador técnico.
Por lo tanto, el objetivo de nuestra conversación es presentarle un panorama detallado de la esencia de las métricas. Una métrica sirve para que, al mirarla, usted pueda obtener una visión completa del proceso.
Una vez que obtuvimos la métrica, podemos garantizar en un 99% el estado operativo del sistema, porque no es solo una mirada al archivo de registro que indica que el sistema está funcionando. Una garantía del 99% de operatividad significa que, por ejemplo, en el 99% de los casos, la API responde a una velocidad normal de 30 ms. Esto es precisamente lo que preocupa a tus usuarios, colegas y gerentes. Muchos de nuestros clientes monitorean los registros de los servidores web y, al no notar ningún error, piensan que todo está en orden. Por ejemplo, ven una velocidad de red de 200 mb/s y piensan: "¡bien, todo excelente!". Pero para lograr esos 200, los usuarios requieren un tiempo de respuesta de 30 milisegundos, y esa es precisamente la métrica que no se mide ni se recoge en los archivos de registro. Sin embargo, los usuarios se sorprenden de que el sitio se cargue muy lentamente, porque al no contar con la métrica necesaria, no conocen la razón de este comportamiento.
Pero dado que tenemos un SLA que garantiza el 100% de operatividad, los clientes comienzan a expresar su indignación, ya que en realidad es muy difícil usar el sitio. Por lo tanto, para crear un SLA objetivo, es necesario tener una visión completa del proceso, formada por las métricas recopiladas. Este es el tema de mi constante disputa con algunos proveedores, quienes al crear el SLA no comprenden lo que significa el término «uptime» y, en la mayoría de los casos, no explican a sus clientes cómo funciona su API.
Si has creado un servicio, por ejemplo, una API para un tercero, debes entender lo que significa la métrica obtenida de 39,5: una respuesta, una respuesta exitosa, una respuesta a una velocidad de 20 ms o a una velocidad de 5 ms. Eres tú quien debe adaptar su SLA a tu propio SLA, a tus propias métricas.
Habiendo aclarado todo esto, se puede proceder a crear un magnífico panel de monitoreo. Digan, ¿alguien ya ha usado la aplicación de visualización interactiva Grafana? ¡Excelente! Soy un gran fan de este software de código abierto, porque es gratuito y fácil de usar.
Si aún no has utilizado Grafana, te mostraré cómo trabajar con ella. Quienes nacieron en los 80 y 90 probablemente recuerden a los cariñosos ositos CareBears. No sé cuán populares fueron esos ositos en Rusia, pero en lo que respecta a las métricas, debemos ser unos "osos cariñosos". Como dije, necesitas una visión completa del funcionamiento de todo el sistema, y no debe limitarse solo a tu API, tu sitio web o el servicio que se ejecuta en una máquina virtual.
Debes organizar la recopilación de las métricas que reflejan de manera más completa el funcionamiento de todo el sistema. La mayoría de ustedes son desarrolladores de software, por lo que su vida está cambiando constantemente, adaptándose a nuevas demandas del producto, y así como están preocupados por los procesos de codificación, también deben preocuparse por las métricas. Deben saber cómo cada métrica se relaciona con cada línea de código que han escrito. Por ejemplo, la próxima semana comienzan una nueva campaña de marketing y esperan que un gran número de usuarios visite su sitio. Para analizar este evento, necesitarás métricas, y tal vez necesites un panel completo para rastrear la actividad de estas personas. Las métricas te ayudarán a entender cuán exitosa y cómo realmente funciona tu campaña de marketing. Te ayudarán, por ejemplo, a desarrollar un CRM efectivo: un sistema de gestión de relaciones con los clientes.
Así que, comencemos con nuestro servicio en la nube Azure. Es muy fácil encontrar y organizar la recopilación de métricas porque aquí tienes Azure Monitor. Este monitor centraliza la gestión de la configuración de tu sistema. Cada uno de los elementos de Azure que desees aplicar en tu sistema tiene numerosas métricas habilitadas por defecto. Es una aplicación gratuita que funciona directamente "fuera de la caja" y no requiere ninguna configuración previa, no necesitas escribir nada ni "ajustarlo" a tu sistema. Nos aseguraremos de esto al revisar la siguiente demo.
Además, existe la posibilidad de enviar estas métricas a aplicaciones de terceros, como el sistema de almacenamiento y análisis de logs Splunk, la aplicación en la nube para la gestión de logs SumoLogic, la herramienta de procesamiento de logs ELK, IBM Radar. Sin embargo, hay algunas diferencias pequeñas que dependen de los recursos que esté utilizando: máquinas virtuales, servicios de red, bases de datos de Azure SQL, es decir, el uso de métricas varía según las funciones de su entorno de trabajo. No diré que estas diferencias son significativas, pero, desafortunadamente, están presentes y deben tenerse en cuenta. La activación y el envío de métricas se pueden realizar de varias maneras: a través del Portal, CLI/Power Shell o utilizando plantillas ARM.
Antes de comenzar la primera demostración, responderé a las preguntas que tengan. Si no hay preguntas, comencemos. En la pantalla se muestra cómo se ve la página de Azure Monitor. ¿Alguien de ustedes puede decir que este monitor no funciona?
Entonces, ahora todo está en orden, ven cómo se ven los servicios de monitorización. Puedo decir que es una herramienta excelente y muy fácil de usar para el trabajo diario. Con ella se pueden monitorizar aplicaciones, redes e infraestructura. Recientemente, la interfaz de monitorización ha sido mejorada, y si antes los servicios estaban ubicados en diferentes lugares, ahora toda la información sobre los servicios se consolida en la página de inicio del monitor.
La tabla de métricas es una pestaña en la ruta HomeMonitorMetrics, a la que se puede acceder para ver todas las métricas disponibles y seleccionar las necesarias. Pero si necesita habilitar la recopilación de métricas, debe usar la ruta del directorio HomeMonitorDiagnostic settings y marcar las casillas de verificación de métricas Habilitado/Deshabilitado. Por defecto, prácticamente todas las métricas están habilitadas, pero si necesita activar algo adicional, necesitará cambiar el estado de diagnóstico de Deshabilitado a Habilitado.
Para ello, debe hacer clic en la fila de la métrica seleccionada y en la pestaña que se abre, habilitar el modo de diagnóstico. Si va a analizar la métrica seleccionada, después de hacer clic en el enlace Activar diagnóstico, debe marcar en la ventana emergente la casilla de verificación Enviar a Log Analytics.
Log Analytics es algo similar a Splunk, pero más económico. Este servicio permite recopilar todas tus métricas, registros y todo lo que necesites, y almacenarlos en el espacio de trabajo de Log Analytics. El servicio utiliza un lenguaje especial para consultar datos, KQL – Kusto Query Language, cuyo funcionamiento revisaremos en la próxima demostración. Por ahora, cabe destacar que con él puedes formular consultas sobre métricas, registros, términos, tendencias, patrones, etc., y crear paneles de control.
Así que marcamos la casilla Send to Log Analytics y las casillas del panel LOG: DataPlaneRequests, MongoRequests y QueryRuntimeStatistics, y más abajo en el panel METRIC – la casilla Requests. Luego asignamos un nombre y guardamos la configuración. En la línea de comandos, esto se representa con dos líneas de código. Por cierto, la interfaz de Azure Cloud en este sentido se asemeja a Google, que también permite usar la línea de comandos en tu navegador web. AWS no tiene nada parecido, así que Azure es mucho más conveniente en este aspecto.
Por ejemplo, puedo ejecutar la demostración a través de la interfaz web, sin necesidad de usar ningún código en mi portátil. Para ello, debo autenticarme con mi cuenta de Azure. Luego puedo usar, por ejemplo, terrafone, si ya lo estás utilizando, esperar a que se conecte al servicio y obtener un entorno de trabajo Linux, que es el que Microsoft utiliza por defecto.
A continuación, utilizo Bash, integrado en Azure Cloud Shell. Una característica muy útil es el IDE integrado en el navegador, una versión simplificada de VS Code. Después, puedo acceder a mi plantilla de métricas de errores, modificarla y ajustarla a mis necesidades.
Al configurar la recolección de métricas en esta plantilla, puedes aplicarla para crear métricas para toda tu infraestructura. Una vez que hayamos aplicado las métricas, las hayamos recopilado y guardado, necesitaremos visualizarlas.
Azure Monitor se ocupa únicamente de las métricas y no permite obtener una visión general del estado de tu sistema. Puedes tener una serie de otras aplicaciones que están ejecutándose fuera del entorno de Azure. Así que si necesitas monitorear todos los procesos, visualizando todas las métricas recopiladas en un solo lugar, Azure Monitor no es adecuado para esto.
Para abordar esta tarea, Microsoft ofrece la herramienta Power BI: un software integral para análisis empresarial que incluye la visualización de una amplia variedad de datos. Es un producto bastante costoso, y su precio depende del conjunto de funciones que necesites. Por defecto, te ofrece 48 tipos de datos procesables y se conecta a las bases de datos SQL Azure, Azure Data Lake Storage, los servicios de Machine Learning de Azure y Azure Databricks. Aprovechando su escalabilidad, puedes obtener nuevos datos cada 30 minutos. Esto puede ser suficiente para tus necesidades o no, si requieres visualización de monitoreo en tiempo real. En este caso, se recomienda utilizar aplicaciones como la mencionada Grafana. Además, la documentación de Microsoft describe la posibilidad de enviar métricas, logs y tablas de eventos mediante SIEM: herramientas a los sistemas de visualización Splunk, SumoLogic, ELK e IBM radar.
23:40 min
La continuación será muy pronto...
Un poco de publicidad 🙂
Gracias por permanecer con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendando a tus conocidos, , un análogo único de servidores entry-level que hemos diseñado para Ti: (disponibles opciones con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
¿Dell R730xd a mitad de precio en el centro de datos Equinix Tier IV en Ámsterdam? Solo aquí ¡en los Países Bajos! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — ¡desde $99! Lee sobre cómo
Fuente: habr.com
