David O'Brien lanzó recientemente su propia empresa, Xirus (https://xirus.com.au), centrándose en los productos en la nube de Microsoft Azure Stack. Están diseñados para crear y ejecutar de manera consistente aplicaciones híbridas en centros de datos, ubicaciones perimetrales, oficinas remotas y la nube.
David capacita a personas y empresas en todo lo relacionado con Microsoft Azure y Azure DevOps (anteriormente VSTS) y todavía realiza consultoría práctica e infracodificación. Ha sido ganador del premio Microsoft MVP (Microsoft Most Valuable Professional) durante 5 años y recientemente recibió el premio Azure MVP. Como coorganizador del Microsoft Cloud and Datacenter Meetup de Melbourne, O'Brien habla regularmente en conferencias internacionales, combinando su interés en viajar por el mundo con su pasión por compartir historias de TI con la comunidad. El blog de David está ubicado en , también publica su formación online en Pluralsight.
La charla habla sobre la importancia de las métricas para comprender lo que sucede en su entorno y el rendimiento de su aplicación. Microsoft Azure tiene una forma potente y sencilla de mostrar métricas para todo tipo de cargas de trabajo, y la conferencia explica cómo puede usarlas todas.
A las 3 de la madrugada de un domingo, mientras duermes, de repente te despierta un mensaje de texto: "la aplicación supercrítica no responde de nuevo". ¿Qué está sucediendo? ¿Dónde y cuál es el motivo de los “frenos”? En esta charla, conocerá los servicios que Microsoft Azure ofrece a los clientes para recopilar registros y, en particular, métricas de sus cargas de trabajo en la nube. David le dirá qué métricas deberían interesarle cuando trabaje en una plataforma en la nube y cómo llegar a ellas. Aprenderá sobre herramientas de código abierto y creación de paneles, y terminará con el conocimiento suficiente para crear sus propios paneles.
Y si a las 3 a.m. le vuelve a despertar un mensaje que indica que una aplicación crítica ha fallado, podrá descubrir rápidamente la causa.
Buenas tardes, hoy hablaremos de métricas. Mi nombre es David O'Brien, soy cofundador y propietario de una pequeña empresa consultora australiana, Xirus. Gracias de nuevo por venir aquí a pasar tu tiempo conmigo. ¿Por qué estamos aquí? Para hablar de métricas, o mejor dicho, os hablaré de ellas, y antes de hacer nada, comencemos con la teoría.
Le diré qué son las métricas, qué puede hacer con ellas, a qué debe prestar atención, cómo recopilar y habilitar la recopilación de métricas en Azure y qué es la visualización de métricas. Le 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. ¿Quién trabaja con AWS? Veo pocos. ¿Qué pasa con Google? ¿Nube ALI? ¡Un hombre! Excelente. Entonces, ¿qué son las métricas? La definición oficial del Instituto Nacional de Estándares y Tecnología de EE. UU. es: “Una métrica es un estándar de medición que describe las condiciones y reglas para medir una propiedad y sirve para comprender los resultados de la medición”. ¿Qué significa?
Tomemos un ejemplo de una métrica para cambiar el espacio libre en disco de una máquina virtual. Por ejemplo, nos dan el número 90 y este número significa porcentaje, es decir, la cantidad de espacio libre en el disco es del 90%. Observo 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 dice cómo se obtuvo el resultado 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, descubrimos la cantidad de espacio libre en disco y ahora podemos usarlo, usar esta memoria, etc. Una vez que hemos recibido el resultado de la métrica, debemos interpretarlo. Por ejemplo, la métrica arrojó un resultado de 90. Necesitamos saber qué significa este número: la cantidad de espacio libre o la cantidad de espacio en disco utilizado en porcentaje o gigabytes, latencia de red igual a 90 ms, etc., es decir , necesitamos interpretar el significado del valor métrico. Para que las métricas sean significativas, después de interpretar un único valor de métrica, debemos asegurarnos de que se recopilen varios valores. Esto es muy importante porque muchas personas no son conscientes de la necesidad de recopilar métricas. Microsoft ha hecho que sea muy fácil recopilar métricas, pero depende de usted asegurarse de que se recopilen. Estas métricas se almacenan solo durante 41 días y desaparecen al día 42. Por lo tanto, dependiendo de las propiedades de su equipo externo o interno, debe cuidar cómo guardar métricas durante más de 41 días, en forma de registros, registros, etc. Por lo tanto, después de la recopilación, debe colocarlos en algún lugar que le permita obtener todas las estadísticas de cambios en los resultados de las métricas, si es necesario. Una vez que los coloque allí, podrá comenzar a trabajar con ellos de manera efectiva.
Sólo después de obtener las métricas, interpretarlas y recopilarlas, podrá crear un SLA (acuerdo de nivel de servicio). Este SLA puede no ser de mucha importancia para sus clientes; es más importante para sus colegas, gerentes, aquellos que mantienen el sistema y se preocupan por su funcionalidad. La métrica puede medir la cantidad de tickets; por ejemplo, recibe 5 tickets por día y, en este caso, muestra la velocidad de respuesta a las solicitudes de los usuarios y la velocidad de resolución de problemas. Una métrica no debería decir simplemente que su sitio se carga en 20 ms o que su velocidad de respuesta es de 20 ms, una métrica es más que un simple indicador técnico.
Por lo tanto, el objetivo de nuestra conversación es presentarles una imagen detallada de la esencia de las métricas. La métrica sirve para que con solo mirarla puedas obtener una imagen completa del proceso.
Una vez que tenemos la métrica, podemos garantizar al 99% que el sistema está funcionando, porque no basta con mirar un archivo de registro que dice que el sistema está funcionando. Una garantía de tiempo de actividad del 99 % significa que, por ejemplo, el 99 % del tiempo la API responde a una velocidad normal de 30 ms. Esto es exactamente lo que interesa a sus usuarios, colegas y directivos. Muchos de nuestros clientes monitorean los registros del servidor web, pero no notan ningún error en ellos y piensan que todo está bien. Por ejemplo, ven una velocidad de red de 200 Mb/s y piensan: "¡vale, todo está genial!". Pero para alcanzar esos 200, los usuarios necesitan una velocidad de respuesta de 30 milisegundos, y este es precisamente el indicador que no se mide ni se recoge en los archivos de registro. Al mismo tiempo, los usuarios se sorprenden de que el sitio se carga muy lentamente, ya que, al no tener las métricas necesarias, no conocen los motivos de este comportamiento.
Pero como tenemos un SLA de tiempo de actividad del 100%, los clientes empiezan a quejarse porque el sitio es realmente muy difícil de usar. Por lo tanto, para crear un SLA objetivo, es necesario ver la imagen completa del proceso creado por las métricas recopiladas. Este es un problema constante que tengo con algunos proveedores que, al crear SLA, no tienen idea de lo que significa el término "tiempo de actividad" y en la mayoría de los casos no explican a sus clientes cómo funciona su API.
Si creó un servicio, por ejemplo, una API para una tercera persona, debe comprender qué significa la métrica resultante de 39,5: respuesta, respuesta exitosa, respuesta a una velocidad de 20 ms o a una velocidad de 5 ms. Depende de usted adaptar su SLA a su propio SLA, a sus propias métricas.
Una vez que haya descubierto todo esto, puede comenzar a crear un panel impresionante. Dime, ¿alguien ha utilizado ya la aplicación de visualización interactiva Grafana? ¡Excelente! Soy un gran admirador de este código abierto porque es gratuito y fácil de usar.
Si aún no has usado Grafana, te diré cómo trabajar con él. Cualquier persona nacida en los años 80 y 90 probablemente recuerda a CareBears. No sé qué tan populares eran estos osos en Rusia, pero cuando se trata de métricas, deberíamos ser los mismos "ositos cariñosos". Como dije, necesita una visión general de cómo funciona todo el sistema, y no debería tratarse solo de su API, su sitio web o el servicio que se ejecuta en una máquina virtual.
Debe organizar la recopilación de aquellas métricas que reflejen más plenamente el funcionamiento de todo el sistema. La mayoría de ustedes son desarrolladores de software, por lo que su vida cambia constantemente, se adapta a los requisitos de nuevos productos y, así como les preocupan los procesos de codificación, deberían preocuparse por las métricas. Necesita saber cómo se relaciona la métrica con cada línea de código que escribe. Por ejemplo, la próxima semana comenzará una nueva campaña de marketing y espera que una gran cantidad de usuarios visiten su sitio. Para analizar este evento, necesitará métricas y es posible que necesite un panel completo para rastrear la actividad de estas personas. Necesitará métricas para comprender el éxito de su campaña de marketing y su rendimiento real. Le ayudarán, por ejemplo, a desarrollar un CRM (sistema de gestión de relaciones con los clientes) eficaz.
Entonces, comencemos con nuestro servicio en la nube Azure. Es muy fácil encontrar y organizar la recopilación de métricas porque tiene Azure Monitor. Este monitor centraliza la gestión de la configuración de su sistema. Cada uno de los elementos de Azure que desea aplicar a su sistema tiene muchas métricas habilitadas de forma predeterminada. Esta es una aplicación gratuita que funciona desde el primer momento y no requiere ninguna configuración preliminar; no necesita escribir ni "atornillar" nada en su sistema. Verificaremos esto mirando la siguiente demostración.
Además, es posible enviar estas métricas a aplicaciones de terceros, como el sistema de análisis y almacenamiento de registros Splunk, la aplicación de gestión de registros basada en la nube SumoLogic, la herramienta de procesamiento de registros ELK e IBM Radar. Es cierto que existen ligeras diferencias que dependen de los recursos que utilice: una máquina virtual, servicios de red, bases de datos Azure SQL, es decir, el uso de métricas difiere según las funciones de su entorno de trabajo. No diré que estas diferencias sean graves, pero lamentablemente siguen presentes y hay que tenerlo en cuenta. Habilitar y enviar métricas es posible de varias maneras: a través de Portal, CLI/Power Shell o usando plantillas ARM.
Antes de comenzar mi primera demostración, responderé cualquier pregunta que puedas tener. Si no hay preguntas, comencemos. La pantalla muestra cómo se ve la página de Azure Monitor. ¿Alguno de ustedes puede decir que este monitor no funciona?
Ahora todo está bien, puedes ver cómo se ven los servicios del monitor. Puedo decir que esta es una herramienta excelente y muy sencilla para el trabajo diario. Se puede utilizar para monitorear aplicaciones, redes e infraestructura. Recientemente, se ha mejorado la interfaz de monitoreo y, si antes los servicios estaban ubicados en diferentes lugares, ahora toda la información sobre los servicios está consolidada en la página de inicio del monitor.
La tabla de métricas es una pestaña a lo largo de la ruta HomeMonitorMetrics, a la que puede acceder para ver todas las métricas disponibles y seleccionar las que necesita. Pero si necesita habilitar la recopilación de métricas, debe usar la ruta del directorio de configuración de HomeMonitorDiagnostic y marcar las casillas de verificación de métricas habilitadas/deshabilitadas. De forma predeterminada, casi todas las métricas están habilitadas, pero si necesita habilitar algo adicional, deberá cambiar el estado de diagnóstico de Deshabilitado a Habilitado.
Para hacer esto, haga clic en la línea de la métrica seleccionada y en la pestaña que se abre, habilite 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 la casilla de verificación Enviar a Log Analytics en la ventana que aparece.
Log Analytics es un poco similar a Splunk, pero cuesta menos. Este servicio le permite recopilar todas sus métricas, registros y todo lo demás que necesita y colocarlos en el espacio de trabajo de Log Analytics. El servicio utiliza un lenguaje de procesamiento de consultas KQL especial: Kusto Quarry Language, veremos su funcionamiento en la próxima demostración. Por ahora, señalaré que con su ayuda puedes crear consultas sobre métricas, registros, términos, tendencias, patrones, etc. y crear paneles de control.
Entonces, marcamos la casilla de verificación Enviar a Log Analytics y las casillas de verificación del panel LOG: DataPlaneRequests, MongoRequests y QueryRuntimeStatistics, y debajo en el panel METRIC, la casilla de verificación Solicitudes. Luego le asignamos un nombre y guardamos la configuración. En la línea de comando, esto representa dos líneas de código. Por cierto, Azure Cloud Shell se parece en este sentido a Google, que también le permite utilizar la línea de comandos en su navegador web. AWS no tiene nada de eso, por lo que Azure es mucho más conveniente en este sentido.
Por ejemplo, puedo ejecutar una demostración a través de la interfaz web sin utilizar ningún código en mi computadora portátil. Para hacer esto, debo autenticarme con mi cuenta de Azure. Luego puedes usar, por ejemplo, terrafone, si ya lo usas, espera la conexión al servicio y obtienes el entorno de trabajo Linux que Microsoft usa por defecto.
A continuación, uso Bash, integrado en Azure Cloud Shell. Algo muy útil es el IDE integrado en el navegador, una versión ligera de VS Code. A continuación, puedo acceder a mi plantilla de métricas de error, editarla y personalizarla según mis necesidades.
Una vez que configure la recopilación de métricas en esta plantilla, podrá usarla para crear métricas para toda su infraestructura. Una vez que hayamos aplicado las métricas, las hayamos recopilado y almacenado, necesitaremos visualizarlas.
Azure Monitor solo se ocupa de métricas y no proporciona una imagen general del estado de su sistema. Es posible que tenga otras aplicaciones ejecutándose fuera del entorno de Azure. Entonces, si necesita monitorear todos los procesos y visualizar todas las métricas recopiladas en un solo lugar, Azure Monitor no es adecuado para esto.
Para solucionar este problema, Microsoft ofrece la herramienta Power BI, un software integral de análisis empresarial que incluye la visualización de una amplia variedad de datos. Este es un producto bastante caro, cuyo costo depende del conjunto de funciones que necesita. De forma predeterminada, le ofrece 48 tipos de datos para procesar y está vinculado a Azure SQL Data Warehouses, Azure Data Lake Storage, Azure Machine Learning Services y Azure Databricks. Gracias a la escalabilidad, puede recibir nuevos datos cada 30 minutos. Esto puede ser suficiente o no para sus necesidades si necesita visualización de monitoreo en tiempo real. En este caso se recomienda utilizar aplicaciones como la Grafana que mencioné. Además, la documentación de Microsoft describe la capacidad de enviar métricas, registros y tablas de eventos utilizando herramientas SIEM a los sistemas de visualización Splunk, SumoLogic, ELK e IBM radar.
23:40 min
Continuará muy pronto...
Algunos anuncios 🙂
Gracias por estar con nosotros. ¿Te gustan nuestros artículos? ¿Quieres ver más contenido interesante? Apóyanos haciendo un pedido o recomendándonos a amigos, , un análogo único de servidores de nivel de entrada, que fue inventado por nosotros para usted: (disponible con RAID1 y RAID10, hasta 24 núcleos y hasta 40GB DDR4).
Dell R730xd 2 veces más barato en el centro de datos Equinix Tier IV en Amsterdam? Solo aqui ¡en los Paises Bajos! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ¡desde $99! Leer acerca de
Fuente: habr.com