Recomendaciones para diseñar y crear un sistema de supervisión

Se aplica a esta recomendación de lista de comprobación de excelencia operativa de Azure Well-Architected Framework:

OE:07 Diseñe e implemente un sistema de supervisión para validar las opciones de diseño e informar sobre el diseño futuro y las decisiones empresariales. Este sistema captura y expone la telemetría operativa, las métricas y los registros que emiten desde la infraestructura y el código de la carga de trabajo.

Guía relacionada: Recomendaciones para instrumentar una aplicación

En esta guía se describen las recomendaciones para diseñar y crear un sistema de supervisión. Para supervisar eficazmente la carga de trabajo en busca de seguridad, rendimiento y confiabilidad, necesita un sistema completo con su propia pila que proporciona la base para todas las funciones de supervisión, detección y alertas.

Definiciones

Término Definición
Registros Eventos del sistema registrados. Los registros pueden contener diferentes tipos de datos en un formato de texto estructurado o de forma libre. Contienen una marca de tiempo.
Métricas Valores numéricos recopilados a intervalos regulares. Las métricas describen algunos aspectos de un sistema en un momento determinado.

Estrategias de diseño principales

Para implementar un diseño completo del sistema de supervisión para la carga de trabajo, siga estos principios básicos:

  • Siempre que sea práctico, aproveche las herramientas de supervisión proporcionadas por la plataforma, que normalmente requieren muy poca configuración y puede proporcionar información detallada sobre la carga de trabajo que, de lo contrario, podría ser difícil de lograr.

  • Recopile registros y métricas de toda la pila de cargas de trabajo. Todos los recursos de infraestructura y las funciones de aplicación deben configurarse para generar datos estandarizados, significativos y que deben recopilarse.

  • Almacene los datos recopilados en una solución de almacenamiento estandarizada, confiable y segura.

  • Procese los datos almacenados para que se puedan controlar mediante soluciones de análisis y visualización.

  • Analice los datos procesados para determinar con precisión el estado de la carga de trabajo.

  • Visualice el estado de la carga de trabajo en paneles o informes significativos para los equipos de carga de trabajo y otras partes interesadas.

  • Configure alertas accionables y otras respuestas automáticas a umbrales definidos de forma inteligente para notificar a los equipos de carga de trabajo cuando surjan problemas.

  • Incluya sistemas de supervisión y alertas en las prácticas generales de pruebas de cargas de trabajo.

  • Asegúrese de que los sistemas de supervisión y alertas están en el ámbito de la mejora continua. El comportamiento de la aplicación y la infraestructura en producción proporciona oportunidades de aprendizaje continuo. Incorpore esas lecciones a los diseños de supervisión y alertas.

  • Vincula los datos de supervisión que recopilas y analizas a los flujos de usuario y del sistema para correlacionar el estado de los flujos con los datos, además del estado general de la carga de trabajo. El análisis de esos datos en términos de los flujos ayudará a alinear la estrategia de observabilidad con el modelo de mantenimiento.

Debe automatizar todas las funciones del sistema de supervisión tanto como sea posible, y todas deben ejecutarse continuamente, todo el día, todos los días.

Esta canalización de flujo de trabajo muestra el sistema de supervisión:

Diagrama que muestra las fases de un sistema de supervisión completo como una canalización.

Colección

Nota

Debe instrumentar la aplicación para habilitar el registro. Para más información, consulte la guía de instrumentación.

Debe configurar todos los componentes de carga de trabajo, tanto si son recursos de infraestructura como funciones de aplicación, para capturar telemetría o eventos como registros y métricas.

Los registros son principalmente útiles para detectar e investigar anomalías. Normalmente, los registros los genera el componente de carga de trabajo y, a continuación, se envían a la plataforma de supervisión o se extraen mediante la automatización.

Las métricas son principalmente útiles para crear un modelo de mantenimiento e identificar tendencias en el rendimiento y la confiabilidad de la carga de trabajo. Las métricas también son útiles para identificar tendencias en el comportamiento de uso de los clientes. Estas tendencias pueden ayudar a guiar las decisiones sobre mejoras desde la perspectiva del cliente. Normalmente, las métricas se definen en la plataforma de supervisión y la plataforma de supervisión y otras herramientas sondean la carga de trabajo para capturar métricas.

Datos de aplicación

En el caso de las aplicaciones, el servicio de recopilación puede ser una herramienta de administración del rendimiento de aplicaciones (APM) que se puede ejecutar de forma autónoma desde la aplicación que genera los datos de instrumentación. Después de habilitar APM, tiene una visibilidad clara de las métricas importantes, en tiempo real e históricamente. Use un nivel adecuado de registro. El registro detallado puede generar costos significativos. Establezca los niveles de registro según el entorno. Los entornos inferiores no necesitan el mismo nivel de detalle que la producción, por ejemplo.

Los registros de aplicaciones admiten el ciclo de vida completo de la aplicación. El registro es esencial para comprender cómo funciona la aplicación en varios entornos, qué eventos se producen y las condiciones en las que se producen.

Se recomienda recopilar registros y eventos de aplicación en todos los entornos principales. Separe los datos entre entornos tanto como sea posible mediante el uso de diferentes almacenes de datos para cada entorno, si es práctico hacerlo. Use filtros para asegurarse de que los entornos no crítico no complican la interpretación de los registros de producción. Por último, las entradas de registro correspondientes en la aplicación deben capturar un identificador de correlación para sus respectivas transacciones.

Debe capturar eventos de aplicación en tipos de datos estructurados con puntos de datos legibles por máquina en lugar de tipos de cadena no estructurados. Un formato estructurado que usa un esquema conocido puede facilitar el análisis y el análisis de registros. Además, los datos estructurados se pueden indexar y buscar fácilmente, y los informes se pueden simplificar enormemente.

Los datos deben tener un formato independiente que sea independiente de la máquina, el sistema operativo o el protocolo de red. Por ejemplo, emita información en un formato autodescripto como JSON, MessagePack o Protobuf en lugar de ETL/ETW. Un formato estándar permite al sistema construir canalizaciones de procesamiento. Los componentes que leen, transforman y envían datos en el formato estándar se pueden integrar fácilmente.

Datos de infraestructura

En el caso de los recursos de infraestructura de la carga de trabajo, asegúrese de recopilar registros y métricas. Para los sistemas de infraestructura como servicio (IaaS), capture los registros de sistema operativo, capa de aplicación y diagnóstico, además de las métricas relacionadas con el estado de la carga de trabajo. En el caso de los recursos de plataforma como servicio (PaaS), es posible que esté limitado en la capacidad de capturar registros relacionados con la infraestructura subyacente, pero asegúrese de que puede capturar registros de diagnóstico además de las métricas relacionadas con el estado de la carga de trabajo.

Tanto como sea posible, recopile registros de la plataforma en la nube. Es posible que pueda recopilar registros de actividad para la suscripción y los registros de diagnóstico para el plano de administración.

Estrategias de recopilación

Evite recuperar manualmente los datos de telemetría de cada componente. Mueva los datos a una ubicación central y consolide allí. En el caso de una solución de varias regiones, se recomienda recopilar, consolidar y almacenar datos en una región por región y, a continuación, agregar los datos regionales en un único sistema central.

Compensación: tenga en cuenta que hay implicaciones de costos para tener almacenes de datos regionales y centralizados.

Para optimizar el uso del ancho de banda, dé prioridad en función de la importancia de los datos. Puede transferir los datos menos urgentes en lotes. Sin embargo, estos datos no se deben retrasar indefinidamente, especialmente si contiene información sensible al tiempo.

Hay dos modelos principales que el servicio de recopilación puede usar para recopilar datos de instrumentación:

  • Modelo de extracción: recupera activamente los datos de los distintos registros y otros orígenes para cada instancia de la aplicación.

  • Modelo de inserción: espera pasivamente que los datos se envíen desde los componentes que constituyen cada instancia de la aplicación.

Agentes de supervisión

Puede usar agentes de supervisión en el modelo de extracción. Los agentes se ejecutan localmente en un proceso independiente con cada instancia de la aplicación, extrae periódicamente los datos y escribe la información directamente en el almacenamiento común compartido por todas las instancias de la aplicación.

Diagrama que muestra el uso de un agente de supervisión para extraer información y escribirla en el almacenamiento compartido.

Nota

El uso de un agente de supervisión resulta muy conveniente para capturar datos de instrumentación que se extraen naturalmente de un origen de datos. Es adecuado para una aplicación a pequeña escala que se ejecuta en un número limitado de nodos en una sola ubicación. Algunos ejemplos incluyen información de SQL Server vistas de administración dinámica o la longitud de una cola de Azure Service Bus.

Consideraciones de rendimiento

Una aplicación compleja y altamente escalable podría generar grandes volúmenes de datos. La cantidad de datos puede sobrecargar fácilmente el ancho de banda de E/S disponible para una única ubicación central. La solución de telemetría no debe actuar como cuello de botella, y debe ser escalable a medida que el sistema se expanda. Idealmente, la solución debe incorporar un grado de redundancia para reducir los riesgos de perder información de supervisión importante (como la auditoría o los datos de facturación) si se produce un error en parte del sistema.

Una manera de almacenar en búfer los datos de instrumentación consiste en usar la puesta en cola:

Diagrama que muestra cómo puede usar una cola para almacenar en búfer los datos de instrumentación.

En esta arquitectura, el servicio de recopilación de datos envía datos a una cola. Una cola de mensajes es adecuada porque proporciona semántica "al menos una vez" que ayuda a garantizar que los datos en cola no se perderán después de publicarlos. Puede implementar el servicio de escritura de almacenamiento mediante un rol de trabajo independiente. Puede usar el patrón Priority Queue para implementar esta arquitectura.

Para obtener escalabilidad, puede ejecutar varias instancias del servicio de escritura de almacenamiento. Si se supervisa un gran volumen de eventos o un gran número de puntos de datos, puede usar Azure Event Hubs para enviar los datos a una instancia de proceso diferente para su procesamiento y almacenamiento.

Estrategias de consolidación

Los datos recopilados de una única instancia de una aplicación proporcionan una vista localizada del estado y el rendimiento de esa instancia. Para evaluar el estado general del sistema, debe consolidar algunos aspectos de los datos de las vistas locales. Puede hacerlo después de almacenar los datos, pero, en algunos casos, puede hacerlo a medida que se recopilan los datos.

Diagrama que muestra un ejemplo de uso de un servicio para consolidar los datos de instrumentación.

Los datos de instrumentación se pueden pasar por un servicio independiente de consolidación de datos que combine los datos y sirva de proceso de filtrado y limpieza. Por ejemplo, puede fusionar datos de instrumentación que incluyan la misma información de correlación, como un identificador de actividad. (Un usuario podría iniciar una operación empresarial en un nodo y, a continuación, transferirse a otro nodo si se produce un error en el primer nodo o debido a cómo se configura el equilibrio de carga). Este proceso también puede detectar y quitar los datos duplicados. (La duplicación puede producirse si el servicio de telemetría usa colas de mensajes para insertar datos de instrumentación fuera del almacenamiento).

Storage

Al elegir una solución de almacenamiento, tenga en cuenta el tipo de datos, cómo se usa y la urgencia que se necesita.

Nota

Use soluciones de almacenamiento independientes para entornos que no son de producción y de producción para garantizar que los datos de cada entorno sean fáciles de identificar y administrar.

Tecnologías de almacenamiento

Considere un enfoque de persistencia poliglot, donde es probable que se usen diferentes tipos de información en tecnologías más adecuadas para la forma en que es probable que se use cada tipo.

Por ejemplo, se accede a Azure Blob Storage y Azure Table Storage de maneras similares. Pero las operaciones que puede realizar en ellos difieren, al igual que la granularidad de los datos que contienen. Si necesita realizar más operaciones de análisis o precisa funcionalidades de búsqueda de texto completo en los datos, podría ser más apropiado usar el almacenamiento de datos que ofrezca funcionalidades que estén optimizadas para tipos concretos de accesos a datos y consultas. Por ejemplo:

  • Los datos de los contadores de rendimiento se pueden almacenar en una base de datos SQL para permitir el análisis ad hoc.

  • Es posible que sea mejor almacenar los registros de seguimiento en los registros de Azure Monitor o azure Data Explorer.

  • Puede almacenar información de seguridad en una solución HDFS.

Es posible que se necesiten los mismos datos de instrumentación para más de un fin. Por ejemplo, puede usar contadores de rendimiento para proporcionar una vista histórica del rendimiento del sistema a lo largo del tiempo. Esta información puede combinarse con otros datos de uso para generar información de facturación del cliente. En estas situaciones, los mismos datos se pueden enviar a más de un destino, como a una base de datos de documentos que puede ser un almacén a largo plazo para contener información de facturación y a un almacén multidimensional para controlar análisis complejos de rendimiento.

Asegúrese de habilitar la funcionalidad para proteger los datos frente a la eliminación accidental, como bloqueos de recursos y eliminación temporal.

Además, asegúrese de proteger el acceso al almacenamiento mediante el control de acceso basado en rol para ayudar a garantizar que solo los usuarios que necesiten acceder a los datos puedan hacerlo.

Servicio de consolidación

Puede implementar otro servicio que recupera periódicamente los datos del almacenamiento compartido, las particiones y los filtra según su propósito y, a continuación, lo escribe en un conjunto adecuado de almacenes de datos.

Diagrama que muestra un servicio de creación de particiones de datos que mueve los datos a un almacén de datos adecuado en función de su tipo.

Un enfoque alternativo es incluir esta funcionalidad en el proceso de consolidación y limpieza y escribir los datos directamente en esos almacenes a medida que se recuperan, en lugar de guardarlos en un área intermedia de almacenamiento compartido.

Cada enfoque tiene sus ventajas e inconvenientes. La implementación de un servicio de creación de particiones independiente reduce la carga en el servicio de consolidación y limpieza, y permite que al menos algunos de los datos con particiones se vuelvan a generar si es necesario (dependiendo de la cantidad de datos que se conservan en el almacenamiento compartido). Sin embargo, este enfoque consume recursos adicionales. Además, podría haber un retraso entre la recepción de los datos de instrumentación de cada instancia de aplicación y la conversión de estos datos en información útil.

Consideraciones sobre las consultas

Considere la urgencia con que se requieren los datos. Es necesario que el acceso a los datos que generan alertas sea rápido, de forma que deben mantenerse en almacenamientos de datos rápido, y se deben indexar o estructurar para optimizar las consultas que realiza el sistema de alertas. En algunos casos, puede ser necesario que el servicio de recopilación aplique un formato a los datos y los guarde localmente para que una instancia local del sistema de alertas pueda enviar notificaciones rápidamente. Los mismos datos se pueden enviar al servicio de escritura en almacenamiento que se muestra en los diagramas anteriores y se pueden almacenar de forma centralizada si también se necesitan para otros fines.

Consideraciones sobre la retención de datos

En algunos casos, una vez procesados y transferidos los datos, puede quitar los datos de origen sin procesar originales almacenados localmente. En otros casos, puede ser necesario o útil guardar la información sin procesar. Por ejemplo, es posible que desee mantener los datos generados para la depuración disponibles en su formato sin procesar, pero luego descartarlos rápidamente después de que se resuelvan los errores.

Los datos de rendimiento suelen tener una duración más larga para que pueda usarlo para detectar tendencias de rendimiento y para planear la capacidad. La vista consolidada de estos datos normalmente se mantiene en línea durante un período limitado para permitir un acceso rápido. Después, se pueden archivar o descartar.

Resulta útil almacenar datos históricos, así puede detectar tendencias a largo plazo. En lugar de guardar los datos antiguos en su totalidad, es posible que pueda muestrear los datos para reducir su resolución y ahorrar costos de almacenamiento. Por ejemplo, en lugar de guardar indicadores de rendimiento de minutos a minuto, puede consolidar los datos de más de un mes de antigüedad para formar una vista de hora a hora.

Es posible que los datos recopilados para la medición y facturación de los clientes se guarden de forma indefinida. Además, los requisitos normativos pueden dictar que la información recopilada para la auditoría y la seguridad deben archivarse y guardarse. Estos datos también son confidenciales y es necesario cifrarlos o aplicarles otro tipo de protección para evitar su manipulación. Nunca debe registrar contraseñas de usuario u otra información que pueda usarse para confirmar el fraude de identidad. Debe limpiar estos detalles de los datos antes de almacenarlos.

Para asegurarse de que cumple con las leyes y regulaciones, minimice el almacenamiento de cualquier información identificable. Si necesita almacenar información identificable, asegúrese de que, al diseñar la solución, tenga en cuenta los requisitos que permiten a los usuarios solicitar que se eliminen su información.

Análisis

Después de recopilar datos de varios orígenes de datos, analícelos para evaluar el bienestar general del sistema. Para este análisis, tenga un conocimiento claro de lo siguiente:

  • Estructuración de datos basados en KPI y métricas de rendimiento que ha definido.

  • Cómo correlacionar los datos capturados en diferentes métricas y archivos de registro. Esta correlación es importante cuando realiza un seguimiento de una secuencia de eventos y puede ayudarle a diagnosticar problemas.

En la mayoría de los casos, los datos de cada componente de la arquitectura se capturan localmente y, a continuación, se combinan con precisión con los datos generados por otros componentes.

Por ejemplo, una aplicación de tres niveles podría tener:

  • Nivel de presentación que permite a un usuario conectarse a un sitio web.

  • Nivel intermedio que hospeda un conjunto de microservicios que procesa la lógica de negocios.

  • Nivel de base de datos que almacena los datos asociados a la operación.

Los datos de uso de una sola operación empresarial pueden abarcar los tres niveles. Esta información debe correlacionarse para ofrecer una visión general del uso de recursos y procesamiento por parte de la operación. La correlación puede implicar cierto preprocesamiento y filtrado de datos en el nivel de base de datos. En el nivel intermedio, la agregación y el formato son tareas comunes.

Recomendaciones

  • Correlacione los registros de nivel de aplicación y de recursos. Evalúe los datos en ambos niveles para optimizar la detección de problemas y la solución de estos problemas. Puede agregar los datos en un único receptor de datos o aprovechar los métodos que consultan eventos en ambos niveles. Se recomienda una solución unificada, como Azure Log Analytics, para agregar y consultar registros de nivel de aplicación y de recursos.

  • Defina tiempos de retención claros en el almacenamiento para el análisis en frío. Se recomienda esta práctica para habilitar el análisis histórico durante un período específico. También puede ayudarle a controlar los costos de almacenamiento. Implemente procesos que garantizan que los datos se archivan en un almacenamiento más barato y agreguen datos para el análisis de tendencias a largo plazo.

  • Analice las tendencias a largo plazo para predecir problemas operativos. Evalúe los datos a largo plazo para formar estrategias operativas y también para predecir qué problemas operativos es probable que se produzcan y cuándo. Por ejemplo, puede tener en cuenta que los tiempos de respuesta promedio aumentan lentamente con el tiempo y se aproximan al objetivo máximo.

Para obtener instrucciones detalladas sobre estas recomendaciones, consulte Análisis de datos de supervisión para aplicaciones en la nube.

Visualización

Paneles

La manera más común de visualizar datos es usar paneles que pueden mostrar información como una serie de gráficos o gráficos, o en algún otro formulario visual. Estos elementos se pueden parametrizar y un analista puede seleccionar los parámetros importantes, como el período de tiempo, para cualquier situación específica.

Alinee los paneles con el modelo de estado para que indiquen cuándo la carga de trabajo o los componentes de la carga de trabajo son correctas, degradadas o incorrectas.

Para que un sistema de panel funcione de forma eficaz, debe ser significativo para el equipo de carga de trabajo. Visualice la información relacionada con el estado de la carga de trabajo y que también sea procesable. Cuando la carga de trabajo o un componente se degradan o están en mal estado, los miembros del equipo de carga de trabajo deben ser capaces de identificar fácilmente dónde se origina el problema y comenzar sus acciones correctivas o investigaciones. Por el contrario, la información que no es procesable o que no está relacionada con el estado de la carga de trabajo puede hacer que el panel sea innecesariamente complejo y frustrante para los miembros del equipo que intentan distinguir el ruido en segundo plano de los datos accionables.

Es posible que tenga paneles para las partes interesadas o los desarrolladores que están personalizados para mostrar solo los datos sobre la carga de trabajo que encuentran pertinentes. Asegúrese de que el equipo de carga de trabajo comprende los tipos de puntos de datos que otros equipos están interesados en ver y obtener una vista previa de los paneles antes de compartirlos para comprobar la claridad. Proporcionar paneles sobre la carga de trabajo para las partes interesadas es una buena manera de mantenerlos informados del estado de la carga de trabajo, pero conlleva un riesgo de ser productivo si las partes interesadas no entienden claramente los datos que ven.

Un buen panel no solo muestra información. También permite a un analista plantear preguntas improvisadas sobre esa información. Algunos sistemas ofrecen herramientas de administración que un operador puede usar para realizar estas tareas y explorar los datos subyacentes. En su lugar, en función del repositorio que se usa para contener la información, puede ser posible consultar los datos directamente o importarlos en herramientas como Excel para realizar análisis e informes adicionales.

Nota

Restrinja el acceso del panel al personal autorizado. Es posible que la información sobre los paneles sea comercialmente confidencial. También debe proteger los datos subyacentes para evitar que los usuarios los cambien.

Notificación

Los informes se utilizan para generar una vista general del sistema. Puede incorporar datos históricos e información actual. Los requisitos de los informes se dividen en dos amplias categorías: los informes operativos y los de seguridad.

Los informes operativos suelen incluir lo siguiente:

  • Agregación de estadísticas que puede usar para comprender la utilización de recursos del sistema general o de subsistemas concretos durante un período especificado.

  • Identificación de tendencias en el uso de recursos en todo el sistema o en subsistemas concretos durante un período de tiempo determinado.

  • Supervisión de las excepciones que se hayan producido en todo el sistema o en subsistemas concretos durante un período determinado.

  • Determinar la eficacia de la aplicación para los recursos implementados y comprender si el volumen de recursos y sus costos asociados se pueden reducir sin afectar innecesariamente al rendimiento.

Los informes de seguridad realizan un seguimiento del uso del sistema por parte del cliente. Pueden incluir:

  • Auditoría de las operaciones de usuario. Esta tarea requiere registrar las solicitudes individuales que cada usuario completa, junto con fechas y horas. Los datos se deben estructurar para permitir que un administrador reconstruya rápidamente la secuencia de operaciones que un usuario completa durante un período especificado.

  • Seguimiento del uso de recursos por usuario. Esta tarea requiere registrar cómo cada solicitud de un usuario accede a los distintos recursos que componen el sistema y durante cuánto tiempo. Un administrador puede usar estos datos para generar un informe de uso, por usuario, durante un período especificado, posiblemente para la facturación.

En muchos casos, los procesos por lotes pueden generar informes según una programación definida. La latencia no es normalmente un problema. También debe tener procesos por lotes que puedan generar informes de forma espontánea, según sea necesario. Por ejemplo, si almacena datos en una base de datos relacional como Azure SQL Database, puede usar una herramienta como SQL Server Reporting Services para extraer y dar formato a los datos y presentarlos como un conjunto de informes.

Alertas

Para ayudar a garantizar que el sistema siga siendo correcto, dinámico y seguro, establezca alertas para que los operadores puedan responder a ellos de forma oportuna. Una alerta puede contener suficiente información contextual para ayudarles a empezar a trabajar rápidamente en las actividades de diagnóstico. Las alertas se pueden usar para invocar funciones de corrección como el escalado automático u otros mecanismos de recuperación automática. Las alertas también pueden habilitar el reconocimiento de costos proporcionando visibilidad sobre los presupuestos y los límites.

Recomendaciones

  • Defina un proceso para la respuesta de alerta que identifique los propietarios responsables y las acciones.

  • Configure alertas para un ámbito bien definido (tipos y grupos de recursos) y ajuste el nivel de detalle para minimizar el ruido.

  • Use una solución de alertas automatizada, como Splunk o Azure Monitor, en lugar de requerir que las personas busquen activamente problemas.

  • Use alertas para poner en funcionamiento los procesos de corrección. Por ejemplo, cree automáticamente vales para realizar el seguimiento de problemas y sus soluciones.

  • Realice un seguimiento del estado de los servicios de la plataforma en la nube en regiones, la comunicación sobre interrupciones, las actividades de mantenimiento planeado y otros avisos de estado.

Umbrales

Las alertas se generan cuando se cruzan los umbrales, según lo detecte el sistema de supervisión. Asegúrese de que los umbrales establecidos generalmente le proporcionan tiempo suficiente para implementar los cambios necesarios en la carga de trabajo para evitar la degradación o las interrupciones. Por ejemplo, establezca el umbral de escalado automático para iniciar el escalado antes de que cualquiera de los sistemas en ejecución se agote hasta el punto de una experiencia de usuario degradada. Base los valores de umbral que asigne en la experiencia pasada en la administración de la infraestructura y validelos a través de las pruebas que se realizan como parte de las prácticas de pruebas.

Para obtener instrucciones detalladas sobre los casos de uso de alertas y otras consideraciones, consulte Diseño de una estrategia confiable de supervisión y alertas.

Facilitación de Azure

  • Azure Monitor es una solución de supervisión completa para recopilar, analizar y responder a los datos de supervisión de los entornos locales y en la nube.

  • Log Analytics es una herramienta de la Azure Portal que puede usar para editar y ejecutar consultas de registro en los datos del área de trabajo de Log Analytics.

    Si usa varias áreas de trabajo, consulte la guía de arquitectura del área de trabajo de Log Analytics para conocer los procedimientos recomendados.

  • Application Insights es una extensión de Azure Monitor. Proporciona características de APM.

  • Azure Monitor Insights son herramientas de análisis avanzadas para tecnologías específicas de Azure (como máquinas virtuales, servicios de aplicaciones y contenedores). Estas herramientas forman parte de Azure Monitor y Log Analytics.

  • Azure Monitor para soluciones de SAP es una herramienta de supervisión de Azure para entornos de SAP que se ejecutan en Azure.

  • Azure Policy puede ayudarle a aplicar los estándares de la organización y a evaluar el cumplimiento a gran escala.

  • Alertas de línea base de Azure Monitor (AMBA) es un repositorio central de definiciones de alertas que los clientes y asociados pueden usar para mejorar su experiencia de observabilidad a través de la adopción de Azure Monitor.

Lista de comprobación de excelencia operativa

Consulte el conjunto completo de recomendaciones.