Share via

Modelado de estado y observabilidad de cargas de trabajo críticas en Azure

  • Artículo

El modelado de estado y la observabilidad son conceptos esenciales para maximizar la confiabilidad, que se centra en instrumentación y supervisión sólidas y contextualizadas. Estos conceptos proporcionan información crítica sobre el estado de la aplicación, lo que promueve la identificación rápida y la resolución de problemas.

La mayoría de las aplicaciones críticas son significativas en términos de escala y complejidad y, por lo tanto, generan grandes volúmenes de datos operativos, lo que hace que sea difícil evaluar y determinar una acción operativa óptima. En última instancia, el modelado de estado se esfuerza por maximizar la observabilidad mediante el aumento de los registros de supervisión sin procesar y las métricas con requisitos empresariales clave para cuantificar el estado de la aplicación, lo que impulsa la evaluación automatizada de los estados de mantenimiento para lograr operaciones coherentes y rápidas.

Este área de diseño se centra en el proceso para definir un modelo de mantenimiento sólido, asignando estados de mantenimiento cuantificados de la aplicación a través de construcciones operativas y observabilidad para lograr la madurez operativa.

Importante

Este artículo forma parte de la serie de cargas de trabajo críticas de Azure Well-Architected . Si no está familiarizado con esta serie, se recomienda empezar con lo que es una carga de trabajo crítica.

Hay tres niveles principales de madurez operativa al esforzarse por maximizar la confiabilidad.

  1. Detecte y responda a los problemas a medida que se producen.
  2. Diagnostique problemas que se están produciendo o que ya se han producido.
  3. Prediga y evite problemas antes de que se produzcan.

Vídeo: Definición de un modelo de estado para la carga de trabajo crítica

Estado de la aplicación superpuesta

Para crear un modelo de mantenimiento, primero defina el estado de la aplicación en el contexto de los requisitos empresariales clave cuantificando los estados "correctos" y "incorrectos" en un formato en capas y medible. A continuación, para cada componente de aplicación, refina la definición en el contexto de un estado de ejecución estable y se agrega según los flujos de usuario de la aplicación. Superponer con requisitos empresariales no funcionales clave para el rendimiento y la disponibilidad. Por último, agregue los estados de mantenimiento de cada flujo de usuario individual para formar una representación aceptable del estado general de la aplicación. Una vez establecida, estas definiciones de estado superpuestas deben usarse para informar a las métricas críticas de supervisión en todos los componentes del sistema y validar la composición del subsistema operativo.

Importante

Al definir los estados "incorrectos", representan para todos los niveles de la aplicación. Es importante distinguir entre los estados de error transitorios y no transitorios para calificar la degradación del servicio en relación con la falta de disponibilidad.

Consideraciones de diseño

  • El proceso de modelado del estado es una actividad de diseño de arriba abajo que comienza con un ejercicio arquitectónico para definir todos los flujos de usuario y asignar dependencias entre componentes funcionales y lógicos, de modo que asigna implícitamente dependencias entre los recursos de Azure.

  • Un modelo de mantenimiento depende completamente del contexto de la solución que representa y, por lo tanto, no se puede resolver "lista para usar" porque "un tamaño no se ajusta a todos".

    • Las aplicaciones variarán en la composición y las dependencias
    • Las métricas y los umbrales de métricas de los recursos también se deben ajustar correctamente en términos de qué valores representan estados correctos y incorrectos, que están muy influenciados por la funcionalidad de la aplicación abarcada y los requisitos no funcionales de destino.

  • Un modelo de estado superpuesta permite realizar un seguimiento del estado de la aplicación a dependencias de nivel inferior, lo que ayuda a provocar rápidamente la degradación del servicio.

  • Para capturar los estados de mantenimiento de un componente individual, las características operativas distintas de ese componente deben entenderse bajo un estado estable que refleje la carga de producción. Por lo tanto, las pruebas de rendimiento son una funcionalidad clave para definir y evaluar continuamente el estado de la aplicación.

  • Es posible que los errores dentro de una solución en la nube no se produzcan de forma aislada. Una interrupción en un único componente puede provocar que varias funcionalidades o componentes adicionales no estén disponibles.

    • Estos errores pueden no ser observables inmediatamente.

Recomendaciones de diseño

  • Defina un modelo de mantenimiento medible como prioridad para garantizar una comprensión operativa clara de toda la aplicación.

    • El modelo de mantenimiento se debe superponer y reflejar la estructura de la aplicación.
    • La capa fundamental debe tener en cuenta los componentes individuales de la aplicación, como los recursos de Azure.
    • Los componentes fundamentales deben agregarse junto con los requisitos clave no funcionales para crear una lente contextualizada de la empresa en el estado de los flujos del sistema.
    • Los flujos del sistema deben agregarse con pesos adecuados en función de la importancia empresarial para crear una definición significativa del estado general de la aplicación. Se deben priorizar los flujos de usuario financieros significativos o orientados al cliente.
    • Cada capa del modelo de mantenimiento debe capturar lo que representan los estados "correctos" y "incorrectos".
    • Asegúrese de que el modelo de calor puede distinguir entre los estados transitorios y no transitorios incorrectos para aislar la degradación del servicio de la falta de disponibilidad.

  • Represente los estados de mantenimiento mediante una puntuación de estado granular para cada componente de aplicación distinto y cada flujo de usuario mediante la agregación de puntuaciones de mantenimiento para los componentes dependientes asignados, teniendo en cuenta los requisitos clave no funcionales como coeficientes.

    • La puntuación de mantenimiento de un flujo de usuario debe representarse mediante la puntuación más baja en todos los componentes asignados, lo que tiene en cuenta la obtención relativa de los requisitos no funcionales para el flujo de usuario.
    • El modelo que se usa para calcular las puntuaciones de estado debe reflejar de forma coherente el estado operativo y, si no es así, el modelo se debe ajustar y volver a implementar para reflejar nuevos aprendizajes.
    • Defina los umbrales de puntuación de mantenimiento para reflejar el estado de mantenimiento.

  • La puntuación de mantenimiento se debe calcular automáticamente en función de las métricas subyacentes, que se pueden visualizar a través de patrones de observabilidad y actuar a través de procedimientos operativos automatizados.

    • La puntuación de mantenimiento debe convertirse en fundamental para la solución de supervisión, de modo que los equipos operativos ya no tengan que interpretar y asignar datos operativos al estado de la aplicación.

  • Use el modelo de mantenimiento para calcular la obtención del objetivo de nivel de servicio (SLO) de disponibilidad en lugar de la disponibilidad sin procesar, lo que garantiza que la demarcación entre la degradación del servicio y la falta de disponibilidad se refleje como SLO independientes.

  • Use el modelo de mantenimiento en canalizaciones de CI/CD y ciclos de prueba para validar que el estado de la aplicación se mantiene después de las actualizaciones de código y configuración.

    • El modelo de mantenimiento debe usarse para observar y validar el estado durante las pruebas de carga y las pruebas de caos como parte de los procesos de CI/CD.

  • La creación y el mantenimiento de un modelo de mantenimiento es un proceso iterativo y la inversión en ingeniería deben alinearse para impulsar mejoras continuas.

    • Defina un proceso para evaluar y ajustar continuamente la precisión del modelo y considere la posibilidad de invertir en modelos de aprendizaje automático para entrenar aún más el modelo.

Ejemplo: modelo de estado superpuesta

Se trata de una representación simplificada de un modelo de estado de la aplicación superpuesta con fines ilustrativos. En las implementaciones de referencia de Mission-Critical se proporciona un modelo de mantenimiento completo y contextualizado:

Al implementar un modelo de estado, es importante definir el estado de los componentes individuales mediante la agregación y la interpretación de las métricas clave de nivel de recurso. A continuación se muestra un ejemplo de cómo se pueden usar las métricas de recursos:

de mantenimiento de ejemplo críticasDefiniciones

Esta definición de mantenimiento se puede representar posteriormente mediante una consulta de KQL, como se muestra en la consulta de ejemplo siguiente que agrega InsightsMetrics (Container Insights) y AzureMetrics (configuración de diagnóstico para el clúster de AKS) y compara (combinación interna) con los umbrales de estado modelados.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

La salida de la tabla resultante se puede transformar posteriormente en una puntuación de estado para facilitar la agregación en niveles superiores del modelo de mantenimiento.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

Estas puntuaciones agregadas se pueden representar posteriormente como un gráfico de dependencias mediante herramientas de visualización como Grafana para ilustrar el modelo de mantenimiento.

En esta imagen se muestra un modelo de estado en capas de ejemplo de la implementación de referencia en línea de Azure Mission-Critical y se muestra cómo un cambio en el estado de mantenimiento de un componente fundamental puede tener un impacto en cascada en los flujos de usuario y el estado general de la aplicación (los valores de ejemplo corresponden a la tabla de la imagen anterior).

Visualización del modelo de mantenimiento de ejemplo

Vídeo de demostración: Demostración del modelado de estado y supervisión

Receptor de datos unificado para el análisis correlacionado

Muchos conjuntos de datos operativos se deben recopilar de todos los componentes del sistema para representar con precisión un modelo de calor definido, teniendo en cuenta los registros y las métricas de los componentes de la aplicación y los recursos subyacentes de Azure. En última instancia, esta gran cantidad de datos debe almacenarse en un formato que permita la interpretación casi en tiempo real para facilitar una acción operativa rápida. Además, la correlación entre todos los conjuntos de datos abarcados es necesaria para garantizar que el análisis eficaz no esté enlazado, lo que permite la representación por capas del estado.

Se requiere un receptor de datos unificado para asegurarse de que todos los datos operativos se almacenan rápidamente y están disponibles para el análisis correlacionado con el fin de crear una representación de "panel único" del estado de la aplicación. Azure proporciona varias tecnologías operativas diferentes bajo el paraguas de Azure Monitor y el área de trabajo de Log Analytics sirve como receptor de datos nativos de Azure principal para almacenar y analizar los datos operativos.

Colección de datos de mantenimiento crítico de misión recopilación

Consideraciones de diseño

Azure Monitor

  • Azure Monitor está habilitado de forma predeterminada para todas las suscripciones de Azure, pero los registros de Azure Monitor (área de trabajo de Log Analytics) y los recursos de Application Insights deben implementarse y configurarse para incorporar funcionalidades de recopilación y consulta de datos.

  • Azure Monitor admite tres tipos de datos de observabilidad: registros, métricas y seguimientos distribuidos.

    • Los registros se almacenan en áreas de trabajo de Log Analytics, que se basan en Azure Data Explorer. Las consultas de registro se almacenan en paquetes de consultas que se pueden compartir entre suscripciones y se usan para impulsar componentes de observabilidad, como paneles, libros u otras herramientas de creación de informes y visualización.
    • Las métricas se almacenan en una base de datos de serie temporal interna. Para la mayoría de los recursos de Azure, las métricas se recopilan y conservan automáticamente durante 93 días. Los datos de métricas también se pueden enviar al área de trabajo de Log Analytics mediante una configuración de diagnóstico para el recurso.

  • Todos los recursos de Azure exponen registros y métricas, pero los recursos deben configurarse correctamente para enrutar los datos de diagnóstico al receptor de datos deseado.

Sugerencia

Azure proporciona varias directivas integradas que se pueden aplicar para asegurarse de que los recursos implementados están configurados para enviar registros y métricas a un área de trabajo de Log Analytics.

  • No es raro que los controles normativos requieran que los datos operativos permanezcan dentro de zonas geográficas o países o regiones de origen. Los requisitos normativos pueden estipular la retención de tipos de datos críticos durante un período de tiempo prolongado. Por ejemplo, en la banca regulada, los datos de auditoría deben conservarse durante al menos siete años.

  • Los distintos tipos de datos operativos pueden requerir períodos de retención diferentes. Por ejemplo, es posible que los registros de seguridad deban conservarse durante un largo período, mientras que es poco probable que los datos de rendimiento requieran retención a largo plazo fuera del contexto de AIOps.

  • Los datos se pueden archivar o exportar desde áreas de trabajo de Log Analytics con fines de retención o auditoría a largo plazo.

  • Los clústeres dedicados proporcionan una opción de implementación que permite Availability Zones para la protección frente a errores zonales en regiones de Azure admitidas. Los clústeres dedicados requieren un compromiso de ingesta de datos diario mínimo.

  • Las áreas de trabajo de Log Analytics se implementan en una región de Azure especificada.

  • Para protegerse contra la pérdida de datos frente a la falta de disponibilidad de un área de trabajo de Log Analytics, los recursos se pueden configurar con varias opciones de diagnóstico. Cada configuración de diagnóstico puede enviar métricas y registros a un área de trabajo de Log Analytics independiente.

    • Los datos enviados a cada área de trabajo de Log Analytics adicional incurrirán en costos adicionales.
    • El área de trabajo redundante de Log Analytics se puede implementar en la misma región de Azure o en regiones de Azure independientes para una redundancia regional adicional.
    • El envío de registros y métricas desde un recurso de Azure a un área de trabajo de Log Analytics en otra región incurrirá en costos de salida de datos entre regiones.
    • Algunos recursos de Azure requieren un área de trabajo de Log Analytics dentro de la misma región que el propio recurso.
    • Consulte Procedimientos recomendados para los registros de Azure Monitor para obtener más opciones de disponibilidad para el área de trabajo de Log Analytics.

  • Los datos del área de trabajo de Log Analytics se pueden exportar a Azure Storage o Azure Event Hubs de forma continua, programada o única.

    • La exportación de datos permite el archivado de datos a largo plazo y protege frente a posibles pérdidas de datos operativas debido a la falta de disponibilidad.
    • Los destinos de exportación disponibles son Azure Storage o Azure Event Hubs. Azure Storage se puede configurar para distintos niveles de redundancia , incluidos zonales o regionales. La exportación de datos a Azure Storage almacena los datos en archivos .json.
    • Los destinos de exportación de datos deben estar dentro de la misma región de Azure que el área de trabajo de Log Analytics. Destino de exportación de datos del centro de eventos que se encuentra dentro de la misma región que el área de trabajo de Log Analytics. Azure Event Hubs recuperación ante desastres geográfica no es aplicable a este escenario.
    • Hay varias limitaciones de exportación de datos. Solo se admiten tablas específicas en el área de trabajo para la exportación de datos.
    • El archivado se puede usar para almacenar datos en un área de trabajo de Log Analytics para la retención a largo plazo a un costo reducido sin exportarlos.

  • Los registros de Azure Monitor tienen límites de limitación de consultas de usuario, que pueden aparecer como una disponibilidad reducida para los clientes, como los paneles de observabilidad.

    • Cinco consultas simultáneas por usuario: si ya se están ejecutando cinco consultas, las consultas adicionales se colocan en una cola de simultaneidad por usuario hasta que finaliza una consulta en ejecución.
    • Tiempo en cola de simultaneidad: si una consulta se encuentra en la cola de simultaneidad durante más de tres minutos, se finalizará y se devolverá un código de error 429.
    • Límite de profundidad de cola de simultaneidad: la cola de simultaneidad está limitada a 200 consultas y se rechazarán consultas adicionales con un código de error 429.
    • Límite de frecuencia de consulta: hay un límite por usuario de 200 consultas por 30 segundos en todas las áreas de trabajo.

  • Los paquetes de consultas son recursos de Azure Resource Manager, que se pueden usar para proteger y recuperar consultas de registro si el área de trabajo de Log Analytics no está disponible.

    • Los paquetes de consulta contienen consultas como JSON y se pueden almacenar externas a Azure similares a otros recursos de infraestructura como código.
      • Se puede implementar a través de la API rest de Microsoft.Insights.
      • Si se debe volver a crear un área de trabajo de Log Analytics, se puede volver a implementar el paquete de consultas desde una definición almacenada externamente.

  • Application Insights se puede implementar en un modelo de implementación basado en el área de trabajo, respaldado por un área de trabajo de Log Analytics donde se almacenan todos los datos.

  • El muestreo se puede habilitar en Application Insights para reducir la cantidad de telemetría enviada y optimizar los costos de ingesta de datos.

  • Todos los datos recopilados por Azure Monitor, incluido Application Insights, se cobran según el volumen de datos ingeridos y la duración que se conservan.

    • Los datos ingeridos en un área de trabajo de Log Analytics se pueden conservar sin cargo adicional hasta los primeros 31 días (90 días si Sentinel está habilitado).
    • Los datos ingeridos en una instancia de Application Insights basada en áreas de trabajo se conservan durante los primeros 90 días sin cargo adicional.

  • El modelo de precios del plan de compromiso de Log Analytics proporciona un costo reducido y un enfoque predecible para los cargos de ingesta de datos.

    • Cualquier uso por encima del nivel de reserva se factura al mismo precio que el nivel actual.

  • Log Analytics, Application Insights y Azure Data Explorer usan el Lenguaje de consulta Kusto (KQL).

  • Las consultas de Log Analytics se guardan como funciones dentro del área de trabajo de Log Analytics (savedSearches).

Recomendaciones de diseño

  • Use el área de trabajo de Log Analytics como receptor de datos unificado para proporcionar un "panel único" en todos los conjuntos de datos operativos.

    • Descentralice las áreas de trabajo de Log Analytics en todas las regiones de implementación usadas. Cada región de Azure con una implementación de aplicaciones debe tener en cuenta un área de trabajo de Log Analytics para recopilar todos los datos operativos que se originan en esa región. Todos los recursos globales deben usar un área de trabajo de Log Analytics dedicada independiente, que se debe implementar dentro de una región de implementación primaria.
      • El envío de todos los datos operativos a un único área de trabajo de Log Analytics crearía un único punto de error.
      • Los requisitos para la residencia de datos pueden prohibir que los datos salgan de la región de origen y las áreas de trabajo federadas resuelvan este requisito de forma predeterminada.
      • Hay un costo de salida sustancial asociado a la transferencia de registros y métricas entre regiones.
    • Todas las marcas de implementación dentro de la misma región pueden usar el mismo área de trabajo de Log Analytics regional.

  • Considere la posibilidad de configurar recursos con varias opciones de diagnóstico que apunten a diferentes áreas de trabajo de Log Analytics para protegerse frente a la falta de disponibilidad de Azure Monitor para las aplicaciones con menos stamps de implementación regionales.

  • Use Application Insights como una herramienta de supervisión del rendimiento de aplicaciones (APM) uniforme en todos los componentes de la aplicación que le facilite recopilar registros de aplicaciones, métricas y seguimientos.

    • Implemente Application Insights en una configuración basada en áreas de trabajo para asegurarse de que cada área de trabajo regional de Log Analytics contiene registros y métricas de los componentes de la aplicación y los recursos subyacentes de Azure.

  • Use consultas entre áreas de trabajo para mantener un "panel único" unificado en las distintas áreas de trabajo.

  • Use paquetes de consultas para proteger las consultas de registro en caso de falta de disponibilidad del área de trabajo.

    • Almacene paquetes de consultas en el repositorio git de la aplicación como recursos de infraestructura como código.

  • Todas las áreas de trabajo de Log Analytics deben tratarse como recursos de ejecución prolongada con un ciclo de vida diferente a los recursos de la aplicación dentro de una marca de implementación regional.

  • Exporte datos operativos críticos desde el área de trabajo de Log Analytics para la retención y el análisis a largo plazo para facilitar AIOps y análisis avanzados para refinar el modelo de mantenimiento subyacente e informar a la acción predictiva.

  • Evalúe cuidadosamente qué almacén de datos se debe usar para la retención a largo plazo; no todos los datos deben almacenarse en un almacén de datos activa y consultable.

    • Se recomienda encarecidamente usar Azure Storage en una configuración grS para el almacenamiento de datos operativos a largo plazo.
      • Use la funcionalidad de exportación del área de trabajo de Log Analytics para exportar todos los orígenes de datos disponibles a Azure Storage.

  • Seleccione los períodos de retención adecuados para los tipos de datos operativos dentro de Log Analytics, configurando períodos de retención más largos dentro del área de trabajo donde existen requisitos de observabilidad "activos".

  • Use Azure Policy para asegurarse de que todos los recursos regionales enrutan los datos operativos al área de trabajo correcta de Log Analytics.

Nota:

Al realizar la implementación en una zona de aterrizaje de Azure, si hay un requisito para el almacenamiento centralizado de datos operativos, puede bifurcar los datos en la creación de instancias, por lo que se ingiere en las herramientas centralizadas y en las áreas de trabajo de Log Analytics dedicadas a la aplicación. Como alternativa, exponga el acceso a las áreas de trabajo de Log Analytics de la aplicación para que los equipos centrales puedan consultar los datos de la aplicación. En última instancia, es fundamental que los datos operativos que se originan en la solución estén disponibles en las áreas de trabajo de Log Analytics dedicadas a la aplicación.

Si se requiere la integración de SIEM, no envíe entradas de registro sin procesar, sino que envíe alertas críticas.

  • Configure solo el muestreo en Application Insights si es necesario para optimizar el rendimiento o si no el muestreo se convierte en prohibitivo.

    • El muestreo excesivo puede provocar señales operativas perdidas o inexactas.

  • Use los identificadores de correlación para todos los eventos de seguimiento y los mensajes de registro para vincularlos a una solicitud determinada.

    • Devuelve los identificadores de correlación al autor de la llamada para todas las llamadas, no solo solicitudes con errores.

  • Asegúrese de que el código de aplicación incorpora la instrumentación y el registro adecuados para informar al modelo de mantenimiento y facilitar la solución de problemas posterior o el análisis de la causa principal cuando sea necesario.

    • El código de la aplicación debe usar Application Insights para facilitar el seguimiento distribuido, proporcionando al autor de la llamada un mensaje de error completo que incluye un identificador de correlación cuando se produce un error.

  • Use el registro estructurado para todos los mensajes de registro.

  • Agregue sondeos de estado significativos a todos los componentes de la aplicación.

    • Al usar AKS, configure los puntos de conexión de mantenimiento para cada implementación (pod) para que Kubernetes pueda determinar correctamente cuándo un pod es correcto o incorrecto.
    • Al usar Azure App Service, configure las comprobaciones de estado para que las operaciones de escalado horizontal no provoquen errores mediante el envío de tráfico a instancias que aún no están listas y asegúrese de que las instancias incorrectas se reciclan rápidamente.

Si la aplicación está suscrita al soporte técnico de Microsoft Mission-Critical, considere la posibilidad de exponer sondeos de estado clave a Soporte técnico de Microsoft, por lo que el estado de la aplicación se puede modelar con mayor precisión mediante Soporte técnico de Microsoft.

  • Registre solicitudes de comprobación de estado correctas, a menos que no se puedan tolerar volúmenes de datos aumentados en el contexto del rendimiento de la aplicación, ya que proporcionan información adicional para el modelado analítico.

  • No configure áreas de trabajo de Log Analytics de producción para aplicar un límite diario, lo que limita la ingesta diaria de datos operativos, ya que esto puede provocar la pérdida de datos operativos críticos.

    • En entornos inferiores, como desarrollo y pruebas, se puede considerar un límite diario como un mecanismo opcional de ahorro de costos.

  • Siempre que los volúmenes de ingesta de datos operativos cumplan el umbral de nivel mínimo, configure las áreas de trabajo de Log Analytics para usar los precios basados en el plan de compromiso para impulsar las eficiencias de los costos en relación con el modelo de precios de pago por uso.

  • Se recomienda encarecidamente almacenar consultas de Log Analytics mediante el control de código fuente y usar la automatización de CI/CD para implementarlas en las instancias de área de trabajo de Log Analytics pertinentes.

Visualización

Representar visualmente el modelo de mantenimiento con datos operativos críticos es esencial para lograr operaciones eficaces y maximizar la confiabilidad. Los paneles deben utilizarse en última instancia para proporcionar información casi en tiempo real sobre el estado de la aplicación para los equipos de DevOps, lo que facilita el diagnóstico rápido de desviaciones del estado estable.

Microsoft proporciona varias tecnologías de visualización de datos, incluidos los paneles de Azure, Power BI y Azure Managed Grafana (actualmente en versión preliminar). Los paneles de Azure se colocan para proporcionar una solución de visualización integrada estrechamente integrada para los datos operativos en Azure Monitor. Por lo tanto, tiene un papel fundamental para desempeñar en la representación visual de los datos operativos y el estado de la aplicación para una carga de trabajo crítica. Sin embargo, hay varias limitaciones en cuanto al posicionamiento de los paneles de Azure como una plataforma de observabilidad holística y, como resultado, se debe tener en cuenta el uso complementario de soluciones de observabilidad líderes en el mercado, como Grafana, que también se proporciona como una solución administrada en Azure.

Esta sección se centra en el uso de Paneles de Azure y Grafana para crear una sólida experiencia de paneles capaz de proporcionar lentes técnicas y empresariales en el estado de la aplicación, lo que permite a los equipos de DevOps y una operación eficaz. La sólida creación de paneles es esencial para diagnosticar problemas que ya se han producido y dar soporte a los equipos operativos en la detección y respuesta a los problemas a medida que se producen.

Consideraciones de diseño

  • Al visualizar el modelo de estado mediante consultas de registro, tenga en cuenta que hay límites de Log Analytics en consultas simultáneas y en cola, así como la tasa de consulta general, con las consultas posteriores en cola y limitadas.

  • Las consultas para recuperar datos operativos usados para calcular y representar puntuaciones de estado se pueden escribir y ejecutar en Log Analytics o Azure Data Explorer.

    • Las consultas de ejemplo están disponibles aquí.

  • Log Analytics impone varios límites de consulta, que deben diseñarse para al diseñar paneles operativos.

  • La visualización de métricas de recursos sin procesar, como el uso de CPU o el rendimiento de red, requiere una evaluación manual por parte de los equipos de operaciones para determinar los impactos en el estado de mantenimiento, y esto puede ser difícil durante un incidente activo.

  • Si varios usuarios usan paneles dentro de una herramienta como Grafana, el número de consultas enviadas a Log Analytics se multiplica rápidamente.

    • Alcanzar el límite de consultas simultáneas en Log Analytics pondrá en cola las consultas posteriores, lo que hace que la experiencia del panel se sienta "lenta".

Recomendaciones de diseño

  • Recopile y presente las salidas consultadas de todas las áreas de trabajo de Log Analytics regionales y el área de trabajo global de Log Analytics para crear una vista unificada del estado de la aplicación.

Nota:

Si se implementa en una zona de aterrizaje de Azure, considere la posibilidad de consultar el área de trabajo de Log Analytics de la plataforma central si existen dependencias clave en los recursos de la plataforma, como ExpressRoute para la comunicación local.

  • Se debe usar un modelo de "semáforo" para representar visualmente estados "correctos" y "incorrectos", con verde que se usa para ilustrar cuándo se cumplen completamente los requisitos no funcionales clave y los recursos se usan de forma óptima. Use "Verde", "Amber y "Rojo" para representar estados "Correcto", "Degradado" y "No disponible".

  • Use paneles de Azure para crear lentes operativas para los recursos globales y las marcas de implementación regionales, que representan métricas clave, como el recuento de solicitudes para Azure Front Door, la latencia del lado servidor para Azure Cosmos DB, los mensajes entrantes y salientes para Event Hubs y el uso de CPU o los estados de implementación para AKS. Los paneles deben adaptarse para impulsar la eficacia operativa, infundiendo aprendizajes de escenarios de error para garantizar que los equipos de DevOps tengan visibilidad directa de las métricas clave.

  • Si los paneles de Azure no se pueden usar para representar con precisión el modelo de mantenimiento y los requisitos empresariales necesarios, se recomienda encarecidamente considerar Grafana como una solución de visualización alternativa, lo que proporciona funcionalidades líderes en el mercado y un amplio ecosistema de complementos de código abierto. Evalúe la oferta de versión preliminar administrada de Grafana para evitar las complejidades operativas de la administración de la infraestructura de Grafana.

  • Al implementar Grafana autohospedado, emplea un diseño de alta disponibilidad y distribuido geográficamente para garantizar que los paneles operativos críticos puedan ser resistentes a errores de plataforma regional y escenarios de errores en cascada.

    • Separe el estado de configuración en un almacén de datos externo, como Azure Database for Postgres o MySQL, para asegurarse de que los nodos de aplicación de Grafana permanecen sin estado.

      • Configure la replicación de base de datos entre regiones de implementación.

    • Implemente nodos de Grafana en App Services en una configuración de alta disponibilidad en una región, mediante implementaciones basadas en contenedores.

      • Implemente App Service instancias en regiones de implementación consideradas.

      App Services proporciona una plataforma de contenedor de baja fricción, que es ideal para escenarios de bajo escala, como paneles operativos, y aislar Grafana de AKS proporciona una separación clara de preocupación entre la plataforma de aplicaciones principal y las representaciones operativas de esa plataforma. Consulte el área de alineación de la plataforma de aplicaciones para obtener más recomendaciones de configuración.

    • Use Azure Storage en una configuración grS para hospedar y administrar objetos visuales y complementos personalizados.

    • Implemente los componentes de Grafana de réplica de lectura de aplicación y base de datos en un mínimo de dos regiones de implementación y considere la posibilidad de emplear un modelo en el que se implementa Grafana en todas las regiones de implementación consideradas.

Para escenarios destinados a un >SLO del 99,99 %, Grafana debe implementarse en un mínimo de 3 regiones de implementación para maximizar la confiabilidad general de los paneles operativos clave.

  • Mitigue los límites de consultas de Log Analytics mediante la agregación de consultas en un único o pequeño número de consultas, como mediante el operador "union" de KQL y establezca una frecuencia de actualización adecuada en el panel.

    • Una frecuencia de actualización máxima adecuada dependerá del número y la complejidad de las consultas del panel; se requiere el análisis de las consultas implementadas.

  • Si se alcanza el límite de consultas simultáneas de Log Analytics, considere la posibilidad de optimizar el patrón de recuperación mediante el almacenamiento (temporalmente) de los datos necesarios para el panel en un almacén de datos de alto rendimiento, como Azure SQL.

Respuesta automatizada a incidentes

Aunque las representaciones visuales del estado de las aplicaciones proporcionan información operativa y empresarial valiosa para admitir la detección y el diagnóstico de problemas, se basa en la preparación y las interpretaciones de los equipos operativos, así como en la eficacia de las respuestas posteriores desencadenadas por el usuario. Por lo tanto, para maximizar la confiabilidad, es necesario implementar alertas extensas para detectar de forma proactiva y responder a problemas casi en tiempo real.

Azure Monitor proporciona un amplio marco de alertas para detectar, clasificar y responder a señales operativas a través de grupos de acciones. Por lo tanto, esta sección se centrará en el uso de alertas de Azure Monitor para impulsar acciones automatizadas en respuesta a las desviaciones actuales o potenciales de un estado de aplicación correcto.

Importante

Las alertas y la acción automatizada son fundamentales para detectar y responder rápidamente a los problemas a medida que se producen, antes de que se produzca un mayor impacto negativo. Las alertas también proporcionan un mecanismo para interpretar las señales entrantes y responder a evitar problemas antes de que se produzcan.

Consideraciones de diseño

  • Las reglas de alerta se definen para activarse cuando se cumplen criterios condicionales para las señales entrantes, que pueden incluir varios orígenes de datos, como métricas, consultas de registro o pruebas de disponibilidad.

  • Las alertas se pueden definir en Log Analytics o Azure Monitor en el recurso específico.

  • Algunas métricas solo son interrogables en Azure Monitor, ya que no todos los puntos de datos de diagnóstico están disponibles en Log Analytics.

  • La API de alertas de Azure Monitor se puede usar para recuperar alertas activas e históricas.

  • Hay límites de suscripción relacionados con las alertas y los grupos de acciones, que deben diseñarse para:

    • Existen límites para el número de reglas de alerta configurables.
    • La API de alertas tiene límites de limitación, que se deben tener en cuenta para escenarios de uso extremo.
    • Los grupos de acciones tienen varios límites estrictos para el número de respuestas configurables, que se deben diseñar para.
      • Cada tipo de respuesta tiene un límite de 10 acciones, aparte del correo electrónico, que tiene un límite de 1000 acciones.

  • Las alertas se pueden integrar dentro de un modelo de estado por capas mediante la creación de una regla de alertas para una consulta de búsqueda de registros guardada desde la función de puntuación "raíz" del modelo. Por ejemplo, mediante "WebsiteHealthScore" y alertas sobre un valor numérico que representa un estado "Incorrecto".

Recomendaciones de diseño

  • Para las alertas centradas en recursos, cree reglas de alerta en Azure Monitor para asegurarse de que todos los datos de diagnóstico están disponibles para los criterios de la regla de alerta.

  • Consolide acciones automatizadas en un número mínimo de grupos de acciones, alineados con los equipos de servicio para admitir un enfoque de DevOps.

  • Responda a señales de uso excesivo de recursos mediante operaciones de escalado automatizado, mediante funcionalidades de escalado automático nativo de Azure siempre que sea posible. Cuando la funcionalidad de escalado automático integrada no sea aplicable, use la puntuación de mantenimiento del componente para modelar señales y determinar cuándo responder con operaciones de escalado automatizadas. Asegúrese de que las operaciones de escalado automatizadas se definen según un modelo de capacidad, que cuantifica las relaciones de escala entre componentes, de modo que las respuestas de escala abarcan componentes que deben escalarse en relación con otros componentes.

  • Acciones de modelo para dar cabida a una ordenación prioritaria, que debe determinarse por el impacto empresarial.

  • Use la API de alertas de Azure Monitor para recopilar alertas históricas que se incorporen en el almacenamiento operativo "en frío" para el análisis avanzado.

  • Para escenarios críticos de error, que no se pueden cumplir con una respuesta automatizada, asegúrese de que la "automatización de runbooks" operativa esté en contexto para impulsar una acción rápida y coherente una vez que se proporciona la interpretación manual y el cierre de sesión. Uso de notificaciones de alerta para impulsar la identificación rápida de problemas que requieren interpretación manual

  • Cree asignaciones dentro de sprints de ingeniería para impulsar mejoras incrementales en las alertas para asegurarse de que los nuevos escenarios de error que no se hayan considerado anteriormente se pueden adaptar completamente dentro de nuevas acciones automatizadas.

  • Realice pruebas de preparación operativa como parte de los procesos de CI/CD para validar las reglas de alerta clave para las actualizaciones de implementación.

Acción predictiva y operaciones de inteligencia artificial (AIOps)

Los modelos de Aprendizaje automático se pueden aplicar para correlacionar y priorizar los datos operativos, lo que ayuda a recopilar información crítica relacionada con el filtrado de alertas excesivas "ruido" y predecir problemas antes de que causen impacto, así como acelerar la respuesta a incidentes cuando lo hacen.

Más concretamente, se puede aplicar una metodología de AIOps a información crítica sobre el comportamiento del sistema, los usuarios y los procesos de DevOps. Estas conclusiones pueden incluir la identificación de un problema que sucede ahora (detectar), cuantificar por qué está ocurriendo el problema (diagnosticar) o indicar lo que ocurrirá en el futuro (predecir). Esta información se puede usar para impulsar acciones que ajusten y optimicen la aplicación para mitigar problemas activos o potenciales, mediante métricas empresariales clave, métricas de calidad del sistema y métricas de productividad de DevOps, para priorizar según el impacto empresarial. Las acciones realizadas se pueden integrar en el sistema a través de un bucle de comentarios que entrena aún más el modelo subyacente para impulsar eficiencias adicionales.

Metodologías críticas de

Hay varias tecnologías analíticas en Azure, como Azure Synapse y Azure Databricks, que se pueden usar para compilar y entrenar modelos analíticos para AIOps. Por lo tanto, esta sección se centrará en cómo se pueden colocar estas tecnologías dentro de un diseño de aplicación para dar cabida a AIOps e impulsar la acción predictiva, centrándose en Azure Synapse que reduce la fricción al reunir lo mejor de los servicios de datos de Azure junto con las eficaces características nuevas.

AIOps se usa para impulsar la acción predictiva, interpretar y correlacionar señales operativas complejas observadas durante un período sostenido para responder y evitar problemas antes de que se produzcan.

Consideraciones de diseño

  • Azure Synapse Analytics ofrece varias funcionalidades de Machine Learning (ML).

    • Los modelos de ML se pueden entrenar y ejecutar en grupos de Spark de Synapse con bibliotecas como MLLib, SparkML y MMLSpark, así como bibliotecas populares de código abierto, como Scikit Learn.
    • Los modelos de ML se pueden entrenar con herramientas comunes de ciencia de datos como PySpark/Python, Scala o .NET.

  • Synapse Analytics se integra con Azure ML a través de cuadernos de Azure Synapse, lo que permite entrenar modelos de ML en un área de trabajo de Azure ML mediante ML automatizado.

  • Synapse Analytics también permite que las funcionalidades de APRENDIZAJE automático que usan Azure Cognitive Services resuelvan problemas generales en varios dominios, como la detección de anomalías. Cognitive Services se puede usar en Azure Synapse, Azure Databricks y a través de SDK y API REST en aplicaciones cliente.

  • Azure Synapse se integra de forma nativa con herramientas de Azure Data Factory para extraer, transformar y cargar (ETL) o ingerir datos dentro de las canalizaciones de orquestación.

  • Azure Synapse permite el registro de conjuntos de datos externo a los datos almacenados en Azure Blob Storage o Azure Data Lake Storage.

    • Los conjuntos de datos registrados se pueden usar en las tareas de análisis de datos del grupo de Spark de Synapse.

  • Azure Databricks se puede integrar en canalizaciones de Azure Synapse Analytics para funcionalidades adicionales de Spark.

    • Synapse organiza la lectura de datos y lo envía a un clúster de Databricks, donde se puede transformar y preparar para el entrenamiento del modelo de ML.

  • Normalmente, los datos de origen deben prepararse para el análisis y el aprendizaje automático.

    • Synapse ofrece varias herramientas para ayudar con la preparación de datos, incluidos apache Spark, cuadernos de Synapse y grupos de SQL sin servidor con T-SQL y visualizaciones integradas.

  • Los modelos de ML entrenados, operativos e implementados se pueden usar para la puntuación por lotes en Synapse.

    • Los escenarios de AIOps, como la ejecución de predicciones de regresión o degradación en canalizaciones de CI/CD, pueden requerir puntuación en tiempo real .

  • Hay límites de suscripción para Azure Synapse, que deben entenderse completamente en el contexto de una metodología de AIOps.

  • Para incorporar completamente AIOps, es necesario proporcionar datos de observabilidad casi en tiempo real a modelos de inferencia de ML en tiempo real de forma continua.

    • Las funcionalidades como la detección de anomalías deben evaluarse dentro del flujo de datos de observabilidad.

Recomendaciones de diseño

  • Asegúrese de que todos los recursos de Azure y los componentes de la aplicación estén totalmente instrumentados para que haya disponible un conjunto de datos operativo completo para el entrenamiento del modelo de AIOps.

  • Ingiera datos operativos de Log Analytics de las cuentas de Azure Storage globales y regionales en Azure Synapse para su análisis.

  • Use la API de alertas de Azure Monitor para recuperar alertas históricas y almacenarla en el almacenamiento en frío para que los datos operativos se usen posteriormente en los modelos de ML. Si se usa la exportación de datos de Log Analytics, almacene datos de alertas históricos en las mismas cuentas de Azure Storage que los datos exportados de Log Analytics.

  • Después de preparar los datos ingeridos para el entrenamiento de ML, escríbalos de nuevo en Azure Storage para que esté disponible para el entrenamiento del modelo de ML sin necesidad de que se ejecuten los recursos de proceso de preparación de datos de Synapse.

  • Asegúrese de que la operacionalización del modelo de ML admite la puntuación por lotes y en tiempo real.

  • A medida que se crean modelos de AIOps, implemente MLOps y aplique prácticas de DevOps para automatizar el ciclo de vida de ML para el entrenamiento, la operacionalización, la puntuación y la mejora continua. Cree un proceso iterativo de CI/CD para los modelos de AIOps ML.

  • Evalúe Azure Cognitive Services para escenarios predictivos específicos debido a su baja sobrecarga administrativa e integración. Considere la detección de anomalías para marcar rápidamente las variaciones inesperadas en los flujos de datos de observabilidad.

Paso siguiente

Revise las consideraciones de implementación y pruebas.

Implementación y pruebas