DEVICE AND METHOD FOR ANALYZING THE BEHAVIOR OF AN APPLICATION MODULE SUBJECT TO RESOURCE SHORTAGE

Description

[0001] The present invention relates to the field of monitoring the performance of IT infrastructures and particularly that of application resilience. More particularly, the invention relates to a device and a method for analyzing an application brick subject to a scarcity of resources in order to improve its resilience. [Prior art]

[0002] In the field of IT infrastructure performance monitoring, managing the performance and availability of software applications plays a key role. Thus, an information system (IS) administrator strives to implement tools to detect, diagnose, and correct application performance problems to maintain an expected level of service, particularly despite the occurrence of hardware or software failures. Indeed, certain applications are cornerstones of a company's activity and a high level of resilience is therefore required.

[0003] The resilience of an application or application chain is its ability to provide the best possible service despite the occurrence of a problem in one of its components. Resilience becomes increasingly important as companies continue to implement applications whose continued operation is critical to them and for which service interruption is not an option. Thus, resilience is a very broad term that includes fault tolerance, high availability, and the ability to recover from a failure. High resilience helps reduce the negative consequences of failures.

[0004] There are known methods for testing application resilience and investigating the causes of failure. For example, as illustrated in US2012185735, there are many technical solutions for monitoring application behavior, profiling application behavior, or dumping information related to an application crash. Then, there are methods for testing application resilience that involve receiving a test script that specifies a failure scenario in an application. The specified failure scenario is translated into fault injection rules that are used to stage a specific failure.

[0005] However, there is no satisfactory solution dedicated to studying and improving the resilience of an application facing resource scarcity. For example, EP3106989 describes a solution simulating resource scarcity by applying a parasitic load. In this solution, the application is subjected to an indiscriminate scarcity of all resources without considering critical resources.

[0006] However, when an application runs in a computer system, whether it is a centralized or distributed system, the performance of the application depends at least in part on the amount of available computing resources. Thus, failures can occur when the available resources are saturated. However, computer applications experience significant variations in their level of use that can lead to a reduction in available computing resources. This use can vary during the day (i.e. working hours compared to the rest of the day), during the week (i.e. Saturday, Sunday compared to other weekdays), during the month and year (e.g. monthly, quarterly, annual closing period, etc.). For example, when an application is in production, it can experience significant changes in usage (i.e.e charge) over time, caused by a change in the number of users and / or the nature of their activities.

[0007] Nowadays, resources are increasingly shared between the different applications of a company's information system. Applications can therefore increasingly encounter resource saturation problems. Indeed, the failure of an application due to saturation of available resources can occur during a load peak on said application, but also during a load peak on a third-party application using the same resources or during a malfunction on a component of the IT infrastructure leading to a reduction in available resources. Thus, the problem of resilience in the face of resource saturation is exacerbated in shared or virtualized environments where the saturation of a resource by a first application can cause the failure of a task of a second application and require its complete re-execution.

[0008] Typically, to address these challenges, IT administrators will increase available resources, possibly based on load testing consisting of a simulation of increased application load. Based on this, over time, IT administrators typically evolve their IT infrastructure to consistently deliver high-performance business application services tailored to their organization's needs.

[0009] However, these tests are generally based on an increase in load and not on the behavior of the application chain when faced with resource saturation. However, an application will not react in the same way to an increase in its load and to a reduction in the resources available for its operation.

[0010] Thus, there is a need for methods and devices to make applications more resilient to saturation of available resources. A resilient application will be able, despite the loss of a portion of the available resources, to continue to operate while ensuring desired service levels or to operate in a degraded mode where only critical services are maintained at acceptable service levels. [Technical problem]

[0011] The invention therefore aims to remedy the drawbacks of the prior art. In particular, the invention aims to propose a device for analyzing the behavior of an application brick subject to a scarcity of resources, said device making it possible to monitor the behavior of the application brick and to diagnose the nature and / or source of a possible failure caused by the scarcity of resources. According to one embodiment, this device can in particular be used to improve the resilience of an application brick in the face of a scarcity of resources.

[0012] The invention further aims to propose a method for analyzing the behavior of an application brick subject to a scarcity of resources, said method being able, according to one embodiment, to make applications more resilient in the face of saturation of available resources. [Brief description of the invention]

[0013] To this end, the invention relates to a device for analyzing the behavior of an application brick subject to a scarcity of resources in an IT infrastructure according to claim 1.

[0014] Such a device can be used to simulate the saturation of one or more resources and to analyze the behavior of applications using these resources in order to make them more resilient to the various saturations that may occur in production. Indeed, for each critical resource, it is possible to use the resource scarcity module to gradually simulate the scarcity of the resource while maintaining the load level of the application (i.e. application brick) to be qualified. The scarcity of the resource is preferably progressive until it causes a failure of the application, then the application performance management module makes it possible to determine the source and / or the nature of the failure. The device according to the invention can provide an IS administrator with the source and the nature of the failures of the application brick following a resource scarcity.This will enable the IT administrator to take appropriate corrective action. This may be related to system configuration issues, application configuration issues, or even application brick design issues. The resilient application brick will then be able to continue operating while ensuring desired service levels despite the loss of some of the available resources, or to operate in a degraded mode where only critical services are maintained at acceptable service levels.

[0015] Once the adaptations have been made, the device according to the invention can be used to repeat the simulation in order to validate that the adaptations allow the application brick to be resilient to the scarcity of the resource. If this is the case, the device can be used to continue the scarcity of said resource to validate the resilience of the application brick beyond the failure point found previously or to test the resilience of the application brick on another type of resource.

[0016] According to other optional features of the device: The generated failure data includes data on the level of resource scarcity that the application brick can withstand before suffering a failure. Thus, the IT administrator will be informed of the resilience of the application brick concerned and the failures that it is able to withstand. The application performance management module is configured to select the nature of the failure from: hardware configuration of the IT infrastructure, software configuration of the IT infrastructure, configuration of the application brick, and design of the application brick.it further comprises a knowledge repository configured to store predetermined failure data based on execution data, the application performance management module comprises trace collectors for example deployed on processes involved in the execution of the application brick, said trace collectors being configured to collect execution data and the application performance management module is configured to generate the failure data from the knowledge repository based on collected execution data. it further comprises an evolution rules repository configured to store corrective actions based on failure data and a resilience improvement module configured to identify corrective actions from failure data generated by the application performance management module.This makes it possible, in particular, quickly and automatically, to generate modification proposals making it possible to increase the resilience of the application brick to resource saturation. The execution rules repository is configured to store several categories of predetermined thresholds of quality of service parameters including a so-called acceptable category, corresponding to the service levels beyond which the application brick is considered to provide a degraded but acceptable service and in that the resilience improvement module is configured to implement said corrective actions so that the application brick provides service levels corresponding to the so-called acceptable category despite a scarcity of resources.Thus, a resilient application brick will be able, despite the loss of a portion of the available resources, to continue to operate while ensuring desired service levels or to operate in a degraded mode where only critical services are maintained at acceptable service levels. The resilience improvement module is configured to implement said corrective actions or to verify their implementation to enable the application to be resilient to a scarcity of resources. Thus, the invention makes it possible to facilitate modifications to the application brick, or to the IT infrastructure hosting it, leading to an increase in the resilience of the application brick in the face of resource saturation.it further comprises a repository of accessible resources configured to store data characteristic of accessible resources and an infrastructure evolution module configured to generate at least one evolution plan listing resource modifications to be made in the IT infrastructure from the data characteristic of accessible resources and the failure data. the rules for consumption of critical resources comprise at least the following data: a starting resource consumption level, a final resource consumption level, a consumption increase step, and a duration between each increase step.

[0017] The invention further relates to a method for analyzing the behavior of an application brick subject to a scarcity of resources in an IT infrastructure according to claim 10.

[0018] The method according to the invention makes it possible, in an automated manner, to make an application brick more resilient in the face of saturation of available resources. In addition, it may include a step of selecting at least one corrective action instruction if a failure is identified and a step of applying the identified corrective action.

[0019] Preferably, the method according to the invention may comprise at least one, more preferably at least two of the following steps: a step of analyzing the implication of the design of the application brick in the failure following a scarcity of a critical resource, a step of analyzing the implication of the configuration of the application brick in the failure, and a step of analyzing the implication of the resources of the IT infrastructure in the failure.

[0020] Thus, the process will be able to automatically determine the origin of a failure and possibly include a step of applying an identified corrective action.

[0021] According to other optional process features: when it is determined that the design of the application brick is involved in the failure, then the method comprises a step of generating a report comprising collected trace data and then a step of determining the existence or not of other critical resources to be tested for this application brick. when it is determined that the existence of other critical resources to be tested for this application brick, then the method further comprises a modification of the critical resource to be scarified and otherwise the analysis of the behavior of this application brick is finalized and a report is generated. when it is determined that the configuration of the application brick is involved in the failure, then the method comprises a step of generating a report comprising data on the faulty configuration of the application brick and a step of modifying configuration files of the application brick.when it is determined that one or more resources are involved in the failure following a scarcity of a critical resource, then the method comprises a step of generating a report comprising data on the faulty resource(s) and a step of modifying the resources of the IT infrastructure.

[0022] Other advantages and characteristics of the invention will appear on reading the following description given by way of illustrative and non-limiting example, with reference to the appended Figures which represent: Figures 1A and 1B , the cumulative processor occupancy rate (“central processing unit” - CPU) ( Fig. 1B ) or not ( Fig. 1A ) of different IT structures, depending on time (in months), by application bricks (B1, B2). Figure 2, a schematic view of the elements of the device for analyzing the behavior of an application brick subject to a scarcity of resources according to one embodiment of the invention. Figure 3 , a schematic representation of a method for analyzing the behavior of an application brick subject to a scarcity of resources according to the invention. The steps framed by dotted lines are optional. Figure 4 , steps of preparing the device and / or initiating the method according to the invention. Figure 5 , a schematic view of sub-steps of a step of a method for analyzing the behavior of an application brick subject to a scarcity of resources according to an embodiment of the invention. Figure 6 , a schematic view of a method for analyzing the behavior of an application brick subject to a scarcity of resources according to an embodiment of the invention. Figure 7, a failure analysis according to an embodiment of the invention.

[0023] Thus, aspects of the present invention are described with reference to flowcharts and / or functional diagrams of methods, apparatuses (systems) and computer program products according to embodiments of the invention.

[0024] In the figures, flowcharts and block diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a system, device, module, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some implementations, the functions associated with the blocks may appear in a different order than shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the functionality involved.Each block of the block diagrams and / or flowchart, and combinations of blocks in the block diagrams and / or flowchart, may be implemented by special hardware systems that perform the specified functions or acts or carry out combinations of special hardware and computer instructions. [Description of the invention]

[0025] In the remainder of the description, "behavior of an application brick" means the execution conditions of the application brick such as the execution of the processes involved, internal or external transactions, or even the performance of the application brick with respect to users.

[0026] The term "resilience" within the meaning of the invention corresponds to the capacity of an application brick to offer the expected service despite the occurrence of a malfunction in the IT infrastructure hosting it or a failure in one of its components.

[0027] For the purposes of the invention, the term "IT infrastructure" means a set of IT structures (i.e. IT devices) capable of operating an application or an application chain. The IT structure may be one or more servers, for example composed of a presentation server, a business server and a data server. The IT infrastructure may also be a "test" server with the same resources as a production server or a clone of a virtual production server. Preferably, an IT structure is a server.

[0028] The expression "application chain" within the meaning of the invention corresponds to a set of applications, linked together by a flow of information and aiming to offer, through several processes, one or more functionalities which may be the subject of a service level agreement (SLA for "Service-level agreement").

[0029] The term "application building block" within the meaning of the invention corresponds to a component of an application. The combination of application building blocks is often necessary for the operation of applications, in particular business applications, such as a web application, a content sharing platform or a computing platform. The application building blocks of the IT infrastructure include, for example, an FTP server, an email server, a Java application server and / or one or more databases.

[0030] For the purposes of the invention, the term "probe" or "computer probe" means software associated with equipment which makes it possible to carry out, manage and send back to computer equipment measurements intended to provide information, among other things, on the values ​​of quality of service parameters, the operating status of resources or the use of resources.

[0031] For the purposes of the invention, the term "predetermined load plan" means a configuration file for the load or constraint to be applied to an IT infrastructure. The configuration file may, for example, be a file, or a set of files, which allows several data or fields to be associated. This association of fields is also called a load record. Such a load configuration file is, for example, an XML file, a CSV file, an INI file, a JSON file, etc. A load configuration file may include one or more load records. It may be generated from information provided by a user.

[0032] “Resources” means hardware resources such as parameters, capabilities or functions of computing devices enabling the operation of an application brick or an application. A single computing device is generally associated with several resources. Similarly, a single resource is generally shared between several application bricks. For example, the term “resource” may include physical or virtual resources such as network disks characterized for example by their inputs / outputs (I / O), reading / writing on disks, the memory usage rate, a network characterized by its bandwidth, a processor characterized for example by its usage (in percentage) or the occupancy rate of its caches, a RAM characterized by the amount allocated, or more generally the latency time of a process or packet losses.It is not necessary to monitor all the resources of an IT infrastructure to implement the method according to the invention and it is possible to form a group of critical resources whose use is particularly important. By "use of resources" is meant the consumption of a resource for example by a business application consisting of one or more application bricks monopolizing at least part of the resources.

[0033] The expression "critical resource" within the meaning of the invention corresponds to the resource(s) whose use under nominal (i.e. usual) conditions is closest to its limit use (predetermined maximum use threshold) or its saturation. Thus, the scarcity of a critical resource means that the execution conditions of the application brick are not respected (e.g. resource consumption threshold not respected or processing times not respected). For example, in an IT infrastructure comprising a CPU and 8Gb of RAM where under usual conditions there is consumption of 80% of CPU and 2 Gb of RAM then the critical resource will be the CPU resource.

[0034] For the purposes of the invention, the term "level of a resource" or "levels of resources" means a quantity of resource. For example, this may correspond, for network disks, to the number of available network disks or the quantity of memory available on these network disks, for a processor, to the number of cores or the number of processors or the size of the caches, for a RAM, to the available quantity, and for ports, to the number of ports that can be opened simultaneously. The initial level of a resource corresponds to the quantity of resource available on the IT infrastructure for the application chain(s). The "step of a resource" may be, on the one hand, the minimum quantity of resource that can be added or subtracted during a modification step and, on the other hand, a multiple of the modification that can be undergone by the level of said resource. Some resources have a high granulometry (e.g.servers) while others have a low granularity (e.g. available RAM).

[0035] For the purposes of the invention, the term "resource utilization level" means a value representative of the consumption or occupation of said resource during the operation of an application chain. For example, the utilization value may correspond, for network disks, to their inputs / outputs, reading / writing on disks, the memory utilization rate, for a network to its bandwidth, for processors to their use (in percent) or to the cache occupancy rate, for RAM the quantity used and for ports, the number of ports having been opened simultaneously during the operation of the method. The utilization value is advantageously reduced to the percentage of the resource level.

[0036] By "predetermined maximum usage threshold" is meant, within the meaning of the invention, a maximum parameter value associated with each resource allowing proper functioning of said resource. For example, this corresponds to the maximum acceptable limits of resource consumption for an IT infrastructure hosting one or more application bricks. These limits may be real or hypothetical and generally correspond to a level of usage beyond which malfunctions may occur and result in a shutdown of the resource, the IT infrastructure or at least a reduction in quality of service. For example, Table 1 below presents the predetermined maximum usage thresholds for three resources. Table 1 CPU1 Network usage Disk Usage Predetermined maximum usage threshold 80 % 350 KBps 60 o / s

[0037] The term "malfunction" within the meaning of the invention corresponds to the occurrence of a hardware incident or congestion on the IT structure hosting an application brick. The term "failure" within the meaning of the invention corresponds to a reduction in the quality of service of the application brick of various natures and / or sources which may, for example, arise from a design or configuration problem.

[0038] The expression "level of service" or "quality of service" within the meaning of the invention corresponds to an assessment of the quality of the service provided by an application brick or an application chain. A third party can commit to a level of service and thus guarantee good performance for the critical applications of an organization. The expression "quality of service parameter" within the meaning of the invention corresponds to subjective or objective criteria such as latency times of a process, packet losses, throughputs, resource utilization values ​​and response times per request. There are generally a plurality of quality of service parameters. In particular, there may be a different threshold response time for each of the different requests or an overall response time. The expression "degraded mode" within the meaning of the invention corresponds to an operation of the application brick where only part of the services are maintained.

[0039] The expression "predetermined threshold of quality of service parameter" within the meaning of the invention corresponds to a parameter value to which a third party can commit in order to guarantee good performance for the critical applications of an organization and as this can be defined in a service level agreement (SLA for "Service-level agreement"). For example, a threshold can be of the type: all response times are less than 3 seconds. Nevertheless, it can be advantageous to have detailed thresholds depending on the business actions. For example, a request implementing a file printing may have a higher response time threshold than a request involving the display of a web page. The predetermined thresholds of quality of service parameters can also include predetermined maximum usage thresholds.In the context of the invention, a critical resource may be a resource for which a reduction in its resource level or an exceeding of the predetermined maximum usage threshold would have a significant impact on one or more application brick service levels. For the purposes of the invention, "exceeding" means exceeding or lowering 10%, preferably 20% of the values ​​predetermined by the measured values.

[0040] For the purposes of the invention, "process", "calculate", "determine", "display", "extract", "compare" or more broadly "executable operation" means an action performed by a device or processor unless the context indicates otherwise. In this regard, operations refer to actions and / or processes of a data processing system, for example a computer system or an electronic computing device, which manipulates and transforms data represented as physical (electronic) quantities in the memories of the computer system or other devices for storing, transmitting or displaying information. These operations may be based on applications or software.

[0041] The terms or phrases "application", "software", "program code", and "executable code" mean any expression, code or notation, of a set of instructions intended to cause data processing to perform a particular function directly or indirectly (e.g. after a conversion operation to other code). Examples of program code may include, but are not limited to, a subroutine, a function, an executable application, source code, object code, a library and / or any other sequence of instructions designed for execution on a computer system.

[0042] For the purposes of the invention, the term "processor" means at least one hardware circuit configured to execute operations according to instructions contained in a code. The hardware circuit may be an integrated circuit. Examples of a processor include, but are not limited to, a central processing unit, a graphics processor, an application-specific integrated circuit (ASIC), and a programmable logic circuit.

[0043] For the purposes of the invention, the term "coupled" means connected, directly or indirectly, with one or more intermediate elements. Two elements can be coupled mechanically, electrically or linked by a communication channel.

[0044] The expression "human-machine interface" within the meaning of the invention corresponds to any element allowing a human being to communicate with a computer in particular and, without this list being exhaustive, a keyboard and means allowing, in response to orders entered on the keyboard, to perform displays and possibly to select elements displayed on the screen using the mouse or a touchpad. Another example of an embodiment is a touch screen allowing elements touched by the finger or an object to be selected directly on the screen and possibly with the possibility of displaying a virtual keyboard.

[0045] In the remainder of the description, the same references are used to designate the same elements.

[0046] THE Figures 1A and 1Billustrate the consumption of resources, here the CPU occupancy rate, as a function of time, by application bricks (B1, B2) hosted on the same IT infrastructure. The Figure 1A presents the CPU consumption of the application bricks as a function of time and as a function of the maximum capacity of the IT structure on which they are currently hosted.

[0047] There Figure 1B presents the cumulative CPU consumption over time on IT infrastructure 1 of application bricks B1 and B2. Figure 1B shows that although consumption is controlled in the first period, there is a little later, about five months, an excess over a period p of a predetermined maximum usage threshold (dotted line). Such an excess leads to a risk of failure on one or other of these application bricks.

[0048] A classic method of securing the operation of application brick B1 or brick B2 could be to further increase the quantity of resources available for the application bricks according to predictions of increased needs. However, a failure associated with saturation (i.e. scarcity) of a critical resource can occur even if a resource margin has been planned.

[0049] Thus, the inventors have developed a new device 1 for analyzing the behavior of an application brick 2 subject to a scarcity of resources in an IT infrastructure 4. This device advantageously makes it possible to study the behavior of an application brick facing a scarcity of resources. For example, it can be used to determine the behavior of an application brick facing a loss of more than 10, 20, 30 or 40% of available RAM, check whether the application brick continues to function and, if so, determine the nature of the failure.

[0050] This device can also be used to increase the resilience of an application brick. An application brick whose resilience has been increased will, for example, be able to continue to operate despite a reduction in availability of more than 10, 20, 30 or 40% of one or more resources used. Alternatively, an application brick whose resilience has been increased will be able to keep its main (i.e. essential) functions operational despite a significant reduction in available resources.

[0051] Thus, unlike prior art devices or systems, the IS administrator will know, in the event of a malfunction or load peak, what is the level of reduction in available resources that the application bricks can support, whether or not there has been an improvement in resilience to resource saturation. In addition, the use of the device according to the invention can allow him to modify the application brick and / or its environment so as to increase its resilience to resource reductions. Indeed, the device according to the invention is also a tool allowing the IS administrator to determine which modification will ensure high availability of the application brick studied.

[0052] There figure 2schematically illustrates a non-limiting functional representation of a device 1 for analyzing the behavior of an application brick 2 subject to a scarcity of resources in an IT infrastructure 4. The IT infrastructure 4 may comprise one or more IT structures 3 (e.g. server, machine, virtual machine) and the application brick(s) 2 may call upon one or more IT structures 3. The IT infrastructure 4 preferably designates a pre-production architecture having a configuration similar or identical to a production architecture and which may, for example, take the form of a virtual machine.

[0053] The device 1 comprises a storage module 10, a resource scarcity module 20, an injection module 30, a metrics collection module 40, a failure detection module 50, and an application performance management module 60. The device 1 can also be configured (e.g. via dedicated software) to implement the behavior analysis method according to the invention.

[0054] A memorization module 10is capable of, preferably configured to, store a plurality of repositories. For this purpose, the storage module 10 may comprise any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and / or non-volatile memory, such as read-only memory, flash memories, hard disks, optical disks and magnetic tapes. The storage module 10 may comprise a plurality of instructions or modules or applications for performing various functionalities. Thus, the storage module 10 may implement routines, programs, or matrix-type data structures. Preferably, the storage module 10 may comprise a medium readable by a computer system in the form of volatile memory, such as random access memory (RAM) and / or cache memory.The storage module 10 can, for example, be connected to the other components of the device 1 via a bus and one or more data carrier interfaces.

[0055] The storage module 10 is configured in particular to store a resource repository 11configured to store identification data of critical resources used by the application brick. The resource repository 11 may for example be configured to store identification data of the different virtual machines or partitions supporting the application brick(s) studied. The critical resource may for example be a RAM but many other resources may be considered such as reading / writing a disk, reading / writing a network, or the rate of use of a memory. In addition, the resource repository 11 may be configured to store the available quantity of critical resources (e.g. CPU number and power, quantity of memory).

[0056] More particularly, a critical resource may be a resource whose average consumption is greater than 60% or a resource whose consumption has one or more consumption peaks greater than 70% or a resource for which a loss of 20% or more of availability leads to a failure on the application brick studied. The device 1 according to the invention may also be able to identify which resources are important for the operation of the application brick.

[0057] The storage module 10 is also configured to store a reference 12 of execution rules. The execution rules repository 12 is configured to store data corresponding to predetermined quality of service parameter thresholds, beyond which the application brick is considered to be faulty (i.e. malfunctioning).

[0058] Advantageously, the execution rule repository 12 is configured to store several categories of predetermined thresholds of quality of service parameters with, for example, a category corresponding to the service levels beyond which an application brick is considered to provide a degraded but acceptable service and a category corresponding to the service levels beyond which an application brick is considered to be faulty. Thus, the category can correspond to an indicator of acceptability of the service level with, for example, values ​​of the type: expected operation, acceptable operation, unacceptable operation.

[0059] Preferably, the predetermined quality of service parameter thresholds comprise at least response time values, the predetermined quality of service parameter thresholds may also comprise CPU consumption, network or disk usage values. Several resources may be measured in parallel as well as several service level indicators may be monitored in parallel. Preferably, the service levels are measured regularly and may correspond for example to a search response time of less than one second.

[0060] Preferably, the execution rules repository 12 is configured to store data corresponding to predetermined quality of service parameter thresholds beyond which the application brick is considered to be faulty.

[0061] The storage module 10 is also configured to store a reference 13 of rarefaction.The scarcity repository 13 is configured to store rules for consuming critical resources that can be used for a progressive scarcity of critical resources. Thus, this scarcity repository 13 is configured to store instructions allowing the consumption and therefore the scarcity of the resources available for the application brick 2. Such consumption of resources can be carried out according to the noise generation method described in the document EP2975526.

[0062] Critical resources consumed through the implementation of consumption rules may include (but are not limited to) network type, conditions associated with the network, available transmit and / or receive bandwidth, available power / energy, available processor power (e.g. clock speed, number of cores, cache, etc.), and available amount of memory.

[0063] As mentioned, scarcity is generated via resource consumption, the consumed portion of which (i.e. used or occupied) is then no longer available for the application brick whose behavior is being studied. The scarcity reference 13 thus makes it possible to define consumption rules for a progressive modification of the scarcity of resources of different virtual machines.

[0064] Consumption rules can be considered as creating a degraded environment for the application brick(s) studied because the consumption rules can control how much of the IT infrastructure 4 resources the application brick(s) 2 studied access. The consumption rules for critical resources advantageously include at least the following data: a starting resource consumption level, corresponding for example to the lowest quantity of resource to be consumed; a final resource consumption level, corresponding for example to the highest quantity of resource to be consumed; a consumption increase step, corresponding for example to the difference between a first quantity of resource to be consumed and a following quantity, and a predetermined duration between each increase step.

[0065] Thus, reference 13 makes it possible to simply define a progressive scarcity of critical resources.

[0066] The existence of a predetermined duration between each increase step makes it possible to subject the application brick to a given scarcity of resources for a duration sufficient to cause a failure. Thus, the duration between each increase step may, for example, be greater than or equal to five minutes or greater than or equal to ten minutes. Advantageously, the duration between each increase step is not too long so as to allow a rapid study of the behavior of the application brick. For example, the predetermined duration between each increase step is less than two hours.

[0067] The repository 13 may take the form of one or more resource scarcity configuration files or instructions transmitted from a graphical interface or any other communication interface. Indeed, these values ​​may be pre-recorded or entered via an interface when implementing the study of the behavior of the application brick.

[0068] Some critical resource consumption rule data is advantageously entered when implementing the application brick behavior study. This is the case, for example, of the scarcity start date and the identifier of the critical resource to be scarified.

[0069] When this data is stored, it is stored, for example, in a resource scarcity configuration file, which may be an XML file, a CSV file, an INI file, or a JSON file. A configuration file contains one or more configuration records. Alternatively, the scarcity configuration file is stored in a database.

[0070] Additionally, consumption rules can specify an order of the different rarefactions to be performed and a duration during which each rarefaction must be performed.

[0071] The storage module 10 is also capable of, preferably configured to, store a application load reference 14. The application load repository 14 is configured to store a predetermined load plan, preferably representative of the operation of the application brick.

[0072] The predetermined load plan is representative of the typical operation, or nominal load, of application brick 2 to be tested. Thus, the predetermined load plan can be used to generate constraints on the IT infrastructure simulating the activity and therefore the use of resources by application brick 2 to be tested. The nominal load corresponds to the current activity on the application or the load usually observed in production for the application brick. This can correspond, for example, to a distribution of different types of scenarios reproducing the main actions of the application brick with, for example, how many scenarios per hour of each type must be played to mimic the operation of the application brick.Indeed, during the method according to the invention, to simulate the operation of the application brick, it is not necessary to reproduce the exhaustiveness of the actions or requests supported by said application brick during its current use. Thus, the set of requests can be limited to the simulation of the main business scenarios in which the application brick is involved.

[0073] Thus, the load plan advantageously includes values ​​for the following parameters: the different types of scenario, the weighting of each of these business scenarios (e.g. the relative proportion of some compared to others), and the overall load level (e.g. the target volume or the desired request rate during the process). Equivalently, it can include information on the number of scenarios of each type executed simultaneously, for example for an hour. It can also include information on the IT infrastructure tested.

[0074] The set of queries is generally recorded in a load command file containing the code to be executed. Execution of the load command file can produce a number of actions as diverse as creating, consulting, modifying, deleting files or printing, copying and displaying data. These actions will generally be similar to the main business actions supported by the application brick. Thus, as will be detailed later, the method according to the invention can also include a step of loading a load command file.

[0075] This application load repository 14 can be configured to store instructions, in the form of a load plan, making it possible to simulate the activity of the application brick 2 studied. The load plan configuration file can also include fields relating to the start date of the load, for example an absolute date evaluated relative to an internal clock of the device 1 or a date relating to the start of a test scenario. It can also include the end date of the load or the duration of the load, for example a number of seconds.

[0076] Furthermore, the storage module 10 may be capable of, preferably configured to, store a knowledge base 15 configured to store predetermined failure data based on runtime data.

[0077] Thus, the knowledge repository 15 includes data relating to the different sources and natures of application brick failures (i.e. predetermined failure data) which are correlated with execution data. It can therefore be used to generate information on application brick failures based on measured execution data.

[0078] Preferably, the knowledge repository 15 may include a list of failure natures based on measured execution data.

[0079] Furthermore, the storage module 10 may be capable of, preferably configured to, store a reference 16 of evolution rules.The evolution rules repository 16 is configured to store predetermined failure parameters and corrective action data associated with predetermined failure parameters. Thus, the evolution rules repository 16 can be configured to store associations between predetermined failure parameters (e.g. execution data and / or nature of failure) and data relating to at least one corrective action.

[0080] Advantageously, the data relating to at least one corrective action may include reports intended for an administrator or executable instructions allowing the configuration of the IT infrastructure or the application brick to be modified (e.g. Java Messaging Service - JMS, Java Database Connectivity - JDBC).

[0081] Preferably, the evolution rules repository 16 is configured to store corrective actions based on failure data.

[0082] Furthermore, the storage module 10 may be capable of, preferably configured to, store a repository 17 of accessible resources. The repository 17 of accessible resources is configured to store data characteristic of accessible resources. Preferably, the data characteristic of accessible resources comprises, for at least one type of resource, data on the available quantity of the accessible resource as well as data corresponding to an indicator of the complexity of making the accessible resource available.

[0083] The accessible resources are, for example, unassigned resources that the IS administrator can assign to the IT infrastructure 4 and more particularly to the application brick 2 whose behavior is being studied. Thus, this repository 17 can correspond to a listing of data on resources that can be added to the IT infrastructure 4 in order to improve the resilience of the application brick 2 being studied.

[0084] The repository 17 may contain, in particular, for each resource: its type, its quantity, the list of compatible servers. Thus, the characteristics of available resources may preferably include: data identifying the available resource, data on the type of resource available, a list of IT structures 3 (eg servers) compatible with the available resource, and / or data on the quantity of resource available.

[0085] This reference may also include data relating to the complexity of integrating said resource. The data corresponding to an indicator of evolution complexity is representative of the complexity of evolving (i.e. downwards and / or upwards) the resources of the IT structure(s) 3. For example, depending on the resources, these may be in stock (i.e. low complexity) or already used on another server (i.e. high complexity). In addition, adding or removing RAM and adding a disk are relatively easy and quick actions, whereas removing a disk is a more delicate operation. In addition, adding power to a virtual server is very easy.

[0086] Advantageously, the repository 17 of accessible resources also includes data corresponding to a compatibility indicator. The compatibility indicator makes it possible to determine on which computer structures the available resource can be installed. The data stored via the repository 17 of accessible resources are generally entered by a user via an HMI. The data stored via the repository 17 of accessible resources can also be received via a communication module and come from accessible resource inventory management software.

[0087] Table 2 below illustrates a repository 17 of resources accessible according to an embodiment detailing the compatibility according to the IT structures 3 (S1, S2-Virt, S3). Table 2 Resource type Compatibility Quantity Complexity indicator Disk - 4 TB S1, S3 10 1 Memory - 2 GB S1, S3 10 3 Memory - 1 GB S2-Virt 8 GB 1

[0088] The device according to the invention comprises a 20 resource scarcity module. The resource scarcity module 20 is capable of, preferably configured to, generate a controlled consumption of at least one critical resource according to the consumption rules previously stored in the scarcity repository 13.

[0089] The resource scarcity module 20 advantageously has the function of progressively simulating the scarcity of a critical resource. Thus, it is possible to progressively increase the scarcity of the critical resource until it causes a failure of the application or application brick 2.

[0090] Preferably, the resource scarcity module 20 is configured to generate a controlled consumption of at least one critical resource according to the consumption rules previously stored in the scarcity repository 13. There may be a consumption of one critical resource or a simultaneous consumption of several critical resources.

[0091] For example, the scarcity of a resource may be based on all or part of the following data: an identifier of the component or resource to be disturbed: for example a network address; a value for the start date of the rarefaction, this could for example be an absolute date evaluated relative to an internal clock of the device producing the rarefaction; and a value for the duration of the rarefaction (eg number of seconds) or a value for the end date of the rarefaction.

[0092] These values ​​may for example be acquired by the resource scarcity module 20 via a call to one or more resource scarcity configuration files of the scarcity repository 13 or else to instructions transmitted from an interface (e.g. graphical). Thus, the scarcity module 20 may be configured to receive and take into account consumption rules. These consumption rules are for example entered via a graphical interface and stored in a memory, for example a RAM.

[0093] The rarefaction repository 13 coupled with the rarefaction module 20 allow the generation of codes whose execution results in the implementation of the rarefaction (i.e. the consumption of resources). These codes are either object codes, for example for the rarefaction of memory, or so-called "shell" scripts or shell scripts. The codes can also be compilable codes, the compilation being carried out at the time of the implementation of the rarefaction.

[0094] As will be detailed below, the device is configured to carry out the scarcity of resource(s) in parallel with maintaining a load level of the application brick to be qualified (i.e. studied).

[0095] The device 1 according to the invention also comprises an injection module 30.The injection module 30 is capable of, preferably configured to, subject the IT infrastructure 4 to a load corresponding to the application load of the application brick 2 according to a predetermined load plan stored in the application load repository 14. Preferably, the load corresponds to the nominal application load.

[0096] The load data, contained in the load plan, can be used by the injection module 30 in order to create a load plan making it possible to simulate an activity of the application brick with, for example, the opening and sending of files, backups or even internet browsing.

[0097] The submission of the IT infrastructure 4 to the application load is preferably achieved by using injection mechanisms such as JMeter, Tsung or Gatling. Preferably, this is achieved by injecting requests according to a predetermined load plan.

[0098] The device 1 according to the invention also comprises a Metrics Collection Module 40. The metrics collection module 40 is capable of, preferably configured to, measure the consumption of the resources of the IT infrastructure 4 and / or the service levels of the application brick 2. Preferably, the metrics collection module 40 is configured to generate measured values ​​of service levels of the application brick.

[0099] To do this, the metrics collection module 40 may use a probe 41 or a plurality of probes 41. The probe(s) 41 make it possible to collect data on the consumption of the resources of the IT infrastructure 4 and more particularly of each application structure 3 comprising it. Several resources may be measured in parallel. The probe(s) 41 may also be used to measure the service levels of the application brick 2. The collection module 40 may use a monitoring file comprising metrics collection rules. These metrics collection rules may specify data that must be recorded during the execution of the application brick.

[0100] These measurements can, for example, be carried out using a probe such as "Nigel's Monitor" (Nmon) or "Performance Monitor" (Perfmon). Nmon probes allow, for example, the display of CPU, memory, swap, network data, information on users, groups, storage media, kernel usage, or the most power-consuming processes. Perfmon probes allow the performance of an IT infrastructure to be measured. The information collected can, for example, correspond to resource usage percentages, response times, processing times, but also the status of ports, the number of JDBC or JMS message queues, the file system occupancy rate, the operating rate of the garbage collector for J2EE (Java Enterprise Edition) applications.

[0101] These probes can be associated with each parameter (e.g. resource or functionalities) to report measurement or metric information, representing for example the operating status of the resources and the associated consumption. For each parameter, the probe(s) define a parameter identifier and a parameter value. The parameter values ​​can be monitored continuously or at configurable intervals so as to obtain information for each parameter as a function of time. This information can be stored in a memory. In certain embodiments, the device comprises a human-machine interface making it possible to define the probes on each machine which report the metrics originating from the use of the machine's resources.

[0102] The metric collection module 40 allows you to collect and measure resource consumption and / or service levels of the application brick.

[0103] The device according to the invention also comprises a fault detection module 50. Detecting a failure via measured service level values ​​makes it possible to monitor the performance of the application brick and can, for example, refer to the performance observed by end users of the application brick, such as, for example, an average response time.

[0104] The failure detection module 50 is capable of, preferably configured to, compare the predetermined quality of service parameter thresholds with the measured values ​​of the resource consumption and / or the service levels of the application brick. The failure detection module 50 is generally configured to identify an exceedance of the predetermined maximum values ​​by the measured values.

[0105] Thus, the failure detection module 50 is advantageously configured to allow IS administrators to implement rules defining which types of events constitute abnormal behavior and to analyze the collected data to identify when abnormal behavior has occurred during the controlled consumption of resources. The failure detection module 50 may further be configured to, in the presence of an overrun, interrupt the controlled consumption.

[0106] The device according to the invention also comprises a application performance management module 60. The application performance management module 60 is capable of, preferably configured to, in the presence of an exceedance, the predetermined quality of service parameter thresholds, analyze the behavior of the application brick and generate failure data capable of providing information on the nature and / or the source of the failure.

[0107] Thus, once a failure has been caused, the device 1 according to the invention can determine, in particular using the application performance management module 60, the nature of the failure. The failure can have many natures. For example, it can be linked to system configuration problems (number of open files, number of ports, etc.) as well as to application configuration problems (jms file, jdbc pool, etc.) or even to application brick design problems such as too strong coupling between processing operations.

[0108] Preferably, the application performance management module 60 is configured to implement profiling or trace analysis functionalities in order to identify the nature of the failure.

[0109] In particular, the application performance management module 60 is configured to perform monitoring and tracking of individual transactions and to provide data describing the internal execution details, performance and behavior of each individual monitored transaction.

[0110] For this, the application performance management module 60 may comprise trace collectors 61 deployed on the processes involved in the execution of the application brick studied. These trace collectors 61 are configured to identify the transactions executed by the processes of the application brick studied and capture the execution details of these transactions. These trace collectors 61 may also monitor the incoming and outgoing communications carried out by the processes with which they are associated so as to correlate trace data of a transaction with the parties (e.g., components or third-party application bricks) involved in this transaction.

[0111] The application performance management module 60 may for this purpose comprise one or more trace collectors 61. A trace collector is configured to monitor the execution of the application brick and create an execution trace. For example, the trace collector 61 may record information associated with the execution of the application brick, such as other application bricks with which the application brick communicates and which memory areas the application brick accesses. This information from the trace collector(s) 61 may be collected and stored as data and then analyzed by the application performance management module 60.

[0112] The application performance management module 60 is therefore advantageously configured to process execution data (i.e. traces) in response to the detection of a failure. For example, the trace collectors 61 can execute so as to generate an execution trace when the memory usage exceeds a predetermined threshold and then the module processes the data so as to identify the nature of the failure.

[0113] Preferably, the application performance management module 60 is configured to monitor parameters of the execution of the application brick studied while the controlled consumption of resources is carried out.

[0114] This runtime data may be correlated with the scarcities to determine what scarcities levels caused the application behavior (e.g., performance degradation, excessive consumption of one or more resources). For example, the application performance management module 60 may correlate the scarcities with the monitored service level data (e.g., using timestamps or other information). Thus, advantageously, the application performance management module 60 may be configured to correlate a level of available resources to a service level.

[0115] Furthermore, the application performance management module 60 may correlate the execution details of the transactions performed during the scarcities and in particular during a failure so as to identify the nature of the failure. For example, the application performance management module 60 may correlate the scarcities with the monitored execution data to determine that a decrease in the amount of available memory may cause an undesired increase in disk reads / writes (I / O), or that a certain processor speed may cause an increase in memory usage, or that a storage device is failing because it cannot support a moderate increase in I / O. Thus, the application performance management module 60 is preferably configured to identify the nature of the failure. The nature of the failure may, for example, be related to the IT infrastructure (e.g.hardware or software configuration) or to the application brick (eg configuration or design).

[0116] Thus, the application performance management module 60 is preferably configured to select the nature of the failure from among the following failures: hardware configuration of the IT infrastructure, software configuration of the IT infrastructure, configuration of the application brick, and design of the application brick.

[0117] Performance management module 60 provides information on the nature and / or source of the failure.

[0118] Advantageously, the device according to the invention can also comprise a 70 module for improving resilience.This module makes it possible, from a repository 16 of evolution rules, to select the solution(s) to be implemented depending on the type of failure (i.e. source and / or nature). Thus, the resilience improvement module 70 is capable of, preferably configured to, select at least one corrective action from the failure data generated by the application performance management module 60 and from a repository 16 of evolution rules comprising predetermined values ​​of the failure parameters.

[0119] The resilience improvement module 70 is preferably configured to compare the nature of the identified failure and / or the measured execution data to predetermined values ​​of the failure parameters.

[0120] For example, if the nature of the identified failure in the presence of resource scarcity is faulty or excessive I / O, then the selected corrective action may correspond to an instruction to change the storage device concerned. Alternatively, depending on the number of I / O requests, the selected corrective action may correspond to an instruction to increase the amount of memory on one or more computing structures 3 so as to avoid overloading the disks in the presence of resource scarcity.

[0121] The resilience improvement module 70 may be configured to send an administrator an instruction comprising data relating to at least one corrective action. Alternatively, the resilience improvement module 70 may be configured to execute a corrective action such as, for example, opening additional ports. Thus, it may be capable of, preferably configured to, implement said corrective actions to enable the application (i.e. the application brick) to be resilient to a scarcity of resources.

[0122] Thus, advantageously, the resilience improvement module 70 monitors the application brick and processes the execution data associated with the application brick. The resilience improvement module 70 analyzes the collected execution data and / or the failure data to associate an identified failure with a predetermined corrective action and recorded in a repository 16 of evolution rules.

[0123] Advantageously, the device according to the invention can also comprise an 80 infrastructure evolution module. The infrastructure evolution module 80 is capable of, preferably configured to, generate at least one evolution plan listing resource modifications to be made in the IT infrastructure 4 from the characteristic data of accessible resources from the repository 17 of accessible resources and the failure data.

[0124] The different modules or repositories are distinct on the figure 2but the invention can provide various types of arrangement such as for example a single module combining all the functions described here. Similarly, these means can be divided into several electronic cards or else gathered on a single electronic card.

[0125] The device 1 according to the invention may be integrated into a computer system and thus be able to communicate with one or more external devices such as a keyboard, a pointing device, a display, or any device allowing a user to interact with the device 1. It should be understood that although not shown, other hardware and / or software components could be used in conjunction with a device 1. Thus, in one embodiment of the present invention, the device 1 may be coupled to a human machine interface (HMI). The HMI, as already discussed, may be used to allow the transmission of parameters to the devices or conversely make available to the user the values ​​of the data measured or calculated by the device. Generally, the HMI is communicatively coupled with a processor and it comprises a user output interface and a user input interface.The user output interface may include a display and audio output interface and various indicators such as visual indicators, audible indicators, and haptic indicators. The user input interface may include a keyboard, mouse, or other cursor navigation module such as a touchscreen, a touchpad, a stylus input interface, and a microphone for inputting audible signals such as user speech, data, and commands that can be recognized by the processor.

[0126] In one embodiment of the present invention, the device 1 may be coupled to a communication interface, for example a network interface of the Ethernet, FiberChannel, InfiniBand type or any devices allowing the device 1 to communicate with one or more other computing devices.

[0127] Furthermore, as will be appreciated by those skilled in the art, aspects of the present invention may be embodied as a system, method, or computer program product. Accordingly, aspects of the present invention may take the form of an all-hardware embodiment, an all-software embodiment (including firmware, resident software, microcode, etc.), or a particular embodiment such as a "circuit," "module," or "system." Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0128] Any combination of one or more computer-readable media may be used. In the context of this document, a computer-readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. A computer-readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include: a hard disk drive, random access memory (RAM).

[0129] Computer program code for performing operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, C++ or the like, the "C" programming language or similar programming languages, a scripting language such as Perl, or similar languages, and / or functional languages ​​such as Meta Language. The program code may execute entirely on a user's computer, partly on a user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to a user's computer by any type of network, including a local area network (LAN) or a wide area network (WAN).

[0130] These computer program instructions may be stored on a computer-readable medium capable of directing a computing device (e.g., computer, server, etc.), such that the instructions stored in the computer-readable medium produce a computing device configured to implement the invention.

[0131] According to another aspect, the invention relates to a process for analyzing the behavior of an application brick 2 subject to a scarcity of resources in an IT infrastructure4.

[0132] The method can be implemented by a device 1 according to the invention and more particularly by a device 1 according to the preferred embodiments of the invention.

[0133] More generally, the method according to the invention can be implemented by a behavior analysis device comprising a storage module 10, a resource scarcity module 20, an injection module 30, a metrics collection module 40, a failure detection module 50, and an application performance management module 60.

[0134] As presented in the figure 3 , the method according to the invention may comprise a 100 data acquisition step.This acquisition step 100 corresponds for example to the loading 120 of the parameters and operating rules allowing the implementation of the method. This step can be carried out just before the following steps of the method. This data acquisition step 100 more particularly comprises the loading 120 of data, preferably stored on a storage module 10 according to the invention, including data identifying critical resources used by the application brick, data corresponding to predetermined quality of service parameter thresholds, beyond which the application brick is considered to be faulty, rules for consumption of critical resources for a progressive scarcity of critical resources and a predetermined load plan representative of the operation of the application brick.

[0135] The method according to the invention may also include a prior storage step 110 corresponding to the recording of the parameters and operating rules enabling the implementation of the method. This step may be carried out just before the following steps of the method or may be carried out well before.

[0136] In addition, the figure 4illustrates steps of preparing the device and / or initiating the method according to the invention. Beforehand, the method according to the invention may comprise the reception 140 of probe data 41. This data may be processed so as to define 150 the application load so as to establish a load plan comprising data relating to the level of resource use by said application brick, as a function of time. The probe data 41 may also be processed so as to identify 160 the critical resources. In parallel, or successively, the method may comprise the choice 170 of the application brick to be studied, for example via an interface, as well as the definition 180 of the consumption rules allowing a progressive scarcity. Once this data has been defined or acquired, it may be loaded 120 by the device 1.

[0137] As illustrated in the figure 3 , the method according to the invention comprises a generation step 200 of controlled consumption of at least one critical resource according to the consumption rules previously stored, for example on a scarcity reference 13. This controlled consumption generation step 200 can for example be carried out by a resource scarcity module 20.

[0138] There Figure 5 presents a detailed illustration of the sub-steps that can be implemented during the generation 200 of the controlled consumption of at least one critical resource. This controlled consumption can begin with the loading 210 into memory of the instructions included in a rarefaction repository 13 and detailing the type of rarefaction to be implemented. At this stage, a user can viaa user client 5 configures 220 the duration of the rarefaction, for example, by modifying the instruction codes of the rarefaction according to the desired duration of the rarefaction. Once the possible settings have been made, the rarefaction module 20 integrates the rarefaction data and the settings so as to generate 230 a resource rarefaction configuration file comprising the instruction codes capable of generating the desired rarefaction. Then, it identifies the device(s) or computer structures 3 which must undergo the rarefaction and transfers 240 the resource rarefaction configuration file to them. Finally, it can initiate 250 the execution of the instruction codes on said devices

[0139] Thus, the rarefaction can be deployed from the behavior analysis device on IT infrastructures and then executed by these IT structures 3 according to a schedule managed by the IT structures 3.

[0140] As illustrated in the figure 3 , the method according to the invention also comprises a submission step 300 of the IT infrastructure 4 to an application load, said application load being representative of the operation of the application brick 2. This step 300 of generating an application load can for example be carried out by an injection module 30.

[0141] As already discussed, this application load which is injected onto the IT infrastructure 4 preferably corresponds to the nominal load of the application brick when the application chain concerned operates in nominal mode. Thus, during this step, the IT infrastructure 4 will be subjected to a load corresponding to the nominal application load of the application brick 2 according to a predetermined load plan stored on the application load repository 14.

[0142] The method according to the invention also comprises a resource consumption measurement step 400 of the IT infrastructure 4 and / or service levels of the application brick 2. This step of measuring 400 the consumption of resources can for example be carried out by a module 40 for collecting metrics.

[0143] As mentioned, the measurement step 400 can be carried out by means of computer probes. Advantageously, the computer probe mechanism is started before the scarcity of resources and the implementation of the load plan. This makes it possible, on the one hand, to quickly identify degradations in performance or service levels (such as response times) beyond a predetermined limit and to identify resources having a utilization value greater than a predetermined maximum utilization threshold and therefore that the resource is at risk of failure.

[0144] The method may also include a step of storing the measured values ​​of resource usage during the execution of all the requests.

[0145] The method according to the invention also comprises a comparison step 500 of the predetermined thresholds of quality of service parameters with the measured values ​​of service levels of the application brick.Furthermore, in the presence of an overrun, the method can interrupt the controlled consumption. This comparison step 500 can for example be carried out by a failure detection module 50.

[0146] The measured QoS parameter values ​​are in line with the QoS parameter threshold values ​​when they have not crossed the predetermined thresholds. For example, when the response time of a request has remained below the predetermined QoS parameter threshold for the response time to that request.

[0147] The method may also include a step of storing the measured values ​​of resource usage during the execution of all the requests.

[0148] The method according to the invention also comprises, in the presence of an overshoot, a step 600 of analyzing the behavior of the application brick 2 and identifying the nature and / or source of the failure.This analysis step 600 may, for example, be carried out by an application performance management module 60. This analysis may, for example, consist of determining whether different hypotheses have been proven, detecting anomalies or estimating an impact on users.

[0149] This analysis step may include processing of the application brick's log files and / or data generated by trace collectors such as Profiling ®< , J profiler ®< or Dynatrace ®< .

[0150] The method according to the invention may advantageously include a step of improving resilience comprising the identification of corrective actions corresponding to the nature of the identified failures. This step may for example be carried out by a resilience improvement module 70. In addition, the method according to the invention may include a step 800 of implementing the corrective actions or verifying their implementation.

[0151] For example, the method according to the invention may include a step of modifying the level of a resource of the IT infrastructure before re-executing the steps of the method. Indeed, when the method makes it possible to identify a corrective action consisting of increasing a critical resource level, the method includes a step making it possible to implement in an automated manner, for example viaa script, said modification or optimization and then re-execute the resource scarcity and the application load in order to determine whether the resilience of the application brick has actually been improved following the modification of the resources. The resource level that can be modified can for example be selected from: the number of CPUs allocated, the amount of memory available and the number of ports that can be opened simultaneously. Such a step can for example be implemented by an infrastructure evolution module 80.

[0152] Preferably, the level of a single resource is modified at this stage. Indeed, the modification of a single resource at a time makes it possible to better identify the consequences of this modification on the quality of service of the application brick as well as on the use of resources. Ideally, a single resource is modified at a time and this resource is modified iteratively until the resilience of the application brick with respect to a scarcity of this resource reaches the expected level.

[0153] Changing the resource level can be done by the resource step. In this case, the level of said resource is changed by subtracting or adding at least one step of that resource to its current resource level value. The magnitude of the change in the level of a resource is then equal to one or more steps of said resource.

[0154] The level of certain resources may be modified automatically within the framework of the method of the invention without external intervention. Indeed, certain resources may be modified via scripts executed on the IT infrastructure 4 and capable of providing access to new resources. However, not all resources may be modified in this way by a software action and certain resources will require the intervention of an operator capable of physically modifying the IT infrastructure in order to increase the level of the resource.

[0155] Thus, the method according to the invention may include a step of determining a mode of modification of the resource. For this, each resource may be associated with information concerning the method of modification of said resource. For each of the resources, the method may call upon a file comprising metadata making it possible to know, for example, whether the resource is modifiable, which scripts must be called to modify the resource, and whether said resource will require a restart of the machine or whether hot modification is possible. The resources that can be easily modified, for example by means of a dedicated script, are typically: CPU configuration of a machine, memory configuration of a machine and number of ports that can be opened simultaneously.

[0156] Alternatively, the method according to the invention may comprise a step of generating an alert, said alert comprising an identifier of the resource whose level is to be modified and an instruction on the level to be reached. When the resource to be modified requires manual intervention for its modification, this allows an operator to manually modify the quantity of resource available for the application brick.

[0157] There figure 6 illustrates a method according to one embodiment of the invention. The method can be initiated by loading 120 stored data necessary for implementing the method. This includes here, a step of acquiring the configuration of the scarcity of resources on the one hand and the application load on the other hand. This data may have been previously stored in repositories or have been transmitted by a human-machine interface and then preferably stored.

[0158] Then, there is controlled consumption 200 of at least one critical resource of the application brick 2 on an IT infrastructure 4 such as a consumption of the available RAM and an implementation 320 of the nominal load of the application brick. These two steps can be ordered indifferently provided that they are executed in parallel (i.e. concomitantly). They are implemented by the execution of commands in a scripting language. These steps are carried out in a test environment allowing the behavior of the application brick to be controlled as best as possible.

[0159] From data from the metric collection 420, the method implements a comparison 520 of data so as to identify a failure. In the absence of failure (NOK), the method may comprise a step 521 of comparing the controlled consumption to a maximum threshold of controlled consumption so as to determine whether the scarcity can be increased. If this is the case (NOK), the scarcity is reconfigured 522 so as to increase the controlled consumption and then it is implemented again. If the maximum threshold of controlled consumption has been reached (OK), then the method may comprise a step 523 making it possible to determine whether all the critical resources have been tested (i.e. scarified). If there are still resources to be tested (NOK), then it comprises a step 524 of modifying the critical resource to be scarified while if there are no resources left to be tested (OK), then resilience is reached 525 for this application brick.

[0160] If a failure is identified during the data comparison step 520 (OK), then the method comprises a failure analysis step 600 and then, from generated failure data, the method may comprise a step 720 of selecting at least one corrective action instruction, preferably by a resilience improvement module 70. If a corrective action is identified (OK), then the method comprises a corrective action application step 721, whereas in the absence of corrective action (NOK), the method may comprise a step 523 for determining whether all critical resources have been tested (i.e., made scarce).

[0161] There figure 7illustrates an analysis 600 of the failure according to an embodiment of the invention. This analysis may comprise a first step of analyzing the implication of the design 610 of the application brick in the failure following a scarcity of a critical resource. If during this step, comprising for example an analysis of a trace collector file, it is determined that the design of the application brick is involved (OK) in the failure then the method comprises a step of generating 611 a report comprising the collected trace data then a step of determining 612 the existence or not of other critical resources to be tested for this application brick. If this is the case (OK) then there is a modification 613 of the critical resource to be scarce and if not (NOK) then the analysis of the behavior of this application brick is finalized and a report is generated 650.

[0162] If it is determined that the design of the application brick is not involved in the failure (NOK) then the method comprises a step of analyzing the involvement of the configuration 620 of the application brick in the failure. If during this step, comprising for example an analysis of a trace collector file, it is determined that the configuration of the application brick is involved in the failure following a scarcity of a critical resource then the method comprises a step of generating 621 a report comprising data on the faulty configuration of the application brick and a step of modifying 622 the configuration files of the application brick. The method then comprises a reinitialization 660 of the analysis with an application brick having a modified configuration.

[0163] If it is determined that the configuration of the application brick is not involved in the failure (NOK) then the method comprises a step of analyzing the involvement of the resources 630 of the IT infrastructure 4 in the failure. If during this step, comprising for example an analysis of a trace collector file, it is determined that one or more resources are involved in the failure following a scarcity of a critical resource then the method comprises a step of generating 631 a report comprising data on the faulty resource(s) and a step of modifying 632 the resources of the IT infrastructure. The method then comprises a reinitialization 660 of the analysis with an application brick having a modified configuration.

[0164] If it is determined that the resources of the IT infrastructure are not involved in the failure (NOK) then the method comprises a step 633 of generating a report. This can be followed by a step 634 of determining the existence or not of other critical resources to be tested for this application brick. If this is the case (OK) then there is modification 635 of the critical resource to be made scarce and if not (NOK) then the analysis of the behavior of this application brick is finalized and a report is generated 650.

[0165] Once any corrections have been made to the configuration of the application brick or the IT infrastructure, or if IT infrastructure resources have been modified, the behavior analysis process is reset to validate that the adaptations now allow the application to be resilient to resource scarcity. If this is indeed the case, we can decide to continue scarcity of said resource to validate the resilience of the application beyond the breaking point found previously or test the resilience of the application on another type of resource.

[0166] Thus, the present invention makes it possible to automatically analyze the behavior of an application brick as well as its resilience to the scarcity of resources and, if necessary, to make modifications to increase said resilience. This, as well as all these advantages previously described, therefore contribute to facilitating the management of an IT infrastructure for an IT administrator and to increasing the resilience of the application bricks that it supports without having to systematically increase the quantities of resources allocated.

Claims

1. Device (1) for analyzing the behavior of an application component (2) subjected to an increasing scarcity of resources in a computing infrastructure (4), said device comprising: - means for identifying critical resources used by the application component, a critical resource being a resource of which the use under nominal conditions is closest to the limit use or the saturation thereof; - a storage module (10), configured to store a plurality of repositories including: ∘ a resource repository (11), configured to store data for identifying critical resources used by the application component, ∘ an execution rules repository (12), configured to store data corresponding to predetermined quality-of-service parameter thresholds, beyond which the application component is considered to have failed, ∘ an increasing scarcity repository (13), configured to store critical resource consumption rules for progressive scarcity of critical resources, and ∘ an application load repository (14), configured to store a predetermined load plan representative of the operation of the application component; - an increasing resource scarcity module (20), configured to generate a controlled consumption of at least one identified critical resource according to the consumption rules previously stored in the increasing scarcity repository (13); - an injection module (30), configured to subject the computing infrastructure to an application load representative of the operation of the application component (2) according to the load plan stored in the application load repository (14); - a metrics collection module (40), configured to measure the consumption of resources of the computing infrastructure (4) and / or the service levels of the application component (2); - a failure detection module (50), configured to compare the predetermined quality-of-service parameter thresholds with the measured values of the resource consumption and / or service levels of the application component; and - an application performance management module (60), configured to, when predetermined quality-of-service parameter thresholds are exceeded, analyze the behavior of the application component and generate failure data capable of providing information on the nature and / or source of the failure.

2. Behavior analysis device according to claim 1, characterized in that the failure data generated includes a piece of data on a level of increasing resource scarcity that the application component (2) can withstand before suffering a failure.

3. Behavior analysis device according to either claim 1 or claim 2, characterized in that the application performance management module (60) is configured to select the nature of the failure from: - hardware configuration of the computing infrastructure, - software configuration of the computing infrastructure, - configuration of the application component, and - design of the application component.

4. Behavior analysis device according to any of claims 1 to 3, characterized in that it further comprises a knowledge repository (15) configured to store predetermined failure data based on execution data, in that the application performance management module (60) comprises trace collectors (61), said trace collectors (61) being configured to collect execution data, and in that the application performance management module (60) is configured to generate the failure data from the knowledge repository (15) based on collected execution data.

5. Behavior analysis device according to any of claims 1 to 4, characterized in that it further comprises a development rules repository (16) configured to store corrective actions based on failure data, and a resilience improvement module (70) configured to identify corrective actions from failure data generated by the application performance management module (60).

6. Behavior analysis device according to claim 5, characterized in that the execution rules repository (12) is configured to store a plurality of categories of predetermined quality-of-service parameter thresholds, including a so-called acceptable category, corresponding to the service levels beyond which the application component is considered to provide a degraded but acceptable service, and in that the resilience improvement module (70) is configured to implement said corrective actions so that the application component (2) provides service levels corresponding to the so-called acceptable category despite an increasing scarcity of resources.

7. Behavior analysis device according to either claim 5 or claim 6, characterized in that the resilience improvement module (70) is configured to implement said corrective actions or to verify the implementation thereof in order to enable the application to be resilient to increasing resource scarcity.

8. Behavior analysis device according to any of claims 1 to 7, characterized in that it further comprises an accessible resource repository (17) configured to store accessible resource characteristic data, and an infrastructure development module (80) configured to generate at least one development plan listing resource modifications to be carried out in the computing infrastructure (4) from accessible resource characteristic data and failure data.

9. Behavior analysis device according to any of claims 1 to 8, characterized in that the critical resource consumption rules comprise at least the following data: - an initial level of resource consumption, - a final level of resource consumption, - an increase step in consumption, and - a time between each increase step.

10. Method for analyzing the behavior of an application component subjected to an increasing scarcity of resources in a computing infrastructure, said method being implemented by a behavior analysis device comprising a storage module (10), an increasing resource scarcity module (20), an injection module (30), a metrics collection module (40), a failure detection module (50), and an application performance management module (60), said method comprising the following steps: - identifying (160) critical resources, a critical resource being a resource of which the use under nominal conditions is closest to the limit use or the saturation thereof; - generating (200) on a computing infrastructure, via the increasing resource scarcity module (20), a controlled consumption of at least one identified critical resource according to the previously stored consumption rules; - subjecting (300) the computing infrastructure, via the injection module (30), to an application load representative of the operation of the application component (2) according to a load plan stored, for example, in an application load repository (14); - measuring (400), via the metrics collection module (40), the consumption of resources of the computing infrastructure (4) and / or the service levels of the application component (2); - comparing (500), via the failure detection module (50), predetermined quality-of-service parameter thresholds with the measured service level values of the application component (2) in order to identify when these thresholds are exceeded; and - when predetermined quality-of-service parameter thresholds are exceeded, analyzing (600) the behavior of the application component (2) and generating, via the application performance management module (60), failure data capable of providing information on the nature and / or source of the failure.

11. Method for analyzing the behavior of an application component according to claim 10, characterized in that it further comprises a step of selecting (720) at least one corrective action instruction if a failure is identified, and a step of applying the identified corrective action (721).

12. Method for analyzing the behavior of an application component according to either claim 10 or claim 11, characterized in that, if it is determined that the design of the application component is involved in the failure, the method comprises a step of generating (611) a report comprising collected trace data and then a step of determining (612) whether or not there are other critical resources to be tested for this application component.

13. Method for analyzing the behavior of an application component according to claim 12, characterized in that, if it is determined that there are other critical resources to be tested for this application component, then the method further comprises the modification (613) of the critical resource to be made increasingly scarce and otherwise the analysis of the behavior of this application component is finalized and a report is generated (650).

14. Method for analyzing the behavior of an application component according to any of claims 10 to 13, characterized in that, if it is determined that the configuration (620) of the application component is involved in the failure, then the method comprises a step of generating (621) a report comprising a piece of data on the failed configuration of the application component and a step of modifying (622) configuration files of the application component.

15. Method for analyzing the behavior of an application component according to any of claims 10 to 14, characterized in that, if it is determined that one or more resources are involved in the failure as a result of an increasing scarcity of a critical resource, then the method comprises a step of generating (631) a report comprising a piece of data on the failing resource(s) and a step of modifying (632) the resources of the computing infrastructure.