ES2427645A2 - Método para gestionar el rendimiento en aplicaciones de múltiples capas implantadas en una infraestructura de tecnología de información - Google Patents

Abstract

Método para gestionar el rendimiento en aplicaciones de múltiples capas implantadas en una infraestructura de tecnología de información. En el método de la invención, dichas aplicaciones de múltiples capas proporcionan servicios a un usuario y tienen recursos asignados en dicha infraestructura de TI y la gestión al menos comprende detectar la degradación del rendimiento y proporcionar acciones correctivas por medio de enfoques estadísticos o modelos analíticos. El método de la invención comprende usar una combinación de dichos enfoques estadísticos y dichos modelos analíticos teniendo en cuenta los datos de monitorización procedentes de dicha infraestructura de TI con el fin de asignar dichos recursos con elasticidad y con el fin de proporcionar, cuando se detecta una anomalía o anomalías, dichas acciones correctivas procesando dichos datos de monitorización, comprendiendo dicho procesamiento operaciones estadísticas, predicciones, reconocimientos y/o correlaciones de patrón. El sistema está dispuesto para implementar el método del primer aspecto.

Description

MÉTODO PARA GESTIONAR EL RENDIMIENTO EN APLICACIONES DE MÚLTIPLES CAPAS IMPLANTADAS EN UNA INFRAESTRUCTURA DE TECNOLOGÍA DE INFORMACIÓN

Campo de la técnica

La presente invención se refiere en general, en un primer aspecto, a un método para gestionar el rendimiento en aplicaciones de múltiples capas implantadas en una infraestructura de tecnología de información, proporcionando dichas aplicaciones de múltiples capas servicios a un usuario y teniendo recursos asignados en dicha infraestructura de TI, comprendiendo dicha gestión al menos detectar la degradación del rendimiento y proporcionar acciones correctivas por medio de enfoques estadísticos o modelos analíticos y más particularmente a un método que comprende usar una combinación de dichos enfoques estadísticos y dichos modelos analíticos teniendo en cuenta los datos de monitorización procedentes de dicha infraestructura de TI con el fin de asignar dichos recursos con elasticidad y con el fin de proporcionar,
cuando se detecta una anomalía o anomalías, dichas acciones correctivas procesando dichos datos de monitorización, comprendiendo dicho procesamiento operaciones estadísticas, predicciones, reconocimientos y/o correlaciones de patrón.

Un segundo aspecto de la invención se refiere a un sistema dispuesto para implementar el método del primer aspecto.

Estado de la técnica anterior

Los enfoques de informática en la nube [1] permiten ajustar los recursos asignados a los clientes (normalmente, potencia de cálculo, almacenamiento y red) a la demanda de utilización actual de sus servicios. La elasticidad automática (considerada una de las “aplicaciones clave” de la informática en la nube) consiste en añadir o sustraer automáticamente los recursos mencionados anteriormente a o de los servicios implantados en la nube sin ninguna intervención humana basándose en la demanda [2].

Por ejemplo, una empresa dada desarrolla un servicio de compras en línea nuevo. Cuando se lanza en primer lugar, la empresa puede tener una estimación de los recursos necesarios pero el uso real puede variar en el tiempo (por ejemplo, durante las primeras semanas sólo unos pocos usuarios pueden usarlo, y después empieza a aumentar de una manera lineal) e incluso el uso puede cambiar dependiendo de las horas del día (por ejemplo, la hora pico puede ser de 6 a 10 p.m.

mientras que de 2 a 6 a.m. apenas se usa) o los días de la semana (por ejemplo, puede usarse más durante la semana de trabajo que los fines de semana). Puesto que a priori es difícil estimar de manera precisa la demanda real de recursos en un momento dado, el ajuste a escala automático es una de las características más

5  importantes que un servicio en la nube debería proporcionar. Esta característica de adaptación de un conjunto de recursos a las necesidades basándose en la carga se conoce como elasticidad.

Poder adaptar los recursos de aplicación a la demanda es una característica muy importante, aunque esto no garantiza un comportamiento correcto. En algunos 10 casos, las aplicaciones empiezan a tener un mal funcionamiento, aunque esto no se debe a ningún aumento en la demanda, sino que se produce por algunas cuestiones internas como por ejemplo un disco duro que está casi lleno debido a una gran cantidad de archivos de registro, o un número muy alto de conexiones bloqueadas en un sistema de base de datos. La capacidad de detectar un comportamiento deficiente 15 de un sistema (debido a problemas internos) y corregirlos sin proporcionar más recursos pero mejorando el rendimiento se conoce como autorregeneración. En general, el resultado de aplicar una medida de elasticidad para un problema de autorregeneración no mejora el comportamiento final de la aplicación. Algunos productos, como SQL Anywhere, ofrecen algunas herramientas que permiten realizar

20 procedimientos de autorregeneración interna [17]. Los sistemas operativos a menudo proporcionan funciones para configurar acciones que realizan algunos tipos de procedimientos de autorregeneración a nivel máquina. A este nivel, las aplicaciones de múltiples capas son particularmente importantes. Las aplicaciones de múltiples capas son un tipo especial de aplicaciones

25  que dividen las funcionalidades en N capas separadas (N capas) [3]. El paradigma de N capas es muy común en aplicaciones basadas en Internet. Desde un punto de vista de implantación, una aplicación de múltiples capas puede implantarse en diferentes máquinas siguiendo diversas opciones: varias capas en una única máquina, varias máquinas para una capa particular, etc.

30 Desde un punto de vista de informática en la nube, las aplicaciones de múltiples capas son especialmente importantes, puesto que su comportamiento se basa en el funcionamiento apropiado de todas las capas; y el comportamiento de cada una de las capas también depende del modo en el que se comportan las diferentes máquinas que las soportan. Un problema complejo de un sistema de regeneración de

35  aplicaciones es identificar la razón de una QoS deficiente en estas aplicaciones de múltiples capas. La causa puede ser una asignación de recursos en la nube no adecuada para hacer frente a las necesidades de aplicación (elasticidad) o cualquiera de los demás problemas registrados de la forma interna en la que se realizan algunas acciones (autorregeneración).

5 Para detectar o bien la falta de recursos o bien un funcionamiento interno inapropiado de los elementos, pueden aplicarse diferentes clases de mecanismos: algunos de ellos se basan en enfoques estadísticos (por ejemplo, una red neuronal que detecta la necesidad de ajustar a escala una capa de aplicación particular basándose en medidas de monitorización específicas), mientras que otras se basan en

10  un conjunto de procedimientos analíticos (por ejemplo, cuando un parámetro de monitorización dado alcanza un umbral implica un problema de autorregeneración particular). Además, los enfoques estadísticos pueden incluso predecir la capacidad o problema de regeneración antes de que ocurra. Para este fin, pueden definirse modelos para detectar los problemas de ajustabilidad a escala y regeneración para

15  aplicaciones de múltiples capas en entornos de informática en la nube, modelos o bien analíticos o bien empíricos. Los modelos analíticos (también denominados modelos Ab initio, primer principio) se basan estrictamente en consideraciones de primer nivel de cada uno de los componentes individuales del sistema. Ejemplos de estos modelos son las ecuaciones diferenciales, modelos de colas, redes de Petri o árboles de

20 decisión. Éstos proporcionan salidas válidas sin entrenamiento. Por otro lado, los modelos empíricos (estadísticos) tienden a capturar el comportamiento real de cualquier sistema, basándose en un historial y experimentación anterior, e incluyendo lo que no es ideal que ignoren los modelos analíticos. En la actualidad, la mayoría de los sistemas de informática en la nube ofrecen

25  herramientas que puede analizar el comportamiento de un recurso de informática en la nube particular (CPU, disco duro, etc.). Sin embargo, las soluciones comerciales no proporcionan algoritmos de regeneración general a nivel de aplicación. El estado de la técnica a nivel de investigación ha producido modelos analíticos para que las aplicaciones de múltiples capas [3] detecten cuellos de botella en una capa específica

30  de una aplicación multicapa. Sin embargo, se pretende que estos estudios modelen el comportamiento de aplicaciones en diferentes condiciones de carga; no se considera el efecto producido por la degradación del rendimiento del sistema no provocado por cargas adicionales. Esta insuficiencia en el modelo puede provocar el aumento de la ajustabilidad a escala de una aplicación particular sin aumentar el rendimiento o,

35  incluso peor, disminuirlo.

Los enfoques de autorregeneración actuales previamente descritos tienen dos problemas. En primer lugar, carecen de generalidad ya que los mecanismos de autorregeneración están sumamente unidos a un componente particular (base de datos, sistema operativo, etc.) y no se centran en el algoritmo general para aplicar las

5  acciones. En segundo lugar, no se proporciona un mecanismo holístico a nivel de aplicación para definir las acciones de autorregeneración que deben realizarse.

Además, las propuestas existentes consideran el uso de modelos para detectar problemas de ajustabilidad a escala y regeneración, pero a menudo se limitan al uso de modelos o bien analíticos o bien empíricos, presentando cada uno de ellos algunos

10  inconvenientes. En particular, en modelos analíticos se ignoran las suposiciones empíricas, provocando que el modelo sea incompleto, y las salidas pueden ser imprecisas. Esto es peor cuanto más complejo sea el sistema de modelar, haciéndolo a menudo inadecuado para actuar en un entorno de nube. Con respecto a los modelos empíricos, su inconveniente es la necesidad de entrenamiento para el entorno exacto

15 en el que deben implantarse; esto a menudo significa que deben realizarse varios experimentos particulares en el sistema, que a su vez significa que la operación normal se ve afectada, y no son completamente funcionales durante este periodo inicial. Existen varios intentos de combinar ambos tipos de modelos para compensar

20  sus inconvenientes, aunque se centran principalmente en moldear una red neuronal para proporcionar realimentación a un modelo ab initio (analítico) de modo que algunos de sus parámetros de modelado se adaptan capturando la variabilidad del mundo real [14, 15]. No obstante, el modelo predominante es el único no empírico, así que se verá afectado por sus limitaciones inherentes, principalmente el hecho de ser

25 incompleto e impreciso. Durante la redacción del presente documento se analizaron varias patentes como antecedentes técnicos proporcionados por el departamento de patentes TID. En el documento [US 2005/0131993] se describe una solución para un control autonómico de un sistema de rejilla. Sin embargo, esta invención se aplica a sistemas

30  de rejilla, no a sistemas en la nube; además, la invención se basa en aplicar un conjunto de acciones a desencadenadores específicos sin la capacidad de combinar modelos estadísticos y analíticos.

La invención en el documento [US 2009/0300625] presenta un método en el que las aplicaciones hacen uso de “componentes de procesamiento conectables” para 35 ejecutar; el uso de estos recursos se monitoriza y la aplicación se adapta dependiendo

de la monitorización. El uso principal de este sistema va en la dirección del cálculo paralelo. Sin embargo, no considera la combinación de información analítica y estadística, o acciones de autorregeneración/ajuste a escala.

La invención en el documento [US 2006/0069621] describe un sistema para

5  asignar recursos en los sistemas de rejilla. Sin embargo, estas asignaciones se basan en crear un catálogo de soluciones en el que los proveedores y consumidores de recursos tratan de conseguir los recursos disponibles. Esta invención no hace referencia a ninguno de los desafíos principales de la presente invención.

La invención en el documento [US 2007/0288626] describe un sistema que

10 optimiza la monitorización de sistemas de cálculo de rejilla aplicando filtros Kalman en los diferentes nodos de monitorización, que no están en el alcance del trabajo presentado en nuestra invención. La invención en el documento [US 2008/0320482] describe un método para planificar tareas usando un modelo de tarea, modelo de recursos, modelo financiero y

15  SLA, en el que se realizan algunas acciones reparadoras cuando no se cumple el SLA para las tareas. Sin embargo este método proporciona una solución para maximizar el uso de recursos entre aplicaciones competidoras aunque la presente invención intenta cubrir las necesidades de la aplicación optimizando los recursos asignados a la misma.

20 La invención en el documento [US 2008/0208778 A1] describe un método para la optimización de un proceso no lineal industrial típico. Se considera un modelo analítico representado mediante ecuaciones diferenciales y restricciones cuyos parámetros se estiman mediante un modelo empírico anterior (por ejemplo, una red neuronal). Este método proporciona una solución para maximizar una función objetivo,

25  sin embargo la presente invención intenta mantener una alta calidad de servicio (QoS) descubriendo por adelantado los riesgos potenciales y discriminando mediante cuestiones de autorregeneración y elasticidad heurísticos.

Descripción de la invención

30 Es necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas encontradas en la misma, particularmente en relación con la falta de propuestas que en realidad gestionen el rendimiento de servicios en una infraestructura de tecnología de información desde un punto de vista holístico y que reconozcan problemas de la forma más rápida y eficaz evitando la realización de

35  pruebas o actuar sobre causas erróneas.

Para este fin, la presente invención proporciona, en un primer aspecto, un método para gestionar el rendimiento en aplicaciones de múltiples capas implantadas en una infraestructura de tecnología de información, proporcionando dichas aplicaciones de múltiples capas servicios a un usuario y teniendo recursos asignados en dicha infraestructura de TI, comprendiendo dicha gestión al menos detectar la degradación del rendimiento y proporcionar acciones correctivas por medio de enfoques estadísticos o modelos analíticos.

A diferencia de las propuestas conocidas, el método de la invención, de una manera característica comprende además usar una combinación de dichos enfoques estadísticos y dichos modelos analíticos teniendo en cuenta los datos de monitorización procedentes de dicha infraestructura de TI con el fin de:

asignar dichos recursos con elasticidad; y

proporcionar, cuando se detecta una anomalía o anomalías, dichas acciones correctivas procesando dichos datos de monitorización, comprendiendo dicho procesamiento operaciones estadísticas, predicciones, reconocimientos y/o correlaciones de patrón.

Otras realizaciones del método del primer aspecto de la invención se describen según las reivindicaciones adjuntas 2 a 20, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Un segundo aspecto de la presente invención se refiere a un sistema para gestionar el rendimiento en aplicaciones de múltiples capas implantadas en una infraestructura de tecnología de información, proporcionando dichas aplicaciones de múltiples capas servicios a un usuario y teniendo recursos asignados en dicha infraestructura de TI, comprendiendo dicha gestión al menos detectar la degradación del rendimiento y proporcionar acciones correctivas por medio de enfoques estadísticos o modelos analíticos.

A diferencia de las propuestas conocidas, el sistema de la invención, de una manera característica comprende además una entidad de control del rendimiento que recibe datos de monitorización procedentes de dicha infraestructura de TI y usa una combinación de dichos enfoques estadísticos y dichos modelos analíticos tomando dichos datos de monitorización para:

asignar dichos recursos con elasticidad; y

proporcionar, cuando se detecta una anomalía o anomalías, dichas acciones correctivas procesando dichos datos de monitorización, comprendiendo dicho procesamiento operaciones estadísticas, predicciones, reconocimientos y/o correlaciones de patrón.

Otras realizaciones del sistema del segundo aspecto de la invención se describen según las reivindicaciones adjuntas 21 a 37, y en una sección posterior relativa a la descripción detallada de varias realizaciones.

Breve descripción de los dibujos

Las anteriores y otras ventajas y características se entenderán de manera más completa a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos, que deben considerarse de una manera ilustrativa y no limitativa, en los que:

La figura 1 muestra el sistema de control del rendimiento, según una realización de la presente invención.

La figura 2 muestra un esquema detallado del sistema de control del rendimiento, según una realización de la presente invención.

La figura 3 muestra el módulo de reconocimiento de patrón, según una realización de la presente invención.

La figura 4 muestra el módulo de detección de anomalías, según una realización de la presente invención.

La figura 5 muestra el módulo originador de acciones, según una realización de

la presente invención.

La

figura 6 muestra un ejemplo de un modelo analítico para la

autorregeneración.

La

figura 7 muestra un ejemplo de un modelo analítico para la

autorregeneración y ajustabilidad a escala.

Descripción detallada de varias realizaciones

Esta invención presenta un sistema de control del rendimiento especialmente diseñado para gestionar el rendimiento de servicios desde un punto de vista holístico. El objetivo es mantener una alta calidad de servicio (QoS) que se percibe por los usuarios finales de las aplicaciones implantadas en la nube. El desafío es cómo reconocer el problema de la forma más rápida y eficaz, evitando la realización de pruebas o actuar sobre causas erróneas como asignación de recursos de ajuste a escala cuando la causa real es un problema de la base de datos.

La invención introduce tres características principales. En primer lugar, la invención permite combinar tanto enfoques estadísticos como modelos analíticos, para garantizar una asignación adecuada de recursos de nube, tolerante a fluctuaciones en demanda de servicio, mientras que se proporciona un diagnóstico eficaz y acciones

5  correctivas de problemas potenciales. En segundo lugar, la capacidad de la invención para predecir el comportamiento futuro y, en este sentido, anticipar acciones correctivas antes de que se produzcan los problemas. Finalmente, la adaptación por servicio, de modo que la invención pueda controlar (y aprender el comportamiento de) cada servicio de una manera independiente.

10 Para lograr esta misión, el sistema analiza los incidentes del evento (por ejemplo, las advertencias del sistema operativo), y supervisa varias métricas de QoS del nivel de servicio (por ejemplo, tiempo de respuesta del acceso a web), así como otras métricas internas de infraestructuras de nube (por ejemplo, carga de CPU, consumo de memoria). Esta información se usa para detectar anomalías y desarrollar

15  estrategias preventivas, soportadas por mecanismos que incluyen predicción de la evolución de las métricas monitorizadas, reconocimiento basado en patrón de cuestiones anómalas, correlación de datos, y detección de posibles comportamientos estacionarios en los problemas identificados. Para facilitar la colaboración de las estrategias mencionadas anteriormente se han establecido un método y un sistema

20 con el fin de proporcionar la base para la creación y evolución de un sistema de control del rendimiento que se autoadapta a características particulares de servicios implantados en la infraestructura de TI en general y aplicaciones de múltiples capas implantadas en la nube en particular. La invención incluye el sistema y los métodos para supervisar un entorno de

25  implantación de infraestructura de TI garantizando una QoS adecuada, por servicio, donde cada servicio es en principio una aplicación de múltiples capas. En el alcance de esta invención, el entorno de TI se entiende como un amplio conjunto de host físicos y virtuales y varias plataformas de aplicación (por ejemplo, servidores web, bases de datos) y servicios de cliente que se ofrecen por encima de esa

30  infraestructura. El almacenamiento de datos y las redes también se consideran como parte de la infraestructura de TI, siempre que sean relevantes para el rendimiento de los servicios mencionados.

En este sentido, la solución proporciona un sistema de control del rendimiento, que incluye los mecanismos para el análisis avanzado de datos monitorizados, el 35 aparato para tomar decisiones correctivas basándose en ese análisis, y un actuador

para implementarlas siempre que sea necesario en el entorno de infraestructura de TI. También se incluyen, aunque no se representan a este nivel, los instrumentos necesarios para la evaluación de las acciones tomadas. Las sondas de monitorización están fuera del alcance de esta solución, y sólo sus datos recopilados son

5 significativos en esta propuesta.

Volviendo a la figura 1, se presenta un esquema generalizado del sistema de la invención, incluyendo el sistema (113) de control del rendimiento referido. Este sistema (113) recibe constantemente la entrada de la infraestructura (100) de TI. En la medida de esta invención esta infraestructura de TI incluye host que pueden ser o bien

10  físicos (101, 102, 105) o bien virtuales (106, 107), aplicaciones y servicios (108, 109) ejecutados en la infraestructura de TI, y redes de interconexión y almacenamiento (103, 104) usadas por todos los elementos mencionados anteriormente.

El sistema (113) recibe como entrada datos de monitorización procedentes de un conjunto heterogéneo de fuentes, que básicamente se divide en métricas (110, 15 112) de infraestructura, y métricas (111) de servicio. Las métricas de infraestructura comprenden indicadores del rendimiento de los host físicos (110) y virtuales (112) (por ejemplo, carga de memoria y CPU, uso de memoria de intercambio), de almacenamiento (por ejemplo, rendimiento de E/S, ocupación en disco) y de redes (por ejemplo, ancho de banda usado, errores de paquete). Las métricas de servicio se

20 relacionan con el software ejecutado en la infraestructura de TI y, como tal, abarca cualquier KPI (Key Performance Indicator; indicador de rendimiento clave) que el propietario o usuario de la infraestructura considere pertinente tener en cuenta para el sistema (113). El sistema (113) de control del rendimiento se representa en la figura 1 a un

25  nivel alto, que comprende tres módulos principales que se explicarán más adelante en mayor detalle: la monitorización/análisis (114), el originador (115) de acciones y el organizador (116). La parte (114) de monitorización/análisis recibe los datos de monitorización procedentes de la infraestructura (100) de TI, y los procesa. Este procesamiento incluye las operaciones estadísticas, predicciones, reconocimiento y/o

30  correlaciones de patrón que son necesarios para realizar la detección de anomalías posterior. El originador (115) de acciones está encargado de tomar decisiones sobre las actuaciones que necesitan realizarse sobre la infraestructura de TI para garantizar su funcionamiento correcto. Estas acciones deben ejecutarse mediante el organizador (116); de manera similar a la monitorización de datos de entrada, las acciones pueden

35  referirse a elementos (117) de infraestructura o servicios y aplicaciones (118). Sin

embargo, no es necesaria una relación directa entre la fuente de información de monitorización y las acciones: las métricas procedentes de un conjunto de recursos de infraestructura o servicio pueden iniciar un conjunto de acciones sobre algunas infraestructuras o servicios que pueden, o no, incluirse en el mismo conjunto de origen. 5 Los ejemplos de acciones orientadas a infraestructura (117) incluyen host de replicación que forman parte de una aplicación de múltiples capas, proporcionar más ancho de banda en una red congestionada, o añadir más memoria a una máquina virtual que está intercambiando de manera excesiva. Los ejemplos de acciones sobre servicios (118) son reiniciar una aplicación que no responde, restablecer conexiones 

10 bloqueadas a una base de datos, o aumentar el número de hilos de procesamiento en un servidor web. Los componentes del sistema (113) de control del rendimiento se mostraron en la figura 2. Comprende una unidad (202) de monitorización que proporciona datos a un módulo (203) de predicción de serie temporal, un módulo (204) de reconocimiento de

15 patrón, al módulo (205) de detección de anomalías y al originador (214) de acciones. Este originador (214) de acciones generará un conjunto (223) de acciones que se realizarán en la infraestructura de TI, a través del organizador (206). La unidad (202) de monitorización es el punto de entrada para las métricas

(201) en el sistema de control del rendimiento. Un entorno de TI incluye un número

20  significativo de elementos de diferente naturaleza, tal como se muestra en la figura 1. Se supone que se implantan varias sondas de monitorización en el interior de cada uno de estos elementos. Las sondas se basan habitualmente en software, y existen muchos ejemplos: ganglia [5], nagios [6], collectd [7], aunque también pueden basarse en hardware, que también es común cuando se monitorizan infraestructuras de red. La

25  implementación e implantación de estas sondas está fuera del alcance de esta invención, así para el propósito de este documento, se supondrá que reúnen los datos considerados relevantes por el administrador de infraestructura de TI incluyendo, pero sin limitarse a, carga de memoria, CPU y utilización de disco de máquinas físicas o virtuales, y KPI de aplicaciones implantadas. Para el propósito de esta invención, los

30  datos monitorizados deben poder representarse como un par {clave, valor}, en el que la clave es una marca de tiempo que indica cuándo se obtuvieron los datos en la fuente, y el valor es la cifra monitorizada real.

Debe entenderse que los datos de monitorización proceden de muchas fuentes diferentes que pueden proporcionarlos a tasas diferentes o formatos diferentes: es la 35 tarea de la unidad (202) de monitorización consolidar y homogeneizar todos los data de una manera que pueda entenderse por los módulos posteriores en el sistema (200) de control del rendimiento. Esta consolidación a menudo implica la realización de un nuevo muestreo de los datos recibidos para obtener una tasa de muestreo común, interpolación y suavizado de muestras para minimizar picos, o sincronización de 5 marcas de tiempo de datos. Estas tareas de procesamiento previo comprenden también técnicas estadísticas ligeras para producir una salida consistente que minimice los fallos inherentes a las sondas de monitorización: por ejemplo, las métricas (201) proporcionadas a la unidad (202) de monitorización pueden presentar interrupciones en el tiempo debido a una sonda defectuosa o un fallo de red. Los datos

10 que faltan pueden inferirse de datos pasados y presentes, proporcionando así un flujo de monitorización ininterrumpido para módulos posteriores. Las salidas de la unidad (210, 211, 212) de monitorización son de la misma forma que las métricas (201) monitorizadas, {clave, valor}, y se dirigen al módulo (203) de predicción de serie temporal, el módulo (204) de reconocimiento de patrón, el

15 módulo (205) de detección de anomalías y el originador (214) de acciones. El módulo (203) de predicción de serie temporal ofrece un servicio de predicción de evolución a corto plazo que contribuye a la naturaleza proactiva de la solución. Las predicciones se realizan sobre las métricas procesadas por el módulo

(210) de monitorización, usando una variedad de técnicas diferentes. Estas

20  predicciones (213a, 213b) son similares a los datos (210) de monitorización procesados obtenidos del módulo de monitorización, pero haciendo referencia a un intervalo estimado T antes de la marca de tiempo de la última muestra monitorizada.

La selección de qué técnicas de predicción deben aplicarse está fuera del alcance de esta invención, y existe abundante literatura [8, 9]. Algunas referencias, 25 tales como la mostrada en [4], usan datos históricos para suponer un comportamiento normal estadístico de las métricas futuras, y los combinan con lecturas de datos reales que se usan como factor de corrección. Sin embargo, los enfoques más simples, tales como regresión lineal, se encuentran en otros entornos y han demostrado ser útiles si el conjunto de datos es lo suficientemente simple. Otros ejemplos pueden ser

30 regresión múltiple, redes neuronales, promedios móviles integrados autorregresivos, modelado de BoxJenkins, etc. Se permite que varias técnicas simultáneas coexistan en este módulo (203), que proporcionarán diferentes predicciones, y actuarán de manera opuesta: dado un conjunto de predicciones generadas en un tiempo dado t por las técnicas en este

35  módulo, se evaluarán en el tiempo t + T, comparándolas con los valores (210)

monitorizados reales. La proporción de éxito de cada técnica se entiende como una medida de la similitud de los datos (213a, 213b) predichos y reales (210, en t + T). Esta similitud puede obtenerse mediante cualquier cálculo de distancia que pueda considerar cualquiera familiarizado con la materia. La proporción de éxito se usa para

5  el equilibrio entre las técnicas de predicción, y generar pesos para expresar la preferencia en el uso de uno u otro para próximas predicciones en el módulo (203) de predicción de serie temporal. También es posible seleccionar un subconjunto de técnicas a priori, basándose en reglas de contexto extraídas de análisis históricos.

El resultado de este módulo (203) es una secuencia de datos para un tiempo T

10  que extiende la entrada (210) de métrica original, manteniendo el mismo formato {clave, valor}: la clave indica una marca de tiempo (en el futuro), siendo el valor el valor estimado para esa métrica. Junto con ese par, puede darse una indicación de la proporción de éxito estimada para esa predicción. La salida resultante (213a, 213b) sería de la forma {{clave, valor}, éxito}. Esta salida se toma como entrada en los

15 módulos (205) de detección de anomalías y originador (214) de acciones. El módulo (204) de reconocimiento de patrón se encarga de generar y reconocer patrones complejos a partir de la evolución temporal de las métricas (212) monitorizadas. Mientras que la unidad (202) de monitorización y el módulo (203) de predicción de serie temporal generan como salidas flujos de métrica sencillos, este

20  módulo (204) analiza, y combina varias métricas para obtener un patrón que puede resumir un comportamiento en un momento dado. Esto puede observarse obteniendo una toma instantánea inteligente (patrón) del estado de la infraestructura. En una segunda etapa, el módulo (204) procesa los datos (212) de entrada para buscar acontecimientos de ese patrón, y notificar de estos acontecimientos (215) al módulo

25  (205) de detección de anomalías. El módulo de reconocimiento de patrón estima que un patrón particular es relevante tras recibir una realimentación (216) desde el módulo de detección de anomalías en ese sentido.

La figura 3 representa este módulo en más detalle. La primera etapa en la operación de este módulo (300) es la generación de patrones en sí mismo (301). Se 30 entiende que la infraestructura de TI monitorizada implica un elevado número de métricas diferentes, cada una de ellas con un significado único y preciso (por ejemplo, utilización de memoria, carga de CPU, o tiempo de respuesta de un servidor web). No obstante, observar un conjunto de métricas como un todo proporciona una mejor perspectiva del comportamiento real de la infraestructura. Por ejemplo, un tiempo de 35 respuesta deficiente en un servidor web puede derivarse de una alta carga de CPU.

Además, la alta carga de CPU puede ser debida a una alta utilización de memoria lo que provoca demasiados intercambios en el sistema. Algunas de las métricas (212) leídas se correlacionarán fuertemente, y por tanto pueden ignorarse, o combinarse en una nueva métrica asimilada. Otras métricas, sin embargo, no presentarán una clara 5 relación directa entre ellas o las asimiladas. Es nuestra tesis que el valor durante un intervalo dado de un conjunto de métricas (o bien básicas (212) o bien asimiladas) puede posiblemente indicar una anomalía en un instante futuro. Los patrones se introducen en este caso basándose en un conjunto de métricas, y debe almacenarse en un repositorio (303) de patrones. Para esta invención, sólo se requiere que el 10 repositorio (303) de patrones funcione como una base de datos convencional, con el conjunto habitual de operaciones CRUD: crear, leer, actualizar y borrar patrones. El módulo (301) de generación de patrón produce nuevos patrones según el siguiente procedimiento: cuando se detecta una anomalía por el módulo (205) de detección de anomalías, esta información se pasa al organizador (206), que iniciará un conjunto de

15  acciones, y proporciona una determinada realimentación (218) según su resultado. Si el módulo (205) de detección de anomalías puede confirmar que la anomalía detectada en realidad se ha producido, el módulo (301) de generación de patrón es notificado de este hecho (216), originado un patrón nuevo usando las métricas (212) antes de ese momento, y almacenándolo en la base (303) de datos de patrones.

20 La segunda etapa de la operación del módulo (204) de reconocimiento de patrón es la identificación en tiempo real de los patrones creados, que se realiza por el módulo (302) de identificación de patrón. Este módulo (302) recibe los datos (212) de monitorización procesados previamente y realiza una búsqueda para dar con acontecimientos de uno o muchos de los patrones almacenados en la base (303) de

25  datos de patrones. La información acerca de la identificación de patrones se proporciona (215) al módulo (205) de detección de anomalías, que va a describirse en más detalle después. Lo importante a indicar en este punto es que la realimentación

(216) producida por el módulo (205) de detección de anomalías cuando tienen lugar las anomalías reales, no sólo se usa por el módulo (301) de generación de patrón para

30  producir nuevos patrones, tal como se describió anteriormente, sino también por el módulo (302) de identificación de patrón como medio de establecimiento de una proporción de éxito para cada uno de los patrones identificados, y por tanto ya almacenados.

El módulo (204) de reconocimiento de patrón ejecuta una tarea de aprendizaje 35 supervisada: inicialmente, la base (303) de datos de patrones estará vacía, o cargada previamente con algunos patrones genéricos que pueden haberse identificado en el pasado en infraestructuras de TI similares a la presente. Las anomalías nuevas ocupan la base (303) de datos con patrones, siguiendo los mecanismos mencionados anteriormente. Después de un tiempo de entrenamiento inicial, las anomalías similares 

5  posteriores se identificarán, y evitarán, cuando se detecte su patrón asociado y esa información se pasa (215) al módulo (205) de detección de anomalías.

La detección de patrones es especialmente útil considerando que los patrones de anomalía generados pueden generarse a partir de un conjunto de métricas que no se originan necesariamente dentro de la misma fuente monitorizada. Por ejemplo, en

10  un escenario de servicio de múltiples capas típico, el conjunto de métricas asociado al patrón puede incluir KPI del servicio, así como métricas de infraestructura de las diversas máquinas físicas o virtuales que ejecutan ese servicio. Un problema de rendimiento puede aparecer cuando coinciden combinaciones de factores: un alto volumen de accesos al frontend, junto con una baja condición de memoria de la capa

15  de negocio, y un alto número de conexiones bloqueadas al backend. Cada una de las situaciones, individualmente, puede señalar a un problema potencial. Pero usando un patrón la combinación de las tres situaciones puede detectarse de manera simultánea, anticipando probablemente un problema más serio, y llevando a una solución diferente.

20 De manera similar al módulo (203) de predicción de serie temporal, el componente (302) de identificación de patrón también soporta la coincidencia de diferentes métodos de correspondencia de patrón que compiten para determinar cuál es el más apropiado para cada situación. La literatura [11, 12] que describe algunos métodos de correspondencia de patrón detalla la utilidad de las redes neuronales,

25  detección comprimida, modelos Markov ocultos, etc. Sin embargo, su utilidad fácilmente se encuentra de manera habitual en otros campos de investigación, tal como reconocimiento de voz o imagen, pero no tanto en relación con datos de servicios informáticos. Siempre que cada método en tiempo real analice los datos 

(212) de entrada, y haya una realimentación (216) del módulo (205) de detección de

30  anomalías indicando si se ha producido una anomalía, es sencillo establecer una valoración entre las técnicas de correspondencia de patrones: las que detectan un patrón que condujo a una anomalía real se valorarán más altas que las que no. Como resultado, el módulo (302) de identificación de patrón equilibrará entre los diferentes métodos, dando prioridad a uno de ellos por encima de los otros, y garantizando un

35  grado superior de éxito. Esta prioridad debería ser diferente para cada contexto: alguna técnica de correspondencia de patrón puede prevalecer para un tipo particular de métrica o anomalía, aunque otras técnicas se consideran más adecuadas para otras.

La salida (215) de este módulo (204) es información que indica qué patrón se

5  ha identificado, así como la probabilidad de éxito de esa identificación basándose en datos históricos. Habitualmente los patrones se almacenarán en la base (303) de datos de patrones con una única clave asociada a los mismos. Esta única clave, junto con la proporción de éxito, son los dos valores {clave, éxito} que conforman la salida (215).

10 El módulo (205) de detección de anomalías detecta e identifica anomalías basándose en conjuntos de incidentes. En el alcance de esta invención, los incidentes se interpretan como “síntomas”, o indicaciones aisladas de algunas situaciones irregulares en la infraestructura de TI monitorizada (por ejemplo, la CPU está alcanzando el 100% de carga, el disco está casi lleno). Las anomalías (es decir

15  “trastornos”) describen un comportamiento no deseado en la infraestructura, asociado a uno o muchos incidentes, que es necesario solucionar. Por tanto, la detección de anomalías consiste en encontrar la razón principal de algunos incidentes, con una determinada probabilidad. Estos incidentes puede ser o bien externos (225) o bien internos, tal como se describirá en los siguientes párrafos.

20 La figura 4 ilustra la arquitectura interna del módulo (205) de detección de anomalías. La propia detección se realiza en el recurso (403) de diagnóstico de anomalías, basándose en varias entradas. Estas entradas incluyen incidentes (224) externos, incidentes (404) generados internamente, así como patrones (215) detectados. La asociación entre incidentes, patrones y anomalías se almacena en la

25 base (402) de datos de anomalías. Los incidentes (225) externos se proporcionan habitualmente mediante sondas específicas que están diseñadas para monitorizar un único elemento en la infraestructura (100) de TI con el fin de dar una alarma cuando se cumpla una determinada condición. Aunque la misma información de incidente puede derivarse a

30 partir del análisis de las métricas monitorizadas, se supone que los incidentes (224) externos se detectan y alimentan al recurso (403) de diagnóstico de anomalías mediante sensores que no forman parte del sistema (113) de control del rendimiento, facilitando su extensibilidad. Los incidentes internos (o autogenerados) son el resultado del análisis de los 

35  datos monitorizados en el recurso (401) de análisis avanzado. Estos datos se

proporcionan por los módulos anteriores: métricas (211) de procesamiento previo de monitorización generadas por la unidad (202) de monitorización, que conforman los valores reales leídos de la infraestructura de TI, y métricas (213a) predichas estimadas por el módulo (203) de predicción de serie temporal, que ofrece información de la 5 evolución futura de esas mismas métricas (211). Dados esos datos (211, 213a), el recurso (401) de análisis avanzado aplica diferentes heurísticas, pero complementarias, para producir incidentes (404). El catálogo de heurísticas es amplio, y depende de los datos usados como entrada. Un ejemplo de heurísticas aplicadas es usar la evolución (211) de métricas y el estudio continuo de datos históricos, para 10 establecer los umbrales de confianza que indican que una métrica particular está dentro de su rango de operación normal (estos umbrales pueden haberse establecido también por un operador de TI informado, usando reglas tales como “El tiempo de respuesta para este servicio debe ser inferior a 1 segundo”). La violación de esos umbrales desencadenaría un incidente interno. Además, usando la estimación de 15 métrica procedente del módulo (213a) de predicción de serie temporal es posible prever un incidente interno, que puede ser útil para la detección de anomalías proactiva. Un tercer ejemplo de heurística aplicada es detectar cualquier comportamiento estacionario en incidentes (por ejemplo, la base de datos presenta un número anómalo de conexiones bloqueadas cada 5 días), analizar su distribución de

20 probabilidad durante el tiempo, conociendo así si se espera que ocurra en un futuro próximo. Los patrones (215) detectados del módulo (204) de reconocimiento de patrón se alimentan directamente al recurso (403) de diagnóstico de anomalías. Esto es debido al hecho de que los patrones se usan para detectar anomalías y no incidentes 

25  aislados: como se indicó anteriormente, la generación de patrones nuevos se lanza en el módulo (204) de reconocimiento de patrón cuando se confirma la anomalía detectada por el organizador (206).

La base (402) de datos de anomalías almacena relaciones entre anomalías y conjuntos de uno o más incidentes. Esta base (402) de datos debe ocuparse 30 inicialmente por un administrador de sistemas experimentado, que debe poder establecer la lógica que asocia varios incidentes (tanto internos como externos) con anomalías generales en la infraestructura (100) de TI, junto con una indicación de su intensidad. Además, la base (402) de datos también almacena automáticamente la correspondencia entre las anomalías detectadas y los patrones generados. Por tanto, 35 la detección de anomalías puede ocurrir de dos maneras diferentes: (1) el recurso (403) de diagnóstico de anomalías recibe continuamente la indicación de incidentes (224, 404), que consulta (406) en la base (402) de datos de anomalías. Cuando se detectan un número suficiente de incidentes asociados a la misma anomalía, se desencadena (217) una indicación de anomalía, junto con una probabilidad de éxito en 5 la detección. La probabilidad de éxito en la detección se relaciona con el número y tipo de incidentes necesarios, y ambos son valores que representan un umbral que debe establecerse inicialmente por el administrador de sistemas que ocupa la base (402) de datos de anomalías. Por ejemplo, consideremos una anomalía en relación con cinco incidentes igualmente relevantes: cuando se detectan cuatro de los cinco incidentes, el

10  recurso (403) de diagnóstico de anomalías puede suponer que la anomalía está teniendo lugar con un 80% de probabilidad. También existe la posibilidad de que (2) el recurso (403) de diagnóstico de anomalías reciba la indicación de que se ha detectado

(215) un patrón. En ese caso, se supone que la anomalía asociada a ese patrón en la base (402) de datos de anomalías ocurre con una probabilidad dada (debido a lo 15 básico descrito del mecanismo de generación de patrones).

Con el fin de aumentar la probabilidad de éxito en la detección de una anomalía, la lógica que relaciona los incidentes con esa anomalía puede incluir la conveniencia de realizar algunas pruebas adicionales sobre determinados elementos en la infraestructura de TI. Estas comprobaciones proporcionan una perspectiva que

20  no puede obtenerse mediante el análisis de datos monitorizados (por ejemplo, una prueba puede implicar perfilar una base de datos para una determinada consulta, que es algo que sería poco práctico de hacer sistemáticamente como parte de la monitorización). El recurso (403) de diagnóstico de anomalías puede desencadenar

(226) esas comprobaciones (228). La utilidad de los resultados (227) depende de la

25 lógica que solicitó la comprobación. Algunos beneficios pueden incluir: determinar que de hecho ocurre una anomalía; estimar la intensidad de un incidente detectado; o sólo distinguir entre dos anomalías muy similares. Debido al hecho de que algunos incidentes (internos) se detectan usando una entrada (213a) del módulo (203) de predicción de serie temporal, es posible que

30  algunas anomalías se detecten antes de que ocurran realmente (es decir, se predicen). Por tanto, la salida (217) de este módulo (205) de detección de anomalías debe incluir también una trama de tiempo estimada para que la anomalía se produzca. Esta estimación se usará por el originador (214) de acciones cuando se planifiquen las acciones para solucionar esa anomalía.

35 Finalmente, este componente (205) también incorpora mecanismos de

contienda para evitar un comportamiento no deseado: es posible que el organizador

(206) se desborde con varias indicaciones de anomalías casi concurrentes, que pueden estar altamente relacionadas. Para evitar esto, el módulo (205) de detección de anomalías debe proporcionar mecanismos para la consolidación de anomalías: las 

5  anomalías pueden correlacionarse y, si se consideran similares (por ejemplo, siempre se detectan dentro de una trama de tiempo estrecha, o se relacionan con los mismos incidentes externos o internos), pueden agruparse formando una única anomalía, simplificando así detecciones futuras.

El originador (214) de acciones proporciona una serie de acciones que es 

10  necesario tomar con el fin de aliviar una situación anómala en la infraestructura (100) de TI, según se detecta por el módulo (205) de detección de anomalías. Esta serie de acciones se proporciona como un flujo (220) de trabajo al organizador (206), que las realizará y proporcionará realimentación (219) sobre los resultados. El flujo de trabajo de acciones (220) se obtiene tras alimentar al originador (214) de acciones información

15  relacionada con la anomalía reenviada (219) por el organizador (206).

Las referencias para este servicio se basan ahora en la figura 5, que representa el originador (214) de acciones en más detalle. Esta invención propone el uso de modelos tanto analíticos (502) como estadísticos (503) dentro del originador

(500) de acciones, junto con un evaluador (501) que equilibrará las decisiones

20  tomadas por uno cualquiera de ellos (504, 506). En este punto es importante aclarar que puede haber anomalías cuya simplicidad no requiera la contienda de los dos tipos de modelos, y puedan solucionarse usando una única acción (por ejemplo, rotando los registros de una aplicación). El enfoque generaliza e incluye las acciones dentro de los modelos (502) analíticos, considerando que el evaluador (501) no siempre necesitará

25 equilibrarse con respecto a otros modelos (503). Aunque que el uso de modelos de cualquier tipo para la toma de decisiones no es una novedad en sí misma, debe indicarse que en el sistema (114) de control del rendimiento propuesto ningún modelo específico (sea analítico o estadístico) desprecia a otro; se entiende que la competición beneficia al rendimiento del sistema y añade

30  flexibilidad con el fin de superar los cambios de manera más satisfactoria. El evaluador

(501) realiza la tarea de medir la proporción de éxito de cada resultado propuesto, usando realimentación (219) del organizador (206), y asigna pesos para maximizar esa proporción de éxito en resultados futuros.

Los modelos (502) analíticos (denominados también modelos de primer 35 principio) se basan en consideraciones de primer nivel de cada componente individual

del sistema, ignorando suposiciones empíricas. Esto permite establecer un conjunto de reglas (que puede ser más o menos rígido, dependiendo de los parámetros que lo formen) que determinan las acciones a tomar para abordar una anomalía particular. Estas reglas son genéricas para todos los sistemas similares: la figura 6 muestra un 5 modelo analítico de muestra que controla el comportamiento cuando se detecta una anomalía referente al disco. Algunos parámetros deben adaptarse a la infraestructura

(100) de TI a la que se aplica el sistema (114) de control del rendimiento. En el ejemplo de la figura 6, L se determinaría mediante una máquina. Un ejemplo más complejo se muestra en la figura 7, donde se obtienen varias decisiones de

10  autorregeneración y elasticidad tras analizar varias restricciones. Además, en este caso los parámetros específicos que describen el modelo deben definirse antes de su uso. Es deseable que los parámetros evolucionen como resultado de la realimentación

(505) proporcionada por el evaluador (501). Estos modelos (502) analíticos presentan la ventaja de ser operativos sin entrenamiento anterior, aparte de la adaptación inicial 15 de los parámetros, pero en algunos casos pueden considerarse como potencialmente incompletos e imprecisos, especialmente si la infraestructura (100) de TI es compleja.

Los modelos (503) estadísticos (también denominados modelos empíricos) tienden a capturar el comportamiento real de cualquier sistema, basándose en el historial y experimentación anterior, incluyendo comportamientos no ideales a menudo

20  ignorados por los modelos (502) analíticos. Una posible implementación de modelos

(503) estadísticos puede basarse en redes neuronales o redes bayesianas: antes de ofrecer salidas precisas, necesitan entrenarse. En el caso del originador (500) de acciones, este entrenamiento se realiza usando (a) entradas procedentes del módulo

(205) de detección de anomalías, (b) acciones realizadas por el organizador (206) y (c)

25  realimentación de las acciones tomadas (223); estos datos se reenvían (219, 507) por el organizador (206) y el evaluador (501). Adicionalmente, (d) la entrada se toma del módulo (203) de predicción de serie temporal, que proporciona estimaciones (213b) sobre métricas (201) monitorizadas en la infraestructura (100) de TI, y (e) las propias métricas monitorizadas. Por tanto, después de cierto entrenamiento, los modelos (503)

30  estadísticos podrán relacionar lecturas de datos (e) reales y (d) previstas con (a) anomalías detectadas, (b) acciones tomadas y (c) sus resultados acerca de la infraestructura de TI, y generar nuevo flujos de trabajo de acciones (506) para que considere el evaluador (501). Un inconveniente inherente a los modelos (503) estadísticos es la necesidad de este entrenamiento inicial, durante el que no pueden

35  ofrecerse recomendaciones adecuadas; sin embargo, esto se compensa por el uso simultáneo de modelos (502) analíticos dentro del originador (500) de acciones, listos para su operación desde el comienzo.

El evaluador (501) recibe los flujos de trabajo sugeridos de acciones (504, 506) desde los modelos (502) analíticos y modelos (503) estadísticos, y selecciona el flujo de trabajo de acciones que va a ofrecerse (220) al organizador (206). Esta decisión se toma basándose completamente en la proporción de éxito de historial pasado de cada modelo (502, 503) para cada anomalía (219) detectada específica. Una posible realización de este evaluador (501) podría incluir una base de datos en la que los flujos (504, 506) de trabajo sugeridos de cada modelo se asocian con anomalías (219) detectadas, y la realimentación que resulta de la ejecución de los flujos de trabajo por el organizador (206) se usa para asignar un peso a cada flujo de trabajo indicando qué éxito ha tenido. El evaluador (501) es crucial para el trabajo combinado de ambos tipos de modelos (502, 503) en el originador de acciones.

Un ejemplo de este enfoque combinado que funciona mejor que cualquiera de los modelos individualmente es en el caso de un ajuste a escala de múltiples capas de un centro de datos virtuales. Los modelos analíticos (que podrían ser similares a los que se muestran en la figura 7) proporcionan una estimación de las acciones para tomar cuando el rendimiento global se degrada en un servicio de múltiples capas, basándose en las indicaciones de una detección (217) de comportamiento anómalo, y proporciona un flujo (504) de trabajo que indica qué capa o capas van a escalarse. De manera simultánea, un modelo (503) estadístico compuesto por una red neuronal puede entrenarse con tanto las acciones tomadas (que inicialmente serán las de los modelos (502) analíticos, ya que la red neuronal carece aún del entrenamiento suficiente), como el resultado real. Finalmente, cuando el modelo (503) estadístico se entrena satisfactoriamente, el evaluador (501) recibirá flujos de trabajo desde ambos modelos (504, 506) que indican qué capas es necesario ajustar a escala, y el resultado esperado de un KPI particular, tal como “tiempo medio de servicio”. Después de aplicar cualquiera de esos flujos de trabajo por el organizador (206), el evaluador (501) recibirá la realimentación desde la infraestructura (100) de TI, y calculará qué modelo estima mejor el KPI resultante. Una vez que esta secuencia se realiza varias veces, el evaluador (501) tendrá información suficiente para decidir qué modelo es más preciso cuando surge una anomalía de ajuste a escala. Además, estas decisiones de predominio de un modelo sobre el otro no son estáticas, sino que evolucionan continuamente.

El organizador (206) gestiona el conjunto de instrucciones sobre la infraestructura (100) de TI necesaria para solucionar una anomalía que se ha detectado y notificadas (217) por el módulo (205) de detección de anomalías. Este conjunto de instrucciones se proporciona por el originador (214) de acciones en forma

5  de flujo (220) de trabajo que incluye las acciones concretas que será necesario ejecutar sobre cada uno de los elementos implicados en esa anomalía. Estos elementos son un subconjunto de aquéllos que se monitorizan en la infraestructura de TI, incluyendo host físicos (101, 102, 105) o virtuales (106, 107), servicios (108, 109), almacenamiento (103) y redes (104). Los elementos implicados en la anomalía pueden

10  coincidir o no con aquéllos cuyas métricas (201) monitorizadas y datos (211, 213a, 215) derivados indicaron al módulo (205) de detección de anomalías que se estaba produciendo una anomalía. Esto se debe a las relaciones complejas entre los elementos en la infraestructura (100) de TI y la heterogeneidad en la naturaleza de métricas que se usan como entradas para el sistema (113) de control del rendimiento.

15 Cuando se detecta una anomalía por el módulo (205) de detección de anomalías, se pasa una indicación de este hecho (217) al organizador (206), en forma de una referencia única a la anomalía, y datos asociados que indican la intensidad, duración, estimación de trama de tiempo presente y probabilidad de éxito en la identificación. Estos datos se reenvían (219) al originador (214) de acciones, que

20  actuando como que se describió anteriormente, genera un flujo de trabajo de acciones

(220) para que las realice el organizador (206). Estas una o muchas acciones (221) se ejecutan sobre elementos de la infraestructura (100) de TI, a través de algunas interfaces establecidas que dependen de la clase de cada elemento. Esta invención no pretende definir esas interfaces, sino dejar que el implementador de la realización elija 25 las más adecuadas para la infraestructura de TI sobre la que se opera el sistema (113) de control del rendimiento. Por ejemplo, en el caso de acciones sobre componentes de red, o parámetros de host físico, SNMP [16] se usa generalmente como protocolo de acción. En el caso de almacenamiento, también puede usarse el SNMP, aunque hay soluciones más apropiadas para realizaciones orientadas al almacenamiento en la

30  nube, tal como CDMI [13]. Como último ejemplo, las acciones sobre servicios o aplicaciones pueden realizarse usando las interfaces de gestión que proporcionan habitualmente (XMLRPC, REST, SOAP, Telnet son algunos casos comunes), o pueden simplemente implicar la emisión de instrucciones sobre una conexión SSH.

Las peticiones (221) de acción, cuando se ejecutan sobre la infraestructura 35 (100) de TI, originarán algunas acciones en los elementos (223) objetivo, y se

obtendrá una realimentación por dos trayectorias diferentes. Por un lado, habrá un efecto global en la parte de la infraestructura (100) de TI que se vio afectada por la anomalía. Este efecto puede recogerse e introducirse en el sistema (200) de control del rendimiento como parte de las métricas (201) monitorizadas. Incluso si hay una 5 falta de efecto, o si el efecto es despreciable y no puede medirse, esto produce una realimentación en el sentido de que las métricas (201) monitorizadas no habrán alterado por la acción (221). Esto probablemente implicará que la anomalía continuará detectándose por el módulo (205) de detección de anomalías, o bien como consecuencia de las métricas (211, 213a, 215) de entradas anómalas o bien se 10 produzca una indicación (224) de un evento (225) de incidente. Por otro lado, se requiere que cada acción (221) emitida por el organizador (206) reciba una realimentación (222) directa desde el elemento en el que se ha realizado. Esto indica al organizador (206) si la acción (223) se ha ejecutado satisfactoriamente, o si ha habido errores que le impidieron tener éxito. El éxito se mide sólo en términos del

15  resultado de la ejecución de acción en sí misma, y no está relacionado con el posible efecto de rendimiento sobre la infraestructura de TI. De nuevo, el formato en el que se recibe esta realimentación (222) depende enormemente del tipo de elemento en el que se ha solicitado (223) la acción; generalmente usará la misma interfaz a través de la que se emitió la acción (véanse los ejemplos anteriores).

20 Algunas de las acciones surten efecto inmediatamente después de aplicarse mientras que algunas otras requieren más tiempo: Por ejemplo, los resultados de añadir una nueva máquina virtual a un servicio habitualmente no son visibles justo después de que la nueva máquina está operativa, sino que tarda un poco más de tiempo antes de que se estabilice el servicio. Con el fin de evitar el lanzamiento de

25  medidas adicionales mientras que las que ya se tomaron no están completamente operativas, el sistema podrá considerar el tiempo esperado que podría tardar una acción para solucionar un problema. Este tiempo puede o bien proporcionarse por el originador (214) de acciones como parte de la descripción de la acción, o bien podría inferirse o aprenderse con el tiempo.

30 La realimentación, ya provenga en forma de informe acerca del éxito o fallo en la ejecución de acciones (223) o se infiera de la misma anomalía que se detecta después de emitir acciones (217), se usa por el organizador (206) de tres maneras complementarias. En primer lugar, es posible que el flujo de trabajo de acciones (220) proporcionado por el originador (214) de acciones incluya condiciones y ramas a

35  seguir dependiendo del resultado de cada acción (221). En este caso, algunas

acciones (221) alternativas se emitirían a la infraestructura de TI, hasta que se complete el flujo de trabajo. Por ejemplo, si se envían instrucciones a una base de datos para restablecer sus conexiones, y se ignoran estas instrucciones, la propia base de datos puede reiniciarse. En segundo lugar, la información recibida acerca del 5 éxito o fallo de las acciones (en un sentido más general, incluyendo tanto la realimentación desde su ejecución como también sus efectos), debe reenviarse (219) al originador (214) de acciones, como su propio canal de realimentación. Esto permite que los modelos (208, 209) se adapten ellos mismos, con el fin de seguir, o dejar de, sugerir las mismas acciones asociadas con las mismas anomalías. Por ejemplo, el 10 aumento de memoria de una máquina virtual podría considerarse como la solución para el bajo rendimiento de un servidor web que se ejecuta en la misma. Si esta se realiza acción, pero no tiene un efecto medible sobre el rendimiento, el originador

(214) de acciones tendrá que alterar los modelos (208, 209) para que esta acción se suprima de los flujos (220) de trabajo generados para esa anomalía, y se añade una

15  nueva acción. Finalmente, también se proporciona alguna realimentación (218) al módulo

(205) de detección de anomalías. Esta realimentación (218) incluye información que permitirá que el módulo (205) de detección de anomalías evalúe sus heurísticas, puesto que indicará el resultado del flujo de trabajo de acciones (220) proporcionadas

20  por el originador (214) de acciones. Algunos casos están presentes en este caso como posibles escenarios a partir de la realimentación (218): (1) Habitualmente, el informe

(218) del organizador (206) indica que el flujo de trabajo de acciones correctivas se ha ejecutado satisfactoriamente, y el módulo (205) de detección de anomalías usa esta información junto con la monitorización de supervisión de métricas y algunas posibles 25 comprobaciones (228) para evaluar que la anomalía se ha solucionado; (2) si el organizador (206) notifica (218) al módulo (205) de detección de anomalías que las acciones correctivas se han ejecutado satisfactoriamente, pero que aún se detecta la misma anomalía, o que dichas acciones correctivas han fallado, sería necesario realizar acciones de nivel más alto (por ejemplo notificar al operador de la 30 infraestructura de TI de la anomalía que no puede corregirse), pero el módulo (205) de detección de anomalías debe dejar de notificar la anomalía al organizador (206); (3) si el módulo (205) de detección de anomalías predice una anomalía en un tiempo futuro t, y la realimentación (218) notifica que las acciones preventivas se ejecutan satisfactoriamente, pero la anomalía aparece dentro del marco de tiempo predicho,

35 puede confirmarse una detección de anomalía exitosa, incluso si aún es necesario

ejecutar acciones correctivas adicionales; (4) si el módulo (205) de detección de anomalías predice una anomalía en un momento futuro t, las acciones preventivas se ejecutan (218) satisfactoriamente, y la anomalía no aparece, puede usarse una evolución real de métricas para evaluar que la detección de anomalías era correcta.

5 Está implementándose un prototipo de la invención, para controlar el rendimiento de aplicaciones de múltiples capas implantadas en un entorno de informática en la nube. En esta realización, la infraestructura de TI es la nube referida, que está compuesta por un conjunto de host físicos que usan la tecnología VMware ESXi [18] como hipervisor. Por tanto, cada aplicación de múltiples capas comprende

10 un conjunto de máquinas virtuales implementadas en tales hipervisores, controlándose por el sistema de control del rendimiento. El sistema de monitorización usa varias sondas. Las métricas de infraestructura (CPU, memoria, etc.) se recogen por collectd [7], que se ejecuta en las máquinas virtuales. Como métrica de servicio se usa el número de peticiones al sistema, y el

15  retardo de aplicación de extremo a extremo, notificado por un sistema Nagios [6] que periódicamente emite transacciones de servicio, midiendo el retardo medio para completar tales transacciones. Cada sonda y el sistema Nagios notifican a una instancia central de collectd, que actúa como módulo de monitorización en los términos de la invención descrita anteriormente: reúne todos los datos monitorizados y

20 los ofrece de manera integrada a los diferentes subsistemas (predicción de serie temporal, reconocimiento de patrones y detección de anomalías). El módulo de predicción de serie temporal usa tres técnicas básicas para prever futuros valores de métrica: una regresión polinómica, una red neuronal, y una distribución estadística de métrica de historial pasado. Los tres métodos se aplican y 

25 se comparan con los valores de métrica reales en el futuro, para estimar el error cuadrático medio, y aplicar así más peso en la técnica más precisa. El módulo de reconocimiento de patrones usa un subconjunto de métricas monitorizadas (carga de CPU, memoria o utilización de disco, retardo de aplicación de extremo a extremo y número de peticiones al sistema) para crear patrones, tomando

30  los últimos 10 minutos de datos antes de cada anomalía. Se usa un muestreo disperso en esos datos, y se usa un algoritmo de reconocimiento de imágenes para la detección de patrones.

El módulo de detección de anomalías usa una base de datos de anomalías que se ha ocupado anteriormente con incidentes que sirven para identificar algunas 35 anomalías típicas que se aplican en el entorno en la nube (por ejemplo alta utilización

de disco, o un retardo de extremo a extremo del servicio de múltiples capas que incumple un SLA). La detección de incidentes se basa en umbrales, de modo que cuando un conjunto de métricas supera sus umbrales asociados, se notifica al organizador, interaccionando con el originador de acciones en secuencia para conocer qué flujo de trabajo de acciones aplicar. Con respecto a los modelos analíticos dentro del originador de acciones, el flujo de trabajo básico mostrado en la figura 6 se usa para casos sencillos en los que la superación del umbral define de manera unívoca la acción de autorregeneración a aplicar. Por ejemplo, cuando la utilización de disco (Ud) es mayor que un valor L dado (por ejemplo L = 95%) aplica una acción para liberar espacio (por ejemplo eliminando archivos de registro antiguos). Para situaciones más complejas, se usa el flujo de trabajo mostrado en la figura 7, que analiza las causas de diferentes problemas y aumenta a escala la aplicación si el problema al final está relacionado con la falta de capacidad. Este flujo de trabajo es el que debe usarse cuando el retardo de extremo a extremo usado como métricas de servicio (Ts) supera un valor dado (Us), de modo que a priori no se conoce si la degradación del tiempo de servicio se debe a algunos problemas internos en algunos de los componentes de servicio existentes (de modo que es necesario aplicar una acción de autorregeneración) o a la falta de capacidad (de modo que es necesario aumentar a escala una de las capas de las aplicaciones). Para este flujo de trabajo más complejo, el modelo estadístico funciona en paralelo. Basándose en una red neuronal, se entrena usando como entradas los datos monitorizados de servicio (retardo de extremo a extremo) y las predicciones sobre el número de peticiones entrantes al sistema, así como las decisiones de ajuste a escala tomadas por el modelo analítico y el retardo de extremo a extremo resultante después de haber aplicado acciones en el sistema. Tanto el analítico como estadístico estiman un retardo de extremo a extremo de servicio resultante después de completarse sus acciones de ajuste a escala sugeridas. Estas estimaciones se comparan por el evaluador con los valores reales, y usa aquel modelo que tenga el menor error medio para la siguiente acción de ajuste a escala.

El organizador se implementa usando un motor de reglas de negocio. En particular se usa el motor drools [19]. Las reglas que rigen el comportamiento del sistema y que implementan los diferentes flujos de trabajo proporcionados por el originador de acciones se codifican en RIF [20] y luego se codifican para un lenguaje interno de drools.

Este prototipo puede usarse en los siguientes posibles escenarios de control de rendimiento: El sistema de control del rendimiento detecta tiempos de respuesta de aplicación web pobres, indicando cómo puede solucionarse el problema añadiendo 5 más recursos informáticos al backend.

El sistema de control del rendimiento detecta que cada 5 días el número de conexiones bloqueadas a la base de datos es anómalamente alto, y por tanto es necesario que se reinicie. El sistema de control del rendimiento detecta que algunas fluctuaciones en los

10  tiempos de respuesta de aplicación web se provocan por un disco que está casi lleno.

Ventajas de la invención La solución descrita en esta invención presenta un sistema y método de control de rendimiento para aplicaciones de múltiples capas, que proporciona ventajas a 15 múltiples niveles con respecto a soluciones existentes:

1.En el análisis del rendimiento y en la selección de acciones que van a tomarse cuando se detectan anomalías, la invención combina desde un punto de vista holístico mecanismos de autorregeneración y de elasticidad.

Esto, en comparación con las soluciones de elasticidad existentes, evita los 

20  problemas derivados de aplicar soluciones de elasticidad para los problemas de autorregeneración, que pueden llevar a una asignación de recursos ineficaz (es decir podría asignarse una nueva máquina para mejorar la eficacia de la base de datos, mientras que el problema real era el número de conexiones bloqueadas; esto podría incluso no mejorar el rendimiento global del servicio).

25 Comparando la solución propuesta con sistemas de autorregeneración existentes, mejora de varias maneras: Ofrece maneras para definir las acciones de autorregeneración al nivel de aplicación, no sólo al nivel de máquina o de subsistema. Por ejemplo, considérense dos capas A y B (cada una compuesta por una pluralidad de máquinas) que se

30  comunican usando una VLAN dada (en un sentido 802.1q). La infraestructura de red tiene diferentes VLAN, cada uno destinado a un propósito/calidad particular. La configuración para unir la interfaz de red de cada máquina a un VLAN dado se realiza localmente en la máquina dada (por ejemplo usando vconfig e ifconfig un sistema GNU/Linux). Considérese que en un momento dado las capas usan VLAN X para

35  comunicarse y el sistema de control detecta un problema con VLAN X que está

provocando pérdida de paquetes (por ejemplo derivado por un problema en uno de los conmutadores L2 que implementan el VLAN). Entonces, como medida de autorregeneración, el sistema decide cambiar la comunicación de intercapas a un VLAN (Y) “más seguro”, por tanto cambiando el VLAN de X a Y. Esto conduce a una

5 acción de reconfiguración en cada una de las máquinas (tanto en la capa A como en la capa B) para separar la interfaz de red de X y unirla a Y. La autorregeneración no soluciona problemas en relación con la falta de recursos, que se proporciona por aplicar soluciones de elasticidad. Al aplicar ambos mecanismos (autorregeneración y elasticidad) de una manera 10 coordinada, se obtienen algunas ventajas:

La elasticidad no es habitualmente una solución inmediata; normalmente tarda varios minutos entre que se lanza la acción para crear un nuevo elemento en la capa y el momento en el que el sistema es estable con la nueva configuración de recursos. Esto podría llevar a una situación en la que se está incumpliendo el KPI. En

15  ciertas circunstancias, mientras que surte efecto un procedimiento de elasticidad, una acción de autorregeneración puede aplicarse de manera simultánea para mitigar en cierta medida el incumplimiento del KPI. Por ejemplo, asúmase que es necesario ajustar a escala la capa de base de datos, pero mientras tanto, y con el fin de reducir las conexiones rechazadas, se aplica una acción de autorregeneración para aumentar

20  el número de conexiones concurrentes. Esto aumentará el tiempo de respuesta pero al menos se reducirá el número de conexiones rechazadas mientras que un nuevo recurso de base de datos está activo.

En otros casos podría ser poco evidente si un determinado problema puede solucionarse aplicando una u otra técnica. Dependiendo del problema y del tiempo de 25 reacción puede decidirse aplicar ambas al mismo tiempo o probar la primera y en el

caso de fallo probar la segunda más adelante. 2.La combinación de enfoques estadísticos y modelos analíticos en la aplicación de mecanismos de autorregeneración y elasticidad. También es importante destacar que nuestro sistema propone el uso de

30  recursos de modelado y estadísticos avanzados para proporcionar una revisión proactiva hacia la detección de las acciones correctivas necesarias, a diferencia de las soluciones tradicionales basadas en umbrales predefinidos o un comportamiento reactivo después de haberse producido un problema real. Estas acciones, que pueden implicar desencadenar mecanismos de ajuste a escala o autorregeneración, o bien a

35  nivel de infraestructura o bien a nivel de servicio, se generan mediante un componente de modelo innovador. Aunque el uso de modelos en sí mismo no es novedoso, la técnica anterior habitualmente usa modelos o bien analíticos, basados en la teoría, o bien estadísticos, red neuronal, teniendo cada uno de ellos graves inconvenientes: los modelos analíticos son a menudo incompletos e imprecisos, y los modelos estadísticos

5  necesitan un poco de entrenamiento antes de ser funcionales, e incluso luego están limitados por la calidad de las entradas durante ese entrenamiento. La presente invención combina ambos tipos de modelo para centrarse en sus lados negativos, proporcionando varias ventajas:

El enfoque propuesto es un enfoque completamente funcional desde el 10 comienzo: el entrenamiento progresivo del modelo estadístico sólo mejorará el rendimiento global.

Las respuestas (generación de acciones) son más precisas, puesto que no están unidas a un modelo particular. Un sistema de evaluación equilibra sus decisiones basándose en su proporción de éxito.

15 Incorporando como entradas no sólo datos monitorizados, sino también técnicas de reconocimiento de patrones y predicción, se logra una detección de anomalías más precisa y útil.

Estas tres ventajas permiten que la presente invención mantenga el sistema supervisado trabajando dentro de los límites deseados, mejorando tanto la eficacia 20 como la eficiencia.

3.El uso de modelos predictivos. Mediante la aplicación de medidas que pueden predecir el comportamiento de la aplicación, el sistema de control del rendimiento puede tomar mecanismos de corrección incluso antes de que se produzca un problema, mejorando toda la experiencia de usuario y la calidad del sistema y la

25 aplicación. 4.La adaptabilidad de cada aplicación. Todos los procedimientos del sistema se adaptan y se aplican según las bases de la aplicación. Esto significa que el sistema de control del rendimiento se adapta al comportamiento de cada una de las aplicaciones.

30 Un experto en la técnica podría introducir cambios y modificaciones en las realizaciones descritas sin apartarse del alcance de la invención tal como se define en las reivindicaciones adjuntas.

SIGLAS

CDMI

Cloud Data Management Interface; interfaz de gestión de datos

en la nube

CRUD

Create, Read, Update, Delete; crear, leer, actualizar, borrar

5 

TI Information Technologies; tecnologías de información

REST

Representational State Transfer; transferencia de estado de

representación

RIF

Rule Interchange Format; formato de intercambio de reglas

SSH

Secure Shell; shell segura

10 

SLA Service Level Agreement; acuerdo de nivel de servicio

SNMP

Simple Network  Management Protocol; protocolo simple de

gestión de red

SOAP

Simple Object Access Protocol; protocolo de acceso a objetos 

simple

15 

VLAN Virtual Local Area Network; red de área local virtual

XML

Extensible Markup Language; lenguaje de marcado extensible

XMLRPC

XML Remote Procedure Call; llamada a procedimiento remoto

XML

BIBLIOGRAFÍA

[1] L. M. Vaquero, L. RoderoMerino, J. Caceres, M. Lindner, “A Break in the Clouds: Towards a Cloud Definition”, ACM SIGCOMM Computer Communication Review, vol. 39(1), págs. 5055, enero de 2009.

5 [2] L. RoderoMerino, L. M. Vaquero, V. Gil, J. Fontán, F. Galán, R. S. Montero, I.

M. Llorente, “From Infrastructure Delivery to Service Management in Clouds”, Future Generation Computer Systems, special issue on Federated Resource Management in Grid and Cloud computing Systems, vol. 26(8), págs. 12261240, octubre de 2010.

[3] B. Urgaonkar, G. Pacifici, P. Shenoy, M. Spreitzer, A. Tantawi, “An Analytical

10  Model for Multitier Internet Services and Its Applications”, ACM SIGMETRICS Int’l Conf. on Measurement and Modeling of Computer Systems (SIGMETRICS’05), págs. 291302, Alberta (Canadá), junio de 2005

[4] B. Urgaonkar, P. Shenoy, A. Chandray, P. Goyal, “Dynamic Provisioning of

Multitier Internet Applications” 15 [5] Ganglia Monitoring System, http://ganglia.info (último acceso junio de 2011)

[6] Nagios The Industry Standard in IT Infrastructure Monitoring, http://nagios.org (último acceso junio de 2011)

[7] collectd – The system statistics collection daemon, http://collectd.org (último acceso junio de 2011)

20  [8] J. Hamilton, “Time Series Analysis”, Princeton: Princeton Univ. Press, 1994, ISBN 0691042896

[9] D. Shasha, “High Performance Discovery in Time Series”, Berlin: Springer, 2004, ISBN 0387008578

[10] E. J. Candès y M. Wakin. “An introduction to compressive sampling”. IEEE 25 Signal Processing Magazine, marzo de 2008, págs. 2130

[11] M. Gales, S. Young. “The Application of Hidden Markov Models in Speech Recognition”, Foundations and Trends in Signal Processing, 1 (3), 2007, págs. 195–

304: sección 2.2.

[12] C. M. Bishop, “Neural Networks for Pattern Recognition”, Oxford University 30 Press, 1995, ISBN: 0198538642

[13] Cloud Data Management Interface (CDMI), http://www.snia.org/cdmi (último acceso junio de 2011)

[14] M. Thompson y M. Kramer, “Modeling Chemical Processes Using Prior

Knowledge and Neural Networks”, AIChE Journal, vol. 40, pág. 1328, 1994. 35 [15] S. Gupta, P. Liu, S. Svoronos, R. Sharma, N. AbdelKhalek, Y. Cheng, y H. ElShall, “Hybrid FirstPrinciples/Neural Networks Model for Column Flotation”, AIChE Journal, vol. 45, pág. 557, 1999.

[16] J. Case, K. McCloghrie, M. Rose, y S. Waldbusser, “Introduction to version 2 of the Internetstandard Network Management Framework”, RFC 1441, SNMP Research, 5 Inc., Hughes LAN Sistemas, Dover Beach Consulting, Inc., Carnegie Mellon University, abril de 1993.

[17] I. T. Bowman, et al. “SQL Anywhere: A Holistic Approach to Database Selfmanagement”, IEEE 23rd Int’l Conf. Data Engineering Workshop, págs. 414423, Estambul (Turquía), 2007. 10 [18] VMware vSphere Hypervisor, http://www.vmware.com/products/esxi (último acceso junio de 2011)

[19] Drools, http://www.jboss.org/drools (último acceso junio de 2011)

[20] Rule Interchange Format, W3C Std., 2005. http://www.w3.org/2005/rules (último acceso junio de 2011)

15 

Claims (29)

1. REIVINDICACIONES

   1. Método para gestionar el rendimiento en aplicaciones de múltiples capas implantadas en una infraestructura de tecnología de información, proporcionando dichas aplicaciones de múltiples capas servicios a un usuario y teniendo recursos asignados en dicha infraestructura de TI, comprendiendo dicha gestión al menos detectar la degradación del rendimiento y proporcionar acciones correctivas por medio de enfoques estadísticos o modelos analíticos, caracterizado porque dicho método comprende realizar los siguientes pasos: usar una combinación de dichos enfoques estadísticos y dichos modelos analíticos teniendo en cuenta los datos de monitorización procedentes de dicha infraestructura de TI para:

   asignar dichos recursos con elasticidad; y proporcionar, cuando se detecta una anomalía o anomalías, dichas  acciones correctivas procesando dichos datos de monitorización, comprendiendo dicho procesamiento operaciones estadísticas, predicciones, reconocimientos y/o correlaciones de patrón,

   predecir el comportamiento futuro del uso de dichos servicios; y analizar al menos dichos datos de monitorización para anticipar dichas acciones correctivas, comprendiendo dichos datos de monitorización métricas de dicha infraestructura de TI y/o de dichos servicios, comprendiendo dichas métricas incidentes de evento y supervisando métricas de calidad de servicio y/o métricas internas de dicha infraestructura de TI, en el que dichos datos de monitorización proceden de las métricas de infraestructura y/o métricas de servicio de dicha infraestructura de TI, dicha infraestructura de TI comprende host físicos y/o virtuales y redes de interconexión y elementos de almacenamiento usados por dichos host físicos y/o virtuales y por dichas aplicaciones de múltiples capas, dichas métricas de infraestructura comprenden indicadores del rendimiento de dichos host físicos y/o virtuales, redes de interconexión y elementos de almacenamiento y dichas métricas de servicio comprenden indicadores del rendimiento del software ejecutado en dicha infraestructura de TI, reunir información de al menos una métrica de dichos host físicos y/o virtuales e indicadores del rendimiento claves de dichas aplicaciones de múltiples capas en dichos datos de monitorización y representar dichos datos de monitorización mediante un par de valores: una marca de tiempo que indica cuándo se obtuvieron los datos y un valor de una métrica monitorizada real,

   realizar una predicción de evolución a corto plazo de dichas métricas de

   infraestructura y/o de servicio con referencia a un intervalo estimado de tiempo

   antes de una marca de tiempo de la última muestra monitorizada por medio de

   técnicas de predicción de la siguiente lista no cerrada aplicada a dichos datos

   de monitorización: regresión lineal, regresión múltiple, redes neuronales,

   promedios móviles integrados autorregresivos, modelado de BoxJenkins o

   usar datos históricos combinados con valores de datos reales usados como un

   factor de corrección,

   emitir un par de valores diferentes tras realizar dicha predicción de

   evolución a corto plazo de modo que dicho par de valores indican: una marca

   de tiempo en el futuro y un valor que es un valor estimado para una métrica

   concreta,

   generar patrones a partir de la evolución temporal de dichos datos de

   monitorización, en el que dichos patrones se basan en un conjunto de métricas

   de dichos datos de monitorización, usando dicho conjunto de métricas antes

   del momento en que se detectan dicha anomalía o anomalías,

2. 2.

   Método según la reivindicación 1, que comprende controlar cada uno de dichos servicios de una manera independiente por medio de una adaptación por servicio de dicha infraestructura de tecnología de información.

3. 3.

   Método según la reivindicación 1, en el que dicha al menos una métrica es una de la siguiente lista no cerrada de métricas: CPU, carga de memoria y utilización de disco.

4. 4.

   Método según la reivindicación 1 ó 3, que comprende realizar un procesamiento previo de dichos datos de monitorización con el fin de homogeneizar dichos datos de monitorización, comprendiendo dicho procesamiento previo la realización de un nuevo muestreo, interpolación y suavizado, sincronización de marcas de tiempo de datos y/o utilización de técnicas estadísticas.

5. 5.

   Método según la reivindicación 1, que comprende comparar los valores monitorizados reales con un conjunto de predicciones con el fin de obtener una proporción de éxito, obteniéndose dicho conjunto de predicciones usando de manera simultánea una pluralidad de dichas técnicas de predicción o usando una de dichas técnicas de predicción y en el que dichos valores monitorizados reales se obtienen después de dicho intervalo de tiempo estimado en relación con dicho conjunto de predicciones.

6. 6.

   Método según la reivindicación 5, que comprende emplear una de dichas 

   técnicas de predicción según dicha proporción de éxito con el fin de realizar dicha predicción de evolución a corto plazo.

7. 7.

   Método según la reivindicación 1, que comprende almacenar los patrones generados en una base de datos de patrones e identificar dichos patrones generados por medio de un mecanismo de reconocimiento basado en patrones que comprende buscar acontecimientos entre dichos datos de monitorización y dichos patrones generados almacenados en dicha base de datos de patrones.

8. 8.

   Método según la reivindicación 7, que comprende realizar una identificación de dichos patrones generados usando diferentes técnicas de correspondencia de patrones y valorando cada una de dichas técnicas de correspondencia de patrones según un grado de éxito, siendo dicho grado de éxito más alto cuando dichos datos de monitorización identificados como un patrón generado conducen a una anomalía.

9. 9.

   Método según cualquiera de las reivindicaciones anteriores, que comprende asociar dicha anomalía o anomalías a uno o más incidentes, describiendo dichos uno o más incidentes un comportamiento no deseado de dicha infraestructura de TI que necesita corregirse y siendo dichos uno o más incidentes, incidentes externos cuando se indican mediante sensores y/o alarmas previstos en dicha infraestructura de TI y siendo incidentes internos según heurísticas aplicadas a dichos datos de monitorización.

10. 10.

    Método según la reivindicación 9, en el que dichas heurísticas comprenden: usar evolución de métricas y estudio continuo de datos históricos para establecer umbrales de confianza que determinan si una métrica particular está dentro de su rango de operación normal o si dicha métrica particular está fuera de dicho rango de operación normal generando un incidente interno; o usar dicha predicción a corto plazo para prever un incidente interno; o analizar la distribución de probabilidad de tiempo de dicho uno o más incidentes que responden al comportamiento estacionario con el fin de prever un incidente interno.

11. 11.

    Método según la reivindicación 9 ó 10, que comprende almacenar las relaciones entre dicha anomalía o anomalías y dicho uno o más incidentes y almacenar la correspondencia entre dicha anomalía o anomalías y dichos patrones generados en una base de datos de anomalías.

12. 12.

    Método según la reivindicación 11, que comprende detectar dicha anomalía o anomalías según las siguientes acciones:

    desencadenar una indicación de anomalía cuando un número determinado de

    dichos uno o más incidentes detectados en dicha infraestructura de TI en un periodo de tiempo dado corresponden parcial o totalmente a una de dicha anomalía o anomalías según una búsqueda en dicha base de datos de anomalías, estableciendo una probabilidad de éxito según la proximidad de dicho número determinado al número de incidentes almacenado en dicha base de datos de anomalías para dicha una de dicha anomalía o anomalías; o recibir una indicación de que se ha detectado uno de dichos patrones generados en el comportamiento de dicha infraestructura de TI y asociar dicho patrón generado con la correspondiente anomalía o anomalías consultando en dicha base de datos de anomalías.

13. 13.

    Método según la reivindicación 12, que comprende agrupar dicha anomalía o anomalías en una única anomalía cuando un conjunto de anomalías se correlacionan entre sí.

14. 14.

    Método según cualquiera de las reivindicaciones anteriores, que comprende generar un flujo de trabajo de dichas acciones correctivas para una anomalía determinada e información relacionada de dicha anomalía determinada, comprendiendo dicha información relacionada la intensidad, duración, estimación de trama de tiempo presente y la probabilidad de éxito, aplicándose dichas acciones correctivas a los elementos de dicha infraestructura de TI de la que proceden dichos datos de monitorización y/o aplicándose a uno o más de dichos elementos cuyas métricas no están implicadas en la detección de dicha anomalía determinada.

15. 15.

    Método según la reivindicación 14, que comprende: usar el protocolo simple de gestión de red, o SNMP, cuando se aplican dichas acciones correctivas a dichos host físicos y/o a dichas redes de interconexión; usar dicho SNMP o interfaz de gestión de datos en la nube cuando se aplican dichas acciones correctivas a dichos elementos de almacenamiento; y usar instrucciones de XMLRPC, REST, SOAP, Telnet o Shell segura cuando se aplican dichas acciones correctivas a dichas aplicaciones de múltiples capas y/o a dichos servicios.

16. 16.

    Sistema para gestionar el rendimiento en aplicaciones de múltiples capas implantadas en una infraestructura de tecnología de información, proporcionando dichas aplicaciones de múltiples capas servicios a un usuario y teniendo recursos asignados en dicha infraestructura de TI, comprendiendo dicha gestión al menos detectar la degradación del rendimiento y proporcionar acciones correctivas por medio de enfoques estadísticos o modelos analíticos,

    caracterizado porque dicho sistema comprende una entidad de control del rendimiento que recibe datos de monitorización procedentes de dicha infraestructura de TI y usa una combinación de dichos enfoques estadísticos y dichos modelos analíticos tomando dichos datos de monitorización para: asignar dichos recursos con elasticidad; y proporcionar, cuando se detecta una anomalía o anomalías, dichas acciones correctivas procesando dichos datos de monitorización, comprendiendo dicho procesamiento operaciones estadísticas, predicciones, reconocimientos y/o correlaciones de patrón, en donde dicha entidad de control del rendimiento al menos comprende: un módulo de monitorización para recibir dichos datos de monitorización y para realizar dicho procesamiento de dichos datos de monitorización; un módulo originador de acciones para realizar dicha provisión de dichas acciones correctivas según dicho procesamiento y dicha combinación de dichos enfoques estadísticos y dichos modelos analíticos; y un módulo organizador para aplicar dichas acciones correctivas a al menos un elemento de dicha infraestructura de TI y/o a al menos una de dichas aplicaciones de múltiples capas, comprendiendo dicha infraestructura de TI host físicos y/o virtuales y redes de interconexión y elementos de almacenamiento usados por dichos host físicos y/o virtuales y por dichas aplicaciones de múltiples capas; comprendiendo dicha entidad de control del rendimiento además: reflejando dichos conjuntos de uno o más incidentes un comportamiento no deseado de dicha infraestructura de TI y recibiendo dicho módulo de detección de anomalías como entradas dichos patrones generados, salidas procedentes de dicho módulo de monitorización, salidas procedentes de dicho módulo de predicción de serie temporal y alarmas implantadas en dicha infraestructura de TI que indican dicho comportamiento no deseado.

    un módulo de predicción de serie temporal encargado de proporcionar una

    predicción de evolución

    a corto plazo que hace referencia a un intervalo

    estimado antes de una marca de tiempo de la última muestra monitorizada

    por medio de técnicas de predicción aplicadas a las salidas procedentes de

    dicho módulo de monitorización;

    un módulo de reconocimiento de patrón encargado de generar e identificar

    patrones

    a partir de la evolución temporal de dichos  datos de

    monitorización, recibiendo dicho módulo de reconocimiento de patrón como

    entrada

    dichas  salidas  procedentes  de dicho módulo de monitorización,

    basándose

    cada uno de dicho patrones  en un conjunto de métricas  de

    dichas 

    métricas  de infraestructura y/o dichas  métricas  de servicio, y

    almacenando

    dicho módulo de reconocimiento de patrón los  patrones

    generados en una base de datos de patrones; y

    un módulo de detección de anomalías  que detecta e identifica dicha

    anomalía

    o anomalías basándose en conjuntos de uno o más incidentes,

17. 17.

    Sistema según la reivindicación 16, en el que dichos datos de monitorización comprenden métricas de infraestructura y métricas de servicio, comprendiendo dichas métricas de infraestructura indicadores del rendimiento de dichos host físicos y/o virtuales, comprendiendo dichos elementos de almacenamiento y/o dichas redes de interconexión y dichas métricas de servicio indicadores del rendimiento del software ejecutado en dicha infraestructura de TI.

18. 18.

    Sistema según la reivindicación 17, en el que dicho módulo de monitorización recibe como entrada dichos datos de monitorización y, homogeneizando dichos datos de monitorización, emite un par de valores que contienen la siguiente información: una marca de tiempo que indica cuándo se obtuvieron los datos; y un valor que indica una métrica monitorizada determinada de dichas métricas de infraestructura y métricas de servicio; en el que dicha homogeneización comprende la realización de un nuevo muestreo, interpolación, suavizado de muestras, sincronización de marcas de tiempo y/o cualquier técnica estadística.

19. 19.

    Sistema según la reivindicación 16, en el que dicho módulo de predicción de serie temporal emite tres valores: una marca de tiempo que indica dicho intervalo estimado; un valor estimado de dicha métrica monitorizada determinada; una proporción de éxito de dicha predicción de evolución a corto plazo; en el que dicha proporción de éxito se calcula según la similitud entre dicho valor estimado y el valor de dicha métrica monitorizada determinada después de dicho intervalo estimado.

20. 20.

    Sistema según la reivindicación 16, en el que dicho módulo de reconocimiento de patrón emite un patrón de dichos patrones generados y un parámetro de éxito asociado a dicho patrón, siendo dicho parámetro de éxito más alto cuando dicho patrón conduce a dicha anomalía o anomalías.

21. 21.

    Sistema según la reivindicación 16, en el que dicho módulo de detección de anomalías aplica heurísticas a dichas salidas procedentes de dicho módulo de monitorización y a dichas salidas procedentes de dicho módulo de predicción

    de serie temporal con el fin de producir dicho conjunto de uno o más incidentes, almacenar las relaciones entre dicha anomalía o anomalías y dichos conjuntos de uno o más incidentes en una base de datos de anomalías y almacenar correspondencias entre dicha anomalía o anomalías y dichos patrones generados.

22. 22.

    Sistema según la reivindicación 21, en el que dicho módulo de detección de anomalías realiza dicha detección de dicha anomalía o anomalías consultando en dicha base de datos de anomalías un conjunto de incidentes producidos en un determinado periodo de tiempo o consultando en dicha base de datos de anomalías un patrón generado recibido como entrada en dicho módulo de detección de anomalías.

23. 23.

    Sistema según la reivindicación 22, en el que dicho módulo de detección de anomalías emite una indicación de anomalía y una probabilidad de éxito de dicha detección de dicha anomalía o anomalías; y una confirmación de anomalía que se activa cuando se confirman dicha anomalía o anomalías por dicho módulo organizador.

24. 24.

    Sistema según la reivindicación 23, en el que dicho módulo de detección de anomalías desencadena una comprobación con el fin de realizar una prueba en al menos un elemento de dicha infraestructura de TI, proporcionando dicha prueba información del éxito en la detección de una anomalía.

25. 25.

    Sistema según la reivindicación 23 ó 24, en el que dicho módulo de reconocimiento de patrón recibe como entrada dicha confirmación de anomalía de dicho módulo de detección de anomalías y genera un patrón, cuando se recibe dicha confirmación de anomalía, dicho patrón se basa en un conjunto de métricas antes del momento en que se recibe dicha confirmación de anomalía y almacenándose dicho patrón en dicha base de datos de patrones.

26. 26.

    Sistema según la reivindicación 25, en el que dicho parámetro de éxito de dicho módulo de reconocimiento de patrón es función de dicha confirmación de anomalía.

27. 27.

    Sistema según cualquiera de las reivindicaciones anteriores a partir de la 16, en el que dicho módulo originador de acciones recibe al menos salidas de dicho módulo de monitorización y dicho módulo de predicción de serie temporal y proporciona a dicho módulo organizador un flujo de trabajo de dichas acciones correctivas, estando dichas acciones correctivas determinadas por dicha combinación de dichos enfoques estadísticos y dichos modelos analíticos 

    o por acciones sencillas que no necesitan tipos de modelo, estando encargado

    un submódulo evaluador de dicho módulo originador de acciones de equilibrar

    los resultados obtenidos con dichos enfoques estadísticos y dichos modelos 

    analíticos.

28. 28.

    Sistema según la reivindicación 27, en el que dicho submódulo evaluador

    5 

    selecciona dicho flujo de trabajo proporcionado a dicho módulo organizador

    según un historial pasado de proporciones de éxito de dichos enfoques

    estadísticos y dichos modelos analíticos para una anomalía concreta, estando

    cada una de dichas proporciones de éxito determinada por la realimentación

    proporcionada a dicho módulo originador de acciones desde dicho módulo

    10 

    organizador.

29. 29.

    Sistema según la reivindicación 28, que comprende:

    dicho módulo de detección de anomalías que envía una referencia única a

    una anomalía concreta y datos asociados de dicha anomalía concreta a dicho

    módulo organizador;

    15 

    dicho módulo organizador que reenvía dichos datos asociados a dicho

    módulo originador de acciones;

    dicho módulo originador de acciones que proporciona dicho flujo de trabajo a

    dicho módulo organizador según dichos datos asociados y dicha combinación

    de dichos enfoques estadísticos y dichos modelos analíticos; y

    20 

    dicho módulo organizador que aplica dichas acciones correctivas a al menos

    un elemento de dicha infraestructura de TI y/o a al menos una de dichas

    aplicaciones de múltiples capas.