Guía de supervisión y diagnóstico

Las aplicaciones distribuidas y los servicios que se ejecutan en la nube son, por su naturaleza, partes complejas de software que componen muchas partes móviles. En un entorno de producción, es importante poder realizar un seguimiento de la forma en que los usuarios usan el sistema, el seguimiento del uso de recursos y, por lo general, supervisar el estado y el rendimiento del sistema. Esta información se puede usar como herramienta de diagnóstico para detectar y corregir problemas y para ayudar a detectarlos antes de que se produzcan.

Escenarios de supervisión y diagnóstico

Puede usar la supervisión para obtener información sobre el funcionamiento de un sistema. La supervisión es una parte fundamental del mantenimiento de los objetivos de calidad de servicio. Entre los escenarios comunes para recopilar datos de supervisión se incluyen:

• Asegurarse de que el sistema permanece en buen estado.
• Seguimiento de la disponibilidad del sistema y sus elementos componentes.
• Mantener el rendimiento para asegurarse de que el rendimiento del sistema no se degrada inesperadamente a medida que aumenta el volumen de trabajo.
• Garantizando que el sistema cumple los acuerdos de nivel de servicio (SLA) establecidos con los clientes.
• Protección de la privacidad y seguridad del sistema, los usuarios y sus datos.
• Realizar un seguimiento de las operaciones que se realizan con fines normativos o de auditoría.
• Supervisar el uso diario del sistema y detectar tendencias que podrían provocar problemas si no se abordan.
• Seguimiento de problemas que se producen, desde el informe inicial hasta el análisis de posibles causas, rectificaciones, actualizaciones de software consecuentes e implementación.
• Operaciones de seguimiento y depuración de versiones de software.

En las secciones siguientes se describen estos escenarios con más detalle. La información de cada escenario se describe en el formato siguiente:

1. Una breve introducción al escenario.
2. Los requisitos típicos de este escenario.
3. Los datos de instrumentación sin procesar necesarios para admitir el escenario y posibles orígenes de esta información.
4. Cómo se pueden analizar y combinar estos datos sin procesar para generar información de diagnóstico significativa.

Monitoreo de la salud

Un sistema es correcto si se está ejecutando y es capaz de procesar solicitudes. El propósito de la supervisión de estado es generar una instantánea del estado actual del sistema para que pueda comprobar que todos los componentes del sistema funcionan según lo previsto.

Requisitos para la supervisión del estado

Un operador debe recibir una alerta rápidamente (en cuestión de segundos) si se considera que alguna parte del sistema es incorrecta. El operador debe poder determinar qué partes del sistema funcionan normalmente y qué partes están experimentando problemas. El estado del sistema se puede resaltar a través de un sistema de semáforo:

• Rojo para un estado incorrecto (el sistema se ha detenido)
• Amarillo para un estado parcialmente correcto (el sistema se está ejecutando con una funcionalidad reducida)
• Verde para un estado completamente correcto

Un sistema completo de supervisión de estado permite a un operador explorar en profundidad el sistema para ver el estado de mantenimiento de los subsistemas y componentes. Por ejemplo, si el sistema general se representa como parcialmente correcto, el operador debe poder acercar y determinar qué funcionalidad no está disponible actualmente.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

Los datos sin procesar necesarios para admitir la supervisión de estado se pueden generar como resultado de:

• Seguimiento de la ejecución de solicitudes de usuario. Esta información se puede usar para determinar qué solicitudes se han realizado correctamente, que han fallado y cuánto tarda cada solicitud.
• Supervisión de usuarios sintéticos. Este proceso simula los pasos realizados por un usuario y sigue una serie predefinida de pasos. Se deben capturar los resultados de cada paso.
• Registrar excepciones, errores y advertencias. Esta información se puede capturar como resultado de instrucciones de seguimiento incrustadas en el código de aplicación, así como recuperar información de los registros de eventos de los servicios a los que hace referencia el sistema.
• Supervisar el estado de los servicios de terceros que use el sistema. Esta supervisión puede requerir la recuperación y el análisis de los datos de mantenimiento que proporcionan estos servicios. Esta información puede tener varios formatos.
• Supervisión de puntos de conexión. Este mecanismo se describe con más detalle en la sección "Supervisión de disponibilidad".
• Recopilación de información de rendimiento ambiental, como el uso de CPU en segundo plano o la actividad de E/S (incluida la red).

Análisis de datos de estado

El enfoque principal de la supervisión de estado es indicar rápidamente si el sistema se está ejecutando. El análisis frecuente de los datos inmediatos puede desencadenar una alerta si se detecta un componente crítico como incorrecto. (No responde a una serie consecutiva de pings, por ejemplo). Después, el operador puede tomar las medidas correctivas adecuadas.

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 detectar tendencias y determinar si es probable que el sistema permanezca en buen estado o si el sistema necesita recursos adicionales. Este elemento predictivo debe basarse en métricas de rendimiento críticas, como:

• Tasa de solicitudes dirigidas a cada servicio o subsistema.
• Los tiempos de respuesta de estas solicitudes.
• El volumen de datos que fluyen 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 permitir que un operador o el escalado automático (si está disponible) realicen las acciones preventivas necesarias para mantener el estado del sistema. Estas acciones pueden implicar la adición de recursos, el reinicio de uno o varios servicios con errores o la aplicación de la limitación a solicitudes de prioridad inferior.

Supervisión de disponibilidad

Un sistema realmente correcto requiere que los componentes y subsistemas que componen el sistema estén disponibles. La supervisión de disponibilidad está estrechamente relacionada con la supervisión de estado. Pero mientras que la supervisión del estado proporciona una vista inmediata del estado actual del sistema, la supervisión de la disponibilidad se preocupa por el seguimiento de la disponibilidad del sistema y sus componentes para generar estadísticas sobre el tiempo de actividad del sistema.

En muchos sistemas, algunos componentes (como una base de datos) se configuran con redundancia integrada para permitir una conmutación por error rápida en caso de que se produzca un error grave o una pérdida de conectividad. Idealmente, los usuarios no deben tener en cuenta que se ha producido este error. Pero desde una perspectiva de supervisión de disponibilidad, es necesario recopilar la mayor cantidad de información posible sobre estos errores para determinar la causa y tomar medidas correctivas para evitar que se repitan.

Los datos necesarios para realizar el seguimiento de la disponibilidad pueden depender de varios factores de nivel inferior. Muchos de estos factores pueden 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 dar una visión 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 en el que se almacenan los detalles del pedido y del sistema de pago que controla las transacciones monetarias para pagar estos pedidos. Por lo tanto, la disponibilidad de la parte de colocación de pedidos del sistema es una función de la disponibilidad del repositorio y del subsistema de pago.

Requisitos para la supervisión de disponibilidad

Un operador también debe poder ver la disponibilidad histórica de cada sistema y subsistema, y usar esta información para detectar cualquier tendencia que pueda hacer que uno o varios subsistemas produzcan errores periódicamente. (¿Los servicios empiezan a producir errores en una hora determinada del día que corresponde a horas punta de procesamiento?)

Una solución de supervisión debe proporcionar una vista inmediata e histórica de la disponibilidad o la falta de disponibilidad de cada subsistema. También debe ser capaz de alertar rápidamente a un operador cuando se produce un error en uno o varios servicios o cuando los usuarios no pueden conectarse a los servicios. Esto es cuestión de no solo supervisar cada servicio, sino también examinar las acciones que realiza cada usuario si estas acciones producen un error cuando intentan comunicarse con un servicio. En cierta medida, un grado de error de conectividad es normal y podría deberse a errores transitorios. Pero puede resultar útil permitir que el sistema genere una alerta para el número de errores de conectividad a un subsistema especificado que se produce durante un período específico.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

Al igual que con la supervisión de estado, los datos sin procesar necesarios para admitir la supervisión de disponibilidad se pueden generar como resultado de la supervisión sintética de usuarios y registrar las excepciones, errores y advertencias que pueden producirse. Además, los datos de disponibilidad se pueden obtener al realizar la supervisión del punto de conexión. La aplicación puede exponer uno o varios puntos de conexión de mantenimiento, cada uno de los cuales prueba el acceso a un área funcional dentro del sistema. El sistema de supervisión puede hacer ping a cada punto de conexión siguiendo una programación definida y recopilando los resultados (correctos o con errores).

Se deben registrar todos los tiempos de espera, los errores de conectividad de red y los reintentos de conexión. Todos los datos deben tener una marca de tiempo.

Análisis de datos de disponibilidad

Los datos de instrumentación deben agregarse y correlacionarse 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. Lo ideal es que un operador pueda correlacionar los errores con actividades específicas: ¿qué ha ocurrido cuando se produjo un error en el sistema?
• Vista histórica de las tasas de error del sistema o de los subsistemas en cualquier período especificado, y la carga en el sistema (número de solicitudes de usuario, por ejemplo) cuando se produjo un error.
• Las razones de falta de disponibilidad del sistema o de los subsistemas. Por ejemplo, las razones podrían ser el servicio no en ejecución, la conectividad perdida, conectada, conectada, el tiempo de espera y conectado, pero devolviendo errores.

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

Esto es útil para fines de Acuerdo de Nivel de Servicio. (La supervisión del Acuerdo de Nivel de Servicio se describe con más detalle más adelante en esta guía). La definición de tiempo de inactividad depende del servicio. Por ejemplo, El servicio de compilación de Visual Studio Team Services define el tiempo de inactividad como el período (minutos acumulados totales) durante el cual el servicio de compilación no está disponible. Un minuto se considera no disponible si todas las solicitudes HTTP continuas al servicio de compilación para realizar operaciones iniciadas por el cliente durante todo el minuto dan lugar a un código de error o no devuelven una respuesta.

Supervisión del rendimiento

A medida que el sistema se coloca bajo más y más estrés (aumentando el volumen de usuarios), el tamaño de los conjuntos de datos a los que estos usuarios acceden crece y la posibilidad de error de uno o más componentes se vuelve más probable. Con frecuencia, el error del componente está precedido de una disminución del rendimiento. Si puede detectar este tipo de disminución, puede tomar medidas proactivas para solucionar la situación.

El rendimiento del sistema depende de varios factores. Cada factor se mide normalmente 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 adscriben correctamente en un período de tiempo especificado. Algunos de estos KPI podrían estar disponibles como medidas de rendimiento específicas, mientras que otras podrían derivarse de una combinación de métricas.

Requisitos para la supervisión del rendimiento

Para examinar el rendimiento del sistema, un operador normalmente necesita ver información que incluye:

• Las tasas de respuesta de las solicitudes de usuario.
• Número de solicitudes de usuario simultáneas.
• Volumen del tráfico de red.
• Tarifas a las que se están completando las transacciones empresariales.
• El promedio de tiempo de procesamiento de las solicitudes.

También puede ser útil proporcionar herramientas que permitan a un operador ayudar a detectar correlaciones, como:

• Número de usuarios simultáneos frente a tiempos de latencia de solicitud (cuánto tiempo tarda en empezar a procesar una solicitud después de que el usuario lo haya enviado).
• Número de usuarios simultáneos frente al tiempo medio de respuesta (cuánto tiempo tarda en completarse una solicitud después de que se haya iniciado el procesamiento).
• El volumen de solicitudes frente al número de errores de procesamiento.

Junto con esta información funcional de alto nivel, un operador debe poder obtener una vista detallada del rendimiento de cada componente del sistema. Normalmente, estos datos se proporcionan a través de contadores de rendimiento de bajo nivel que realizan un seguimiento de información como:

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

Todas las visualizaciones deben permitir que un operador especifique 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.

Un operador debe poder generar una alerta en función de cualquier medida de rendimiento para cualquier valor especificado durante cualquier intervalo de tiempo especificado.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

Puede recopilar 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 a medida que llegan y pasan por el sistema. Esto implica la incorporación de instrucciones de seguimiento en puntos clave del código de la aplicación, junto con la información de tiempo. Todos los errores, excepciones y advertencias deben capturarse con datos suficientes para correlacionarlos con las solicitudes que las provocaron. El registro de Internet Information Services (IIS) es otro origen útil.

Si es posible, también debe capturar datos de rendimiento para cualquier sistema externo 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 esto no es posible, registre información como la hora de inicio y la hora de finalización de cada solicitud realizada a un sistema externo, junto con el estado (correcto, error o advertencia) de la operación. Por ejemplo, puede usar un enfoque de cronómetro para las solicitudes de tiempo: inicie un temporizador cuando se inicie la solicitud y, a continuación, detenga el temporizador cuando finalice la solicitud.

Los datos de rendimiento de bajo nivel para los componentes individuales de un sistema podrían estar disponibles a través de características y servicios como contadores de rendimiento de Windows y Diagnósticos de Azure.

Análisis de los datos de rendimiento

Gran parte del trabajo de análisis consiste en agregar datos de rendimiento por tipo de solicitud de usuario o el subsistema o servicio al que se envía cada solicitud. Un ejemplo de solicitud de usuario es agregar un artículo a un carro de la compra o realizar el proceso de desprotección en un sistema de comercio electrónico.

Otro requisito común es resumir los datos de rendimiento en percentiles seleccionados. Por ejemplo, un operador podría determinar los tiempos de respuesta del 99 por ciento de las solicitudes, el 95 por ciento de las solicitudes y el 70 por ciento de las solicitudes. Puede haber objetivos de Acuerdo de Nivel de Servicio u otros objetivos establecidos para cada percentil. Los resultados en curso se deben notificar casi en tiempo real para ayudar a detectar problemas inmediatos. Los resultados también deben agregarse durante el tiempo más largo para fines estadísticos.

En el caso de problemas de latencia que afectan al rendimiento, un operador debe ser capaz de identificar rápidamente la causa del cuello de botella examinando la latencia de cada paso que realiza cada solicitud. Por lo tanto, los datos de rendimiento deben proporcionar un medio para correlacionar las medidas de rendimiento para cada paso para vincularlos a una solicitud específica.

Según 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 y análisis ad hoc complejos de la información de rendimiento.

Supervisión de seguridad

Todos los sistemas comerciales que incluyan datos confidenciales deben implementar una estructura de seguridad. La complejidad del mecanismo de seguridad suele ser una función de la confidencialidad de los datos. En un sistema que requiere que los usuarios se autentiquen, debe registrar:

• Todos los intentos de inicio de sesión, ya sean erróneos o correctos.
• Todas las operaciones realizadas por y los detalles de todos los recursos a los que accede un usuario autenticado.
• 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, un gran número de intentos de inicio de sesión erróneos podría indicar un ataque por fuerza bruta. Un aumento inesperado de las solicitudes podría ser el resultado de un ataque de denegación de servicio distribuido (DDoS). Debe estar preparado para supervisar todas las solicitudes a todos los recursos, independientemente del origen de estas solicitudes. Un sistema que tenga una vulnerabilidad de inicio de sesión podría exponer accidentalmente recursos al mundo exterior sin necesidad de que un usuario inicie sesión realmente.

Requisitos para la supervisión de seguridad

Los aspectos más críticos de la supervisión de seguridad deben permitir que un operador pueda:

• Detecte intrusiones intentadas por una entidad no autenticada.
• Identifique los intentos de las entidades para realizar operaciones en los datos para los que no se les ha concedido acceso.
• Determine si el sistema, o alguna parte del sistema, está bajo ataque desde fuera o dentro. (Por ejemplo, un usuario autenticado malintencionado podría intentar bajar el sistema).

Para admitir estos requisitos, se debe notificar a un operador 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.

La información proporcionada a un operador debe incluir la dirección de host del origen para cada solicitud. Si las infracciones de seguridad surgen regularmente de un intervalo determinado de direcciones, es posible que estos hosts se bloqueen.

Una parte clave para mantener la seguridad de un sistema es poder detectar rápidamente las acciones que se desvía del patrón habitual. La información como el número de solicitudes de inicio de sesión correctas o erróneas se puede mostrar visualmente para ayudar a detectar si hay un pico en la actividad en un momento inusual. (Un ejemplo de esta actividad es que los usuarios inician sesión a las 3:00 a.m. y realizan un gran número de operaciones cuando su día laborable comienza a las 9:00 a.m. ). Esta información también se puede usar para ayudar a configurar el escalado automático basado en el tiempo. Por ejemplo, si un operador observa que un gran número de usuarios inician sesión regularmente en una hora determinada del día, el operador puede organizarse para iniciar servicios de autenticación adicionales para controlar el volumen de trabajo y, a continuación, apagar estos servicios adicionales cuando se ha superado el pico.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

La seguridad es un aspecto integral de la mayoría de los sistemas distribuidos. Es probable que los datos pertinentes se generen en varios puntos a lo largo de un sistema. Debe considerar la posibilidad de adoptar un enfoque de administración de eventos e información de seguridad (SIEM) para recopilar la información relacionada con la seguridad que resulta 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 que no forman parte de la aplicación. Estas herramientas pueden incluir utilidades que identifican las actividades de examen de puertos por agencias externas o filtros de red que detectan intentos de obtener acceso no autenticado a la aplicación y a los datos.

En todos los casos, los datos recopilados deben permitir que un administrador determine la naturaleza de cualquier ataque y tome las contramedidas adecuadas.

Análisis de datos de seguridad

Una característica clave de la supervisión de seguridad es que recopila datos de muchos orígenes. A menudo, los diferentes formatos y el nivel de detalle requieren un análisis complejo de los datos capturados para vincularlos en un subproceso coherente de información. Aparte de los casos más sencillos (como detectar un gran número de inicios de sesión erróneos o intentos repetidos de obtener acceso no autorizado a recursos críticos), es posible que no sea posible realizar ningún procesamiento automatizado complejo de datos de seguridad. En su lugar, puede ser preferible escribir estos datos, marca de tiempo, pero de lo contrario, en su forma original, en un repositorio seguro para permitir el análisis manual experto.

Supervisión del Acuerdo de Nivel de Servicio

Muchos sistemas comerciales que admiten el pago de clientes hacen garantías sobre el rendimiento del sistema en forma de Acuerdos de Nivel de Servicio. Básicamente, 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 se ocupa de garantizar que el sistema pueda cumplir los Acuerdos de Nivel de Servicio medibles.

Los Acuerdos de Nivel de Servicio a menudo se definen en términos de:

• Disponibilidad general del sistema. Por ejemplo, una organización podría garantizar que el sistema está disponible durante el 99,9 % del tiempo. Esto equivale a no más de 9 horas de tiempo de inactividad por año o aproximadamente 10 minutos a la semana.
• Rendimiento operativo. Este aspecto se expresa a menudo como una o más marcas de agua alta, como garantizar que el sistema puede admitir hasta 100 000 solicitudes simultáneas de usuario o controlar 10 000 transacciones empresariales simultáneas.
• Tiempo de respuesta operativo. El sistema también puede garantizar la velocidad a la que se procesan las solicitudes. Un ejemplo es que el 99 % de todas las transacciones empresariales finalizan en dos segundos y ninguna transacción tarda más de 10 segundos.

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

En el nivel más alto, un operador debe ser capaz de determinar de un vistazo si el sistema cumple los Acuerdos de Nivel de Servicio acordados o no. Y, si no es así, el operador debe ser capaz de explorar en profundidad y examinar los factores subyacentes para determinar los motivos del rendimiento estándar.

Los indicadores típicos de alto nivel que se pueden representar visualmente incluyen:

• Porcentaje del 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 aplicación correctas o con errores.
• Número de errores, excepciones y advertencias de aplicación y sistema.

Todos estos indicadores deben ser capaces de filtrarse por un período de tiempo especificado.

Una aplicación en la nube probablemente comprende varios subsistemas y componentes. Un operador debe poder seleccionar un indicador de alto nivel y ver cómo se compone del estado de los elementos subyacentes. Por ejemplo, si el tiempo de actividad del sistema general está por debajo de un valor aceptable, un operador debe poder acercarse y determinar qué elementos contribuyen a este fallo.

Con fines de alerta, el sistema debe poder generar un evento si alguno de los indicadores de alto nivel supera un umbral especificado. Los detalles de nivel inferior de los distintos factores que componen el indicador de alto nivel deben estar disponibles como datos contextuales para el sistema de alertas.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

Los datos sin procesar necesarios para admitir la supervisión del Acuerdo de Nivel de Servicio son similares a los datos sin procesar necesarios para la supervisión del rendimiento, junto con algunos aspectos de la supervisión del estado y la disponibilidad. Para obtener más información, consulte esas secciones. Puede capturar estos datos mediante:

• Realizar la supervisión del punto de conexión.
• Registrar excepciones, errores y advertencias.
• Seguimiento de la ejecución de solicitudes de usuario.
• Supervisar la disponibilidad de cualquier servicio de terceros que use el sistema.
• Uso de métricas y contadores de rendimiento.

Todos los datos deben tener tiempo y marca de tiempo.

Análisis de datos del Acuerdo de Nivel de Servicio

Los datos de instrumentación deben agregarse para generar una imagen del rendimiento general del sistema. Los datos agregados también deben admitir la exploración en profundidad para habilitar el examen del rendimiento de los subsistemas subyacentes. Por ejemplo, debería poder:

• 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 de una solicitud en los tiempos de respuesta de los elementos de trabajo individuales de esa solicitud.
• Determine la disponibilidad general del sistema como porcentaje de tiempo de actividad durante cualquier período específico.
• Analice el porcentaje de disponibilidad de tiempo de los componentes y servicios individuales del sistema. Esto puede implicar el análisis de registros que han generado servicios de terceros.

Muchos sistemas comerciales son necesarios para notificar cifras reales de rendimiento contra acuerdos de nivel de servicio acordados durante un período especificado, normalmente un mes. Esta información se puede utilizar para calcular créditos u otras formas de reembolso para los clientes si los ACUERDOS de Nivel de Servicio no se cumplen durante ese período. Puede calcular la disponibilidad de un servicio mediante la técnica descrita en la sección 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 provocaron errores en los servicios. Aprender a resolver estos problemas rápidamente o eliminarlos por completo ayuda a reducir el tiempo de inactividad y a cumplir los Acuerdos de Nivel de Servicio.

Auditoría

En función de la naturaleza de la aplicación, puede haber normativas legales u otras normativas legales que especifiquen los 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. Nonrepudiation es un factor importante en muchos sistemas empresariales electrónicos para ayudar a mantener la confianza entre un cliente y la organización responsable de la aplicación o el servicio.

Requisitos para la auditoría

Un analista debe poder realizar un seguimiento de la secuencia de operaciones empresariales que realizan los usuarios para poder reconstruir las acciones de los usuarios. Esto puede ser necesario simplemente como cuestión de registro 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, junto con las tareas que están realizando. Por este motivo, la información de auditoría probablemente adopta la forma de informes que solo están disponibles para analistas de confianza en lugar de como un sistema interactivo que admite la exploración en profundidad de las operaciones gráficas. Un analista debe poder generar un rango de informes. Por ejemplo, los informes pueden enumerar las actividades de todos los usuarios que se producen durante un período de tiempo especificado, detallar la cronología de la actividad de un solo usuario o enumerar la secuencia de operaciones realizadas en uno o varios recursos.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

Los orígenes principales de información para la auditoría pueden incluir:

• 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.

El formato de los datos de auditoría y la forma en que se almacena podría estar controlada por los requisitos normativos. Por ejemplo, es posible que no sea posible limpiar los datos de ninguna manera. (Debe grabarse en su formato original). El acceso al repositorio donde se mantiene debe protegerse para evitar alteraciones.

Análisis de datos de auditoría

Un analista debe poder acceder a los datos sin procesar en su totalidad, 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 se usan las características y los componentes de una aplicación. Un operador puede usar los datos recopilados para:

• Determine qué características se usan en gran medida y determine las posibles zonas activas del sistema. Los elementos de alto tráfico pueden beneficiarse de la creación de particiones funcionales o incluso de la replicación para distribuir la carga de forma más uniforme. Un operador 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 la información estadística sobre el número de transacciones y el volumen de clientes responsables de ellas. Esta información se puede usar para planear la capacidad a medida que crece el número de clientes.

• Detecte (posiblemente indirectamente) la satisfacción del usuario con el rendimiento o la funcionalidad del sistema. Por ejemplo, si un gran número de clientes de un sistema de comercio electrónico abandona regularmente sus carros de compras, esto podría deberse a un problema con la funcionalidad de desprotección.

• 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 su cuota de pago de tiempo de procesamiento o uso de recursos durante un período especificado, su acceso se puede limitar o el procesamiento se puede limitar.

Requisitos para la supervisión del uso

Para examinar el uso del sistema, un operador normalmente necesita ver información que incluye:

• Número de solicitudes procesadas por cada subsistema y dirigidas 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.

Un operador también debe poder generar gráficos. Por ejemplo, un gráfico podría mostrar los usuarios con mayor hambre de recursos o los recursos o características del sistema a los que se accede con más frecuencia.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

El seguimiento de uso se puede realizar en un nivel relativamente alto. Puede tener en cuenta las horas de inicio y finalización de cada solicitud y la naturaleza de la solicitud (lectura, escritura y otras solicitudes, en función del recurso en cuestión). Puede obtener esta información:

• Seguimiento de la actividad del usuario.
• Capturar contadores de rendimiento que miden el uso de cada recurso.
• Supervisar el consumo de recursos por cada usuario.

Para fines de medición, también debe poder identificar qué usuarios son responsables de realizar las operaciones y los recursos que usan estas operaciones. La información recopilada debe ser lo suficientemente detallada como para permitir una 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 se ocupa de administrar estos problemas, asociarlos con esfuerzos para resolver cualquier problema subyacente en el sistema e informar a los clientes de posibles soluciones.

Requisitos para el seguimiento de problemas

Los operadores suelen realizar el seguimiento de problemas mediante un sistema independiente que les permite registrar e informar de los detalles de los problemas que los usuarios notifican. Estos detalles pueden incluir las tareas que el usuario estaba intentando realizar, los síntomas del problema, la secuencia de eventos y los mensajes de error o advertencia que se emitieron.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

El origen de datos inicial para los datos de seguimiento de problemas es el usuario que informó del problema en primer lugar. Es posible que el usuario pueda proporcionar datos adicionales, como:

• 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, junto con cualquier otra información ambiental, como la ubicación del usuario.

Esta información se puede usar para ayudar al esfuerzo de depuración y ayudar a construir un trabajo pendiente para futuras versiones del software.

Análisis de datos de seguimiento de problemas

Es posible que distintos usuarios informen del mismo problema. El sistema de seguimiento de problemas debe asociar informes comunes.

El progreso del esfuerzo de depuración debe registrarse en cada informe de problemas. Cuando se resuelve el problema, se puede informar al cliente de la solución.

Si un usuario notifica un problema que tiene una solución conocida en el sistema de seguimiento de problemas, el operador debe ser capaz de informar al usuario de la solución inmediatamente.

Seguimiento de operaciones y depuración de versiones de software

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

Requisitos para el seguimiento y la depuración

Para realizar el seguimiento de eventos inesperados y otros problemas, es fundamental que los datos de supervisión proporcionen suficiente información para permitir que un analista realice un seguimiento de los orígenes de estos problemas y reconstruya la secuencia de eventos que se produjeron. Esta información debe ser suficiente para permitir que un analista diagnostique la causa principal de cualquier problema. A continuación, un desarrollador puede realizar las modificaciones necesarias para evitar que se repitan.

Requisitos de orígenes de datos, instrumentación y recopilación de datos

La solución de problemas puede implicar el seguimiento de todos los métodos (y sus parámetros) invocados como parte de una operación para crear un árbol que muestre el flujo lógico a través del sistema cuando un cliente realiza una solicitud específica. Las excepciones y advertencias que genera el sistema como resultado de este flujo deben capturarse y registrarse.

Para admitir la depuración, el sistema puede proporcionar enlaces que permiten a un operador 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 imponer una carga adicional en el sistema y debe ser un proceso temporal. Un operador usa este proceso principalmente cuando se produce una serie de eventos muy inusuales y es difícil de replicar, o cuando una nueva versión de uno o varios elementos en un sistema requiere una supervisión cuidadosa para asegurarse de que los elementos funcionan según lo previsto.

Canalización de supervisión y diagnóstico

La supervisión de un sistema distribuido a gran escala plantea un desafío importante. Cada uno de los escenarios descritos en la sección anterior no debe considerarse necesariamente de forma aislada. Es probable que haya una superposición significativa en los datos de supervisión y diagnóstico necesarios para cada situación, aunque es posible que estos datos deba procesarse y presentarse de maneras diferentes. Por estas razones, debe tomar una vista holística de la supervisión y el diagnóstico.

Puede prever todo el proceso de supervisión y diagnóstico como una canalización que comprende las fases que se muestran en la figura 1.

Figura 1: Las fases de la canalización de supervisión y diagnóstico.

En la figura 1 se resalta cómo pueden proceder los datos de supervisión y diagnóstico de varios orígenes de datos. Las fases de instrumentación y recopilación se ocupan de identificar los orígenes desde los que deben capturarse los datos, determinar qué datos capturar, cómo capturarlos y cómo dar formato a estos datos para que se puedan examinar fácilmente. La fase de análisis y diagnóstico toma los datos sin procesar y los usa para generar información significativa que un operador puede usar para determinar el estado del sistema. El operador puede usar esta información para tomar decisiones sobre las posibles acciones que se deben realizar y, a continuación, devolver los resultados a las fases de instrumentación y recopilación. La fase de fase de visualización y alerta presenta una vista consumible del estado del sistema. Puede mostrar información casi en tiempo real mediante una serie de paneles. Además, puede generar informes, gráficos y gráficos para proporcionar una vista histórica de los datos que pueden ayudar 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 a un operador. En algunos casos, también se puede usar una alerta para desencadenar un proceso automatizado que intente realizar acciones correctivas, como el escalado automático.

Estos pasos constituyen un proceso de flujo continuo en el que se producen las fases en paralelo. Lo ideal es que todas las fases se puedan configurar dinámicamente. En algunos puntos, especialmente cuando un sistema se ha implementado recientemente o está experimentando problemas, es posible que sea necesario recopilar datos extendidos con más frecuencia. En otras ocasiones, debería ser posible volver a capturar un nivel base de información esencial para comprobar que el sistema funciona correctamente.

Además, todo el proceso de supervisión debe considerarse una solución activa y continua que está sujeta a mejoras y ajuste finos como resultado de los comentarios. Por ejemplo, puede empezar con la medición de muchos factores para determinar el estado del sistema. El análisis a lo largo del tiempo puede dar lugar a un refinamiento a medida que descarta medidas que no son relevantes, lo que le permite centrarse más precisamente en los datos que necesita al minimizar el ruido de fondo.

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, como se muestra en la figura 1. En el nivel de aplicación, la información procede de los registros de seguimiento incorporados en el 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 cualquier otra información pertinente. La grabación de las horas de entrada y salida también puede resultar útil.

Debe registrar todas las excepciones y advertencias y asegurarse de conservar un seguimiento completo de las excepciones y advertencias anidadas. Idealmente, también debe capturar información que identifique al usuario que ejecuta el código, junto con la información de correlación de actividad (para realizar un seguimiento de las solicitudes a medida que pasan por el sistema). Además, debe registrar intentos de acceso a todos los recursos, como colas de mensajes, bases de datos, archivos y otros servicios dependientes. Esta información se puede usar 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. Estos marcos pueden configurarse 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 una fuente de información de bajo nivel en todo el sistema, como contadores de rendimiento que indican tasas de E/S, uso de memoria y uso de CPU. También se pueden notificar errores del sistema operativo (como el error al abrir un archivo correctamente).

También debe tener en cuenta la infraestructura subyacente y los componentes en los que se ejecuta el sistema. Las máquinas virtuales, 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, estos servicios pueden publicar su propia información de seguimiento, registros y contadores de rendimiento. Entre los ejemplos se incluyen vistas de administración dinámica de SQL Server para realizar operaciones de seguimiento en una base de datos de SQL Server y registros de seguimiento de IIS para registrar las solicitudes realizadas en un servidor web.

A medida que se modifican los componentes de un sistema y se implementan nuevas versiones, es importante poder atribuir problemas, eventos y métricas a cada versión. Esta información debe estar vinculada a la canalización de versión para que se pueda realizar un seguimiento rápido y rectificado de problemas con una versión específica de un componente.

Los problemas de seguridad pueden producirse en cualquier momento del sistema. Por ejemplo, un usuario podría intentar iniciar sesión con un identificador de usuario o una contraseña no válidos. Un usuario autenticado podría intentar obtener acceso no autorizado a un recurso. O bien, un usuario puede proporcionar una clave no válida o obsoleta para acceder a la información cifrada. La información relacionada con la seguridad para las solicitudes correctas y con errores siempre debe registrarse.

La sección Instrumentación de una aplicación contiene más instrucciones sobre la información que debe capturar. Pero puede usar varias estrategias para recopilar esta información:

• Supervisión de aplicaciones y sistemas. Esta estrategia 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 podrían estar habilitadas o deshabilitadas de forma selectiva a medida que se dictan circunstancias. También puede insertar diagnósticos dinámicamente mediante un marco de diagnóstico. Normalmente, estos marcos proporcionan complementos que pueden asociarse a varios puntos de instrumentación en el código y capturar datos de seguimiento en estos puntos.

  Además, el código o la infraestructura subyacente pueden generar eventos en puntos críticos. Los agentes de supervisión configurados para escuchar estos eventos pueden registrar la información del evento.

• Supervisión de usuarios reales. Este enfoque registra las interacciones entre un usuario y la aplicación y observa el flujo de cada solicitud y respuesta. Esta información puede tener un propósito de dos veces: se puede usar para el uso de medición por cada usuario y se puede usar para determinar si los usuarios reciben una calidad de servicio adecuada (por ejemplo, tiempos de respuesta rápidos, latencia baja y errores mínimos). Puede usar los datos capturados para identificar áreas de preocupación en las que se producen errores con más frecuencia. También puede usar los datos para identificar los elementos en los que el sistema se ralentiza, posiblemente debido a zonas activas de la aplicación o a algún otro tipo de cuello de botella. Si implementa este enfoque cuidadosamente, es posible reconstruir los flujos de los usuarios a través de la aplicación con fines de depuración y pruebas.

  Importante

  Debe tener en cuenta los datos capturados mediante la supervisión de usuarios reales para que sean altamente confidenciales, 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.

• Supervisión de usuarios sintéticos. En este enfoque, escribirá su propio cliente de prueba que simula 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 qué tipo de salida de supervisión se genera en estas condiciones.

  Nota:

  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.

• Generación de perfiles. Este enfoque se dirige principalmente a la supervisión y mejora del rendimiento de las aplicaciones. En lugar de funcionar en el nivel funcional de supervisión de usuarios reales y sintéticos, captura información de nivel inferior a medida que se ejecuta la aplicación. Puede implementar la generación de perfiles mediante el muestreo periódico del estado de ejecución de una aplicación (determinar qué fragmento de código se ejecuta en un momento dado). También puede usar la instrumentación que inserta sondeos en el código en momentos importantes (como el inicio y el final de una llamada de método) y los registros que se invocaron a los métodos, en qué momento y cuánto tiempo tardó cada llamada. A continuación, puede analizar estos datos para determinar qué partes de la aplicación pueden causar problemas de rendimiento.

• Supervisión de puntos de conexión. Esta técnica usa uno o varios puntos de conexión de diagnóstico que la aplicación expone específicamente para habilitar 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 asimilar las respuestas. Para obtener más información, consulte el patrón de supervisión de puntos de conexión de mantenimiento.

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. Puede tomar decisiones significativas sobre el rendimiento y el estado de un sistema solo si primero captura los datos que le permiten tomar estas decisiones. La información que recopile mediante la instrumentación debe ser suficiente para permitirle evaluar el rendimiento, diagnosticar problemas y tomar decisiones sin necesidad de iniciar sesión en un servidor de producción remoto para realizar el seguimiento (y la depuración) manualmente. Los datos de instrumentación suelen incluir métricas e información escritas en los registros de seguimiento.

El contenido de un registro de seguimiento puede ser el resultado de los datos textuales escritos por la aplicación o los datos binarios creados como resultado de un evento de seguimiento, si la aplicación usa seguimiento de eventos para Windows (ETW). También se pueden generar a partir de registros del sistema que registran eventos derivados de partes de la infraestructura, como un servidor web. A menudo, los mensajes de registro de texto están diseñados para ser legibles, pero también deben escribirse en un formato que permita a un sistema automatizado analizarlos fácilmente.

También debe clasificar los registros. No escriba todos los datos de seguimiento en un único registro, pero use registros independientes para registrar la salida del seguimiento de diferentes aspectos operativos del sistema. A continuación, puede filtrar rápidamente los mensajes de registro leyendo desde el registro adecuado en lugar de tener que 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.

Las métricas suelen ser 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 (a veces denominadas muestra). Normalmente, una sola instancia de una métrica no es útil de forma aislada. En su lugar, las métricas deben capturarse con el tiempo. El problema clave que se debe tener en cuenta es qué métricas debe registrar y con qué frecuencia. La generación de datos para métricas con demasiada frecuencia puede imponer una carga adicional significativa en el sistema, mientras que la captura de métricas con poca frecuencia podría 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 pueden adoptar varias formas en los datos sin procesar y el proceso de análisis debe proporcionarse con suficientes datos de instrumentación para poder asignar estos formularios diferentes. Por ejemplo, en el nivel de marco de trabajo de la aplicación, una tarea podría identificarse mediante un identificador de subproceso. Dentro de una aplicación, el mismo trabajo podría estar asociado al identificador de usuario para el usuario que realiza esa tarea.

Además, es poco probable que haya una asignación 1:1 entre subprocesos y solicitudes de usuario, ya que las operaciones asincrónicas pueden reutilizar los mismos subprocesos para realizar operaciones en nombre de más de un usuario. Para complicar aún más las cuestiones, una única solicitud podría controlarse mediante más de un subproceso a medida que la ejecución fluye a través del sistema. Si es posible, asocie cada solicitud con un identificador de actividad único que se propaga 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 se usa para capturar los datos de seguimiento).

Todos los datos de supervisión deben tener una marca de tiempo de la misma manera. Para la coherencia, registre todas las fechas y horas mediante la hora universal coordinada. Esto 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 al decidir qué datos de instrumentación necesita recopilar:

• Asegúrese de que la información capturada por eventos de seguimiento sea legible y automática. 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 lee 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 imponer una sobrecarga significativa en el sistema. La generación de perfiles mediante el uso de registros de instrumentación registra un evento (por ejemplo, una llamada al método) cada vez que se produce, mientras que el muestreo registra solo los eventos seleccionados. La selección puede basarse en el tiempo (una vez cada n segundos) o en función de la frecuencia (una vez cada n solicitudes). Si los eventos se producen con mucha frecuencia, la generación de perfiles por instrumentación podría provocar demasiada carga y afectar al rendimiento general. En este caso, el enfoque de muestreo podría ser preferible. Sin embargo, si la frecuencia de los eventos es baja, el muestreo podría perderse. En este caso, la instrumentación podría ser el mejor enfoque.

• Proporcione un contexto suficiente para permitir que un desarrollador o administrador determine el origen de cada solicitud. Esto puede incluir algún tipo de identificador de actividad que identifique una instancia específica de una solicitud. También puede incluir información que se puede usar para correlacionar esta 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 hizo que se realizara la solicitud. Este contexto proporciona información valiosa sobre el estado de la aplicación en el momento en que se capturaron los datos de supervisión.

• Registre todas las solicitudes y las ubicaciones o regiones desde las que se realizan estas solicitudes. Esta información puede ayudar a determinar si hay puntos de acceso específicos de la ubicación. Esta información también puede ser útil para determinar si se debe 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 control 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, ya que esto puede ayudar a analizar eventos y correlacionarlos con 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 que se realiza, 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 específicos, como el número de conexiones a una base de datos, la velocidad a la que se realizan las transacciones y el número de transacciones que se realizan correctamente o con errores. 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 el éxito o error de la llamada. Si es posible, capture información sobre todos los reintentos y errores de los errores transitorios que se produzcan.

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 cualquier aplicación o tecnología específica, pero espera que la información siga un formato específico que normalmente se define mediante un esquema. El esquema especifica eficazmente un contrato que define los campos de datos y los tipos que el sistema de telemetría puede ingerir. El esquema debe generalizarse para permitir que los datos que llegan desde una gama de plataformas y dispositivos.

Un esquema común debe incluir campos comunes a todos los eventos de instrumentación, como el nombre del evento, la hora del evento, la dirección IP del remitente y los detalles necesarios para la correlación 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; La aplicación puede 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. Esto puede ser 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, lo que permite 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. Esto 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 revelar información confidencial sobre el sistema o la información personal sobre los usuarios. Limgue esta información antes de que se registre, pero asegúrese de que se conservan los detalles pertinentes. Por ejemplo, quite el identificador y la contraseña de cualquier cadena de conexión de base de datos, pero escriba la información restante en el registro para que un analista pueda determinar que el sistema tiene acceso a la base de datos correcta. Registre todas las excepciones críticas, pero habilite al administrador para activar y desactivar el registro para niveles inferiores de excepciones y advertencias. Además, capture y registre toda la información lógica de reintento. Estos datos pueden ser útiles para supervisar el estado transitorio del sistema.

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

• 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.

• A excepción de los eventos de auditoría, asegúrese de que todas las llamadas de registro son operaciones de desencadenación y olvido que no bloquean el progreso de las operaciones empresariales. Los eventos de auditoría son excepcionales porque son críticos para la empresa y se pueden clasificar como una parte fundamental de las operaciones empresariales.

• Asegúrese de que el registro es extensible y no tiene dependencias directas en un destino concreto. 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 se puedan implementar a través de cualquier medio adecuado.

• Asegúrese de que todo el registro sea seguro para errores y nunca desencadene errores en cascada. El registro no debe producir ninguna excepción.

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

Recopilación y almacenamiento de datos

La fase de recopilación del proceso de supervisión se ocupa de recuperar la información que genera la instrumentación, dar formato a estos datos para facilitar el consumo de la fase de análisis y diagnóstico y guardar los datos transformados en un almacenamiento confiable. Los datos de instrumentación que se recopilan de diferentes partes de un sistema distribuido se pueden mantener en varias ubicaciones y con distintos formatos. Por ejemplo, el código de la aplicación podría generar archivos de registro de seguimiento y generar datos de registro de eventos de aplicación, mientras que los contadores de rendimiento que supervisan aspectos clave de la infraestructura que usa la aplicación se pueden capturar a través de otras tecnologías. Los componentes y servicios de terceros que use la aplicación pueden proporcionar información de instrumentación en diferentes formatos, mediante archivos de seguimiento independientes, almacenamiento de blobs o incluso un almacén de datos personalizado.

La recopilación de datos se realiza a menudo a través de un servicio de recopilación que se puede ejecutar de forma autónoma desde la aplicación que genera los datos de instrumentación. En la figura 2 se muestra un ejemplo de esta arquitectura, en el que se resalta el subsistema de recopilación de datos de instrumentación.

Figura 2: Recopilación de datos de instrumentación.

Se trata de una vista simplificada. El servicio de recopilación no es necesariamente un único proceso y puede incluir muchas partes constituyentes que se ejecutan en máquinas diferentes, como se describe en las secciones siguientes. Además, si el análisis de algunos datos de telemetría se debe realizar rápidamente (análisis frecuente, como se describe en la sección Compatibilidad con análisis frecuente, intermedio y en frío más adelante en este documento), los componentes locales que funcionan fuera del servicio de recopilación pueden realizar las tareas de análisis inmediatamente. En la figura 2 se muestra esta situación para los eventos seleccionados. Después del procesamiento analítico, los resultados se pueden enviar directamente al subsistema de visualización y alertas. Los datos que están sujetos a análisis en frío o en caliente se mantienen en el almacenamiento mientras espera el procesamiento.

Para aplicaciones y servicios de Azure, Azure Diagnostics proporciona una posible solución para capturar datos. Azure Diagnostics recopila datos de los orígenes siguientes para cada nodo de proceso, lo agrega y, a continuación, lo carga en Azure Storage:

• Registros de IIS
• Registros de solicitudes con error de IIS
• Registros de eventos de Windows
• Contadores de rendimiento
• Volcados de memoria
• Registros de infraestructura de diagnóstico de Azure
• Registros de errores personalizados
• EventSource de .NET
• ETW basado en manifiesto

Para más información, consulte el artículo Azure: Conceptos básicos de telemetría y solución de problemas.

Estrategias para recopilar datos de instrumentación

Teniendo en cuenta la naturaleza elástica de la nube y para evitar la necesidad de recuperar manualmente los datos de telemetría de todos los nodos del sistema, debe organizar que los datos se transfieran a una ubicación central y se consoliden. En un sistema que abarca varios centros de datos, puede resultar útil 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.

Para optimizar el uso del ancho de banda, puede optar por transferir datos menos urgentes en fragmentos, como lotes. Sin embargo, los datos no se deben retrasar indefinidamente, especialmente si contiene información confidencial.

Extracción e inserción de datos de instrumentación

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 (el modelo de extracción). O bien, puede actuar como receptor pasivo que espera a que los datos se envíen desde los componentes que constituyen cada instancia de la aplicación (el modelo de inserción).

Un enfoque para implementar 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 (extrae) los datos de telemetría recopilados en el nodo local y escribe esta información directamente en el almacenamiento centralizado que todas las instancias del recurso compartido de aplicaciones. Este es el mecanismo que implementa Azure Diagnostics. Cada instancia de un rol web o de trabajo de Azure se puede configurar para capturar el diagnóstico y otra información de seguimiento almacenada localmente. El agente de supervisión que se ejecuta junto con cada instancia copia los datos especificados en Azure Storage. En el artículo Habilitación de diagnósticos en Azure Cloud Services y Virtual Machines se proporcionan más detalles sobre este proceso. Algunos elementos, como registros de IIS, volcados de memoria y registros de errores personalizados, se escriben en Blob Storage. Los datos del registro de eventos de Windows, los eventos ETW y los contadores de rendimiento se registran en Table Storage. En la figura 3 se muestra este mecanismo.

Figura 3: Uso de un agente de supervisión para extraer información y escribir en el almacenamiento compartido.

Es factible usar el enfoque que se acaba de describir 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. Sin embargo, una aplicación en la nube global compleja y altamente escalable podría generar grandes volúmenes de datos de cientos de roles web y de trabajo, 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, la solución de telemetría debe ser escalable para evitar que actúe como cuello de botella a medida que se expanda el sistema. 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, puede implementar colas, como se muestra en la figura 4. En esta arquitectura, el agente de supervisión local (si se puede configurar correctamente) o el servicio de recopilación de datos personalizado (si no es así) envía datos a una cola. Un proceso independiente que se ejecuta de forma asincrónica (el servicio de escritura de almacenamiento en la figura 4) toma los datos de esta cola y los escribe en el almacenamiento compartido. Una cola de mensajes es adecuada para este escenario porque proporciona semántica de "al menos una vez" que ayuda a garantizar que los datos en cola no se pierdan después de ser enviados. Puede implementar el servicio de escritura de almacenamiento mediante un rol de trabajo independiente.

Figura 4: Uso de una cola para almacenar en búfer los datos de instrumentación.

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

Para obtener escalabilidad, puede ejecutar varias instancias del servicio de escritura de almacenamiento. Si hay un gran volumen de eventos, puede usar un centro de eventos para enviar los datos a distintos recursos de proceso para el procesamiento y el almacenamiento.

Consolidación de 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, es necesario consolidar algunos aspectos de los datos en las vistas locales. Puede realizar esto después de almacenar los datos, pero en algunos casos, también puede lograrlo a medida que se recopilan los datos. En lugar de escribirse directamente en el almacenamiento compartido, los datos de instrumentación pueden pasar a través de un servicio de consolidación de datos independiente que combina datos y actúa como un proceso de filtrado y limpieza. Por ejemplo, los datos de instrumentación que incluyen la misma información de correlación, como un identificador de actividad, se pueden agrupar. (Es posible que un usuario empiece a realizar una operación empresarial en un nodo y, a continuación, se transfiera a otro nodo en caso de error de nodo o en función de cómo se configure el equilibrio de carga). Este proceso también puede detectar y quitar los datos duplicados (siempre una posibilidad si el servicio de telemetría usa colas de mensajes para insertar datos de instrumentación en el almacenamiento). En la figura 5 se muestra un ejemplo de esta estructura.

Figura 5: Uso de un servicio independiente para consolidar y limpiar los datos de instrumentación.

Almacenamiento de datos de instrumentación

Las discusiones anteriores han mostrado una vista bastante simple de la forma en que se almacenan los datos de instrumentación. En realidad, puede tener sentido almacenar los diferentes tipos de información mediante el uso de tecnologías más adecuadas a la manera en que es probable que se use cada tipo.

Por ejemplo, Azure Blob y Table Storage tienen algunas similitudes en la forma en que se accede a ellos. Pero tienen limitaciones en las operaciones que puede realizar mediante su uso y la granularidad de los datos que contienen es bastante diferente. Si necesita realizar más operaciones analíticas o requerir funcionalidades de búsqueda de texto completo en los datos, puede ser más adecuado usar el almacenamiento de datos que proporciona funcionalidades optimizadas para tipos específicos de consultas y acceso a datos. Por ejemplo:

• Los datos del contador de rendimiento se pueden almacenar en una base de datos SQL para habilitar el análisis ad hoc.
• Es posible que los registros de seguimiento se almacenen mejor en Azure Cosmos DB.
• La información de seguridad se puede escribir en HDFS.
• La información que requiere búsqueda de texto completo se puede almacenar a través de Elasticsearch (que también puede acelerar las búsquedas mediante la indexación enriquecida).

Puede implementar un servicio adicional que recupere periódicamente los datos del almacenamiento compartido, las particiones y los filtra según su finalidad y, a continuación, lo escribe en un conjunto adecuado de almacenes de datos, como se muestra en la figura 6. Un enfoque alternativo consiste en incluir esta funcionalidad en el proceso de consolidación y limpieza y escribir los datos directamente en estos almacenes, ya que se recupera en lugar de guardarlos en un área de almacenamiento compartida intermedia. Cada enfoque tiene sus 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, y permite volver a generar al menos algunos de los datos con particiones si es necesario (dependiendo de la cantidad de datos que se conservan en el almacenamiento compartido). Sin embargo, consume recursos adicionales. Además, puede haber un retraso entre 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.

Figura 6: Creación de particiones de datos según los requisitos analíticos y de almacenamiento.

Los mismos datos de instrumentación pueden ser necesarios para más de un propósito. Por ejemplo, los contadores de rendimiento se pueden usar 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, se pueden enviar los mismos datos a más de un destino, como una base de datos de documentos que puede actuar como un almacén a largo plazo para mantener información de facturación y un almacén multidimensional para controlar análisis complejos de rendimiento.

También debe tener en cuenta la urgencia de los datos. Los datos que proporcionan información para las alertas deben accederse rápidamente, por lo que debe mantenerse en un almacenamiento de datos rápido e indexado o estructurado para optimizar las consultas que realiza el sistema de alertas. En algunos casos, puede ser necesario que el servicio de telemetría recopile los datos de cada nodo para dar formato a los datos y guardarlos localmente para que una instancia local del sistema de alertas pueda notificarle rápidamente cualquier problema. Los mismos datos se pueden enviar al servicio de escritura de almacenamiento que se muestra en los diagramas anteriores y almacenarlos de forma centralizada si también es necesario para otros fines.

La información que se usa para un análisis más considerado, para los informes y para detectar tendencias históricas es menos urgente y se puede almacenar de una manera que admita la minería de datos y las consultas ad hoc. Para obtener más información, consulte la sección Compatibilidad con el análisis frecuente, intermedio y en frío más adelante en este documento.

Rotación de registros y retención de datos

La instrumentación puede generar volúmenes considerables de datos. Estos datos se pueden almacenar en varios lugares, empezando por los archivos de registro sin procesar, los archivos de seguimiento y otra información capturada en cada nodo a la vista consolidada, limpiada y particionada de estos datos contenidos en el almacenamiento compartido. En algunos casos, después de procesar y transferir los datos, los datos de origen sin procesar originales se pueden quitar de cada nodo. En otros casos, puede ser necesario o simplemente útil para guardar la información sin procesar. Por ejemplo, los datos que se generan con fines de depuración podrían dejarse mejor disponibles en su formato sin procesar, pero se pueden descartar rápidamente después de que se hayan rectificado los errores.

Los datos de rendimiento suelen tener una vida útil más larga para que se pueda usar 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 finito para permitir el acceso rápido. Después, se puede archivar o descartar. Es posible que los datos recopilados para la medición y facturación de los clientes deban guardarse indefinidamente. Además, los requisitos normativos pueden dictar que la información recopilada para fines de auditoría y seguridad también debe archivarse y guardarse. Estos datos también son confidenciales y es posible que sea necesario cifrarlos o protegerlos de otro modo para evitar su manipulación. Nunca debe registrar las contraseñas de los usuarios u otra información que pueda usarse para confirmar el fraude de identidad. Estos detalles deben limpiarse de los datos antes de almacenarlos.

Muestreo hacia abajo

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

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 debe 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 autodescriptante como JSON, MessagePack o Protobuf en lugar de ETL/ETW. El uso de un formato estándar permite al sistema construir canalizaciones de procesamiento; Los componentes que leen, transforman y envían datos en el formato acordado se pueden integrar fácilmente.

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

• En caso de que se produzca un error transitorio al enviar 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 servicio de recopilación de datos o agente de supervisión podría optar por quitar los datos más antiguos o guardarlos localmente y transmitirlos más adelante para ponerse al día, a su discreción).

Análisis de datos y diagnóstico de problemas

Una parte importante del proceso de supervisión y diagnóstico es analizar los datos recopilados para obtener una imagen del bienestar general del sistema. Debe haber definido sus propios KPI y métricas de rendimiento, y es importante comprender cómo puede estructurar los datos que se han recopilado para satisfacer los requisitos de análisis. También es importante comprender cómo se correlacionan los datos capturados en diferentes métricas y archivos de registro, ya que esta información puede ser clave para realizar un seguimiento de una secuencia de eventos y ayudar a diagnosticar problemas que surgen.

Como se describe en la sección Consolidación de datos de instrumentación, los datos de cada parte del sistema normalmente se capturan localmente, pero por lo general es necesario combinarlos con los datos generados en otros sitios que participan en el sistema. Esta información requiere una correlación cuidadosa para asegurarse de que los datos se combinan con precisión. Por ejemplo, los datos de uso de una operación pueden abarcar un nodo que hospeda un sitio web al que se conecta un usuario, un nodo que ejecuta un servicio independiente al que se accede como parte de esta operación y el almacenamiento de datos que se mantiene en otro nodo. Esta información debe estar asociada para proporcionar una vista general del uso de recursos y procesamiento para la operación. Es posible que se produzcan algunos preprocesamientos y filtrados de datos en el nodo en el que se capturan los datos, mientras que es más probable que se produzcan agregaciones y formatos en un nodo central.

Compatibilidad con el análisis frecuente, cálido 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 son críticas para el tiempo y requieren que el análisis inmediato de los datos sea eficaz. Esto se conoce como análisis frecuente. Entre los ejemplos se incluyen los análisis necesarios para alertar y algunos aspectos de la supervisión de la seguridad (como detectar un ataque en el sistema). Los datos necesarios para estos fines deben estar disponibles y estructurados rápidamente para un procesamiento eficaz. En algunos casos, puede ser necesario mover el procesamiento de análisis a los nodos individuales donde se mantienen los datos.

Otras formas de análisis son menos críticas para el tiempo y pueden requerir algún cálculo y agregación una vez recibidos los datos sin procesar. Esto se denomina análisis intermedio. El análisis de rendimiento suele estar en esta categoría. En este caso, es poco probable que un evento de rendimiento único aislado sea estadísticamente significativo. (Puede deberse a un pico repentino o a un problema). Los datos de una serie de eventos deben proporcionar una imagen más confiable del rendimiento del sistema.

El análisis intermedio también se puede usar para ayudar a diagnosticar problemas de mantenimiento. Normalmente, un evento de mantenimiento se procesa a través del análisis activo y puede generar una alerta inmediatamente. Un operador debe poder profundizar en los motivos del evento de mantenimiento mediante el examen de los datos de la ruta de acceso activa. Estos datos deben contener información sobre los eventos que conducen al problema que provocó el evento de mantenimiento.

Algunos tipos de supervisión generan datos a largo plazo. Este análisis se puede realizar más adelante, posiblemente según una programación predefinida. En algunos casos, es posible que el análisis tenga que realizar un filtrado complejo de grandes volúmenes de datos capturados durante un período de tiempo. Esto se denomina análisis en frío. El requisito clave es que los datos se almacenan 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 en momentos regulares, pero esta información de estado no tiene que estar disponible para su procesamiento inmediatamente después de que se haya recopilado.

Un operador también puede usar análisis en frío para proporcionar los datos para el análisis predictivo de estado. El operador puede recopilar información histórica durante un período especificado y usarla junto con los datos de mantenimiento actuales (recuperados de la ruta de acceso activa) para detectar tendencias que podrían causar problemas de mantenimiento pronto. En estos casos, podría ser necesario generar una alerta para que se puedan realizar medidas correctivas.

Correlación de 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:

• ¿Qué ha causado una carga intensa de E/S en el nivel del sistema en un momento específico?
• ¿Es el resultado de un gran número de operaciones de base de datos?
• ¿Esto se refleja en 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 en el mismo momento?

Si es así, una acción correctiva que podría reducir la carga podría ser particionar los datos en más servidores. Además, pueden surgir excepciones como resultado de un error en cualquier nivel del sistema. Una excepción en un nivel suele desencadenar otro error en el nivel anterior.

Por estas razones, debe poder 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. A continuación, puede usar esta información para tomar decisiones sobre si el sistema funciona de forma aceptable o no, y determinar lo que se puede hacer para mejorar la calidad del sistema.

Como se describe en la sección Información para correlacionar datos, debe asegurarse 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. Además, estos datos pueden mantenerse en diferentes formatos y es posible que sea necesario analizar esta información para convertirlo en un formato estandarizado para el análisis.

Solución de problemas y diagnóstico de problemas

El diagnóstico requiere la capacidad de determinar la causa de errores o un comportamiento inesperado, incluida la realización de análisis de la causa principal. La información necesaria normalmente incluye:

• Información detallada de los registros de eventos y seguimientos, ya sea para todo el sistema o para un subsistema especificado durante un período de tiempo especificado.
• Complete los seguimientos de pila resultantes de excepciones y errores de cualquier nivel especificado que se produzca dentro del sistema o un subsistema especificado durante un período especificado.
• Volcados de memoria de los procesos con errores en cualquier lugar del sistema o para un subsistema especificado durante un período de tiempo especificado.
• Registros de actividad que registran las operaciones que realizan todos los usuarios o para los usuarios seleccionados durante un período especificado.

El análisis de datos con fines de solución de problemas a menudo requiere un profundo conocimiento técnico de la arquitectura del sistema y los distintos componentes que componen la solución. Como resultado, a menudo se requiere un gran grado de intervención manual para interpretar los datos, establecer la causa de los problemas y recomendar una estrategia adecuada para corregirlos. Puede ser adecuado simplemente 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.

Visualización de datos y generación de alertas

Un aspecto importante de cualquier sistema de supervisión es la capacidad de presentar los datos de forma que un operador pueda detectar rápidamente cualquier tendencia o problema. También es importante la capacidad de informar rápidamente a un operador si se ha producido un evento significativo que podría requerir 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 forma más común de visualizar datos es usar paneles que pueden mostrar información como una serie de gráficos, gráficos o alguna otra ilustración. Estos elementos se pueden parametrizar y un analista debe poder seleccionar los parámetros importantes (como el período de tiempo) para cualquier situación específica.

Los paneles se pueden organizar jerárquicamente. Los paneles de nivel superior pueden proporcionar una vista general de cada aspecto del sistema, pero permitir que un operador explore en profundidad los detalles. Por ejemplo, un panel que muestra la E/S de disco general del sistema debe permitir que un analista vea 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. Lo ideal es que el panel también muestre información relacionada, como el origen de cada solicitud (el usuario o la actividad) que genera esta E/S. Esta información se puede usar para determinar si (y cómo) distribuir la carga de forma más uniforme entre los dispositivos y si el sistema funcionaría mejor si se agregaran más dispositivos.

Un panel también puede usar codificación de colores o algunas otras indicaciones visuales para indicar valores que aparecen anómalos o que están fuera de un intervalo esperado. Con el ejemplo anterior:

• Un disco con una velocidad de E/S que se aproxima a su capacidad máxima durante un período prolongado (un disco activo) se puede resaltar en rojo.
• Un disco con una velocidad de E/S que se ejecuta periódicamente en su límite máximo durante períodos cortos (un disco intermedio) se puede resaltar en amarillo.
• Un disco que muestra el uso normal se puede mostrar en verde.

Para que un sistema de panel funcione de forma eficaz, debe tener los datos sin procesar con los que trabajar. Si va a crear 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 se debe formatear para que el panel los consuma.

Además de mostrar información, un buen panel también permite a un analista formular preguntas sobre esa información. Algunos sistemas proporcionan herramientas de administración que un operador puede usar para realizar estas tareas y explorar los datos subyacentes. Como alternativa, dependiendo del repositorio que se usa para contener esta información, puede ser posible consultar estos datos directamente o importarlos en herramientas como Microsoft Excel para realizar análisis e informes adicionales.

Generación de alertas

La alerta es el proceso de analizar los datos de supervisión e instrumentación y generar una notificación si se 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 haga garantías de rendimiento, disponibilidad y privacidad a los usuarios en los que es posible que los datos deban actuar inmediatamente. Es posible que un operador deba recibir una notificación del evento que desencadenó la alerta. Las alertas también se pueden usar para invocar funciones del sistema, como el escalado automático.

Las alertas suelen depender 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, el sistema podría estar bajo ataque y se debe informar a un operador.
• Métricas de rendimiento. El sistema debe responder rápidamente si una métrica de rendimiento determinada supera un umbral especificado.
• Información de disponibilidad. Si se detecta un error, es posible que sea necesario reiniciar rápidamente uno o varios subsistemas o conmutar por error a un recurso de copia de seguridad. Los errores repetidos en un subsistema pueden indicar problemas más graves.

Los operadores pueden recibir información de alerta mediante muchos canales de entrega, como correo electrónico, un dispositivo de 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 pueden recibir el mismo conjunto de alertas.

Un sistema de alertas debe ser personalizable y los valores adecuados de los datos de instrumentación subyacentes se pueden proporcionar como parámetros. Este enfoque permite a un operador filtrar los datos y centrarse en esos umbrales o combinaciones de valores que son de interés. En algunos casos, los datos de instrumentación sin procesar se pueden proporcionar al sistema de alertas. En otras situaciones, puede ser más adecuado proporcionar datos agregados. (Por ejemplo, se puede desencadenar una alerta si el uso de CPU de un nodo ha superado el 90 por ciento durante los últimos 10 minutos). Los detalles proporcionados al sistema de alertas también deben incluir cualquier información de resumen y contexto adecuada. Estos datos pueden ayudar a reducir la posibilidad de que los eventos falsos positivos activen una alerta.

Informes

Los informes se utilizan para generar una visión general del sistema. Puede incorporar datos históricos además de la información actual. Los propios requisitos de informes se dividen en dos categorías generales: informes operativos e informes de seguridad.

Los informes operativos suelen incluir los siguientes aspectos:

• Agregar estadísticas que puede utilizar para comprender la utilización de recursos del sistema general o de subsistemas específicos durante un período de tiempo específico.
• Identificar tendencias en el uso de recursos para el sistema general o subsistemas específicos durante un período específico.
• Supervisar las excepciones que se han producido en todo el sistema o en subsistemas especificados durante un período especificado.
• Determinar la eficacia de la aplicación en términos de los recursos implementados y comprender si el volumen de recursos (y su costo asociado) se puede reducir sin afectar innecesariamente al rendimiento.

Los informes de seguridad se refieren al seguimiento del uso del sistema por parte de los clientes. Puede incluir:

• Auditoría de operaciones de usuario. Esto requiere registrar las solicitudes individuales que realiza cada usuario, junto con fechas y horas. Los datos deben estructurarse para permitir que un administrador reconstruya rápidamente la secuencia de operaciones que realiza un usuario durante un período especificado.
• Seguimiento del uso de recursos por parte del usuario. Esto 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 debe poder usar estos datos para generar un informe de uso por parte del 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. (La latencia no suele ser un problema). Pero también deben estar disponibles para la generación ad hoc si es 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.

Pasos siguientes

• información general de Azure Monitor
• Supervisión, diagnóstico y solución de problemas de Microsoft Azure Storage
• Introducción a las alertas en Microsoft Azure
• Visualización de notificaciones de mantenimiento del servicio mediante Azure Portal
• ¿Qué es Application Insights?
• Diagnóstico de rendimiento para máquinas virtuales de Azure
• Descargar e instalar SQL Server Data Tools (SSDT) para Visual Studio

Recursos relacionados

• La guía de escalado automático describe cómo reducir la sobrecarga de administración al reducir la necesidad de que un operador supervise continuamente el rendimiento de un sistema y tome decisiones sobre cómo agregar o quitar recursos.
• El patrón de supervisión de puntos de conexión de mantenimiento describe cómo implementar comprobaciones funcionales dentro de una aplicación a la que las herramientas externas pueden acceder a través de puntos de conexión expuestos a intervalos regulares.
• El patrón priority Queue muestra cómo priorizar los mensajes en cola para que se reciban solicitudes urgentes y se puedan procesar antes de mensajes menos urgentes.