Procedimientos recomendados para la supervisión y el diagnóstico

Las aplicaciones distribuidas y los servicios que se ejecutan en la nube son partes complejas del software que componen muchas partes móviles. En un entorno de producción, es importante realizar un seguimiento de cómo los clientes usan el sistema, realizar un seguimiento del uso de recursos y supervisar el estado y el rendimiento del sistema. Puede usar esta información para detectar y corregir problemas y detectar posibles problemas antes de que se produzcan.

Escenarios de supervisión y diagnóstico

Puede usar la supervisión para obtener información sobre cómo funciona un sistema. La supervisión es una parte fundamental del mantenimiento de los objetivos de calidad de servicio (QoS). Recopile datos de supervisión para los siguientes escenarios comunes:

• Asegúrese de que el sistema permanece en buen estado.

• Realice un seguimiento de la disponibilidad del sistema y sus componentes.

• Mantenga el rendimiento para asegurarse de que el rendimiento del sistema no se degrada inesperadamente a medida que aumenta el volumen de trabajo.

• Garantiza que el sistema cumple los acuerdos de nivel de servicio (SLA).

• Proteja la privacidad y seguridad del sistema, los usuarios y sus datos.

• Realizar un seguimiento de las operaciones de auditoría o normativas.

• Supervise el uso diario del sistema y solucione las tendencias que podrían provocar problemas.

• Realice un seguimiento de los problemas que se producen, desde el informe inicial hasta el análisis de posibles causas, rectificaciones, actualizaciones de software e implementación.

• Realizar un seguimiento de las operaciones y depurar las versiones de software.

En las secciones siguientes se describen estos escenarios con más detalle.

Monitoreo de la salud

Un sistema en buen estado funciona y puede procesar solicitudes. Use la supervisión de estado para generar una instantánea del estado actual del sistema para que pueda comprobar que todos los componentes funcionan según lo previsto.

Configuración de alertas

El sistema debe generar una alerta en cuestión de segundos si algún componente no funciona correctamente. Las alertas pueden resaltar el estado del sistema a través de señales de semáforo:

• Rojo: estado anómalo (el sistema se ha detenido)
• Amarillo para un estado parcialmente correcto (el sistema se ejecuta con una funcionalidad reducida)
• Verde: estado correcto

Un sistema completo de supervisión de estado muestra el estado de mantenimiento de cada subsistema y componente para que pueda determinar qué partes funcionan normalmente y qué partes están experimentando problemas.

Recopilar datos de estado

Las siguientes fuentes pueden generar los datos sin procesar necesarios para la supervisión del estado:

• Seguimiento de la ejecución de solicitudes de usuario. Puede usar esta información para determinar qué solicitudes se realizan correctamente o no y medir cuánto tarda cada solicitud.

• Monitorizar usuarios sintéticos. Este proceso simula las acciones que realiza un usuario y sigue una serie predefinida de pasos. Capture los resultados de cada paso.

• Registre excepciones, errores y advertencias. Puede capturar esta información de instrucciones de seguimiento incrustadas en el código de la aplicación y de los registros de eventos de los servicios a los que hace referencia el sistema.

• Supervisa el estado de los servicios que no son de Microsoft que usa el sistema. Es posible que tenga que obtener y procesar los datos de estado que proporcionan estos servicios.

• Supervise los puntos de conexión.

• Recopile información de rendimiento ambiental, como el uso de CPU en segundo plano o las operaciones de entrada/salida (E/S), incluida la actividad de red.

Analizar datos de salud

El enfoque principal del monitoreo de salud es indicar rápidamente si el sistema está en funcionamiento. El análisis en caliente de datos en tiempo real puede desencadenar una alerta si un componente crítico está en mal estado.

Un sistema más avanzado podría incluir un elemento predictivo que realiza un análisis en frío sobre cargas de trabajo recientes y actuales. Un análisis en frío puede identificar tendencias y determinar si es probable que el sistema permanezca en buen estado o necesite más recursos. Base este elemento predictivo en las siguientes métricas de rendimiento críticas:

• Tasa de solicitudes dirigidas a cada servicio o subsistema
• Los tiempos de respuesta de estas solicitudes
• El volumen de datos que fluye hacia y hacia fuera de cada servicio

Si el valor de cualquier métrica supera un umbral definido, el sistema puede generar una alerta para escalar verticalmente. También puede agregar recursos, reiniciar servicios con errores o limitar las solicitudes de prioridad inferior para mantener el estado del sistema.

Supervisión de disponibilidad

En un sistema correcto, todos los componentes y subsistemas están disponibles. La supervisión de disponibilidad está estrechamente relacionada con la monitorización del estado de salud del sistema. La supervisión del estado proporciona una vista inmediata del estado actual del sistema. La supervisión de disponibilidad realiza un seguimiento de la disponibilidad del sistema y sus componentes para generar estadísticas sobre el tiempo de actividad.

En muchos sistemas, algunos componentes, como las bases de datos, se configuran con redundancia integrada para permitir una conmutación por error rápida si se produce un error grave o una pérdida de conectividad. Recopile toda la información posible sobre estos fallos para determinar la causa y tomar medidas correctivas para evitar que se repitan.

Los datos necesarios para realizar un seguimiento de la disponibilidad pueden depender de varios factores de nivel inferior que podrían ser específicos de la aplicación, el sistema y el entorno. Un sistema de supervisión eficaz captura los datos de disponibilidad que corresponden a estos factores de bajo nivel y, a continuación, los agrega para proporcionar una imagen general del sistema. Por ejemplo, en un sistema de comercio electrónico, la funcionalidad empresarial que permite a un cliente realizar pedidos puede depender del repositorio que almacena los detalles del pedido y el sistema de pago que controla las transacciones monetarias. La disponibilidad de la característica de colocación de pedidos depende de la disponibilidad del repositorio y del subsistema de pago.

La solución de supervisión de disponibilidad proporciona vistas actuales e históricas del estado de disponibilidad de cada subsistema. Le avisa rápidamente cuando se produce un error en uno o varios servicios o cuando los usuarios no pueden conectarse a los servicios. Use esta información para identificar tendencias que podrían provocar un error en los subsistemas. Por ejemplo, puede usar los datos de disponibilidad para detectar qué servicios producen un error durante las horas de procesamiento máximas.

Recopilación de datos de disponibilidad

Supervise los usuarios sintéticos, registre excepciones, errores y advertencias, y supervise los puntos de conexión para generar los datos sin procesar necesarios para admitir la supervisión de disponibilidad. La aplicación puede exponer uno o varios puntos de conexión de estado, cada uno de los cuales comprueba el acceso a un área funcional del sistema. El sistema de supervisión sigue una programación definida para hacer ping a cada punto de conexión y recopilar los resultados, como éxito o error.

Registre todos los tiempos de espera, los fallos de conectividad de red y los intentos de reintento de conexión, y añada una marca temporal a todos los datos.

Análisis de datos de disponibilidad

Agregue y ponga en correlación los datos para admitir los siguientes tipos de análisis:

• Disponibilidad inmediata del sistema y subsistemas.

• Las tasas de errores de disponibilidad del sistema y los subsistemas. Correlacionar errores con actividades específicas para comprender las causas del error del sistema.

• Vista histórica de las tasas de error durante un período especificado y la carga en el sistema, como el número de solicitudes de usuario, cuando se produce un error.

• Las razones de falta de disponibilidad del sistema o subsistemas. Estos motivos incluyen la no ejecución del servicio, la conectividad perdida, los tiempos de espera o las respuestas de código de error.

Puede calcular la disponibilidad porcentual de un servicio durante un período de tiempo mediante la fórmula siguiente:

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Use esta fórmula para la supervisión del Acuerdo de Nivel de Servicio. La definición de tiempo de inactividad depende del servicio. Por ejemplo, el servicio de compilación Azure DevOps define el tiempo de inactividad como período, en minutos acumulados totales, durante el cual el servicio de compilación no está disponible. El servicio se considera no disponible durante un minuto si todas las solicitudes HTTP continuas durante ese minuto producen un código de error o no devuelven una respuesta.

Supervisión del rendimiento

A medida que aumenta el volumen de usuarios, el tamaño de los conjuntos de datos a los que acceden los usuarios aumenta y la posibilidad de error de uno o más componentes es más probable. La degradación del rendimiento suele producirse antes del error del componente. Si puede detectar la degradación, puede realizar pasos proactivos para evitar errores.

El rendimiento del sistema depende de varios factores. Normalmente, se mide cada factor a través de indicadores clave de rendimiento (KPI), como el número de transacciones de base de datos por segundo o el volumen de solicitudes de red que se han servido correctamente en un período de tiempo especificado. Algunos de estos KPI podrían estar disponibles como medidas de rendimiento específicas, mientras que otros KPI podrían derivarse de una combinación de métricas.

Requisitos para la supervisión del rendimiento

Para evaluar el rendimiento del sistema, normalmente necesita la siguiente información:

• Las tasas de respuesta de las solicitudes de usuario
• Número de solicitudes de usuario simultáneas
• El volumen del tráfico de red
• Tasas a las que el sistema completa las transacciones empresariales
• El promedio de tiempo de procesamiento de las solicitudes

Use herramientas que pueden ayudarle a identificar las siguientes correlaciones:

• El número de usuarios simultáneos frente a los tiempos de latencia de solicitud o cuánto tiempo tarda en empezar a procesar una solicitud después de que el usuario la envíe.

• Número de usuarios simultáneos frente al tiempo medio de respuesta, o cuánto tiempo tarda en completarse una solicitud después de iniciar el procesamiento.

• El volumen de solicitudes frente al número de errores de procesamiento

Junto con esta información funcional de alto nivel, obtenga una vista detallada del rendimiento de cada componente del sistema. Normalmente, los contadores de rendimiento de bajo nivel proporcionan estos datos. Realizan un seguimiento de la siguiente información:

• Uso de memoria
• Número de subprocesos
• Tiempo de procesamiento de CPU
• Longitud de la cola de solicitudes
• Tasas de E/S de disco o de red y errores
• Número de bytes escritos o leídos
• Indicadores de middleware, como la longitud de la cola

Todas las visualizaciones deben permitirle especificar un período de tiempo. Los datos mostrados pueden ser una instantánea de la situación actual o una vista histórica del rendimiento. El sistema debe generar alertas basadas en cualquier medida de rendimiento para cualquier valor especificado durante cualquier intervalo de tiempo especificado.

Recopilación de datos de rendimiento

Recopile datos de alto nivel de rendimiento, como el rendimiento, el número de usuarios simultáneos, el número de transacciones empresariales y las tasas de error, supervisando el progreso de las solicitudes de los usuarios. Incorpore instrucciones de seguimiento e información de tiempo en los puntos clave del código de la aplicación. Capture todos los errores, excepciones y advertencias con datos suficientes y correlacione con las solicitudes que los provocaron.

Si es posible, capture los datos de rendimiento de los sistemas externos que use la aplicación. Estos sistemas externos pueden proporcionar sus propios contadores de rendimiento u otras características para solicitar datos de rendimiento. Si este método no es posible, registre información como la hora de inicio y la hora de finalización de cada solicitud a un sistema externo y el estado correcto, incorrecto o de advertencia de la operación.

Los datos de rendimiento de bajo nivel de componentes individuales de un sistema pueden estar disponibles a través de características y servicios como los contadores de rendimiento de Windows que recopila el agente de Azure Monitor.

Análisis de datos de rendimiento

La mayoría de los análisis agregan datos de rendimiento por tipo de solicitud de usuario o por el subsistema o servicio al que se envía cada solicitud. Un ejemplo de solicitud de un usuario es añadir un artículo al carrito de la compra o el proceso de pago en un sistema de comercio electrónico.

Otro requisito común es resumir los datos de rendimiento en percentiles. Por ejemplo, puede determinar los tiempos de respuesta de 99% de solicitudes, 95% de solicitudes y 70% de solicitudes. Puede establecer objetivos de Acuerdo de Nivel de Servicio u otros objetivos para cada percentil. Informe de resultados continuos casi en tiempo real para ayudar a detectar problemas inmediatamente. Agregar resultados a lo largo del tiempo con fines estadísticos.

Los problemas de latencia también pueden afectar al rendimiento. Para identificar rápidamente la causa de cuellos de botella, evalúe la latencia de cada paso que realiza cada solicitud. Los datos de rendimiento deben proporcionar una manera de correlacionar las métricas de rendimiento de cada paso para asociarlos a una solicitud específica.

En función de los requisitos de visualización, puede resultar útil generar y almacenar un cubo de datos que contenga vistas de los datos sin procesar. Este cubo de datos puede permitir consultas complejas, no planeadas y análisis de información de rendimiento.

Supervisión de seguridad

Todos los sistemas comerciales que incluyan datos confidenciales deben implementar una estructura de seguridad. La sensibilidad de los datos normalmente determina la complejidad del mecanismo de seguridad. En un sistema que requiere que los usuarios se autentiquen, registre la siguiente información:

• Todos los intentos de inicio de sesión y si producen un error o se realizan correctamente

• Todas las operaciones realizadas por un usuario autenticado y los detalles de todos los recursos a los que acceden

• Cuando un usuario finaliza una sesión y cierra la sesión

La supervisión puede ayudar a detectar ataques en el sistema. Por ejemplo, varios intentos de inicio de sesión erróneos podrían indicar un ataque por fuerza bruta. Un aumento inesperado de las solicitudes podría ser el resultado de un ataque DDoS. Prepárese para supervisar todas las solicitudes a todos los recursos independientemente de su origen. Un sistema que tiene una vulnerabilidad de inicio de sesión podría exponer accidentalmente recursos sin necesidad de que un usuario inicie sesión.

Requisitos para la supervisión de seguridad

Los datos que captura la supervisión de seguridad pueden ayudarle a:

• Detecte intrusiones intentadas por una entidad no autenticada.

• Identifique los intentos de las entidades para realizar operaciones en los datos a los que no tienen acceso.

• Determine si un usuario no autenticado o un usuario autenticado malintencionado está intentando atacar el sistema.

Para admitir estas tareas, el sistema debe enviar alertas si:

• Una cuenta realiza intentos de inicio de sesión erróneos repetidos dentro de un período especificado.

• Una cuenta autenticada intenta acceder repetidamente a un recurso prohibido durante un período especificado.

• Se produce un gran número de solicitudes no autenticadas o no autorizadas durante un período especificado.

Configure alertas para incluir la dirección de host del origen para cada solicitud. Si las infracciones de seguridad se producen regularmente desde un intervalo específico de direcciones, puede bloquear estos hosts.

Una parte clave del mantenimiento de la seguridad de un sistema es la capacidad de detectar rápidamente las acciones que se desvía del patrón habitual. Puede mostrar información como el número de solicitudes de inicio de sesión correctas o erróneas visualmente para ayudar a detectar picos de actividad en momentos inusuales. También puede usar esta información para configurar el escalado automático basado en el tiempo. Por ejemplo, si ve que muchos usuarios inician sesión periódicamente en un momento específico, puede iniciar servicios de autenticación adicionales para controlar el volumen de trabajo. Apague estos servicios después de que se supere el pico.

Recopilación de datos de seguridad

La seguridad es un aspecto integral de la mayoría de los sistemas distribuidos y la supervisión genera datos pertinentes en varios puntos del sistema. Adopte un enfoque de administración de eventos e información de seguridad (SIEM) para recopilar información resultante de los eventos generados por la aplicación, el equipo de red, los servidores, los firewalls, el software antivirus y otros elementos de prevención de intrusiones.

La supervisión de seguridad puede incorporar datos de herramientas fuera de la aplicación. Estas herramientas incluyen utilidades que identifican las actividades de examen de puertos por agencias externas y filtros de red que detectan intentos de obtener acceso no autenticado a la aplicación y a los datos. En algunos casos, las herramientas de implementación de integración continua y entrega continua (CI/CD) constituyen una parte importante del ciclo de vida de la aplicación. Estas herramientas también deben marcar un comportamiento anómalo.

Análisis de datos de seguridad

Una característica clave de la supervisión de seguridad es que recopila datos de muchos orígenes. Los diferentes formatos y niveles de detalle suelen requerir un análisis complejo para integrar los datos en un hilo coherente de información. Puede detectar inicios de sesión erróneos o intentos repetidos de obtener acceso no autorizado a los recursos, pero es posible que el procesamiento automatizado complejo de datos de seguridad no sea factible. En este escenario, debe registrar la marca temporal de los datos y almacenarlos en un repositorio seguro en su forma original para su análisis manual por parte de expertos.

Supervisión del Acuerdo de Nivel de Servicio

Los sistemas comerciales que admiten el pago de los clientes realizan compromisos sobre el rendimiento del sistema en forma de acuerdos de nivel de servicio. Los Acuerdos de Nivel de Servicio establecen que el sistema puede controlar un volumen definido de trabajo dentro de un período de tiempo acordado y sin perder información crítica. La supervisión del Acuerdo de Nivel de Servicio garantiza que el sistema cumpla los Acuerdos de Nivel de Servicio medibles.

Las métricas siguientes definen acuerdos de nivel de servicio:

• Disponibilidad general del sistema. Por ejemplo, una organización podría confirmar que el sistema está disponible 99.9% de la hora. Este porcentaje equivale a no más de nueve horas de tiempo de inactividad por año o aproximadamente 10 minutos por semana.

• Rendimiento operativo. Este aspecto suele expresarse como uno o varios valores máximos de referencia, por ejemplo, el compromiso de que el sistema puede admitir hasta 100 000 solicitudes simultáneas de usuarios o procesar 10 000 transacciones empresariales simultáneas.

• Tiempo de respuesta operativo. Es posible que el sistema también necesite procesar solicitudes a una velocidad definida. Por ejemplo, 99% de todas las transacciones empresariales deben finalizar en un plazo de 2 segundos y ninguna transacción tarda más de 10 segundos.

Requisitos para la supervisión del Acuerdo de Nivel de Servicio

Debe poder determinar rápidamente si el sistema cumple un Acuerdo de Nivel de Servicio. Si no cumple el Acuerdo de Nivel de Servicio, debe evaluar los factores subyacentes para encontrar la causa del rendimiento de subestándar.

Puede representar visualmente los siguientes indicadores de alto nivel:

• Porcentaje de tiempo de actividad del servicio

• Rendimiento de la aplicación, medido en términos de transacciones o operaciones correctas por segundo

• Número de solicitudes de la aplicación completadas con éxito o fallidas

• Número de errores, excepciones y advertencias de aplicación y sistema

Asegúrese de que puede filtrar todos estos indicadores por un período de tiempo especificado.

La aplicación en la nube probablemente comprende varios subsistemas y componentes. Debería poder seleccionar un indicador de alto nivel, como el tiempo de actividad general del sistema, y determinar qué elementos subyacentes afectan a su estado.

Con fines de alerta, el sistema debe generar un evento si alguno de los indicadores de alto nivel supera un umbral especificado. Haga que los detalles de nivel inferior estén disponibles para el sistema de alertas como datos contextuales.

Recopilación de datos del Acuerdo de Nivel de Servicio

Realice las siguientes acciones para capturar los datos sin procesar necesarios para la supervisión del Acuerdo de Nivel de Servicio:

• Realice la supervisión del punto de conexión.
• Registre excepciones, errores y advertencias.
• Seguimiento de la ejecución de solicitudes de usuario.
• Controle la disponibilidad de todos los servicios ajenos a Microsoft que use el sistema.
• Use métricas y contadores de rendimiento.

Todos los datos deben ser registrados y marcados con hora.

Análisis de datos del Acuerdo de Nivel de Servicio

Agregue los datos del Acuerdo de Nivel de Servicio para generar una imagen del rendimiento general del sistema. También debe poder explorar en profundidad los datos agregados para evaluar los subsistemas subyacentes. Por ejemplo, debería poder realizar las siguientes tareas:

• Calcule el número total de solicitudes de usuario durante un período especificado y determine la tasa de éxito y error de estas solicitudes.

• Combine los tiempos de respuesta de las solicitudes de usuario para generar una vista general de los tiempos de respuesta del sistema.

• Analice el progreso de las solicitudes de usuario para desglosar el tiempo de respuesta general en los tiempos de respuesta de los elementos de trabajo individuales de la solicitud.

• Determine la disponibilidad general del sistema como un porcentaje de tiempo de actividad durante un período específico.

• Analice el porcentaje de disponibilidad de tiempo de los componentes y servicios individuales del sistema. Es posible que tenga que analizar los registros que generan los servicios que no son de Microsoft.

Los sistemas comerciales deben notificar cifras reales de rendimiento en relación con los Acuerdos de Nivel de Servicio durante un período especificado. Puede usar esta información para calcular créditos u otras formas de reembolso para los clientes si no cumple los Acuerdos de Nivel de Servicio durante ese período. Puede calcular la disponibilidad de un servicio mediante la técnica descrita en Análisis de datos de disponibilidad.

Con fines internos, una organización también puede realizar un seguimiento del número y la naturaleza de los incidentes que provocan un error en los servicios. Obtenga información sobre cómo resolver estos problemas rápidamente o eliminarlos para que pueda reducir el tiempo de inactividad y cumplir los Acuerdos de Nivel de Servicio.

Auditoría

En función de la naturaleza de la aplicación, las regulaciones legales pueden especificar requisitos para auditar las operaciones de los usuarios y registrar todo el acceso a los datos. La auditoría puede proporcionar evidencias que vinculan a los clientes a solicitudes específicas. El no repudio es un factor importante en los sistemas de negocio electrónico para ayudar a mantener la confianza entre el cliente y la organización responsable de la aplicación o el servicio.

Requisitos para la auditoría

Debe poder realizar un seguimiento de la secuencia de operaciones empresariales que realizan los usuarios para poder reconstruir las acciones de los usuarios. Este registro puede ser necesario para fines de documentación o como parte de una investigación forense.

La información de auditoría es muy confidencial. Es probable que incluya datos que identifiquen a los usuarios del sistema y las tareas que realizan. Por este motivo, la información de auditoría es más probable que solo esté disponible para los analistas de confianza, en lugar de como parte de un sistema interactivo. El analista genera un rango de informes como los ejemplos siguientes:

• Informes que enumeran las actividades de todos los usuarios durante un período de tiempo especificado

• Informes que detallan la cronología de la actividad de un solo usuario

• Informes que enumeran la secuencia de operaciones realizadas en uno o varios recursos

Recopilación de datos de auditoría

Entre las fuentes principales de información para la auditoría se incluyen:

• Sistema de seguridad que administra la autenticación de usuario.
• Registros de seguimiento que registran la actividad del usuario.
• Registros de seguridad que realizan un seguimiento de todas las solicitudes de red identificables y no identificables.

Los requisitos normativos pueden determinar el formato de los datos de auditoría y cómo almacenarlos. Si las regulaciones requieren que registre los datos en su formato original, es posible que no pueda limpiar los datos. Como resultado, el acceso al repositorio que lo almacena debe estar estrechamente protegido para evitar alteraciones.

Análisis de datos de auditoría

Debe poder acceder a los datos sin procesar en su totalidad y en su forma original. Además del requisito de generar informes de auditoría comunes, es probable que las herramientas para analizar estos datos estén especializadas y se mantengan externas al sistema.

Supervisión del uso

La supervisión de uso realiza un seguimiento de cómo los clientes usan las características y componentes de una aplicación. Puede usar los datos para:

• Identificar características populares y puntos de acceso potenciales en el sistema. Los elementos de alto tráfico pueden beneficiarse de la creación de particiones funcionales o la replicación para distribuir la carga de forma más uniforme. También puede usar esta información para determinar qué características se usan con poca frecuencia y son posibles candidatos para la retirada o sustitución en una versión futura del sistema.

• Obtenga información sobre los eventos operativos del sistema en uso normal. Por ejemplo, en un sitio de comercio electrónico, puede registrar información estadística sobre el número de transacciones y el volumen de clientes responsables de ellas. Puede usar esta información para planear la capacidad a medida que crece el número de clientes.

• Detecte la satisfacción del usuario con el rendimiento y la funcionalidad del sistema. Por ejemplo, si muchos clientes de un sistema de comercio electrónico abandonan regularmente sus carritos de compra, podría haber un problema con la funcionalidad del proceso de compra.

• Generar información de facturación. Una aplicación comercial o un servicio multiinquilino pueden cobrar a los clientes los recursos que usan.

• Aplicar cuotas. Si un usuario de un sistema multiinquilino supera la cuota de pago del tiempo de procesamiento o el uso de recursos durante un período especificado, puede limitar su acceso o limitar el procesamiento.

• Detecte problemas ruidosos de vecinos. Para ayudar a impulsar las investigaciones de errores o las decisiones del producto, determine si el tráfico se propaga uniformemente o si un pequeño conjunto de usuarios genera la mayor parte del tráfico. Si un solo usuario genera tráfico significativo, es posible que la característica necesite ajustar el rendimiento. Como alternativa, puede decidir imponer cuotas adicionales para reducir el tráfico.

Requisitos para la supervisión del uso

Para evaluar el uso del sistema, normalmente necesita la siguiente información:

• Número de solicitudes que cada subsistema procesa y dirige a cada recurso.

• El trabajo que realiza cada usuario

• El volumen de almacenamiento de datos que ocupa cada usuario

• Los recursos a los que accede cada usuario

También debe poder generar gráficos. Entre los ejemplos comunes se incluyen gráficos de usuarios que consumen la mayoría de los recursos y los recursos o características del sistema a los que se accede con más frecuencia.

Recopilar los datos de uso

Puede realizar un seguimiento de uso de alto nivel si observa las horas de inicio y finalización de cada solicitud y la naturaleza de cada solicitud, como lectura o escritura. Para capturar esta información, realice las siguientes tareas:

• Seguimiento de la actividad del usuario.
• Capture los contadores de rendimiento que miden el uso de cada recurso.
• Supervise el consumo de recursos de cada usuario.

Para fines de medición, también debe identificar qué usuarios realizan las operaciones y los recursos que usan estas operaciones. Asegúrese de que la información recopilada es lo suficientemente detallada como para admitir la facturación precisa.

Seguimiento de problemas

Los clientes y otros usuarios pueden notificar problemas si se producen eventos o comportamientos inesperados en el sistema. El seguimiento de problemas administra estos problemas, asocia problemas con los esfuerzos para corregirlos e informa a los clientes de las resoluciones.

Requisitos para el seguimiento de problemas

Para realizar un seguimiento de los problemas, use un sistema independiente que le permita registrar e informar de los detalles de los problemas que los usuarios notifican. Estos detalles incluyen las tareas intentadas, los síntomas del problema, la secuencia de eventos y los mensajes de error o advertencia.

Recopilación de datos de seguimiento de problemas

El origen de datos inicial para los datos de seguimiento de problemas es el usuario que notifica el problema. Este usuario puede proporcionar los detalles siguientes:

• Un volcado de memoria, si la aplicación incluye un componente que se ejecuta en el escritorio del usuario

• Una instantánea de pantalla

• Fecha y hora en que se produjo el error y otra información del entorno, como la ubicación del usuario

Utilice esta información para depurar el sistema y crear una lista de tareas pendientes para futuras versiones del software.

Análisis de datos de seguimiento de problemas

Los distintos usuarios pueden notificar el mismo problema y el sistema de seguimiento de problemas debe asociar informes comunes.

Registrar el progreso de la depuración para cada informe. Al resolver el problema, informe al cliente de la solución.

Si un usuario informa de un problema que tiene una solución conocida en el sistema de seguimiento de problemas, puede informar al usuario de la solución inmediatamente.

Seguimiento de las operaciones y depuración de las versiones de software

Cuando un usuario notifica un problema, normalmente solo es consciente del efecto inmediato que tiene en sus operaciones. El usuario solo puede notificar los resultados de su propia experiencia. Estas experiencias suelen ser un síntoma visible de uno o más problemas fundamentales. En muchos casos, un analista debe analizar la cronología de las operaciones subyacentes para establecer la causa principal del problema. Este proceso se denomina análisis de causa principal (RCA).

Requisitos para el seguimiento y la depuración

Para realizar un seguimiento de eventos inesperados y otros problemas, los datos de supervisión deben proporcionar suficiente información para permitir a un analista encontrar el origen del problema y reconstruir la secuencia de eventos. A continuación, un desarrollador puede realizar modificaciones para evitar que el problema se repita.

Recopilación de datos de seguimiento y depuración

Para solucionar problemas, siga todos los métodos y sus parámetros invocados como parte de una operación. A continuación, cree un árbol que muestre el flujo lógico a través del sistema cuando un cliente realiza una solicitud específica. Captura y registra excepciones y advertencias que el sistema genera como resultado de este flujo.

Para facilitar la depuración, el sistema ofrece puntos de enganche que se pueden utilizar para capturar información de estado en puntos cruciales del sistema. O bien, el sistema puede proporcionar información detallada paso a paso a medida que progresan las operaciones seleccionadas. La captura de datos en este nivel de detalle puede aumentar la carga en el sistema y debe ser un proceso temporal. Use este proceso cuando se produzcan eventos inusuales y difíciles de replicar o cuando una nueva versión requiera una supervisión cuidadosa para asegurarse de que los elementos funcionan según lo previsto.

Tubería de monitorización y diagnóstico

La supervisión de un sistema distribuido a gran escala plantea un desafío importante. No debe considerar necesariamente cada uno de los escenarios descritos en las secciones anteriores de forma aislada. Los datos de supervisión y diagnóstico necesarios para cada situación se superponen, pero es posible que tenga que procesar y presentar estos datos de maneras diferentes. Por estas razones, tome una visión holística de la supervisión y el diagnóstico.

Puede imaginar todo el proceso de supervisión y diagnóstico como una canalización que comprende las fases que se muestran en el diagrama siguiente.

En el diagrama se muestra cómo proceden los datos de supervisión y diagnóstico de varios orígenes. Las fases de instrumentación y recopilación le ayudan a identificar los datos que necesita capturar, dónde y cómo capturarlos y cómo dar formato a los datos para poder analizarlos fácilmente. La fase de análisis y diagnóstico toma los datos sin procesar y los usa para generar información significativa que puede usar para determinar el estado del sistema. Puede usar esta información para determinar qué posibles acciones realizar y, a continuación, devolver los resultados a las fases de instrumentación y recopilación. La fase de visualización y alerta presenta una visualización clara del estado del sistema. Puede mostrar información casi en tiempo real mediante una serie de paneles. Puede generar informes, gráficos y gráficos para proporcionar una vista histórica de los datos que pueden ayudarle a identificar tendencias a largo plazo. Si la información indica que es probable que un KPI supere los límites aceptables, esta fase también puede desencadenar una alerta. En algunos casos, una alerta también puede desencadenar un proceso automatizado que intente realizar acciones correctivas, como el escalado automático.

Estos pasos forman un proceso de flujo continuo en el que las fases se ejecutan en paralelo. Lo ideal es que todas las fases se puedan configurar dinámicamente. En algunos puntos, especialmente cuando un sistema se implementa recientemente o está experimentando problemas, es posible que tenga que recopilar datos extendidos con más frecuencia. En otras ocasiones, puede seguir capturando información esencial de alto nivel para comprobar que el sistema funciona correctamente.

Trate todo el proceso de supervisión como una solución activa y continua que necesita ajuste y mejoras en función de los comentarios. Por ejemplo, puede empezar midiendo muchos factores para determinar el estado del sistema y refinar el análisis con el tiempo para descartar las medidas que no son pertinentes.

Orígenes de datos de supervisión y diagnóstico

La información que usa el proceso de supervisión puede provenir de varios orígenes. En el nivel de aplicación, la información procede de los registros de seguimiento que se incorporan al código del sistema. Los desarrolladores deben seguir un enfoque estándar para realizar un seguimiento del flujo de control a través de su código. Por ejemplo, una entrada a un método puede emitir un mensaje de seguimiento que especifica el nombre del método, la hora actual, el valor de cada parámetro y otra información pertinente. También puede que desee registrar las horas de entrada y salida.

Registra todas las excepciones y advertencias, y asegúrate de conservar un rastro completo de cualquier excepción o advertencia anidada. Capture información que identifica al usuario que ejecuta el código y la información de correlación de actividad para realizar un seguimiento de las solicitudes a medida que pasan por el sistema. Registrar los intentos de acceso a todos los recursos, como colas de mensajes, bases de datos, archivos y otros servicios dependientes. Puede usar esta información con fines de medición y auditoría.

Muchas aplicaciones usan bibliotecas y marcos para realizar tareas comunes, como acceder a un almacén de datos o comunicarse a través de una red. Es posible que pueda configurar estos marcos para proporcionar sus propios mensajes de seguimiento e información de diagnóstico sin procesar, como tasas de transacción y errores de transmisión de datos.

El sistema operativo en el que se ejecuta la aplicación puede ser un origen de información de bajo nivel y de todo el sistema, como contadores de rendimiento que indican tasas de E/S, uso de memoria y uso de CPU. También puede notificar errores del sistema operativo, como el error al abrir un archivo correctamente.

Tenga en cuenta también la infraestructura y los componentes subyacentes en los que se ejecuta el sistema. Las máquinas virtuales (VM), las redes virtuales y los servicios de almacenamiento pueden ser orígenes de contadores de rendimiento importantes de nivel de infraestructura y otros datos de diagnóstico.

Si la aplicación usa otros servicios externos, como un servidor web o un sistema de administración de bases de datos (DBMS), estos servicios pueden publicar su propia información de seguimiento, registros y contadores de rendimiento. Por ejemplo, las vistas de administración dinámica (DMV) de SQL Server realizan un seguimiento de las operaciones realizadas en una base de datos de SQL Server. Application Insights realiza un seguimiento de los registros de las solicitudes de grabación realizadas a Azure App Service.

A medida que modifique los componentes del sistema e implemente nuevas versiones, es importante que pueda atribuir problemas, eventos y métricas a cada versión. Asocie esta información con la canalización de publicación para que pueda hacer un seguimiento y corregir rápidamente los problemas de una versión específica de un componente.

Use las estrategias siguientes para recopilar datos de supervisión y diagnóstico:

• La supervisión de aplicaciones y sistemas usa orígenes internos dentro de la aplicación, los marcos de aplicación, el sistema operativo y la infraestructura. El código de aplicación puede generar sus propios datos de supervisión en puntos importantes durante el ciclo de vida de una solicitud de cliente. La aplicación puede incluir instrucciones de seguimiento que puede activar y desactivar según sea necesario. También puede insertar diagnósticos dinámicamente mediante un marco de diagnóstico. Normalmente, estos marcos proporcionan complementos que se conectan a varios puntos de instrumentación en el código y capturan datos de seguimiento en estos puntos.

  El código o la infraestructura subyacente también pueden generar eventos en puntos críticos. Los agentes de supervisión configurados para escuchar estos eventos pueden registrar la información del evento.

• La supervisión del usuario real registra las interacciones entre un usuario y la aplicación y observa el flujo de cada solicitud y respuesta. Use esta información para medir el uso de cada usuario y determinar si los usuarios reciben una QoS adecuada, incluidos tiempos de respuesta rápidos, latencia baja y errores mínimos. Puede usar los datos para identificar las áreas en las que se producen errores con más frecuencia. También puede utilizar los datos para identificar las áreas donde el sistema se ralentiza debido a puntos críticos en la aplicación u otros cuellos de botella. Si implementa este enfoque cuidadosamente, es posible que pueda reconstruir los flujos de los usuarios a través de la aplicación con fines de depuración y pruebas.

  Importante

  Trate los datos capturados por la supervisión real del usuario como altamente confidencial, ya que podría incluir material confidencial. Si guarda los datos capturados, almacénelo de forma segura. Si desea usar los datos con fines de supervisión o depuración de rendimiento, quite primero todos los datos personales.

• La supervisión de usuarios sintéticos requiere que escriba su propio cliente de prueba que simula a un usuario y realiza una serie de operaciones configurables pero típicas. Puede realizar un seguimiento del rendimiento del cliente de prueba para ayudar a determinar el estado del sistema. También puede usar varias instancias del cliente de prueba como parte de una operación de prueba de carga para establecer cómo responde el sistema bajo estrés y la salida de supervisión que generan estas condiciones.

  Note

  Puede implementar la supervisión de usuarios reales y sintéticos mediante la inclusión de código que realiza seguimientos y tiempos de ejecución de llamadas de método y otras partes críticas de una aplicación.

• La generación de perfiles le ayuda a supervisar y mejorar el rendimiento de las aplicaciones. A diferencia de la supervisión del usuario real y la supervisión de usuarios sintéticas, que funcionan en el nivel funcional, la generación de perfiles captura información de nivel inferior a medida que se ejecuta la aplicación. Implemente la generación de perfiles mediante el muestreo periódico del estado de ejecución de una aplicación o determine qué fragmento de código se ejecuta en un momento específico. También puede usar instrumentación para insertar sondas en el código en puntos clave, como al principio y al final de una llamada a un método. Los sondeos registran qué métodos invoca la llamada, en qué momento y cuánto tarda cada llamada. A continuación, puede analizar estos datos para determinar qué partes de la aplicación pueden causar problemas de rendimiento.

• La supervisión de puntos de conexión utiliza uno o varios puntos de conexión de diagnóstico que la aplicación expone específicamente para permitir la supervisión. Un punto de conexión proporciona un camino al código de la aplicación y puede devolver información sobre el estado del sistema. Los distintos puntos de conexión pueden centrarse en varios aspectos de la funcionalidad. Puede escribir su propio cliente de diagnóstico que envíe solicitudes periódicas a estos puntos de conexión y asimila las respuestas. Para obtener más información, consulte el patrón de monitorización de puntos de conexión de salud.

• Los volcados de errores de usuario dependen de que la aplicación proporcione una forma de recopilar una instantánea del estado de la aplicación si esta no puede recuperarse. Los usuarios también deben compartir voluntariamente esa instantánea. No se puede garantizar que se ejecute un volcado de error, pero se pueden utilizar los datos de bajo nivel que proporciona para determinar la causa raíz de los errores. Este escenario es común si los errores se producen con poca frecuencia o si solo se producen errores en una característica de aplicación usada con poca frecuencia.

Para obtener la cobertura máxima, debe usar una combinación de estas técnicas.

Instrumentación de una aplicación

La instrumentación es una parte fundamental del proceso de supervisión. Debe capturar datos que le ayuden a tomar decisiones significativas sobre el rendimiento y el estado del sistema. Use la instrumentación para recopilar información suficiente para evaluar el rendimiento, diagnosticar problemas y tomar decisiones sin iniciar sesión en un servidor de producción remoto para realizar un seguimiento y depurar manualmente. Los datos de instrumentación suelen incluir métricas e información escrita en los registros de seguimiento.

Un registro de seguimiento puede contener datos textuales que la aplicación escribe o datos binarios que crea un evento de seguimiento, si la aplicación usa seguimiento de eventos para Windows (ETW). Los registros del sistema que registran eventos que se producen desde partes de la infraestructura, como un servidor web, también pueden generar contenido de registro de seguimiento. Los mensajes de registro de texto suelen ser legibles por el usuario, pero los escriben en un formato que un sistema automatizado también puede analizar fácilmente.

Clasificar también los registros. No escriba todos los datos de seguimiento en un único registro. Utilice registros independientes para registrar la salida de rastreo de distintos aspectos operativos del sistema. A continuación, puede filtrar rápidamente los mensajes de registro leyendo desde el registro adecuado en lugar de procesar un único archivo largo. Nunca escriba información que tenga requisitos de seguridad diferentes, como la información de auditoría y los datos de depuración, en el mismo registro.

Por lo general, las métricas son una medida o recuento de algún aspecto o recurso del sistema en un momento específico, con una o varias etiquetas o dimensiones asociadas, también denominada ejemplo. Una sola instancia de una métrica no es útil de forma aislada. En su lugar, capture las métricas a lo largo del tiempo. Tenga en cuenta qué métricas se van a registrar y con qué frecuencia. La generación de datos para métricas con demasiada frecuencia puede poner demasiada carga en el sistema. Pero no capturar suficientes datos puede provocar que se pierdan las circunstancias que conducen a un evento significativo. Las consideraciones varían de métrica a métrica. Por ejemplo, el uso de CPU en un servidor puede fluctuar de segundo a segundo, pero el uso elevado se convierte en un problema solo si persiste durante varios minutos.

Información para correlacionar datos

Puede supervisar fácilmente los contadores de rendimiento de nivel de sistema individuales, capturar métricas de recursos y obtener información de seguimiento de aplicaciones de varios archivos de registro. Sin embargo, algunas formas de supervisión requieren la fase de análisis y diagnóstico de la canalización de supervisión para correlacionar los datos recuperados de varios orígenes. Estos datos sin procesar pueden adoptar varias formas, y el proceso de análisis debe contar con datos de instrumentación suficientes para correlacionar estas diferentes formas. Por ejemplo, en el nivel del marco de trabajo de la aplicación, un identificador de subproceso podría identificar una tarea. Dentro de una aplicación, el mismo trabajo podría estar asociado al identificador de usuario para el usuario que realiza esa tarea.

Es probable que una asignación uno a uno no exista entre subprocesos y solicitudes de usuario porque las operaciones asincrónicas pueden reutilizar los mismos subprocesos para realizar operaciones para más de un usuario. Más de un subproceso también puede controlar una sola solicitud a medida que la ejecución fluye a través del sistema. Si es posible, asocie cada solicitud con un identificador de actividad único propagado a través del sistema como parte del contexto de solicitud. La técnica para generar e incluir identificadores de actividad en la información de seguimiento depende de la tecnología que use para capturar los datos de seguimiento.

Aplique la misma marca temporal a todos los datos de monitorización. Para la coherencia, registre todas las fechas y horas mediante UTC. Este método le ayuda a realizar un seguimiento de secuencias de eventos más fácilmente.

Información que se va a incluir en los datos de instrumentación

Tenga en cuenta los siguientes puntos cuando decida qué datos de instrumentación recopilar:

• Asegúrese de que la información capturada por eventos de seguimiento sea legible por máquina y legible por el usuario. Adopte esquemas bien definidos para esta información para facilitar el procesamiento automatizado de datos de registro entre sistemas y proporcionar coherencia al personal de operaciones e ingeniería que leen los registros. Incluya información del entorno, como el entorno de implementación, la máquina en la que se ejecuta el proceso, los detalles del proceso y la pila de llamadas.

• Habilite la generación de perfiles solo cuando sea necesario porque puede agregar una sobrecarga significativa al sistema. La generación de perfiles mediante el uso de registros de instrumentación registra un evento, como una llamada de método, cada vez que se produce, mientras que el muestreo solo registra los eventos seleccionados. La selección puede basarse en el tiempo, una vez cada n segundos o basada en frecuencia, una vez cada n solicitudes. Si los eventos se producen con frecuencia, la generación de perfiles por instrumentación puede provocar demasiada carga y afectar al rendimiento general. En este caso, es preferible el enfoque de muestreo. Sin embargo, si la frecuencia de los eventos es baja, el muestreo podría no detectarlos. En este caso, la instrumentación podría ser el mejor enfoque.

• Proporcione suficiente contexto para que un desarrollador o administrador pueda determinar el origen de cada solicitud. Este contexto puede incluir un identificador de actividad que identifica una instancia específica de una solicitud o información que correlaciona una actividad con el trabajo computacional realizado y los recursos usados. Este trabajo puede cruzar los límites del proceso y de la máquina. Para la medición, el contexto también debe incluir, directa o indirectamente a través de otra información correlacionada, una referencia al cliente que genera la solicitud. Este contexto proporciona información valiosa sobre el estado de la aplicación al capturar datos de supervisión.

• Registre todas las solicitudes y las ubicaciones o regiones desde las que se realizan estas solicitudes. Esta información puede ayudarle a determinar si existen puntos de acceso específicos de la ubicación. También puede ayudarle a determinar si desea volver a particionar una aplicación o los datos que usa.

• Registre y capture cuidadosamente los detalles de las excepciones. A menudo, la información crítica de depuración se pierde como resultado de un manejo deficiente de excepciones. Capture los detalles completos de las excepciones que produce la aplicación, incluidas las excepciones internas y otra información de contexto. Incluya la pila de llamadas si es posible.

• Sea coherente en los datos que capturan los distintos elementos de la aplicación. La coherencia puede ayudarle a analizar eventos y correlacionarlos con las solicitudes de usuario. Considere la posibilidad de usar un paquete de registro completo y configurable para recopilar información, en lugar de depender de los desarrolladores para adoptar el mismo enfoque que implementan diferentes partes del sistema. Recopile datos de contadores de rendimiento clave, como el volumen de E/S, el uso de red, el número de solicitudes, el uso de memoria y el uso de CPU. Algunos servicios de infraestructura pueden proporcionar sus propios contadores de rendimiento, como el número de conexiones a una base de datos, la velocidad a la que el sistema realiza transacciones y el número de transacciones que se realizan correctamente o no. Las aplicaciones también pueden definir sus propios contadores de rendimiento específicos.

• Registre todas las llamadas realizadas a servicios externos, como sistemas de base de datos, servicios web u otros servicios de nivel de sistema que forman parte de la infraestructura. Registre información sobre el tiempo necesario para realizar cada llamada y si la llamada se realiza correctamente o no. Si es posible, captura información sobre todos los intentos de reintento y fallos para cualquier error transitorio que se produzca.

Garantizar la compatibilidad con los sistemas de telemetría

En muchos casos, la información que genera la instrumentación se genera como una serie de eventos y se pasa a un sistema de telemetría independiente para el procesamiento y el análisis. Un sistema de telemetría suele ser independiente de determinadas aplicaciones o tecnologías, pero espera que la información siga un formato específico definido por un esquema. El esquema especifica un contrato que define los campos de datos y los tipos que el sistema de telemetría puede ingerir. Generalice el esquema para permitir datos de una variedad de plataformas y dispositivos. Un ejemplo de un marco y un esquema ampliamente usados es OpenTelemetry.

Un esquema común debe incluir campos que todos los eventos de instrumentación tienen en común, como el nombre del evento, la hora del evento, la dirección IP del remitente. También debe incluir los detalles necesarios para correlacionar con otros eventos, como un identificador de usuario, un identificador de dispositivo y un identificador de aplicación. Recuerde que cualquier número de dispositivos podría generar eventos, por lo que el esquema no debe depender del tipo de dispositivo. Además, varios dispositivos pueden generar eventos para la misma aplicación y la aplicación podría admitir la itinerancia o alguna otra forma de distribución entre dispositivos.

El esquema también puede incluir campos de dominio que son relevantes para un escenario determinado que es común en diferentes aplicaciones. Estos escenarios incluyen información sobre excepciones, eventos de inicio y finalización de la aplicación y éxito o error de llamadas API de servicio web. Todas las aplicaciones que usan el mismo conjunto de campos de dominio deben emitir el mismo conjunto de eventos para crear un conjunto de informes y análisis comunes.

Por último, un esquema puede contener campos personalizados para capturar los detalles de eventos específicos de la aplicación.

Procedimientos recomendados para instrumentar aplicaciones

En la lista siguiente se resumen los procedimientos recomendados para instrumentar una aplicación distribuida que se ejecuta en la nube:

• Facilitar la lectura y el análisis de los registros. Use el registro estructurado siempre que sea posible. Sea conciso y descriptivo en los mensajes de registro.

• En todos los registros, identifique el origen y proporcione información de contexto y tiempo a medida que se escribe cada registro de registro.

• Use la misma zona horaria y formato para todas las marcas de tiempo. Esta práctica ayuda a correlacionar eventos para las operaciones que abarcan hardware y servicios que se ejecutan en diferentes regiones geográficas.

• Clasifique los registros y escriba mensajes en el archivo de registro adecuado.

• No revele información confidencial sobre el sistema ni la información personal sobre los usuarios. Limgue esta información antes de registrarla, pero asegúrese de conservar los detalles pertinentes. Por ejemplo, quite el identificador y la contraseña de las cadenas de conexión de base de datos. Escriba la información restante en el registro para que pueda determinar si el sistema accede a la base de datos correcta. Registre todas las excepciones críticas, pero permita al administrador activar y desactivar el registro para niveles inferiores de excepciones y advertencias. Además, capture y registre toda la información de la lógica de reintento. Puede usar estos datos para supervisar el estado transitorio del sistema.

• Realice un seguimiento de las llamadas fuera de proceso, como las solicitudes a servicios web externos o bases de datos.

• No combine mensajes de registro con requisitos de seguridad diferentes en el mismo archivo de registro. Por ejemplo, no escriba información de depuración y auditoría en el mismo registro.

• Inicie llamadas de registro que sigan funcionando de forma autónoma. Estos tipos de operaciones no bloquean el progreso de las operaciones empresariales. Los eventos de auditoría son una excepción porque son críticos para la empresa. Clasifiquelas como parte fundamental de las operaciones empresariales.

• Asegúrese de que el registro sea extensible y no tenga dependencias directas de un destino específico. Por ejemplo, en lugar de escribir información mediante System.Diagnostics.Trace, defina una interfaz abstracta, como ILogger, que exponga métodos de registro y que pueda implementar a través de cualquier medio adecuado.

• Asegúrese de que todo el registro sea a prueba de fallos y no desencadene nunca fallos en cascada. El registro no debe generar ninguna excepción.

• Trate la instrumentación como un proceso iterativo en curso y revise los registros con regularidad, no solo cuando se produce un problema.

Recopilación y almacenamiento de datos

La fase de recopilación recupera la información que genera la instrumentación, da formato a estos datos para facilitar el consumo durante la fase de análisis y diagnóstico y guarda los datos transformados en un almacenamiento confiable. Puede almacenar los datos de instrumentación que recopila de diferentes partes de un sistema distribuido en varias ubicaciones y formatos. Por ejemplo, el código de la aplicación podría generar archivos de registro de seguimiento y datos del registro de eventos de la aplicación. Otras tecnologías pueden capturar contadores de rendimiento que supervisan aspectos clave de la infraestructura que usa la aplicación. Los componentes y servicios que no sean de Microsoft que use la aplicación pueden proporcionar información de instrumentación en distintos formatos mediante archivos de seguimiento independientes, almacenamiento de blobs o incluso un almacén de datos personalizado.

Un servicio de recopilación que se ejecuta de forma autónoma desde la aplicación que genera los datos de instrumentación normalmente recopila los datos. En el diagrama siguiente se muestra un ejemplo de esta arquitectura y se resalta el subsistema de recopilación de datos de instrumentación.

En este diagrama se muestra una vista simplificada de la recopilación de datos. Normalmente, el servicio de recopilación consta de muchas partes que se ejecutan en máquinas diferentes. Si necesita analizar rápidamente los datos de telemetría, use los componentes locales que funcionan fuera del servicio de recopilación. Después del procesamiento analítico, los componentes envían los resultados directamente al subsistema de visualización y alertas. Los datos sujetos al análisis en frío o en caliente se mantienen en el almacenamiento mientras espera el procesamiento. Para obtener más información, consulte Compatibilidad con análisis caliente, templado y frío.

Para Azure aplicaciones y servicios que se ejecutan en máquinas virtuales, el agente de Azure Monitor proporciona una solución para capturar datos. Define las reglas de recopilación de datos (DCR) que especifican los datos que se deben recopilar de cada nodo de proceso y el área de trabajo de Log Analytics de Azure Monitor a la que se deben enviar. El agente puede recopilar datos de los orígenes siguientes:

• Registros de Internet Information Services (IIS)
• Registros de eventos de Windows
• Contadores de rendimiento
• Syslog desde nodos de Linux
• Registros de texto y JSON que las aplicaciones escriben

Estrategias para recopilar datos de instrumentación

Debido a la naturaleza elástica de la nube y para evitar recuperar manualmente los datos de telemetría de todos los nodos del sistema, organice para consolidar los datos y transferirlos a una ubicación central. En un sistema que abarque varios centros de datos, es posible que desee recopilar, consolidar y almacenar datos en una base regional por región y, a continuación, agregar los datos regionales en un único sistema central.

Para optimizar el uso del ancho de banda, puede transferir datos menos urgentes como lotes. No retrase la transferencia indefinidamente, especialmente si los datos contienen información confidencial.

Recopilación de datos de instrumentación mediante pull y push

El subsistema de recopilación de datos de instrumentación puede recuperar activamente los datos de instrumentación de los distintos registros y otros orígenes para cada instancia de la aplicación. Este método se denomina modelo de extracción. O bien, puede actuar como receptor pasivo que espera a que los componentes que constituyen cada instancia de la aplicación envíen los datos. Este método se denomina modelo push.

Un enfoque para el modelo de extracción es usar agentes de supervisión que se ejecutan localmente con cada instancia de la aplicación. Un agente de supervisión es un proceso independiente que recupera periódicamente los datos de telemetría recopilados en el nodo local y escribe esta información en un almacenamiento centralizado que comparten todas las instancias de la aplicación. El agente de Azure Monitor implementa este mecanismo. Configura los datos que se recopilan de cada instancia de proceso mediante una regla de recopilación de datos. El agente de supervisión que se ejecuta junto con cada instancia recopila los datos especificados, como los registros de IIS, los registros de eventos Windows y los contadores de rendimiento, y los envía a un área de trabajo de Log Analytics en Azure Monitor, donde puede consultarlo y analizarlo. En el diagrama siguiente se muestra un ejemplo de esta arquitectura.

Puede usar los modelos de extracción e inserción para almacenar datos de telemetría para una aplicación a pequeña escala que se ejecuta en un número limitado de nodos en una sola ubicación. Una aplicación en la nube global compleja y altamente escalable podría generar grandes volúmenes de datos a partir de cientos de instancias de proceso, particiones de base de datos y otros servicios. Esta inundación de datos puede sobrecargar fácilmente el ancho de banda de E/S disponible con una sola ubicación central. Por lo tanto, debe poder escalar su solución de telemetría para evitar cuellos de botella a medida que el sistema se expande. 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.

Para solucionar estos problemas, implemente la puesta en cola. En el siguiente ejemplo de arquitectura, el agente local de monitorización o el servicio personalizado de recopilación de datos envía datos a una cola. El servicio de escritura en almacenamiento, un proceso asíncrono independiente, toma los datos de esta cola y los escribe en el almacenamiento compartido. Una cola de mensajes es adecuada para este escenario porque proporciona la semántica al menos una vez, que ayuda a garantizar que los datos en cola no se pierdan una vez enviados. Puedes implementar el servicio de escritura en almacenamiento utilizando un proceso en segundo plano independiente.

El servicio de recopilación de datos local puede agregar datos a una cola inmediatamente después de recibirlos. La cola actúa como un búfer, y el servicio de escritura en almacenamiento puede recuperar y escribir los datos a su propio ritmo. De forma predeterminada, una cola funciona en base a "primero en entrar, primero en salir". Pero puede priorizar los mensajes para acelerarlos a través de la cola si contienen datos que debe controlar rápidamente. Para obtener más información, consulte el patrón de cola de prioridad. Como alternativa, puede utilizar diferentes canales, como temas de Service Bus, para dirigir los datos a distintos destinos según el tipo de procesamiento analítico necesario.

Para obtener escalabilidad, puede ejecutar varias instancias del servicio de escritura de almacenamiento. En el caso de grandes volúmenes de eventos, puede usar un centro de eventos para enviar los datos a distintos recursos de proceso para el procesamiento y el almacenamiento.

Consolidar los datos de instrumentación

Los datos de instrumentación que el servicio de recopilación de datos recupera de una sola instancia de una aplicación proporcionan una vista localizada del estado y el rendimiento de esa instancia. Para evaluar el estado general del sistema, consolida los aspectos de los datos en las vistas locales. Puede realizar este paso después de almacenar los datos, pero en algunos casos también puede hacerlo a medida que se recopilan los datos. En lugar de escribir directamente en el almacenamiento compartido, los datos de instrumentación pasan a través de un servicio independiente que consolida, filtra y limpia los datos. Por ejemplo, los datos de instrumentación que incluyen la misma información de correlación, como un identificador de actividad, se pueden agrupar. 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 nodo o debido al equilibrio de carga. Este proceso también puede detectar y quitar datos duplicados, lo que es posible si el servicio de telemetría usa colas de mensajes para insertar datos de instrumentación en el almacenamiento. En el diagrama siguiente se muestra un ejemplo de esta estructura.

Almacenar datos de instrumentación

En las secciones anteriores se muestra una vista simplificada de cómo almacenar datos de instrumentación. En la práctica, debe almacenar diferentes tipos de información mediante el uso de las tecnologías que se adapten a cómo planea usarla.

Por ejemplo, Azure Blob Storage y Azure Table Storage tienen patrones de acceso similares, pero las operaciones que pueden realizar son limitadas y la granularidad de los datos que almacenan varía. Si necesita realizar operaciones analíticas o requerir funcionalidades de búsqueda de texto completo, es posible que tenga que usar el almacenamiento de datos que proporciona las siguientes funcionalidades de consulta y acceso a datos:

• Almacene los datos del contador de rendimiento en una base de datos SQL para habilitar el análisis no planeado.
• Almacene los registros de seguimiento en Azure Cosmos DB.
• Escriba información de seguridad en el sistema de archivos distribuido de Hadoop (HDFS).
• Almacene información que requiera búsqueda de texto completo mediante Elasticsearch, que usa la indexación enriquecida para acelerar las búsquedas.

En el diagrama siguiente se muestra cómo puede implementar un servicio adicional que recupera periódicamente los datos del almacenamiento compartido, las particiones y filtra los datos según su propósito y, a continuación, lo escribe en un conjunto adecuado de almacenes de datos. Un enfoque alternativo consiste en incluir esta funcionalidad en el proceso de consolidación y limpieza y escribir los datos directamente en estos almacenes a medida que se recuperan, en lugar de guardarlos en un área de almacenamiento compartida intermedia. Cada enfoque tiene ventajas y desventajas. La implementación de un servicio de creación de particiones independiente reduce la carga en el servicio de consolidación y limpieza. También le permite volver a generar al menos parte de los datos particionados, si es necesario, según la cantidad de datos que conserve el almacenamiento compartido. Sin embargo, este enfoque consume más recursos. También puede retrasar la recepción de datos de instrumentación de cada instancia de aplicación y la conversión de estos datos en información accionable.

Es posible que necesite los mismos datos de instrumentación para más de un propósito. Por ejemplo, los contadores de rendimiento pueden proporcionar una vista histórica del rendimiento del sistema a lo largo del tiempo. Puede combinar esta información con otros datos de uso para generar información de facturación del cliente. En estos escenarios, envíe los mismos datos a más de un destino, como una base de datos de documentos que almacena información de facturación y un almacén multidimensional que controla análisis de rendimiento complejos.

Considere la urgencia de necesitar los datos. Los datos que proporcionan información para las alertas deben accederse rápidamente, por lo que debe almacenarlos en el almacenamiento rápido de datos y el índice o estructurarlos para optimizar las consultas del sistema de alertas. En algunos casos, es posible que el servicio de telemetría que recopile los datos de cada nodo necesite dar formato a los datos y guardarlos localmente para que una instancia local del sistema de alertas pueda notificarle rápidamente los problemas. Puede enviar los mismos datos al servicio de escritura de almacenamiento que los diagramas anteriores muestran y almacenarlos de forma centralizada si lo necesita para otros fines.

La información que se usa para el análisis más complejo, para los informes y para identificar tendencias históricas es menos urgente. Almacénelo de una manera que admita la minería de datos y las consultas no planeadas. Para obtener más información, consulte Compatibilidad con análisis caliente, templado y frío.

Rotación de registros y retención de datos

La instrumentación genera una gran cantidad de datos. En algunos casos, una vez procesados y transferidos los datos, se pueden eliminar los datos originales sin procesar de cada nodo. O bien, es posible que tenga que guardar la información sin procesar.

Los datos de rendimiento suelen tener una vida útil más larga para poder usarlo para identificar las tendencias de rendimiento y la capacidad del plan. Mantenga la vista consolidada de estos datos en línea durante un período finito para que pueda acceder a ellos rápidamente. Es posible que tenga que guardar los datos recopilados para la medición y la facturación indefinidamente. Además, los requisitos normativos pueden requerir que archive y guarde la información recopilada con fines de auditoría y seguridad. Cifre o proteja esta información confidencial para evitar alteraciones. Nunca registre las contraseñas de los usuarios u otra información personal. Elimine estos detalles de los datos antes de almacenarlos.

Submuestreo de datos

Almacene datos históricos para detectar tendencias a largo plazo. En lugar de guardar todos los datos antiguos, puede reducir los datos para reducir su resolución y ahorrar costos de almacenamiento. Por ejemplo, en lugar de guardar indicadores de rendimiento de minuto a minuto, puede consolidar los datos de más de un mes de antigüedad para formar un resumen por horas.

Procedimientos recomendados para recopilar y almacenar información de registro

En la lista siguiente se resumen los procedimientos recomendados para capturar y almacenar información de registro:

• El agente de supervisión o el servicio de recopilación de datos debe ejecutarse como un servicio fuera de proceso y ser sencillo de implementar.

• Toda la salida del agente de supervisión o del servicio de recopilación de datos debe ser un formato independiente del equipo, 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 archivos de registro de seguimiento de eventos (ETL) en Linux o ETW. Use un formato estándar para que el sistema pueda construir canalizaciones de procesamiento. Puede integrar fácilmente los componentes que leen, transforman y envían datos en el formato acordado.

• El proceso de supervisión y recopilación de datos debe ser seguro para errores y no debe desencadenar errores en cascada.

• Si un error transitorio envía información a un receptor de datos, el agente de supervisión o el servicio de recopilación de datos debe estar preparado para reordenar los datos de telemetría para que la información más reciente se envíe primero. El agente de supervisión o el servicio de recopilación de datos pueden optar por quitar los datos más antiguos o guardarlos localmente y transmitirlos más adelante para ponerse al día, a su propia discreción.

Análisis de datos y diagnóstico de problemas

Una parte importante de la supervisión y el diagnóstico es analizar los datos recopilados para obtener una imagen del estado general del sistema. Defina sus propios KPI y métricas de rendimiento y aprenda a estructurar los datos para satisfacer los requisitos de análisis. Comprenda cómo se correlacionan los datos capturados en diferentes métricas y archivos de registro porque esta información es clave para realizar un seguimiento de una secuencia de eventos y diagnosticar problemas.

Los datos de cada parte del sistema normalmente se capturan localmente, pero debe combinarlos con los datos generados en otros sitios que participan en el sistema. Correlacionar esta información cuidadosamente para asegurarse de que los datos se combinan con precisión. Por ejemplo, los datos de uso de una operación pueden abarcar los nodos siguientes:

• Un nodo que hospeda un sitio web al que un usuario se conecta
• Un nodo que ejecuta un servicio independiente al que se accede como parte de esta operación
• Un nodo que almacena el almacenamiento de datos

Debe vincular esta información para proporcionar una vista general del uso de recursos y procesamiento para la operación. El nodo que captura los datos puede preprocesarlos y filtrarlos, pero los nodos centrales suelen agregarlos y dar formato a los datos. Para más información, consulte Consolidar los datos de instrumentación.

Admite análisis en caliente, templado y en frío

Analizar y volver a formatear datos con fines de visualización, creación de informes y alertas puede ser un proceso complejo que consume su propio conjunto de recursos. Algunas formas de supervisión requieren que el análisis de datos inmediato sea eficaz, también conocido como análisis frecuente. Entre los ejemplos se incluyen el análisis de alertas y la supervisión de la seguridad. Para el análisis frecuente, haga que los datos estén disponibles y estructurados para un procesamiento eficaz. En algunos casos, es posible que tenga que mover el procesamiento de análisis a los nodos individuales que contienen los datos.

Otras formas de análisis son menos sensibles al tiempo y pueden requerir cálculos y agregaciones después de recibir los datos sin procesar. Este método se denomina análisis en caliente. El análisis de rendimiento suele estar en esta categoría. En este caso, un pico o un error repentinos pueden provocar un evento de rendimiento único aislado que no es estadísticamente significativo. Los datos de una serie de eventos proporcionan una imagen más confiable del rendimiento del sistema.

También puede usar análisis térmico para ayudar a diagnosticar problemas de salud. Utiliza el análisis en tiempo real para procesar un evento de estado y generar una alerta de inmediato. A continuación, utilice el análisis en caliente para analizar los datos y determinar la causa del incidente de estado.

Algunos tipos de supervisión generan datos a largo plazo. Puede realizar este análisis en una fecha posterior, posiblemente según una programación predefinida. En algunos casos, el análisis podría necesitar filtrar grandes volúmenes de datos capturados a lo largo del tiempo. Este método se denomina análisis en frío. El requisito clave es almacenar los datos de forma segura después de capturarlos. Por ejemplo, la supervisión y la auditoría de uso requieren una imagen precisa del estado del sistema a intervalos regulares, pero esta información de estado no tiene que estar disponible inmediatamente para su procesamiento.

También puede utilizar el análisis en frío para proporcionar los datos necesarios para el análisis predictivo del estado. Recopila información histórica durante un período especificado y combínala con los datos de estado actuales para identificar tendencias que podrían causar problemas. En estos casos, es posible que tenga que generar una alerta para corregir la tendencia.

Correlacionar datos

Los datos que captura la instrumentación pueden proporcionar una instantánea del estado del sistema, pero el propósito del análisis es hacer que estos datos sean accionables. Por ejemplo, puede determinar la causa de una carga intensa de E/S en el nivel del sistema en un momento específico y asegurarse de que los tiempos de respuesta de la base de datos, el número de transacciones por segundo y los tiempos de respuesta de la aplicación al mismo momento confirmen los resultados.

Una manera de reducir la carga es particionar los datos en más servidores. Las excepciones pueden producirse debido a un error en cualquier nivel del sistema. Una excepción en un nivel suele desencadenar otro error en el nivel anterior.

Por estos motivos, debe correlacionar los distintos tipos de datos de supervisión en cada nivel para generar una vista general del estado del sistema y las aplicaciones que se ejecutan en él. Use esta información para decidir si el sistema funciona de forma aceptable y determinar lo que puede hacer para mejorar la calidad.

Asegúrese de que los datos de instrumentación sin procesar incluyen suficiente información de contexto e identificador de actividad para admitir las agregaciones necesarias para correlacionar eventos. Estos datos se pueden mantener en diferentes formatos, por lo que es posible que tenga que analizarlos y convertirlos en un formato estandarizado para el análisis. Para obtener más información, vea Información para correlacionar datos.

Solución y diagnóstico de problemas

Para diagnosticar problemas, necesita realizar un análisis de causa raíz (RCA) para determinar la causa de fallos o comportamientos inesperados. Normalmente, necesita la siguiente información para todo el sistema o para un subsistema específico durante un período de tiempo especificado:

• Información detallada de los registros de eventos y las trazas
• Trazas de pila completas de excepciones y fallos de cualquier nivel especificado.
• Volcados de memoria de cualquier proceso que haya fallado.
• Registros de actividad que registran las operaciones que realizan todos los usuarios o seleccionan los usuarios.

Para analizar los datos con fines de solución de problemas, necesita un profundo conocimiento técnico de la arquitectura del sistema y sus componentes. Debe interpretar los datos, establecer la causa de los problemas y recomendar una estrategia para corregirlos. Otra estrategia es almacenar una copia de esta información en su formato original y hacer que esté disponible para el análisis en frío por parte de un experto.

Visualizar datos y generar alertas

Los sistemas de supervisión deben presentar datos para que pueda identificar rápidamente tendencias o problemas. También deben notificarle inmediatamente cuando se produzca un evento que requiera atención.

La presentación de datos puede adoptar varias formas, incluida la visualización mediante paneles, alertas e informes.

Visualización mediante paneles

La manera más común de visualizar datos es usar paneles que muestran información como una serie de gráficos, gráficos u otras ilustraciones. Puede parametrizar estos elementos y seleccionar los parámetros importantes, como el período de tiempo, para una situación específica.

Puede organizar los paneles de forma jerárquica. Los paneles de nivel superior proporcionan una vista general de cada aspecto del sistema y le permiten explorar en profundidad los detalles. Por ejemplo, en un panel que muestra la E/S de disco general del sistema, puede ver las tasas de E/S de cada disco individual para determinar si uno o más dispositivos específicos tienen en cuenta un volumen de tráfico desproporcionada. El panel también debe mostrar información relacionada, como el usuario o la actividad que genera esta E/S. Esta información puede ayudarle a distribuir la carga de forma más uniforme entre los dispositivos.

Un panel también puede usar codificación de colores u otras indicaciones visuales para indicar valores que aparecen anómalos o que están fuera de un intervalo esperado. Tenga en cuenta los siguientes ejemplos de codificación de colores:

• Rojo para un disco con una velocidad de E/S que se aproxima a su capacidad máxima durante un período prolongado o un disco activo

• Amarillo para un disco cuya tasa de E/S alcanza periódicamente su límite máximo durante períodos cortos, o un disco templado

• Verde para un disco que muestra el uso normal

Los sistemas de panel deben tener los datos sin procesar para que funcionen de forma eficaz. Si crea su propio sistema de panel o usa un panel desarrollado por otra organización, debe comprender qué datos de instrumentación necesita recopilar, en qué niveles de granularidad y cómo dar formato al panel para que los consuma.

Un panel eficaz también le permite formular preguntas sobre la información. Algunos sistemas proporcionan herramientas de administración que puede usar para realizar estas tareas y explorar los datos subyacentes. En función del repositorio que contenga la información, es posible que pueda consultar datos directamente o importarlos en herramientas como Excel para realizar análisis e informes adicionales.

Generar alertas

Las alertas analizan los datos de supervisión e instrumentación y generan una notificación si detecta un evento significativo.

Las alertas ayudan a garantizar que el sistema siga siendo correcto, dinámico y seguro. Es una parte importante de cualquier sistema que hace garantías de rendimiento, disponibilidad y privacidad a los usuarios. Las alertas también pueden notificarle los eventos que desencadenan alertas. Use alertas para invocar funciones del sistema como el escalado automático.

Las alertas dependen de los siguientes datos de instrumentación:

• Eventos de seguridad: Si los registros de eventos indican que se producen errores repetidos de autenticación o autorización. En este escenario, una alerta debe informarle de que el sistema podría estar bajo ataque.

• Métricas de rendimiento: El sistema debe responder rápidamente si una métrica de rendimiento supera un umbral especificado.

• Información de disponibilidad: Si se detecta un fallo, es posible que tenga que reiniciar rápidamente uno o varios subsistemas o conmutar a un recurso de respaldo. Los errores repetidos en un subsistema podrían indicar problemas más graves.

Puede recibir información de alerta a través de muchos canales, como el correo electrónico, un buscapersonas o un mensaje de texto SMS. Una alerta también puede incluir una indicación de la importancia de una situación. Muchos sistemas de alertas admiten grupos de suscriptores y todos los operadores que son miembros del mismo grupo reciben el mismo conjunto de alertas.

Haga que el sistema de alertas sea personalizable y proporcione los valores adecuados de los datos de instrumentación subyacentes como parámetros. Mediante este enfoque, puede filtrar los datos de umbrales específicos o combinaciones de valores. En algunos casos, puede proporcionar los datos brutos de instrumentación al sistema de alertas. O bien, puede ser más adecuado proporcionar datos agregados. Por ejemplo, una alerta se desencadena cuando el uso de CPU para un nodo supera los 90% durante los últimos 10 minutos. Proporcione al sistema de alertas información de resumen y contexto adecuada para reducir la posibilidad de que los eventos falsos positivos desencadenen una alerta.

Notificación

Use informes para generar una vista general del sistema. Puede incorporar datos históricos e información actual. Los requisitos de informes se dividen en categorías operativas y de seguridad.

Los informes operativos suelen incluir los siguientes aspectos para el sistema general o subsistemas específicos durante un período de tiempo especificado:

• Estadísticas agregadas que puede usar para comprender el uso de recursos

• Tendencias en el uso de recursos

• Supervisión de excepciones

• Eficiencia de la aplicación en términos de los recursos implementados y si puede reducir el volumen de recursos sin afectar al rendimiento.

Los informes de seguridad realizan un seguimiento de cómo los clientes usan el sistema. Normalmente incluye los siguientes aspectos:

• Auditar las operaciones de usuario. Registre solicitudes individuales que cada usuario realiza junto con fechas y horas. Estructura los datos para que pueda reconstruir rápidamente la secuencia de operaciones que realiza un usuario durante un período especificado.

• Realizar un seguimiento del uso de recursos para cada usuario. Registre cómo cada solicitud de un usuario accede a los recursos del sistema y durante cuánto tiempo. Use estos datos para generar un informe de uso para cada usuario durante un período especificado, posiblemente con fines de facturación.

En muchos casos, los procesos por lotes pueden generar informes según una programación definida. Normalmente, la generación de informes no aumenta la latencia, por lo que puede generar informes a petición si es necesario. 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.

Pasos siguientes

• Introducción a Azure Monitor
• Supervisión, diagnóstico y solución de problemas de Storage
• Información general de las alertas en Azure
• Introducción a Application Insights
• Diagnóstico del rendimiento de las máquinas virtuales de Azure

Recursos relacionados

• La guía de escalado automático describe cómo reducir la sobrecarga de administración al reducir la necesidad de supervisar continuamente el rendimiento del sistema y tomar decisiones para agregar o quitar recursos.

• El patrón de supervisión de puntos de conexión de salud describe cómo implementar comprobaciones funcionales dentro de una aplicación a la que las herramientas externas pueden acceder a través de estos puntos de conexión expuestos a intervalos regulares.

• El patrón priority Queue describe cómo priorizar los mensajes en cola para que los sistemas reciban y procesen solicitudes urgentes antes de mensajes menos urgentes.