System, computer-implemented method, and computer program (grouping unusual components of distributed applications)

Abstract

To provide a system, a device, and a computer program for maintaining soundness of an application to be implemented using a micro service architecture.SOLUTION: In a system comprising a process that executes computer executable components stored in a memory, the computer executable components are composed of a graph compiler and a partitioning component. The graph compiler generates a hypernode graph for a distributed application using causality data inferred from log data generated by services emitting errors. The distributed application includes the services. The partitioning component clusters the services into a plurality of groups using the hypernode graph and an objective function.SELECTED DRAWING: Figure 6

Description

[Technical Field]

[0001] One or more embodiments herein relate to computing devices, and more particularly to a system, device, computer-implemented method or computer program product, or combination thereof, that facilitates fault isolation of distributed applications. [Background technology]

[0002] Microservices architectures are becoming increasingly popular when designing software applications because they enable developers to operate on independent schedules and deliver at high velocity, thereby reducing time to market. For applications deployed to hybrid cloud environments, microservices architectures are particularly attractive because the loosely coupled components of an application (e.g., a distributed application) implemented using a microservices architecture improve scalability, flexibility, and maintainability, and increase developer productivity. As a result, developers are switching from traditional monolithic architectures to microservices architectures. Summary of the Invention [Problem to be solved by the invention]

[0003] Maintaining the health of applications implemented using a microservices architecture presents a challenge for information technology (IT) professionals, such as DevOps and site reliability engineers (SREs). For example, a failure in a distributed application may result in multiple services of the application becoming unhealthy or otherwise failing. As another example, a failure in one service of a distributed application may spread to one or more other services of the application. As another example, multiple services of a distributed application may experience errors simultaneously. Therefore, grouping erroneous services of a distributed application and isolating such erroneous services into multiple buckets can be an important task to facilitate fault point identification or error detection in a distributed application.

[0004] Because instrumentation and tracing using metric data can incur additional overhead costs, log data can generally be used to facilitate fault location or error detection in distributed applications. Techniques that use log data to group erroneous services in a distributed application generally use the text portion of the log lines that make up the log data to separate such services into multiple buckets. Such techniques may not be able to explain causal relationships between services or error log templates. Furthermore, such technical techniques may not be able to take into account tokens that may flow between services in a distributed application. [Means for solving the problem]

[0005] The following presents a summary to provide a basic understanding of one or more embodiments of the present invention. This summary is not intended to identify key or critical elements or to delineate the scope of particular embodiments or the scope of the claims. Its sole purpose is to present concepts in a simplified form as a prelude to the more detailed description that is presented later. In one or more embodiments described herein, a system, device, computer-implemented method, or computer program product, or combination thereof, that facilitates fault isolation in a distributed application is described.

[0006] According to one embodiment, a system can include a process that executes computer-executable components stored in a memory. The computer-executable components can comprise a graph compiler and a partitioning component. The graph compiler can generate a hypernode graph of a distributed application using causality data inferred from log data generated by failing services. The distributed application can have services. The partitioning component can cluster the services into groups using the hypernode graph and an objective function. One aspect of such a system is that it facilitates fault isolation of the distributed application.

[0007] In one embodiment, the computer-executable components can further include a token component that generates a token vector for the service using tokens flowing between the services observed in the log data. One aspect of such a system is that the system facilitates the incorporation of services within a given group among multiple groups that exhibit substantially similar behavior with respect to such tokens, and any pair of groups among the multiple groups can exhibit substantially different behavior with respect to such tokens.

[0008] According to another embodiment, a computer-implemented method can include generating, by a system operatively coupled to a processor, a hypernode graph of a distributed application using causality data inferred from log data generated by an erroneous service. The distributed application can include the services. The computer-implemented method can further include clustering, by the system, the hypernode graph and an objective function into a plurality of groups. One aspect of such a computer-implemented method is that it facilitates fault isolation of the distributed application.

[0009] In one embodiment, the objective function may include a modularity metric that evaluates inter-group and intra-group coupling within a plurality of groups. In one embodiment, the system may cluster services into a plurality of groups by maximizing the modularity metric using a hypernode graph. One aspect of such a computer-implemented method is that it facilitates evaluation of inter-group and intra-group coupling within a plurality of groups having a community structure.

[0010] According to another embodiment, a computer program product for hardware-efficient calibration of a quantum computing device may have a computer-readable storage medium having program instructions embodied therewith. The program instructions are executable by a processor to cause the processor to perform operations. The operations may include generating, by the processor, a hypernode graph of a distributed application using causality data inferred from log data generated by services experiencing errors. The distributed application may have services. The operations may further include, by the processor, clustering the services into multiple groups using the hypernode graph and an objective function. One aspect of such a computer program product is that it facilitates fault localization of the distributed application.

[0011] In one embodiment, the objective function may include a text-based metric that evaluates the log data for inter-group and intra-group text similarity within the plurality of groups. One aspect of such a computer program product is that the computer program product facilitates evaluation of inter-group and intra-group log-row similarity.

[0012] According to another embodiment, a system may include a process executing computer-executable components stored in a memory. The computer-executable components may comprise a graph compiler, a token component, and a partition component. The graph compiler may generate a hypernode graph of a distributed application using causality data inferred from log data generated by failing services. The distributed application may have services. The token component may generate token vectors for the services using tokens flowing between the services observed in the log data. The partition component may cluster the services into groups using the hypernode graph, the token vectors, and an objective function. One aspect of such a system is that it facilitates fault isolation of a distributed application.

[0013] In one embodiment, the graph compiler can generate a hypernode graph using a template-level causality graph constructed using template-level time series data obtained from the log data and a service-level causality graph constructed using service-level time series data obtained from the log data. One aspect of such a system is that it facilitates the configuration of causal relationships between service or error log templates.

[0014] According to another embodiment, a computer-implemented method can include generating, by a system operatively coupled to a processor, a hypernode graph of a distributed application using causality data inferred from log data generated by a failing service. The distributed application can include the service. The computer-implemented method can further include generating, by the system, a token vector for the service using tokens flowing between the services observed in the log data. The computer-implemented method can further include the system clustering the services into multiple groups using the hypernode graph, the token vector, and an objective function. One aspect of such a computer-implemented method is that it facilitates fault isolation of the distributed application.

[0015] In one embodiment, the system can generate the hypernode graph using a template-level causality graph constructed using template-level time series data obtained from the log data and a service-level causality graph constructed using service-level time series data obtained from the log data. One aspect of such a computer-implemented method is that the method facilitates configuring causal relationships between service or error log templates. [Brief explanation of the drawings]

[0016] [Figure 1] 1 illustrates a block diagram of an exemplary, non-limiting system that facilitates fault localization of a distributed application, in accordance with one or more embodiments described herein.

[0017] [Figure 2] 1 illustrates an exemplary, non-limiting microservices architecture according to one or more embodiments described herein.

[0018] [Figure 3]1 illustrates an exemplary, non-limiting distributed application according to one or more embodiments described herein.

[0019] [Figure 4] 1 illustrates an exemplary, non-limiting framework that facilitates fault localization of distributed applications, according to one or more embodiments described herein.

[0020] [Figure 5] 1 illustrates an exemplary, non-limiting causal inference process according to one or more embodiments described herein.

[0021] [Figure 6] 1 illustrates a flow diagram of an exemplary, non-limiting, computer-implemented method for facilitating fault localization of a distributed application, according to one or more embodiments described herein.

[0022] [Figure 7] 1 illustrates a flow diagram of another exemplary, non-limiting, computer-implemented method for facilitating fault localization of a distributed application, in accordance with one or more embodiments described herein.

[0023] [Figure 8] FIG. 1 is a block diagram of a non-limiting example of an operating environment in which one or more embodiments described herein may be implemented.

[0024] [Figure 9] FIG. 1 is a block diagram of a non-limiting example of a cloud computing environment, according to one or more embodiments described herein.

[0025] [Figure 10] FIG. 1 is a block diagram of a non-limiting example of an abstraction model layer according to one or more embodiments described herein. DETAILED DESCRIPTION OF THE INVENTION

[0026] The following detailed description is merely exemplary and is not intended to limit the application or uses of the embodiments and / or embodiments, nor is it intended to be bound by any express or implied information presented in the preceding "Background" or "Summary" sections or in the "Detailed Description" section.

[0027] One or more embodiments will now be described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a more thorough understanding of one or more embodiments. It will be apparent, however, that in various instances, one or more embodiments may be practiced without these specific details.

[0028] 1 illustrates a block diagram of an exemplary, non-limiting system 100 that facilitates fault localization of a distributed application in accordance with one or more embodiments described herein. System 100 includes a memory 110 for storing computer-executable components and one or more classical processors 120 operably coupled to memory 110 via one or more communication buses 130 for executing the computer-executable components stored in memory 110. As shown in FIG. 1, the computer-executable components may include a graph compiler 140 and a partitioning component 150.

[0029] The graph compiler 140 can generate a hypernode graph for a distributed application using causality data inferred from log data generated by services experiencing errors, as described in more detail below with respect to FIG. 4. A distributed application can be composed of services. In one embodiment, the hypernode graph can include hypernodes corresponding to particular services of the distributed application, nodes within the hypernodes corresponding to given error templates observed in particular services, edges connecting each of causally related pairs of nodes, hyperedges connecting each of causally related pairs of hypernodes, or a combination thereof. In one embodiment, the graph compiler 140 can generate the hypernode graph using a template-level causality graph constructed using template-level time-series data obtained from the log data, as described in more detail with respect to FIG. 5. In one embodiment, the graph compiler 140 can generate the hypernode graph using a service-level causality graph constructed using service-level time-series data obtained from the log data, as described in more detail with respect to FIG. 5.

[0030] The partitioning component 150 can cluster services into multiple groups using a hypernode graph and an objective function, as described in more detail with reference to FIG. 4 . In one embodiment, the objective function can include a modularity metric that evaluates inter-group and intra-group cohesion of multiple groups. In one embodiment, the partitioning component 150 can cluster services into multiple groups by maximizing the modularity metric using the hypernode graph. In one embodiment, the objective function can include a text similarity metric that evaluates inter-group log-row similarity and intra-group log-row similarity. In one embodiment, the objective function can include a cross-entropy metric that evaluates inter-group entropy compared to intra-group entropy.

[0031] In one embodiment, the computer-executable components stored in memory 110 may further include a token component 160. The token component 160 may generate token vectors for services using tokens observed in the log data flowing between the services, as described in more detail with reference to FIG. 4. In one embodiment, the objective function may include a cross-entropy metric that evaluates between-group cross-entropy compared to within-group cross-entropy for multiple groups. In one embodiment, the partition component 150 may cluster services into multiple groups by evaluating the cross-entropy metric using the token vectors. The functionality of the computer-executable components utilized by the embodiment is addressed in more detail below.

[0032] A software application (application) can be implemented in a monolithic architecture using a single code base with multiple tightly coupled components or modules that can be assembled into a single executable program by running in a single process or runtime environment. Each component of an application implemented in a monolithic architecture can provide different functionality for handling external requests or performing specific tasks. Such components can be constructed using classes or packages and can communicate with other components using method calls. A software application can also be implemented using a microservices architecture, which allows a software application to be composed of a loosely coupled set of well-defined stateless services (or microservices).

[0033] FIG. 2 illustrates an exemplary, non-limiting microservices architecture 200 according to one or more embodiments described herein. Microservices architecture 200 may include a loosely coupled set of well-defined, stateless services that can implement an application (e.g., a distributed application). As shown in FIG. 2, microservices architecture 200 may include services 210, 220, 230, or 240, or a combination thereof. Each service in microservices architecture 200 may provide different functionality for implementing an application that can handle external requests or perform a specific task. For example, services 210, 220, 230, or 240, or a combination thereof, of microservices architecture 200 may implement an e-commerce application. In this example, service 210 may be a front-end service that can provide an entry point to the e-commerce application for end users, service 220 may be a product catalog service that can provide product availability information, service 230 may be a checkout service that facilitates product ordering, and service 240 may be an advertising service that can provide product recommendations.

[0034] In contrast to components of an application implemented in a monolithic architecture, each service in microservices architecture 200 can run in a different process or runtime environment. Thus, each service in microservices architecture 200 can be independently deployed and / or scaled. Continuing with the example above in which microservices architecture 200 can implement an e-commerce application, microservices architecture 200 can have three instances of each service at a first point in time. Notably, the number of instances is arbitrarily selected and applies only to this particular example. In other embodiments, microservices architecture 200 can have fewer instances (e.g., two instances) or more instances (e.g., four instances) of each service at a first point in time. In this example, microservices architecture 200 may have three instances (e.g., instances 212, 214, or 216, or a combination thereof) of a front-end service (e.g., service 210), three instances (e.g., instances 222, 224, or 226, or a combination thereof) of a product catalog service (e.g., service 220), three instances (e.g., instances 232, 234, or 236, or a combination thereof) of a checkout service (e.g., service 230), and three instances (e.g., instances 242, 244, or 246, or a combination thereof) of a payment service (e.g., service 240). At a second point in time, demand for functionality provided by the product catalog service (e.g., service 220) of microservices architecture 200 may remain substantially constant, and demand for functionality provided by the checkout service (e.g., service 230) may decrease.Based on that demand, the checkout service can be rescaled independently from the product catalog service such that microservices architecture 200 includes three instances of the product catalog service (e.g., instances 212, 214, or 216, or a combination thereof) and one instance of the checkout service (e.g., instance 232).

[0035] As discussed above, components of an application implemented in a monolithic architecture can communicate with other components using method calls. In contrast to such components, each service in microservices architecture 200 can communicate with other services through a well-defined application programming interface (API). As shown in FIG. 2, each instance of a given service in microservices architecture 200 can include a well-defined application programming interface (API). Instances 212, 214, and 216 of service 210 can include APIs 213, 215, and 217, respectively. Instances 222, 224, and 226 of service 220 can include APIs 223, 225, and 227, respectively. Instances 232, 234, and 236 of service 230 can include APIs 233, 235, and 237, respectively. Instances 242, 244, and 246 of service 240 can include APIs 243, 245, and 247, respectively.

[0036] Communication through well-defined APIs facilitates autonomous operation of each service in microservices architecture 200, insofar as a given service can communicate a request to invoke a function provided by another service without knowledge of how that service implements the function. For example, FIG. 2 shows instance 214 of service 210 communicating request 250 to API 225 of instance 224 to invoke a function provided by service 220. Some functionality provided by a service of an application implemented using microservices architecture 200 may depend on functionality provided by other services in the application. For example, functionality corresponding to request 250 may depend on functionality provided by services 230 and 240 of microservices architecture 200. Thus, in response to request 250, instance 224 of service 220 may communicate request 260 to API 237 of instance 236 to invoke a function provided by service 230 and request 270 to API 247 of instance 246 to invoke a function provided by service 240.

[0037] FIG. 3 illustrates an exemplary, non-limiting distributed application 300 according to one or more embodiments described herein. The distributed application 300 can be implemented using a microservices architecture (e.g., microservices architecture 200 of FIG. 2). As discussed above with respect to FIG. 2, some functionality provided by services of an application implemented using a microservices architecture may depend on functionality provided by other services of the application. Thus, providing a response 367 to an external request 305 can include invoking functionality provided by multiple services of the distributed application 300. As an example, service A 310 of the distributed application 300 can receive the external request 305 sent to the distributed application 300. For example, the external request 305 can be sent to the distributed application 300 by a cloud consumer (e.g., computing device 954A of FIG. 9). In response to receiving the request 305, service A 310 can communicate request 361 to invoke functionality provided by service B 320 of the distributed application 300.

[0038] The functionality provided by service B 320 may depend on the functionality provided by service C 330 and service D 340 of distributed application 300. Thus, in response to receiving request 361, service B 320 may communicate request 362 to invoke the functionality provided by service C 330 and may communicate request 363 to invoke the functionality provided by service D 340. Service B 320 may receive response 364 from service C 330 having the output of the functionality provided by service C 330 in response to request 362. Service B 320 may also receive response 365 from service D 340 having the output of the functionality provided by service D 340 in response to request 363. Service B 320 may communicate response 366 to service A 310, which may have the output of the functionality provided by service B 320 based on the respective outputs included in responses 364 and 365. Service A 310 can communicate a response 367 to the external request 305 that has the output of the functionality provided by service A 310 based on the output included in response 366 .

[0039] Distributed application 300 can be communicatively coupled to database 350 having log data 352 and metric data 354. Log data 352 can include raw text information related to the runtime operation of distributed application 300, which can be generated by one or more services of distributed application 300. Such raw text information can include log lines generated by print statements included in the code of such services. Each log line typically represents a record of an event that occurred during runtime. Such events can include, but are not limited to, a particular service receiving a communication, sending a communication, encountering an error while processing a request, performing a particular function, and other events that occur during the runtime of distributed application 300. In one embodiment, log data 352 can further include tokens (e.g., request identifier tokens, transaction identifier tokens, and other tokens) that may flow between various services of distributed application 300 while responding to external requests, executing transactions, and / or performing particular tasks. Metric data 354 may include information corresponding to various metrics that may measure the performance of distributed application 300 and / or one or more services comprising distributed application 300 (e.g., central processing unit (CPU) usage, memory consumption, average response time, remote procedure call (RPC) latency, and the like).

[0040] In one embodiment, the request identifier token can be generated by a service (e.g., service A 310) associated with the distributed application 300 that uniquely identifies the external request 305. In one embodiment, the request 361, 362, or 363, or a combination thereof, can include the request identifier token. In one embodiment, the response 364, 365, or 366, or a combination thereof, can include the request identifier token. In one embodiment, receipt of a request (e.g., request 361, 362, or 363, or a combination thereof) by a service (e.g., service A 310, service B 320, service C 330, or service D 340, or a combination thereof) can trigger the service to modify the log data 352 with raw text information indicative of the request. In one embodiment, the raw text information can have the request identifier token. In one embodiment, receipt of a response (e.g., response 364, 365, or 366, or a combination thereof) by a service (e.g., service A 310, service B 320, service C 330, or service D 340, or a combination thereof) can trigger the service to modify log data 352 with raw text information indicating the response. In one embodiment, the raw text information can have a request identifier token.

[0041] Identifying faults or abnormal behavior within an application (e.g., distributed application 300) implemented using a microservices architecture can be difficult for several reasons. For example, a failure of one or more services comprising an application implemented using a microservices architecture can cause non-faulty services to error, insofar as some functionality provided by services in such an application may depend on functionality provided by other services. In this example, the non-faulty services may be able to run normally, but the non-faulty services may appear to be faulty because they error based on erroneous output produced by one or more faulty services.

[0042] As an example, the output of the function provided by service A 310 included in response 367 may be erroneous even if service A 310 is functioning properly. In this example, service C 330 may be faulty, but each of the remaining services (e.g., service A 310, service B 320, and / or service D 340) may be functioning properly. Therefore, the output of the function provided by service C 330 that service B 320 received in response 364 may be erroneous. To the extent that the output of the function provided by service B 320 is based in part on the erroneous output of the function provided by service C 330, service B 320 may communicate the erroneous output to service A 310 in response 366 even if service B 320 is functioning properly.

[0043] While Figure 3 illustrates distributed application 300 as having four services, other applications implemented using a microservices architecture may include many more services. Increasing the number of services in such an application can further complicate the task of identifying failures or abnormal behavior. That task can become even more complex when multiple iterations of a service are introduced.

[0044] 4 illustrates an exemplary, non-limiting framework 400 that facilitates fault localization of a distributed application in accordance with one or more embodiments described herein. To that end, the framework 400 can leverage log data 352 and / or metric data 354 stored in a database 350 to group services experiencing errors during runtime of an application (e.g., the distributed application 300) implemented using a microservices architecture. As discussed above, the graph compiler 140 can generate a hypernode graph for the distributed application using causality data inferred from the log data generated by the failing services. The graph compiler 140 can include a causality inference process 410 having a service-level causality subprocess 412 and a template-level causality subprocess 414 at the service level and the template level, respectively, to infer such causality data.

[0045] Referring to FIG. 5 , the service-level causality subprocess 412 may include, at block 510, generating service-level error time series data for each service experiencing an error. Generating service-level error time series data for a given service experiencing an error may include identifying log lines in log data 352 associated with the given service. Generating service-level error time series data for a given service may further include counting the number of errors appearing in such log lines within each time bin of a defined length (e.g., 10 seconds, 1 minute, 5 minutes, etc.). In one embodiment, the service-level error time series data may have multiple time bins constructed in a sliding fashion. At block 520, the service-level causality subprocess 412 may further include generating service-level metric time series data for each service experiencing an error. Generating service-level metric time series data for a given service experiencing an error may include identifying metric data 354 associated with the given service. Generating service level metrics time series data for a given service may further include dividing the identified metric data 354 into a number of time bins, each time bin having a defined length (e.g., 10 seconds, 1 minute, 5 minutes, etc.).

[0046] At block 530, the service-level causality subprocess 412 may further include constructing a service-level error causality graph from the service-level error time series data generated at block 510. Constructing the service-level error causality graph may include applying a causal inference technique (e.g., Granger causality analysis, principal component (PC) analysis, or other causal inference techniques, or a combination thereof) to the service-level error time series data generated at block 510 for each service experiencing an error. At block 540, the service-level causality subprocess 412 may further include constructing a service-level metric causality graph from the service-level metrics time series data generated at block 520. Constructing the service-level metric causality graph may include applying a causal inference technique (e.g., Granger causality analysis, principal component (PC) analysis, or other causal inference techniques, or a combination thereof) to the service-level metrics time series data generated at block 520 for each service experiencing an error. At block 550, the service-level error causality graph constructed at block 530 and the service-level metric causality graph constructed at block 540 may be integrated to construct a service-level causality graph.

[0047] The template-level causality subprocess 414 may include, at block 560, generating template-level time series data for each error template derived from the log data 352 using log templating techniques. Generating template-level error time series data for a given error template may include counting the number of times the given error template appears in log lines of the log data 352 within each time bin of a defined length (e.g., 10 seconds, 1 minute, 5 minutes, etc.). In one embodiment, the template-level error time series data may have multiple time bins constructed in a sliding fashion. At block 570, the template-level causality subprocess 414 may further include constructing a template-level causality graph from the template-level time series data generated at block 560.

[0048] 4, the graph compiler 140 may further include a hypernode graph process 420 that may generate a hypernode graph for a distributed application using the causality data obtained from the causality inference process 410. Specifically, the hypernode graph process 420 may generate a hypernode graph using the service-level causality graph constructed by the service-level causality subprocess 412 and the template-level causality graph constructed by the template-level causality subprocess 414. The hypernode graph constructed by the hypernode graph process 420 may include hypernodes corresponding to specific services of the distributed application. Nodes within a hypernode of the hypernode graph may correspond to a given error template observed in a specific service. Each edge of the hypernode graph may connect each pair of nodes within a given hypernode that are causally related. Each hyperedge of the hypernode graph may connect each pair of hypernodes that are causally related.

[0049] The framework 400 may further include a token component 160 that can generate token vectors for the services of the distributed application. The token component 160 may include a token counting vector process 430 for generating such token vectors. The token counting vector process 430 may include analyzing the log data 352 to identify tokens flowing between services. Such tokens may include, but are not limited to, transaction identifier tokens, request identifier tokens, or other tokens that may be passed from one service of the distributed application to another, or a combination thereof. For each service i of the distributed application, the token counting vector process 430 generates a token vector T of size |V| i where V can represent the token vocabulary. i An element of may be the number of a given token identified in a log line of the log data 352 corresponding to service i.

[0050] As an example, a distributed application may have two services, service S1 and service S2. In this example, token component 160 may observe three tokens in the logs of services S1 and S2 in log data 352: a first token (“abcd1234”), a second token (“gfhijk34kl”), and a third token (“mkn456”). Notably, the number of services, the number of tokens, and their respective token values ​​are arbitrarily selected and apply only to this particular example. Continuing with this example, token count vector process 430 may observe that in the log generated by service S1, the first token occurred once, the second token occurred three times, and the third token did not occur at all or occurred zero times. Based on these observations, the token count vector that token count vector process 430 generates for service S1 may be <1,3,0>. The token count vector for service S1 may be normalized to convert the individual token count elements to values ​​between 0 and 1. The normalized token count vector for service S1 can be <1 / 4,3 / 4,0 / 4> or <0.25,0.75,0>.

[0051] In this example, the token count vector process 430 may observe in the log generated by service S2 that the first token occurred once, the second token did not occur at all or occurred zero times, and the third token occurred nine times. Based on these observations, the token count vector that the token count vector process 430 generates for service S2 may be <1,0,9>. The token count vector for service S2 may be normalized to convert the individual token count elements to values ​​between 0 and 1. The normalized token count vector for service S2 may be <1 / 10,0 / 10,9 / 10> or <0.1,0.9>.

[0052] The cross-entropy between services S1 and S2 can be analyzed using their respective normalized token count vectors and a cross-entropy function. In one embodiment, the cross-entropy metric subprocess 454 of evaluation process 450 can use the cross-entropy function to analyze the cross-entropy metric of the objective function of evaluation process 450, which is discussed in more detail below. In one embodiment, the cross-entropy function can be implemented using the cross-entropy function defined by Equation 1:

number

[0053] According to Equation 1 above, p represents service S1, q represents service S2, x represents the token space (e.g., three values: abcd1234, gfhijk34kl, and mkn456), and p(x) and q(x) represent the normalized values ​​of the x token in services S1 and S2, respectively.

[0054] Framework 400 may further include a text similarity evaluation process 440 that can analyze log lines of log data 352 to generate a signal indicative of inter-group text similarity and a signal indicative of intra-group text similarity within groups of services into which segmentation component 150 clusters services of the distributed application. As discussed above, segmentation component 150 can cluster services of the distributed application that generate errors into multiple groups using the hypernode graph and objective function generated by graph compiler 140. To that end, segmentation component 150 can include evaluation process 450 and grouping optimization process 460. Clustering the services of the distributed application that generate errors into multiple groups can include evaluation process 450 and grouping optimization process 460 that interact to maximize the objective function of evaluation process 450.

[0055] Such interaction may include a learning process that may include a grouping optimization process 460 that generates an initial community structure using a hypernode graph that clusters services of a distributed application into groups. In one embodiment, the grouping optimization process 460 may generate the initial community structure by randomly assigning services associated with the hypernode graph to groupings in the initial community structure. Given the initial community structure, the evaluation process 450 may analyze an objective function of the initial community structure and provide feedback to the grouping optimization process 460 regarding the initial community structure. Based on that feedback, the grouping optimization process 460 may modify the initial community structure. Given an updated community structure, the evaluation process 450 may analyze an objective function of the updated community structure and provide feedback to the grouping optimization process 460 regarding the updated community structure. Such interaction with the learning process may occur iteratively until the grouping optimization process 460 creates a community structure that maximizes the objective function of the evaluation process 450. In one embodiment, the objective function of the evaluation process 450 may be implemented using the objective function defined by Equation 2:

number

[0056] According to Equation 2 above, α, β, or γ, or a combination thereof, may represent weights assigned to algorithm hyperparameters corresponding to the modularity metric, the cross-entropy metric, and the text similarity metric, respectively. In one embodiment, α, β, or γ, or a combination thereof, may be adjusted to modify the above learning process with respect to evaluation process 450 and grouping optimization process 460. In one embodiment, α, β, or γ, or a combination thereof, may be adjusted using input received from an entity that manages the execution environment of the application having the service experiencing the error.

[0057] The modularity metric subprocess 452 may include analyzing the modularity metric of the objective function of the evaluation process 450 using the hypergraph generated by the graph compiler 140. In one embodiment, the modularity metric may evaluate inter-group and intra-group coupling within multiple groups having a community structure. In one embodiment, the modularity metric subprocess 452 may include a community detection algorithm. The community detection algorithm may include, but is not limited to, Louvain, Leiden, Fast-greedy, label propagation, probabilistic block modeling, or other graph-based community detection algorithms. In one embodiment, analyzing the modularity metric facilitates maximizing the intra-group edges of the community structure while minimizing the inter-group edges of the community structure. In one embodiment, analyzing the modularity metric facilitates allocating services that are highly correlated to one group (or community) of the community structure.

[0058] In one embodiment, the community structure C={C1, C2, ..., and C n Given}, the modularity metric of the modularity metric subprocess 452 can be implemented using the modularity metric defined by Equation 3:

number

[0059] According to equation 3 above, A ij can represent the weight of the edge between service i and service j in the adjacency matrix A derived from the hypernode graph at the service level, and k i can represent the total number of vertex weights connected to vertex i (which can be called the degree of the node), and c ican represent the group (or community) to which vertex i is assigned, δ(x, y) can represent a function that can be 1 if x=y and 0 otherwise, and m can be expressed as (1 / 2)ΣijA ij can be used to represent the number of links that can be defined.

[0060] In one embodiment, the weighted edge from service i to service j in the adjacency matrix A can be constructed using the causal relationships between service i and service j, and the causal relationships between the error templates of service i and service j. In one embodiment, the causal relationships between service i and service j can correspond to the service-level error causality graph constructed in block 550 of the service-level causality subprocess 412. In one embodiment, the causal relationships between the error templates of service i and service j can correspond to the template-level causality graph constructed in block 570 of the template-level causality subprocess 414.

[0061] The cross-entropy metric subprocess 454 may include analyzing the cross-entropy metric of the objective function of the evaluation process 450 using the token vectors generated by the token component 160. The cross-entropy metric may evaluate the inter-group cross-entropy and the intra-group cross-entropy of multiple groups having a community structure. In one embodiment, analyzing the cross-entropy metric facilitates minimizing the cross-entropy within a given group of the community structure while maximizing the cross-entropy across groups having a community structure. In one embodiment, analyzing the cross-entropy metric facilitates the inclusion of services within a given group of the community structure that exhibit substantially similar behavior with respect to tokens present in such services, and any pair of groups having a community structure should exhibit substantially different behavior with respect to such tokens.

[0062] In one embodiment, the community structure C={C1, C2, ..., and C n}, the cross-entropy metric of the cross-entropy metric sub-process 454 can be implemented using the cross-entropy metric defined by Equation 4:

number

[0063] According to Equation 4 above, intergroup_average_cross-entropy can be evaluated by calculating the cross-entropy of each pair of services, including one service in the first group of a given pair of groups and one service in the second group of a given pair of groups, for each pair of groups with a community structure. Intergroup_average_cross-entropy can be further evaluated by dividing the cross-entropy calculated for each pair of groups with a community structure by the total number of pair of groups with a community structure. According to Equation 3 above, intragroup_average_cross-entropy can be calculated by dividing the cross-entropy of each pair of groups C with a community structure by the total number of pair of groups C with a community structure. i Intragroup_cross-entropy(C i ) can be evaluated by calculating the sum of the Intragroup_average_cross-entropy for each group C i It can be further evaluated by dividing the calculated sum by |C|. i ) can be evaluated by computing the average pairwise cross-entropy between services within a given group of community structures.

[0064] The text similarity metric subprocess 456 can include analyzing a text similarity metric for the objective function of the evaluation process 450 using the log data 352. The text similarity metric can evaluate inter-group log line similarity and intra-group log line similarity. In one embodiment, analyzing the text similarity metric facilitates the inclusion of services that, within a given group of community structures, exhibit substantially similar behavior with respect to the log lines generated by sentences in such services, and any pair of groups with community structures should exhibit substantially different behavior with respect to such log lines. In one embodiment, the community structure C={C1, C2, ..., and C n Given}, the text similarity metric of the text similarity metric subprocess 456 can be implemented using the text similarity metric defined by Equation 5:

number

[0065] According to Equation 5 above, intergroup_average_similarity can be evaluated by calculating the text log line similarity for each pair of services, including one service in the first group of a given pair of services and one service in the second group of a given pair of services, for each pair of services with a community structure. Intergroup_average_similarity can be further evaluated by dividing the text log line similarity calculated for each pair of services with a community structure by the total number of pair of services with the community structure. According to Equation 4 above, intragroup_average_similarity can be evaluated by dividing the text log line similarity for each pair of services with a community structure, including one service in the first group of a given pair of services and one service in the second group of a given pair of services. i intragroup_similarity(C i ) can be evaluated by calculating the sum of the Intragroup_average_cross-entropy for each group C iThis can be further evaluated by dividing the calculated sum by |C|. i ) can be evaluated by computing the average pairwise text log line similarity between services within a given group of community structures.

[0066] FIG. 6 illustrates a flow diagram of an exemplary, non-limiting computer-implemented method 600 for facilitating fault localization of a distributed application, according to one or more embodiments described herein. Repeated descriptions of similar elements used in other embodiments described herein are omitted for brevity. At 610, the computer-implemented method 600 may include, by a system operatively coupled to the processor (e.g., using the graph compiler 140), generating a hypernode graph for the distributed application using causality data inferred from log data generated by the service experiencing the error. The distributed application may include services. In one embodiment, the hypernode graph may include hypernodes corresponding to particular services of the distributed application, nodes within the hypernodes corresponding to given error templates observed in the particular services, edges connecting each of causally related pairs of nodes, hyperedges connecting each of causally related pairs of hypernodes, or combinations thereof. In one embodiment, the system may generate the hypernode graph using a template-level causality graph constructed using template-level time-series data obtained from the log data and a service-level causality graph constructed using service-level time-series data obtained from the log data.

[0067] At 620, the computer-implemented method 600 may include the system (e.g., using the partitioning component 150) clustering the services into multiple groups using the hypernode graph, the token vector, and an objective function. In one embodiment, the objective function may include a modularity metric that evaluates inter-group and intra-group coupling within the multiple groups. In one embodiment, the system may cluster the services into multiple groups by maximizing the modularity metric using the hypernode graph.

[0068] In one embodiment, the computer-implemented method 600 may further include generating, by the system (e.g., using the token component 160), tokens flowing between the services observed in the log data to generate token vectors for the services. In one embodiment, the objective function may include an entropy-based metric that evaluates inter-group cross-entropy and intra-group cross-entropy for multiple groups. In one embodiment, the system may cluster the services into multiple groups by evaluating the entropy-based metric using the token vectors.

[0069] FIG. 7 illustrates a flow diagram of an exemplary, non-limiting computer-implemented method 700 for facilitating fault localization of a distributed application in accordance with one or more embodiments described herein. Repeated descriptions of similar elements used in other embodiments described herein are omitted for brevity. At 710, the computer-implemented method 700 may include, by a system operatively coupled to a processor (e.g., using graph compiler 140), generating a hypernode graph for the distributed application using causality data inferred from log data generated by the failing service. The distributed application may include services. In one embodiment, the system may generate the hypernode graph using a template-level causality graph constructed using template-level time-series data obtained from the log data and a service-level causality graph constructed using service-level time-series data obtained from the log data. At 720, the computer-implemented method 700 may include, by the system (e.g., using token component 160), generating token vectors for the services using tokens flowing between the services observed in the log data. At 730, the computer-implemented method 700 can include the system (e.g., using the partitioning component 150) clustering the services into multiple groups using the hypernode graph, the token vector, and the objective function.

[0070] To provide context for various aspects of the disclosed subject matter, Figure 8 and the following discussion are intended to provide a general description of a suitable environment in which various aspects of the disclosed subject matter may be implemented. Figure 8 illustrates a suitable operating environment 800 for implementing various aspects of the present disclosure, which may also include a computer 812. The computer 812 may also include a processing unit 814, a system memory 816, and a system bus 818. The system bus 818 couples system components, including, but not limited to, the system memory 816, to the processing unit 814. The processing unit 814 may be any of a variety of available processors. Dual microprocessors and other multiprocessor architectures may also be used as the processing unit 814. The system bus 818 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus or external bus, and / or a local bus using any of a variety of available bus architectures, including, but not limited to, Industry Standard Architecture (ISA), MicroChannel Architecture (MSA), Enhanced ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), CardBus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Firewire (IEEE 1094), and Small Computer System Interface (SCSI). The system memory 816 may also include volatile memory 820 and nonvolatile memory 822. The basic input / output system (BIOS), containing the basic routines for transferring information between elements within the computer 812, such as during start-up, is stored in the nonvolatile memory 822. By way of example and not limitation, the non-volatile memory 822 may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, or non-volatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM)).The volatile memory 820 can also include random access memory (RAM), which acts as external cache memory. By way of example, and not limitation, RAM is available in many forms, including static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM.

[0071] Computer 812 may also include removable / non-removable, volatile / non-volatile computer storage media. FIG. 8, for example, illustrates disk storage 824. Disk storage 824 may include devices such as, but not limited to, a magnetic disk drive, a floppy disk drive, a tape drive, a Jaz drive, a Zip drive, an LS-100 drive, a flash memory card, or a memory stick. Disk storage 824 may also include storage media separately or in combination with other storage media, including, but not limited to, an optical disk drive, such as a compact disc read-only memory (CD-ROM), a CD recordable drive (CD-R drive), a CD rewriteable drive (CD-RW drive), or a digital versatile disc read-only memory (DVD-ROM). A removable or non-removable interface, such as interface 826, is typically used to facilitate connection of disk storage 824 to system bus 818. FIG. 8 also illustrates software that acts as an intermediary between users and the basic computer resources described in suitable operating environment 800. Such software may also include, for example, operating system 828. Operating system 828, which can be stored on disk storage 824, acts to control and allocate resources of the computer 812. System applications 830 take advantage of the management of resources by operating system 828 through program modules 832 and program data 834, stored, for example, either in system memory 816 or on disk storage 824. It should be appreciated that the present disclosure can be implemented with various operating systems or combinations of operating systems. A user enters commands or information into computer 812 through input devices 836.The input devices 836 include, but are not limited to, pointing devices such as a mouse, trackball, stylus, touchpad, keyboard, microphone, joystick, gamepad, satellite dish, scanner, television tuner card, digital camera, digital video camera, webcam, and the like. These and other input devices connect to the processing unit 814 through the system bus 818 via interface ports 838. Interface ports 838 include, for example, serial ports, parallel ports, game ports, and universal serial bus (USB). The output devices 840 use some of the same types of ports as the input devices 836. Thus, for example, a USB port can be used to provide input to the computer 812 and to output information from the computer 812 to the output device 840. The output adapter 842 is provided to illustrate that some output devices 840, such as monitors, speakers, and printers, require dedicated adapters, among other output devices 840. Output adapters 842 include, by way of example and not limitation, video cards and sound cards that provide a means of connection between output device(s) 840 and system bus 818. It may be noted that other devices and / or systems of devices provide both input and output capabilities, such as remote computer(s) 844.

[0072] The computer 812 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 844. The remote computer 844 can be a computer, a server, a router, a network PC, a workstation, a microprocessor-based appliance, a peer device or other common network node, and the like, and can typically include many of the things or elements described in connection with the computer 812. For simplicity, only a memory storage device 846 is shown with the remote computer 844. The remote computer 844 is logically connected to the computer 812 through a network interface 848 and then physically connected via a communication connection 850. The network interface 848 encompasses wired and / or wireless communication networks such as a local area network (LAN), a wide area network (WAN), a cellular network, and the like. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring, and the like. WAN technologies include, but are not limited to, point-to-point links, circuit-switched networks such as Integrated Services Digital Networks (ISDN) and variations thereon, packet-switched networks, and Digital Subscriber Lines (DSL). Communications connection(s) 850 refer to the hardware / software used to connect network interface 848 to system bus 818. Communications connection(s) 850 are illustratively shown internal to computer 812 for clarity, but can also be external to computer 812. The hardware / software for connecting to network interface 848 can also include, for illustrative purposes only, internal and external technologies such as modems, including ordinary telephone-grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.

[0073] In some cases, various embodiments of system 100 described herein may be associated with a cloud computing environment. For example, system 100 may be associated with cloud computing environment 950, as shown in Figure 9, and / or with one or more functional abstraction layers (e.g., hardware and software layer 1060, virtualization layer 1070, management layer 1080, and / or workload layer 1090) described herein with reference to Figure 10.

[0074] Although this disclosure includes detailed descriptions related to cloud computing, it should be understood that practice of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present invention may be implemented in connection with any other type of computing environment now known or later developed.

[0075] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, services) that can be rapidly provisioned and released with minimal administrative effort or interaction with the service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0076] The features are as follows:

[0077] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without the need for human interaction with the service provider.

[0078] Wide network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg, cell phones, laptops, PDAs).

[0079] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the provided resources, but do have a sense of location independence in that they may be able to identify locations at a higher level of abstraction (e.g., country, state, or data center).

[0080] Rapid Elasticity: Capacity can be provisioned quickly and elastically, sometimes automatically, quickly scaled out, quickly released, and quickly scaled in. To the consumer, the capacity available for provisioning often appears unlimited, and can be purchased in any quantity at any time.

[0081] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services they utilize.

[0082] The service model is as follows:

[0083] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application functions, except for limited user-specific application configuration settings.

[0084] Platform as a Service (PaaS): The ability offered to consumers is to deploy applications they create or acquire, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the configuration of the application hosting environment.

[0085] Infrastructure as a Service (IaaS): The ability offered to consumers is to provision processing, storage, network, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do have control over the operating systems, storage, deployed applications, and in some cases, limited control over selected network components (e.g., host firewalls).

[0086] The deployment model is as follows:

[0087] Non-public cloud: Cloud infrastructure is operated solely for the organization, can be managed by the organization or a third party, and can reside on-premise or off-premise.

[0088] Community Cloud: Cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, compliance considerations). It may be managed by the organization or a third party and may reside on-premises or off-premises.

[0089] Public Cloud: Cloud infrastructure is made available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0090] Hybrid Cloud: A cloud infrastructure is a composition of two or more clouds (non-public, community, or public) that remain unique entities but are joined by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that allow for data and application portability.

[0091] Cloud computing environments are service-oriented with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0092] Referring now to FIG. 9 , an exemplary cloud computing environment 950 is shown. As shown, the cloud computing environment 950 includes one or more cloud computing nodes 910 with which local computing devices used by cloud consumers, such as, for example, a digital assistant (e.g., PDA) or mobile phone 954A, a desktop computer 954B, a laptop computer 954C, or an automobile computer system 954N, or a combination thereof, may communicate. Although not shown in FIG. 9 , the cloud computing node 910 may further include a quantum platform (e.g., a quantum computer, quantum hardware, quantum software, or another quantum platform, or a combination thereof) with which the local computing devices used by the cloud consumers may communicate. The nodes 910 may communicate with each other. They may be grouped (not shown), physically or virtually, into one or more networks, such as the aforementioned non-public cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof. This allows the cloud computing environment 950 to provide infrastructure, platform, or software, or a combination thereof, as a service without the cloud consumer having to maintain resources on their local computing device. It will be understood that the types of computing devices 954A-N shown in FIG. 9 are intended to be illustrative only, and that the computing node 910 and cloud computing environment 950 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0093] 10, a set of functional abstraction layers provided by cloud computing environment 950 (FIG. 9) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 10 are for illustrative purposes only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0094] Hardware and software layer 1060 includes hardware and software components. Examples of hardware components include mainframe 1061, RISC (reduced instruction set computer) architecture-based servers 1062, servers 1063, blade servers 1064, storage devices 1065, and networks and network components 1066. In some embodiments, software components include network application server software 1067, database software 1068, quantum platform routing software (not shown in FIG. 10) or quantum software (not shown in FIG. 10), or a combination thereof.

[0095] The virtualization layer 1070 provides an abstraction layer over which the following examples of virtual entities can be provided: virtual servers 1071, virtual storage 1072, virtual networks including virtual non-public networks 1073, virtual applications and operating systems 1074, and virtual clients 1075.

[0096] In one example, management layer 1080 may provide the functions described below. Resource provisioning 1081 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 1082 provides cost tracking as resources are utilized within the cloud computing environment and charging or billing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 1083 provides consumers and system administrators with access to the cloud computing environment. Service level management 1084 provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment 1085 provides proactive provisioning and procurement of cloud computing resources in anticipation of future requirements according to SLAs.

[0097] The workload tier 1090 provides examples of functions for which a cloud computing environment may be utilized. Non-limiting examples of workloads and functions that may be provided from this tier include mapping and navigation 1091, software development and lifecycle management 1092, virtual classroom instructional delivery 1093, data analytics processing 1094, transaction processing 1095, and vulnerability risk assessment software 1096.

[0098] The present invention may be a system, method, apparatus, or computer program product, or combination thereof, integrated at any possible level of technical detail. A computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to execute aspects of the present invention. A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media may include portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile discs (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or groove-embossed structures having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as being a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0099] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage. The computer-readable program instructions for carrying out the operations of the present invention can be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, or the like, and procedural programming languages ​​such as the “C” programming language or similar. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0100] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions. These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowchart illustrations and / or block diagrams. These computer-readable program instructions can also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein comprises a product containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowchart illustrations and / or block diagrams. The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0101] The flowcharts and block diagrams in the figures 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 a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

[0102] While the subject matter has been described above in the general context of computer-executable instructions for a computer program product executing on one or more computers, those skilled in the art will recognize that the present disclosure can also be combined with or implemented in conjunction with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks and / or implement particular abstract data types. Furthermore, those skilled in the art will appreciate that the computer-implemented methods of the present invention can be practiced with other computer system configurations, including single-processor or multiprocessor computer systems, minicomputing devices, mainframe computers, as well as computers, handheld computing devices (e.g., PDAs, phones), microprocessor-based or programmable consumer or industrial electronics, and the like. The illustrated aspects can also be practiced in distributed computing environments where tasks are performed by remote processing devices linked through a communications network. However, some, if not all, aspects of the present disclosure can be practiced on stand-alone computers. In a distributed computing environment, program modules can be located in both local and remote memory storage devices. For example, in one or more embodiments, computer-executable components can execute from memory that can include or comprise one or more distributed memory units. As used herein, the terms "memory" and "memory unit" are interchangeable. Furthermore, one or more embodiments described herein may execute computer-executable component code in a distributed manner, e.g., with multiple processors acting in combination or cooperation to execute code from one or more distributed memory units. As used herein, the term "memory" can encompass a single memory or memory unit in one location, or multiple memories or memory units in one or more locations.

[0103] As used herein, the terms “component,” “system,” “platform,” “interface,” and the like can refer to or include computer-related entities or entities associated with an operating machine having one or more specific functions. The entities disclosed herein can be hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, or a computer, or a combination thereof. By way of example, both an application running on a server and the server can be a component. One or more components can reside within a process or thread of execution, or both, and a component can be localized on one computer, distributed between two or more computers, or both. In another example, each component can execute from various computer-readable media having various data structures stored thereon. Components can communicate via local and / or remote processes, such as according to signals comprising one or more data packets (e.g., data from one component interacting with another component in a local system, a distributed system, or data from one component interacting with another system over a network such as the Internet via signals or both). As another example, a component can be a device having a specific function provided by mechanical parts operated by electrical or electronic circuits, and operated by a software or firmware application executed by a processor. In such cases, the processor can be internal or external to the device and can execute at least a portion of the software or firmware application.As yet another example, a component may be a device that provides a particular function without mechanical parts through electronic components, where the electronic components may include a processor or other means for executing software or firmware that provides at least part of the functionality of the electronic component. In one aspect, a component may emulate the electronic component via a virtual machine, for example, within a cloud computing system.

[0104] Furthermore, the term "or" is intended to mean an inclusive "or," rather than an exclusive "or." That is, unless otherwise specified or clear from context, "X uses A or B" is intended to mean any of the natural inclusive permutations. That is, if X uses A, if X uses B, or if X uses both A and B, then "X uses A or B" is satisfied in any of the foregoing cases. Furthermore, as used in the subject specification and accompanying drawings, the articles "a" and "an" should generally be construed to mean "one or more" unless otherwise specified or unless the context clearly indicates a reference to the singular form. As used herein, the terms "example" and / or "exemplary" are used to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. Furthermore, any aspect or design described herein as "example" and / or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs, and is not meant to exclude equivalent exemplary structures and techniques known to those skilled in the art.

[0105] As used in the subject specification, the term "processor" can refer to, but is not limited to, a single-core processor, a single processor with software multithreading execution capabilities, a multi-core processor, a multi-core processor with software multithreading execution capabilities, a multi-core processor with hardware multithreading technology, a parallel platform, and a parallel platform with distributed shared memory. Furthermore, a processor may refer to an integrated circuit, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Furthermore, a processor can leverage nanoscale architectures, such as, but not limited to, molecular and quantum dot-based transistors, switches, and gates, to optimize area usage or improve performance of user equipment. A processor can also be implemented as a combination of computing processing units. In this disclosure, terms such as “store,” “storage,” “data store,” “data storage,” “database,” and substantially any other information storage component related to the operation and functionality of a component are used to refer to a “memory component,” an entity embodied in a “memory,” or a component having a memory. It should be understood that the memory and / or memory components described herein can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. By way of example and not limitation, nonvolatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or nonvolatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM)).Volatile memory may include, for example, RAM, which can act as external cache memory. By way of example and not limitation, RAM is available in many forms, including synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Additionally, the memory components of the systems or computer-implemented methods disclosed herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0106] What has been described above includes merely examples of systems and computer-implemented methods. Of course, for purposes of describing this disclosure, it is not possible to describe every conceivable combination of components or computer-implemented methods, but one of ordinary skill in the art will recognize that many more combinations and permutations of the present disclosure are possible. Furthermore, to the extent that "includes," "has," "possesse," and similar terms are used in the detailed description, claims, appendices, and drawings, such terms are intended to be inclusive in a manner similar to the term "comprising," as they are interpreted as "comprising" when used as transitional words in the claims.

[0107] The descriptions of various embodiments are presented for illustrative purposes and are not intended to be exhaustive or to be limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best explain the principles of the embodiments, practical applications, or technical improvements beyond those found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. a processor executing the following computer-executable components stored in memory: a graph compiler that generates a hypernode graph of a distributed application using causality data inferred from log data generated by an failing service, the distributed application comprising the service; and a partitioning component that uses the hypernode graph and an objective function to cluster the services into groups; Equipped with the hypernode graph having hypernodes corresponding to particular services of the distributed application, nodes within the hypernodes corresponding to given error templates observed in the particular services, edges connecting each of causally related pairs of nodes, hyperedges connecting each of causally related pairs of hypernodes, or combinations thereof; system.

2. 2. The system of claim 1, wherein the graph compiler generates the hypernode graph using a causality graph for each error template constructed using time series data for each error template observed at the service obtained from the log data.

3. 2. The system of claim 1, wherein the graph compiler generates the hypernode graph using a causality graph of errors for each service constructed using time series data of errors for each service obtained from the log data.

4. The system of claim 1 , wherein the objective function comprises a modularity metric that evaluates inter-group and intra-group couplings of the plurality of groups.

5. The system of claim 4 , wherein the partitioning component clusters the services into the groups by maximizing the modularity metric using the hypernode graph.

6. The system of claim 1 , wherein the objective function comprises a text similarity metric that evaluates inter-group log-row similarity and intra-group log-row similarity.

7. The system of claim 1 , wherein the objective function comprises a cross-entropy metric that evaluates between-group entropy compared to within-group entropy.

8. The system of claim 1 , further comprising a token component that generates a token vector for the service using tokens flowing between the services observed in the log data.

9. 9. The system of claim 8, wherein the objective function comprises a cross-entropy metric that evaluates between-group cross-entropy compared to within-group cross-entropy of the plurality of groups, and the partitioning component clusters the services into the plurality of groups by evaluating the cross-entropy metric using the token vectors.

10. generating, by a system operatively coupled to a processor, a hypernode graph of a distributed application using causality data inferred from log data generated by an erroneous service, the distributed application comprising the service; clustering, by the system, the services into a plurality of groups using the hypernode graph and an objective function; Equipped with the hypernode graph having hypernodes corresponding to particular services of the distributed application, nodes within the hypernodes corresponding to given error templates observed in the particular services, edges connecting each of causally related pairs of nodes, hyperedges connecting each of causally related pairs of hypernodes, or combinations thereof; Computer-implemented methods.

11. 11. The computer-implemented method of claim 10, wherein the system generates the hypernode graph using a causality graph for each error template constructed using time series data for each error template observed in the service obtained from the log data, and a causality graph for errors for each service constructed using time series data for errors for each service obtained from the log data.

12. 11. The computer-implemented method of claim 10, wherein the objective function has a modularity metric that evaluates inter-group and intra-group coupling within the plurality of groups, and the system clusters the services into the plurality of groups by maximizing the modularity metric using the hypernode graph.

13. generating, by the system, a token vector for the service using tokens flowing between the services observed in the log data; The computer-implemented method of claim 10 further comprising:

14. 14. The computer-implemented method of claim 13, wherein the objective function comprises an entropy-based metric that evaluates inter-group and intra-group cross-entropy of the plurality of groups, and the system clusters the services into the plurality of groups by evaluating the entropy-based metric using the token vectors.

15. The processor generating a hypernode graph of a distributed application using causality data inferred from log data generated by an erroneous service, the distributed application comprising the service; clustering the services into groups using the hypernode graph and an objective function; Execute the hypernode graph having hypernodes corresponding to particular services of the distributed application, nodes within the hypernodes corresponding to given error templates observed in the particular services, edges connecting each of causally related pairs of nodes, hyperedges connecting each of causally related pairs of hypernodes, or combinations thereof; Computer program.

16. the processor, 16. The computer program product of claim 15, wherein the computer program product executes a procedure of generating the hypernode graph using a causality graph for each error template constructed using time series data for each error template observed in the service obtained from the log data, and a causality graph for errors of each service constructed using time series data for errors of each service obtained from the log data.

17. 17. The computer program of claim 15 or 16, wherein the objective function comprises a modularity metric that evaluates inter-group and intra-group couplings within the plurality of groups, and the computer program causes the processor to perform a procedure for clustering the services into the plurality of groups by maximizing the modularity metric using the hypernode graph.

18. the processor, generating token vectors for the services using tokens flowing between the services observed in the log data, wherein the objective function has an entropy-based metric for evaluating inter-group cross-entropy and intra-group cross-entropy for the plurality of groups; and clustering the services into the plurality of groups by evaluating the entropy-based metric using the token vectors.

17. A computer program according to claim 15 or 16.

19. the objective function comprises a text-based metric that evaluates the log data for inter-group text similarity and intra-group text similarity within the plurality of groups.

17. A computer program according to claim 15 or 16.

20. a processor executing the following computer-executable components stored in memory: a graph compiler that generates a hypernode graph of a distributed application using causality data inferred from log data generated by an failing service, the distributed application comprising the service; and a token component that generates a token vector for the service using tokens observed in the log data flowing between the services; a partitioning component that clusters the services into groups using the hypernode graph, the token vector, and an objective function; Equipped with the hypernode graph having hypernodes corresponding to particular services of the distributed application, nodes within the hypernodes corresponding to given error templates observed in the particular services, edges connecting each of causally related pairs of nodes, hyperedges connecting each of causally related pairs of hypernodes, or combinations thereof; system.

21. 21. The system of claim 20, wherein the graph compiler generates the hypernode graph using a causality graph for each error template constructed using time series data for each error template observed in the service obtained from the log data, and a causality graph for errors for each service constructed using time series data for errors for each service obtained from the log data.

22. 1. A computer-implemented method comprising: generating, by a system operatively coupled to a processor, a hypernode graph of a distributed application using causality data inferred from log data generated by an erroneous service, the distributed application comprising the service; generating, by the system, a token vector for the service using tokens flowing between the services observed in the log data; clustering, by the system, the services into a plurality of groups using the hypernode graph, the token vector, and an objective function; Equipped with the hypernode graph having hypernodes corresponding to particular services of the distributed application, nodes within the hypernodes corresponding to given error templates observed in the particular services, edges connecting each of causally related pairs of nodes, hyperedges connecting each of causally related pairs of hypernodes, or combinations thereof; Computer-implemented methods.

23. 23. The computer-implemented method of claim 22, wherein the system generates the hyper-node graph using a causality graph for each error template constructed using time series data for each error template observed in the service obtained from the log data, and a causality graph for errors for each service constructed using time series data for errors for each service obtained from the log data.

Images