Project Flash: uso de Azure Resource Health para supervisar la disponibilidad de máquinas virtuales de Azure

Artículo
02/18/2024

Azure Resource Health es una solución que ofrece Flash. Flash es el nombre interno de un proyecto dedicado a crear un mecanismo sólido, confiable y rápido para que los clientes supervisen el estado de las máquinas virtuales (VM).

En este artículo se describe el uso de Azure Resource Health para supervisar la disponibilidad de máquinas virtuales de Azure. Para obtener información general sobre las soluciones Flash, consulte la Información general de Flash.

Para obtener documentación específica de las otras soluciones que ofrece Flash, elija entre los siguientes artículos:

Azure Resource Health

Ofrece comprobaciones de estado inmediatas y fáciles de usar para los recursos individuales a través del portal. Los clientes pueden acceder rápidamente a la hoja de estado de los recursos en el portal y revisar también un registro histórico de 30 días de las comprobaciones de estado, lo que lo convierte en una herramienta excelente para una solución de problemas rápida y sencilla. La característica existente Azure Resource Health le ayuda a diagnosticar y obtener soporte para los problemas de servicio que afectan a sus recursos Azure. Informa sobre el estado actual y pasado de los recursos, que muestra los intervalos de tiempo que cada uno de los recursos no están disponibles.

Pero sabemos que nuestros clientes y asociados están interesados en comprender qué causa problemas técnicos subyacentes, y en mejorar cómo pueden recibir comunicaciones sobre cualquier problema—para incorporar a los procesos de supervisión, explicar los problemas a otras partes interesadas y, en última instancia, para informar a las decisiones empresariales.

Causas principales de incidencias de máquina virtual en Azure Resource Health

Recientemente hemos enviado una mejora a la experiencia de estado de los recursos que mejorará la información que compartimos con los clientes sobre errores de máquina virtual y proporcionamos más contexto sobre la causa principal que provocó la incidencia. Ahora, además de recibir una notificación rápida cuando la disponibilidad de una máquina virtual se ve afectada, los clientes pueden esperar que se agregue una causa principal más adelante una vez que nuestro sistema automatizado de Análisis de la causa principal (RCA) identifique el componente de la plataforma Azure con errores que provocó el error de la máquina virtual. Veamos un ejemplo para ver cómo funciona este proceso en la práctica:

En el momento T1, un servidor de rack se queda sin conexión debido a una incidencia de red, lo que provoca que las máquinas virtuales del bastidor pierdan conectividad. Las mejoras recientes de confiabilidad relacionadas con la arquitectura de red se compartirán en un futuro entrada de blog De avance de confiabilidad ¡vea este espacio!

En el momento T2, la supervisión interna de Azure reconoce que no puede acceder a las máquinas virtuales en el bastidor y comienza a mitigar mediante la reimplementación de las máquinas virtuales afectadas en un nuevo bastidor. Durante este tiempo, se envía una anotación a los clientes que notifican a los clientes que su máquina virtual se ve afectada actualmente y no está disponible.

En el momento T3, la telemetría de la plataforma desde la parte superior del conmutador de bastidor, la máquina host y los sistemas de supervisión internos se correlacionan conjuntamente en nuestro motor de RCA para derivar la causa principal del error. Una vez calculado, el RCA se vuelve a publicar en el estado de los recursos junto con las recomendaciones de resistencia arquitectónica pertinentes que los clientes pueden implementar para minimizar la probabilidad de impacto en el futuro.

Aunque la funcionalidad inicial de notificación de tiempo de inactividad tiene varios años, la publicación de una instrucción de causa principal es una nueva adición. Ahora, vamos a profundizar en los detalles de cómo derivamos estas causas principales.

Motor de análisis de causa principal

Echemos un vistazo más detallado al ejemplo anterior y veamos los detalles de cómo funciona el motor RCA y la tecnología detrás de él. En el núcleo de nuestro motor de RCA para máquinas virtuales se Azure Data Explorer (ADX), un servicio de macrodatos optimizado para el análisis de telemetría de registros de gran volumen. Azure Data Explorer habilita la capacidad de analizar fácilmente los terabytes de telemetría de registros de dispositivos y servicios que componen la plataforma Azure, unirlos e interpretar los flujos de información correlacionados para derivar una causa principal de diferentes escenarios de error. Esto termina siendo un proceso de ingeniería de datos de varios pasos:

Fase 1: Detección del tiempo de inactividad

La primera fase del análisis de la causa principal es definir el desencadenador en el que se ejecuta el análisis. En el caso de las máquinas virtuales, queremos determinar las causas principales cada vez que una máquina virtual se reinicia inesperadamente, por lo que el desencadenador es una máquina virtual que pasa de un estado ascendente a un estado inactivo. La identificación de estas transiciones desde la telemetría de la plataforma es sencilla en la mayoría de los escenarios, pero es más complicado en torno a ciertos tipos de errores de infraestructura en los que la telemetría de la plataforma podría perderse debido a errores de dispositivo o pérdida de energía. Para controlar estas clases de errores, se requieren—otras técnicas, como el seguimiento de la pérdida de datos como una posible indicación de una transición de disponibilidad de máquina virtual. Azure Data Explorer destaca en este momento del análisis de series y se puede encontrar una visión más detallada de las técnicas en torno a este proceso en la Comunidad tecnológica de Microsoft: Cálculo del tiempo de inactividad mediante funciones de ventana y funciones de serie temporal en Azure Data Explorer.

Fase 2: Análisis de correlación

Una vez definido un evento de desencadenador (en este caso, una máquina virtual que pasa a un estado incorrecto), la siguiente fase es el análisis de correlación. En este paso, se usa la presencia del evento de desencadenador para correlacionar la telemetría desde puntos de la plataforma Azure, como:

Host de Azure: la hoja física que hospeda máquinas virtuales.
TOR: la parte superior del conmutador de red del bastidor.
Azure Storage: el servicio que hospeda discos virtuales para Azure Virtual Machines.

Cada uno de estos sistemas tiene sus propias fuentes de telemetría que necesitan analizarse y correlacionarse con el evento de desencadenador de tiempo de inactividad de la máquina virtual. Este proceso se realiza mediante la comprensión del gráfico de dependencias de una máquina virtual y los sistemas subyacentes que pueden provocar un error en una máquina virtual y, a continuación, unir todos los datos de telemetría de estado de estos sistemas dependientes, filtrados en eventos que se produjeron cerca del momento de la transición de la máquina virtual. El lenguaje de consulta intuitivo y eficaz de Azure Data Explorer ayuda a ofrecer patrones documentados, como combinación de período de tiempo para correlacionar flujos de telemetría temporales juntos. Al final de este proceso de correlación, tenemos un conjunto de datos que representa las transiciones de tiempo de inactividad de la máquina virtual con telemetría de plataforma correlacionada de todos los sistemas dependientes que podrían provocar o podrían tener información útil para determinar lo que provocó el error de la máquina virtual.

Fase 3: atribución de causa principal

El siguiente paso del proceso es la atribución. Ahora que hemos recopilado todos los datos pertinentes juntos en un único conjunto de datos, las reglas de atribución se aplican para interpretar la información y traducirla en una instrucción de causa raíz orientada al cliente. Si vuelve al ejemplo original de un error de TOR, después de nuestro análisis de correlación, es posible que tengamos muchos fragmentos interesantes de información para interpretar. Por ejemplo, los sistemas que supervisan los hosts de Azure podrían tener registros que indican que perdieron conectividad a los hosts durante este tiempo. También podríamos tener señales relacionadas con problemas de conectividad de disco virtual y señales explícitas del dispositivo TOR sobre el error. Ahora se examinan todos estos fragmentos de información y la señal explícita de error TOR se prioriza sobre las demás señales como causa principal. Este proceso de priorización y las reglas subyacentes se construyen con expertos en dominio y se modifican a medida que evoluciona la plataforma Azure. Los mecanismos de detección de anomalías y aprendizaje automático se encuentran sobre estas causas principales con atributos, para ayudar a identificar oportunidades para mejorar estas reglas de clasificación y detectar cambios de patrón en la tasa de estos errores para volver a incorporar a canalizaciones de implementación seguras.

Fase 4: Publicación de RCA

El último paso es publicar las causas principales de Azure Resource Health, donde se vuelven visibles para los clientes. La publicación se realiza mediante una sencilla aplicación de Azure Functions, que consulta periódicamente los datos de causa raíz procesados en Azure Data Explorer emite los resultados al backend de estado de los recursos. Dado que los flujos de información pueden aparecer con varios retrasos en los datos, las RCA se pueden actualizar ocasionalmente en este proceso para reflejar mejores orígenes de información que han llegado a una causa principal más específica que la publicada originalmente.

Hacia el futuro

Identificar y comunicar la causa principal de cualquier incidencia con nuestros clientes y asociados es apenas el principio. Nuestros clientes pueden tener que tomar estos RCA y compartirlos con sus clientes y compañeros de trabajo. Queremos basarse en el trabajo aquí para facilitar la identificación y el seguimiento de los RCA de recursos y compartirlos fácilmente. Para ello, estamos trabajando en los cambios de backend para generar id. de seguimiento únicos por recurso y por tiempo de inactividad que podemos exponer, de modo que pueda hacer coincidir fácilmente los tiempos de inactividad con sus RCA. También estamos trabajando en nuevas funciones que faciliten el envío de RCA por correo electrónico y, en última instancia, la suscripción a RCA para sus máquinas virtuales. Esta característica le permitirá inscribirse en los RCA directamente en la bandeja de entrada después de un evento de indisponibilidad, sin necesidad de ninguna otra acción por su parte.

Pasos siguientes

Para más información sobre las soluciones ofrecidas, continúe con el artículo de solución correspondiente:

Para obtener información general sobre cómo supervisar Azure Virtual Machines, consulte Supervisión de máquinas virtuales de Azure y la referencia Supervisión de máquinas virtuales de Azure.

Share via