Contenido


Monitoreo Más Inteligente: Un enfoque de monitoreo continúa del rendimiento

No se trata de la tecnología que se usa, ¡se trata de cómo uno la utiliza!

Comments

Las arquitecturas orientadas a servicios y basadas en la nube se construyen reutilizando los servicios ya existentes. Lo que solía ser una aplicación monolítica, fácilmente controlada y monitorizada posiblemente en un único servidor, ahora es un conglomerado de servidores y servicios externos que no son fáciles de monitorizar. Cada sistema o servicio puede tener sus propios archivos de registro, posiblemente en varios servidores, en formatos diferentes. Cuando hay que buscar en tantos archivos, es difícil identificar los registros para un cliente que ha informado de un error. Debería ser habitual recopilar los registros en una infraestructura de registros común y centralizada, para permitir acceder rápidamente a todos los registros relevantes. Utilizar un ID de correlación para realizar el seguimiento por el sistema de solicitudes únicas es una técnica disponible, aunque no es común. Sin embargo, los ID de correlación ayudan enormemente al analizar las condiciones de los errores y los problemas de rendimiento.

En el enfoque de Smarter Monitoring, hemos añadido más aspectos que nos han ayudado a analizar y atender los problemas de rendimiento:

  • Contextualizar los IDs de correlación
  • Medidas parametrizadas para el rendimiento
  • Medidas de asignación de recursos
  • Monitorización "Siempre activa", en todos los despliegues y en todos los entornos
  • Un rol de ingeniería del rendimiento que retroalimenta al desarrollo con las mejoras

Las secciones siguientes describen el enfoque general de Smarter Monitoring. También se describe un enfoque de implementación que utiliza una arquitectura "clásica" (una aplicación JEE con una base de datos relacional, por ejemplo), que procesa hasta 500 millones de entradas de registros por día.

El enfoque de Smarter Monitoring

El enfoque de Smarter Monitoring está formado por aspectos técnicos y operativos. Como utilidades básicas, todos los registros se recopilan en una base de datos o en un almacén de datos. Añadir un ID de correlación en cada registro permite correlacionar las entradas del registro para cada solicitud. Los registros parametrizados con sus registros de cronómetro brindan información relevante del rendimiento. En los procesos operativos, un ingeniero de rendimiento utiliza estas características para medir múltiples características del rendimiento. Después, los conocimientos se introducen en el desarrollo.

Base: Recopilar todos los registros

Las aplicaciones actuales deberían recopilar todos los registros en una infraestructura de registro común y central. Una aplicación que obliga a tu equipo de operaciones a buscar manualmente archivos de registro, está obsoleta y malgasta los esfuerzos de tu equipo.

Una solución moderna le permite buscar en los registros sin tener que copiar los archivos de (posiblemente varios) servidores y de varios centros de computación, es posible que incluso a través de unidades de red, para que el equipo de soporte pueda acceder a ellos. En vez de eso, la interfaz de usuario le permite consultar y filtrar los registros según sus necesidades, para poder acceder rápidamente a la información del registro.

ID de correlación contextualizado

Acceder a los registros es un aspecto, pero encontrar la información adecuada es incluso más importante. Un ID de correlación que permite realizar el seguimiento de todas y cada una de las solicitudes del sistema es el primer paso. El ID de correlación normalmente se crea en el cliente o en el servidor. Después se pone en todas las declaraciones procedentes del registro. Pasar el ID de correlación a los otros servicios también permite correlacionar los registros de esos servicios con la solicitud.

Un ID de correlación solo es el primer paso. Poner el ID — y la solicitud — el contexto ayuda a un enfoque de creación de registros más inteligente. La información del contexto puede ser:

  • Utilice el número del caso, el servicio, el nombre de la operación o la capa por la que la solicitud entra en el sistema
  • Canal por el que la solicitud entrará en el sistema, cuando sea relevante, por ejemplo, Lote, EJB, o una llamada de Web
  • ID de usuario para la solicitud
  • Inquilino, cuando corresponda

No se pueden cambiar algunas partes del contexto, pero otras partes se puede, dependiendo de sus requisitos. Por ejemplo, un inquilino no se puede cambiar en un sistema, pero si su sistema está configurado para que los inquilinos puedan comunicarse unos con otros, una solicitud puede cambiar el contexto de su inquilino.

Realizar el seguimiento a través del sistema y de los servicios con el ID de correlación ya habilita el análisis cualitativo de las rutas de ejecución de una solicitud. Ver las declaraciones de registro para una solicitud única puede abrir los ojos, especialmente cuando encuentra bucles con muchas iteraciones en operaciones costosas donde no las esperaba. Normalmente se encontrará con que las constelaciones de datos del sistema productivo no son lo usted espera, Lo que causa solicitudes duraderas y, por lo tanto, problemas de rendimiento. La información del contexto de los IDs de correlación se vuelven incluso más importantes cuando se utilizan con medidas del rendimiento, según se describe a continuación.

Medidas parametrizadas para el rendimiento

Normalmente se utilizan registros para escribir información acerca de lo que está ocurriendo en el sistema y en determinados momentos. La mayor parte del tiempo, esto se realiza con declaraciones del registro manualmente codificadas. Nuestro enfoque añade registros de cronómetro, que son declaraciones de registros generadas automáticamente y que describen cuando las solicitudes entran en una sección específica del código y cuánto tiempo se tardó en ejecutar esta sección. A este respecto, “generadas automáticamente” significa que los registros de cronómetro se escriben en aspectos que se indican en el propio código. Esto, por ejemplo, se puede llevar a cabo en interceptadores de las llamadas EJB, y el programador ni siquiera tiene que pensar en esto.

Además de los registros básicos de cronómetro, es posible añadir parámetros a la entrada del registro. Esto permite, por ejemplo, correlacionar el tiempo de ejecución con el número de elementos procesados con una solicitud. El resultado es el análisis del comportamiento desalado del sistema.

Al combinar los registros del cronómetro con el contexto añadido se crea una poderosa herramienta de análisis de los problemas de rendimiento. Esto también es útil a la hora de analizar los problemas funcionales.

Estadística del rendimiento

Los registros de cronómetro se escriben constantemente. Debido a esto, puede generar estadísticas para cada punto de medida. Las estadísticas resultantes incluyen:

  • Medias
  • Derivación
  • Valores del máximo y mínimo a lo largo del tiempo

Es posible analizar la eficiencia de un algoritmo cuando se utiliza el análisis de percentiles. Por ejemplo: en nuestra aplicación, tenemos un gran número de trabajos por lotes, que se ejecutan todas las noches en paralelo para importar documentos. La imagen 1 muestra la medición del tiempo de ejecución de estos trabajos por lotes (según se ejecutan en el trasfondo, el tiempo de ejecución se puede medir en minutos). El máximo tiene un límite drástico en cinco minutos. Esto significa que los trabajos por lotes se han ejecutado dentro del límite del tiempo de espera de la transacción y que se deben reajustar.

Image shows performance analysis
Image shows performance analysis

El análisis de percentiles puede ayudar a identificar valores atípicos, en el que todos los percentiles esencialmente son una línea plana con picos para el valor máximo. Estos valores atípicos a menudo muestran que han sido causados por contratiempos en la infraestructura, con frecuencia relacionados con grandes operaciones de escritura (BLOBs, por ejemplo) en la base de datos o al acceder al subsistema de almacenamiento. Esto puede ser un indicador de que el subsistema de almacenamiento no está brindando el nivel de servicios necesarios según lo acordado (en caso de que exista un acuerdo).

Si se retienen los valores agregados, es posible ejecutar el análisis estadístico en mayores escalas de tiempo, como se muestra en la figura siguiente, que muestra el tiempo medio de ejecución de tres funciones durante los tres años de producción. Para comenzar con algunas mejoras del rendimiento, vemos algunos avances en la curva roja durante las liberaciones de agosto y diciembre de 2013, hasta que, finalmente, el enfoque de optimización funciona en las liberaciones de julio y agosto de 2014. Al mismo tiempo, tuvimos que optimizar la función que está detrás de la curva azul. Los valores atípicos indican otros problemas, normalmente relacionados con la infraestructura.

Image shows mean execution time values over the years
Image shows mean execution time values over the years

Medir el comportamiento de la escalación

A menudo es una sorpresa ver lo que las personas hacen con un sistema después de haberlo desplegado. Los usuarios finales a menudo no entienden completamente el tipo y el tamaño de las constelaciones de datos (número de artículos en un carro de compra o el número de documentos en una carpeta de casos de un DMS, por ejemplo). Es posible medir el comportamiento de un sistema cuando escala (cómo se comporta un sistema bajo dichos cambios de las constelaciones de datos), cuando en la gestión del rendimiento se utilizan parámetros adicionales. Esto permite, por un lado, identificar por qué algunas solicitudes tardan más tiempo que otras y también permite predecir, hasta cierto grado, el comportamiento anticipado del sistema para tamaños de datos mayores.

La imagen 3 muestra un análisis de un sistema en vivo. El diagrama de arriba a la izquierda muestra los tiempos de ejecución en bruto que se extraen del parámetro. En este caso, este es el número de documentos procesados que esta específica interacción. Arriba a la derecha se muestran los mismos datos, pero cada tiempo de ejecución se divide entre el número de documentos procesados. Lo que esto muestra es un intervalo de tiempo constante y una parte que se incrementa de forma lineal con el número de documentos procesados. Esto le permite predecir cuánto puede durar la interacción con conjuntos de datos mayores.

El diagrama inferior muestra los mismos datos que el diagrama superior, pero se despliegan a lo largo del día. Esto permite correlacionar los tiempos de ejecución con otras situaciones de carga. Observe que hay dos tipos de interacciones (muy probablemente dependen de algunos requisitos funcionales) y cada uno de ellos tarda diferente cantidad de tiempo. Un tipo parece ser capaz de ejecutarse a 500 ms por documento; el otro parece tardar al menos 800 ms.

Image shows measuring scaling behavior with parameterized logs
Image shows measuring scaling behavior with parameterized logs

Medidas de asignación de recursos

No sólo es tener un momento en el tiempo en el que ocurre la solicitud, sino que su duración concreta permite medidas detalladas para la asignación de recursos. Es posible solapar la duración de todas las solicitudes en ejecución en un momento del tiempo y determinar cuántas solicitudes hay en su sistema. A menudo no está claro cuántos usuarios están en el sistema. Las estimaciones se realizan durante la ingeniería de los requisitos, pero al final, esto es difícil de predecir. El diseño cambia cuando en el desarrollo cambia el número de llamadas al servidor por cada interacción, y así sucesivamente. El enfoque de Smarter Monitoring le permite medir fácilmente el grado de paralelismo.

La imagen 4 muestra un ejemplo de esto en una infraestructura de lotes (los números 56, 57-60 son indicadores de los tipos de lotes). El problema era que la infraestructura de lotes se podía configurar según un grado de paralelismo. Sólo con las medidas de Smarter Monitoring fuimos capaces de ver si logramos ese grado de paralelismo. De hecho, identificamos problemas de configuración en el servidor de aplicaciones, que evitaban que el sistema lograse el grado de paralelismo que estaba configurado. En otro caso, era una configuración para los hilos por cada aplicación JEE, y el otro, era un ajuste para el balanceado de la carga de trabajo del servidor de aplicaciones.

Image shows degree of parallelism
Image shows degree of parallelism

Los otros tipos de análisis incluyen:

  • Análisis de tiempo de vuelo — ¿Cuánto se tarda en recibir un mensaje en un sistema asíncrono, y si hay signos de inanición de recursos, como tiempos de espera no previstos?
  • Análisis de las cargas de trabajo — ¿Están las cargas de trabajo distribuidas equitativamente entre sus servidores (o al menos la manera en la que los diseño)?
  • Análisis de latencia de la red — Si tiene registros de cronograma cuando la solicitud sale de un sistema y otro registro del cronograma cuando la misma solicitud (ID de correlación) entra en el otro sistema, puede medir la latencia de la red entre los sistemas.

Ingeniería del rendimiento siempre interactivo

Las herramientas del análisis del rendimiento a menudo están separadas de la aplicación. Esto significa que en el caso de un problema de rendimiento, la herramienta se tiene que configurar posiblemente en un entorno de pruebas, diferente del ambiente de producción. Después se tiene que recrear el problema, lo que a menudo no se consigue.

Un aspecto importante de la solución Smarter Monitoring es que siempre está activa. Es una parte está integrada en el sistema. Incluso en nuestro entorno de desarrollo, un desarrollador puede habilitar el servidor de registro que recopila las declaraciones del registro. Esto ocurre porque cada despliegue contiene la infraestructura de registro y de supervisión. Una solución funcional de Smarter Monitoring es una puerta de calidad para el despliegue. Es posible analizar los registros de cada despliegue en todos los entornos.

Un aspecto importante de Smarter Monitoring es que no existe la necesidad de separar actividades para permitirle recrear y analizar los problemas. Cada despliegue enseña al equipo de despliegue a hacer los pasos necesarios, así se pueden evitar los errores de despliegues y los despliegues con averías.

En nuestro proyecto, los tipos de despliegue pruebas utilizan el enfoque de Smarter Monitoring para analizar los problemas de rendimiento y funcionales. Es una herramienta inestimable para el proceso de gestión de la calidad.

Rol del arquitecto de rendimiento

Smarter Monitoring es una herramienta inestimable porque está "siempre activa". El esfuerzo de análisis de problemas se ha reducido de forma dramática.

Debido a que la solución está disponible en todos los entornos, se pueden utilizar para investigar fácilmente los problemas en todas las etapas del desarrollo. El arquitecto del rendimiento es un rol del proyecto que hemos creado para investigar los problemas de rendimiento. El arquitecto del rendimiento no sólo observa los problemas del rendimiento de producción, sino que también lo hace en los test de carga, y apoya y aconseja a los equipos de desarrollo acerca de la optimización del rendimiento. Es obligatorio que el arquitecto del rendimiento se implique en el proyecto o en las solicitudes de cambio antes de comenzar el diseño y el desarrollo. Gracias a esta implicación temprana, pueden identificar cambios críticos para el rendimiento o utilizar casos de la información recopilada de los registros parametrizados para el rendimiento. De esta manera, los riesgos se identifican anticipadamente y se mitigan de una forma rápida y eficiente.

Consideraciones de la implementación

La implementación de una solución Smarter Monitoring se puede basar en diferentes tipos de tecnología. De hecho, la solución es indiferente a la tecnología. Sin embargo, hay consideraciones que son necesarias en todas las implementaciones.

Implicaciones del tamaño de los datos

Almacenar la cantidad de registros producidos por una solución Smarter Monitoring puede ser un desafío. En nuestra actual implementación, escribimos hasta 500 millones de entradas de registros de rendimiento cada día, con una productividad a un mayor en momentos de pico. Existen algunos requisitos:

  • El subsistema de almacenamiento debe ser capaz de escribir la cantidad de datos en el periodo de tiempo necesario.
  • La base de datos de registros o el almacenamiento — relacional o NoSQL — debe ser capaz de gestionar esta cantidad de datos.
  • El sistema de almacenamiento debe ser capaz de almacenar la cantidad de datos.
  • Los datos antiguos se deben agregar en el momento, y ser borrados cuando es necesario.

Creación asíncrona de registros

La escritura de los archivos de registro en una infraestructura de registros estándar a menudo se ejecuta de forma sincrónica. La escritura sincrónica de registros hace que la aplicación sea susceptible a problemas de rendimiento en la infraestructura de registro y de supervisión.

Así que en vez de escribir los registros de forma sincrónica, las entradas de los registros se deberán recolectar en lotes y ser escritas de forma asíncrona. Para mitigar los problemas de la propia infraestructura de registro se pueden desechar las entradas de los registros menos importantes, para garantizar que la propia aplicación no se ralentice.

En nuestra aplicación, las entradas de registros se entregan a un agregador de registros (según la terminología log4) específico, que los recopila en un lote de entradas de registros, y luego los transfiere de forma asíncrona a un almacenamiento de registros con una única solicitud. El agregador guarda en la memoria interna una determinada cantidad de registros. Después, cuando observa que el número de registros aumenta por encima de los que se pueden escribir en la base de datos, los reduce y añade un registro específico de mensaje de aviso. De esta manera, se puede investigar la situación, pero el propio sistema de producción no se ve ralentizado.

Un aviso de precaución

Cuando comenzamos a trabajar por los registros de cronómetro, estamos emocionados sobre lo que podíamos aprender y medir acerca del sistema. Así que añadimos muchos registros de cronómetro. Añadimos tantos que el registro comenzó a sobrecargar nuestra infraestructura de registros y a ralentizar la aplicación. Así aprendimos a limitar las entradas del cronómetro (principalmente) al cruce de las demarcaciones de los componentes. Esto asegura que se puede identificar el componente responsable por un problema de rendimiento. Los registros de cronómetro esenciales son aquellos en los que una solicitud entra o sale del sistema. Aun así, los registros de cronómetro utilizan aproximadamente 10 veces el espacio que utilizan los registros habituales que todavía existen.

Examinar demasiado a fondo para entender el sistema es algo tentador, incluso si no hay un problema. Asegúrese de concentrarse en los problemas reales. Por ejemplo, el sistema del que llegan esas imágenes, hay una única interacción que no es lineal, pero va siendo exponencialmente más lenta con los conjuntos de datos mayores. Sin embargo, la propia interacción es rápida (hasta 100 ms), y el tamaño del conjunto de datos se estima que es limitado. Con lo tentador que puede ser investigar y corregir el algoritmo, por ahora, el esfuerzo no merece la pena.

Estudio de caso — Un proyecto DMS grande

Este estudio de caso muestra el enfoque de la implementación elegida.

Un cliente grande del sector público de Alemania implementó la solución Smarter Monitoring en un proyecto de un sistema de gestión electrónica de documentos (DMS). La solución ayudó a lograr y a mantener los requisitos de rendimiento, incluso durante las mejoras de rendimiento necesarias para la importación de los documentos. debido a requisitos nuevos, el número de documentos que se tenían que importar cada noche se tuvo que incrementar más de cinco veces. El análisis del sistema con Smarter Monitoring ayudó a lograr este objetivo.

Para permitir el análisis y la retroalimentación inmediata para cualquier problema de rendimiento — y a menudo incluso los otros funcionales— , era importante que la infraestructura de Smarter Monitoring formase parte del proyecto estándar y estuviese disponible a través de todos los entornos.

La solución

La siguiente imagen muestra la solución original.

Image shows Smarter Monitoring overview
Image shows Smarter Monitoring overview

Cada interacción del usuario con el sistema crea un ID de correlación único que se pasa con la solicitud a través del sistema. Los registros del cliente, más de 100 seguidores de motores de aplicaciones y los servidores back-end locales, se recopilan en una base de datos relacional. El cliente basado en Java sólo sube su registro al servidor cuando el usuario acepta voluntariamente los términos y condiciones de privacidad. Los registros del servidor se escriben a través de un servidor de registros log4j, el cual después los escribe de forma asíncrona en una base de datos relacional.

Las métricas recopiladas a través de un cliente JMX amplían los datos de rendimiento con información acerca de la salud de la infraestructura. Después, una interfaz de usuario de supervisión permite hacer consultas y analizar los datos del rendimiento. Cada entrada del registro contiene información de la infraestructura, como el nombre del servidor de origen o el nombre del registrador. La entrada del registro también contiene información sobre el contexto, que incluye al inquilino, el origen de la solicitud y el ID del usuario.

La interfaz de usuario permite exportar los registros una vez filtrados — por el ID de correlación, por ejemplo, para que el equipo de operaciones pueda dar los registros filtrados específicamente al equipo de desarrollo para que los analicen e investiguen más. Con este enfoque, podemos registrar, en la base de datos de registro, aproximadamente 70 GB de datos en hasta 500 millones de entradas de registro diarias.

Algunas decisiones arquitectónicas que podemos revisar en las próximas aplicaciones Smarter Monitoring incluyen:

  • Utilizar servidores de registro que disocien la aplicación de la propia escritura de los registros. Quizás el agregador se puede integrar directamente en la infraestructura de registro del servidor de aplicaciones.
  • Utilizar agregadores JDBC en los servidores de los registros. En un entorno en la nube, puede que sea más práctico utilizar un cargador HTTPS.
  • Se utilizó una base de datos relacional estándar por el conjunto de habilidades y herramientas disponibles. En ese momento no estaban disponibles ni una base de datos NoSQL ni una base de datos en la memoria.

Las decisiones de tecnología se deben de tomar cuidadosamente porque la infraestructura puede variar enormemente dependiendo del conjunto de herramientas utilizadas. Mientras nosotros tenemos una única base de datos grande, otra solución NoSQL presentada en "¿Cómo se escala una infraestructura de registro para aceptar 1000 millones de mensajes por día?" necesita un gran número de seguidores sólo para supervisar únicamente el doble de registros que los de nuestra solución.

Conclusión

El enfoque de Smarter Monitoring es un enfoque de supervisión del rendimiento que es independiente de la tecnología utilizada. Combina muchas funciones de una única manera:

  • Un ID de correlación realizar seguimiento de las solicitudes a través del sistema, incluyendo los microservicios.
  • Los registros de varios servicios se recopilan y agregan en una base de datos de registros central.
  • Los registros de rendimiento parametrizados y sensibles al contexto permiten analizar e investigar detalladamente el rendimiento del comportamiento de escalación.
  • Las medidas de paralelización permiten realizar el seguimiento de la utilización de recursos.
  • Permite medidas totales del rendimiento desde el inicio, en pruebas y en producción.
  • Un rol de ingeniería del rendimiento proporciona conocimientos al equipo de desarrollo.

Nuestra primera implementación utiliza un entorno JEE con bases de datos relacionales sobre un entorno distribuido con arquitectura Intel, pero es posible implementarlo en otros entornos, como System p® o System z®.

Mediante la utilización de este enfoque combinado, los proyectos satisfacen continuamente sus requisitos de escalabilidad y rendimiento, lo que es esencial para los ciclos de desarrollo más rápidos actuales.


Recursos para Descargar


Temas relacionados


Comentarios

Inicie Sesión o Regístrese para agregar comentarios.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Cloud computing
ArticleID=1039459
ArticleTitle=Monitoreo Más Inteligente: Un enfoque de monitoreo continúa del rendimiento
publish-date=11042016