En esta arquitectura se describe una solución que proporciona supervisión y observabilidad en tiempo real de los sistemas y los datos de telemetría de dispositivos de usuario final. Se centra en un caso de uso para el sector multimedia.
Grafana es una marca comercial de su empresa respectiva. El uso de esta marca no implica ninguna aprobación.
Descargue un archivo Visio de esta arquitectura.
En el sistema observable que se muestra en el diagrama, se transmite telemetría sin procesar a Azure Blob Storage a través de HTTP y conectores. La telemetría sin procesar se procesa, transforma, normaliza y guarda en Azure Data Explorer para su análisis. Los sistemas como Grafana y Azure Metrics Advisor leen datos de Data Explorer y extraen información para los usuarios finales.
Más concretamente, estos son los elementos del sistema en el diagrama:
- Instrumentación. La instrumentación se produce a través de sondeos o agentes instalados en sistemas para supervisar los datos. Estos agentes adoptan varias formas. Por ejemplo, en una plataforma de streaming de vídeo a petición, una empresa podría usar estándares abiertos dash.js para recopilar métricas de calidad de experiencia de los clientes.
- Ingesta. Esta telemetría sin procesar puede proceder directamente de los clientes finales a través de llamadas HTTP. Como alternativa, puede cargarlo a través de sistemas de terceros en lagos de datos y almacenamiento persistente, como Blob Storage. Blog Storage admite la capacidad de invocar una función de Azure cuando se carga un nuevo archivo. Puede usar este mecanismo desencadenador para mover la telemetría sin procesar a almacenes de datos estructurados.
- Transformación y persistencia. Es posible que necesite un sistema de transformación para normalizar los datos. Una aplicación de Azure Functions transforma los datos según sea necesario y, luego, los escribe en Data Explorer. Data Explorer es idóneo para el análisis de macrodatos porque está diseñado para un alto rendimiento y una elevada capacidad de proceso en grandes conjuntos de datos.
- Supervisión. Azure Managed Grafana admite la integración con Data Explorer. Puede usar las características de arrastrar y colocar de Grafana para crear rápidamente paneles y gráficos. Grafana es una buena opción para la supervisión de elementos multimedia, ya que proporciona una actualización ultrarrápida de los iconos del panel y también se puede usar para generar alertas.
- Detección de anomalías. El panel de Grafana proporciona compatibilidad con la supervisión manual en el NOC. Sin embargo, con un conjunto de datos grande y una base de usuarios distribuida entre zonas geográficas y usando varios dispositivos, la identificación manual de problemas a través de gráficos y reglas de alerta que tienen umbrales codificados de forma rígida se vuelve ineficaz. Para solucionar este problema, puede usar IA. Los servicios como Metrics Advisor usan algoritmos de aprendizaje automático para comprender y detectar automáticamente anomalías en función de los datos de serie temporal. Además, la plataforma de datos de Kusto tiene funciones de detección de anomalías integradas que tienen en cuenta las tendencias estacionales y de línea de base de los datos.
- Data Explorer es un servicio de análisis de datos administrado que permite analizar grandes volúmenes de datos en tiempo real. Data Explorer es una excelente herramienta para controlar grandes conjuntos de datos que requieren alta velocidad y capacidad de recuperación de datos. Esta arquitectura usa Data Explorer para almacenar y consultar conjuntos de datos para su análisis.
- Blob Storage se usa para almacenar telemetría sin procesar. Esta telemetría puede provenir de sus aplicaciones y servicios o de proveedores de terceros. Los datos se pueden tratar como transitorios si no es necesario realizar más análisis más adelante. Los datos de Blob Storage se ingieren en clústeres de Data Explorer.
- Azure Event Grid es un sistema de entrega de eventos. Se usa para escuchar los eventos publicados por Blob Storage. Los eventos de Azure Storage permiten a las aplicaciones reaccionar a eventos, como la creación y la eliminación de blobs. Una función de Azure se suscribe a eventos publicados por Event Grid.
- Azure Event Hubs es un servicio de ingesta de datos en tiempo real que puede usar para ingerir millones de eventos por segundo desde cualquier origen. Los centros de eventos representan la puerta principal, que a menudo se conoce como agente de ingesta de eventos, para una canalización de eventos. Un agente de ingesta de eventos es un componente o servicio que se encuentra entre los publicadores de eventos y los consumidores de eventos. Desacopla la producción de una secuencia de eventos del consumo de los eventos.
- Azure Functions es una solución sin servidor que se usa para analizar y transformar los datos ingeridos a través de puntos de conexión HTTP y de blob y escribirlos en el clúster de Data Explorer.
- Azure Managed Grafana se conecta fácilmente a Data Explorer. En esta arquitectura, genera gráficos y paneles que permiten visualizar los datos de telemetría. Azure Managed Grafana proporciona una integración profunda con Microsoft Entra ID para poder implementar el acceso basado en roles a paneles y vistas.
- Metrics Advisor forma parte de Azure Applied AI Services. Usa IA para realizar la supervisión de datos y la detección de anomalías en los datos de serie temporal. Metrics Advisor automatiza el proceso de aplicación de modelos a los datos y proporciona un conjunto de API y un área de trabajo basada en web para la ingesta de datos, la detección de anomalías y los diagnósticos. Puede usarlo incluso si no tiene conocimientos sobre aprendizaje automático.
Azure Data Factory y Azure Synapse Analytics proporcionan herramientas y áreas de trabajo para crear flujos de trabajo ETL y la capacidad de realizar un seguimiento y reintentar trabajos desde una interfaz gráfica. Tenga en cuenta que Data Factory y Azure Synapse ambos tienen un retraso mínimo de unos 5 minutos desde el momento de la ingesta hasta la persistencia. Este retraso puede ser aceptable en el sistema de supervisión. Si es así, se recomienda considerar estas alternativas.
Las organizaciones suelen implementar tecnologías variadas y a gran escala para resolver problemas empresariales. Estos sistemas, y los dispositivos de usuario final, generan grandes conjuntos de datos de telemetría.
Esta arquitectura se basa en un caso de uso perteneciente al sector multimedia. La transmisión de elementos multimedia para la reproducción en directo y de vídeo a petición requiere una identificación casi en tiempo real de los problemas de las aplicaciones y la respuesta a ellos. Para admitir este escenario en tiempo real, las organizaciones deben recopilar un conjunto de telemetría masivo, que requiere una arquitectura escalable. Una vez recopilados los datos, se necesitan otros tipos de análisis, como la inteligencia artificial y la detección de anomalías, para identificar eficazmente los problemas en un conjunto de datos tan grande.
Cuando se implementan tecnologías a gran escala, los dispositivos del sistema y del usuario final que interactúan con ellos generan conjuntos masivos de datos de telemetría. En escenarios tradicionales, estos datos se analizan mediante un sistema de almacenamiento de datos para extraer información que se pueda usar para respaldar decisiones de la dirección. Este enfoque puede funcionar en algunos escenarios, pero no responde lo suficiente bien para los casos de uso de transmisión de elementos multimedia. Para solucionar este problema, es necesario extraer información en tiempo real de los datos de telemetría que se generan a partir de la supervisión de servidores, redes y los dispositivos de usuario final que interactúan con ellos. Los sistemas de supervisión que detectan errores son habituales, pero detectarlos casi en tiempo real es difícil. Este es el enfoque de esta arquitectura.
En un escenario de streaming en vivo o vídeo a petición, los datos de telemetría se generan desde sistemas y clientes heterogéneos (móviles, de escritorio y TV). La solución implica tomar datos sin procesar y asociar contexto con los puntos de datos, por ejemplo, dimensiones como geografía, sistema operativo de usuario final, identificador de contenido y proveedor de CDN. La telemetría sin procesar se recopila, transforma y guarda en Data Explorer para su análisis. Luego, puede usar la inteligencia artificial para que los datos tengan sentido y automatizar los procesos manuales de observación y alerta. Puede usar sistemas como Grafana y Metrics Advisor para leer datos de Data Explorer a fin de mostrar paneles interactivos y desencadenar alertas.
Estas consideraciones constituyen los pilares del Marco de buena arquitectura de Azure, un conjunto de principios rectores que puede usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
La confiabilidad garantiza que la aplicación pueda cumplir los compromisos contraídos con los clientes. Para obtener más información, vea Lista de comprobación de revisión de diseño para lade confiabilidad.
Las aplicaciones críticas para la empresa deben seguir ejecutándose incluso durante eventos disruptivos, como las interrupciones de la región de Azure o de la red CDN. Hay dos estrategias principales y una estrategia híbrida para crear redundancia en el sistema:
- Activo/activo. Se está ejecutando código y funciones duplicados. Cualquier sistema puede asumir el control durante un error.
- Activo-en espera. Solo un nodo es activo o principal. El otro está listo para asumir el control en caso de que el nodo principal deje de funcionar.
- Mixto. Algunos componentes o servicios están en la configuración activo-activo, y algunos están en activo/en espera.
Tenga en cuenta que no todos los servicios de Azure tienen redundancia integrada. Por ejemplo, Azure Functions ejecuta una aplicación de funciones solo en una región específica. En Recuperación ante desastres geográfica de Azure Functions se describen varias estrategias que puede implementar, en función de cómo se desencadenen las funciones (HTTP frente a pub/sub).
La aplicación de funciones de ingesta y transformación se puede ejecutar en modo activo-activo. Puede ejecutar Data Explorer en configuraciones activo-activo y activo-en espera.
Azure Managed Grafana admite la redundancia de zona de disponibilidad. Una estrategia para crear redundancia entre regiones consiste en configurar Grafana en cada región en la que se implementa el clúster de Data Explorer.
La optimización de costos consiste en examinar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costos.
El costo de esta arquitectura depende del número de eventos de telemetría de entrada, el almacenamiento de telemetría sin procesar en Blob Storage y Data Explorer, un costo por hora para Azure Managed Grafana y un costo estático para el número de gráficos de serie temporal en Metrics Advisor.
Puede usar la calculadora de precios de Azure para calcular los costos por hora o mensuales.
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar a fin de satisfacer las demandas que los usuarios ponen en ella de forma eficaz. Para obtener más información, vea Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
Dependiendo de la escala y la frecuencia de las solicitudes entrantes, la aplicación de funciones podría ser un cuello de botella, por dos razones principales:
- Arranque en frío. El arranque en frío es una consecuencia de las ejecuciones sin servidor. Hace referencia a la programación y el tiempo de instalación necesarios para poner en marcha un entorno antes de que la función empiece a ejecutarse por primera vez. Como máximo, el tiempo necesario es de unos segundos.
- Frecuencia de solicitudes. Supongamos que tiene 1000 solicitudes HTTP, pero solo un servidor de un solo subproceso para controlarlas. No podrá atender las 1000 solicitudes HTTP a la vez. Para atender estas solicitudes de forma oportuna, debe implementar más servidores. Es decir, debe escalar horizontalmente.
Se recomienda usar SKU Premium o dedicadas para:
- Eliminar los arranques en frío.
- Controlar los requisitos de las solicitudes simultáneas mediante el escalado o la reducción vertical del número de máquinas virtuales de servicio.
Para más información, consulte Selección de una SKU para el clúster de Azure Data Explorer.
Para información sobre cómo implementar este escenario, consulte Supervisión y observabilidad en tiempo real para elementos multimedia en GitHub. Este ejemplo de código incluye la infraestructura como código (IaC) necesaria para arrancar el desarrollo y las funciones de Azure para ingerir y transformar los datos desde los puntos de conexión HTTP y blob.
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- John Hauppa | Administrador de programas técnico sénior
- Uffaz Nathaniel | Ingeniero principal de software
Otros colaboradores:
- Mick Alberts | Escritor técnico
- Dilmurod Makhamadaliev | Ingeniero de software
- Omeed Musavi | Ingeniero principal de software
- Ayo Mustapha | Director principal de programas técnicos
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.