1. A method of determining an optimized root cause for an error event in a cloud environment, the method comprising: receiving, by a Root Cause Determining System (RCDS) (107), information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment; generating, by the RCDS (107), a logical graph comprising plurality of logical nodes, wherein each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource; determining, by the RCDS (107), a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources; generating, by the RCDS (107), a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction; identifying, by the RCDS (107), one or more probable root causes of the error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window, wherein the one or more anomaly nodes correspond to the logical node in which error event has occurred; and generating, by the RCDS (107), dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules.

2. The method as claimed in claim 1 further comprises verifying, by the RCDS (107), each of the one or more rules based on one or more predefined techniques.

3. The method as claimed in claim 1, wherein the execution information of the one or more resources comprises at least one of similar execution patterns and dissimilar execution patterns.

4. The method as claimed in claim 1, wherein the logical relationship between the one or more resources comprises at least one of sibling relationship and subsumption relationship, wherein the sibling relationship is the logical relationship between two metrics of a single resource and the subsumption relationship is the logical relationship between a resource and a sub-resource of the resource.

5. The method as claimed in claim 1, wherein generating the PMG comprises establishing the edges whose correlation weight is greater than a dynamically configured correlation threshold.

6. The method as claimed in claim 1, wherein identifying the one or more probable root causes comprises: updating, by the RCDS (107), temporarily, the correlation weight of each edge in a sequence of edges corresponding to each of the one or more anomaly nodes; determining, by the RCDS (107), based on the updated correlation weight, a Direct Current Correlation (DCC) between pairs of the logical node in which the error event has occurred and each of the plurality of logical nodes present along each of one or more outgoing paths until the DCC corresponding to at least one of the pairs becomes less than the dynamically configured Current Correlation (CC) threshold, wherein each of the one or more outgoing paths comprise the sequence of edges starting from the logical node in which the error event has occurred; and identifying, by the RCDS (107), the pairs having the DCC greater than the dynamically configured CC threshold as the one or more probable root causes of the error event, wherein each of the one or more probable root causes of the error event form a chunk.

7. The method as claimed in claim 7, wherein each of the one or more probable root causes of the error event in the chunk are arranged in a descending order based on the DCC.

8. The method as claimed in claim 1, wherein generating the one or more rules comprises: determining, by the RCDS (107), a count of each of the one or more probable root causes in total number of chunks currently stored in the RCDS (107) corresponding to one or more error events, wherein the count indicates frequency of occurrence of each of the one or more probable root causes in the total number of chunks; identifying, by the RCDS (107), confidence value of each of the one or more probable root causes based on the corresponding count, wherein the confidence value indicates ratio of number of times the one or more probable root causes have occurred in a predefined position in the total number of chunks and the count of the corresponding probable root cause; comparing, by the RCDS (107), the confidence value and the corresponding count of each of the one or more probable root causes with the confidence threshold and the count threshold respectively; and correlating, by the RCDS (107), the one or more error events comprising a common probable root cause in a predefined manner to generate the one or more rules, wherein the count and the confidence value of the common probable root cause are greater than the count threshold and the confidence threshold respectively.

9. The method as claimed in claim 1, wherein the count threshold indicates a minimum number of occurrences of the one or more probable root causes in total number of chunks and the confidence threshold indicates a minimum ratio value of a confidence value of the one or more probable root causes.

10. A Root Cause Determining System (RCDS) (107) for determining an optimized root cause for an error event in a cloud environment, the RCDS (107) comprising: a processor (109); and a memory (113) communicatively coupled to the processor (109), wherein the memory (113) stores the processor-executable instructions, which, on execution, causes the processor (109) to: receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment; generate a logical graph comprising plurality of logical nodes, wherein each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource; determine a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources; generate a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction; identify one or more probable root causes of the error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window, wherein the one or more anomaly nodes correspond to the logical node in which error event has occurred; and generate dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules.

11. The RCDS (107) as claimed in claim 10, wherein the processor (109) is further configured to verify each of the one or more rules based on one or more predefined techniques.

12. The RCDS (107) as claimed in claim 10, wherein the execution information of the one or more resources comprises at least one of similar execution patterns and dissimilar execution patterns.

13. The RCDS (107) as claimed in claim 10, wherein the logical relationship between the one or more resources comprises at least one of sibling relationship and subsumption relationship, wherein the sibling relationship is the logical relationship between two metrics of a single resource and the subsumption relationship is the logical relationship between a resource and a sub-resource of the resource.

14. The RCDS (107) as claimed in claim 10, wherein the processor (109) generates the PMG by establishing the edges whose correlation weight is greater than a dynamically configured correlation threshold.

15. The RCDS (107) as claimed in claim 10, wherein, to identify the one or more probable root causes, the instructions cause the processor (109) to: update temporarily, the correlation weight of each edge in a sequence of edges corresponding to each of the one or more anomaly nodes; determine, based on the updated correlation weight, a Direct Current Correlation (DCC) between pairs of the logical node in which the error event has occurred and each of the plurality of logical nodes present along each of one or more outgoing paths until the DCC corresponding to at least one of the pairs becomes less than the dynamically configured Current Correlation (CC) threshold, wherein each of the one or more outgoing paths comprise the sequence of edges starting from the logical node in which the error event has occurred ; and identify the pairs having the DCC greater than the dynamically configured CC threshold as the one or more probable root causes of the error event, wherein each of the one or more probable root causes of the error event form a chunk.

16. The RCDS (107) as claimed in claim 15, wherein the processor (109) arranges each of the one or more probable root causes of the error event in the chunk in a descending order based on the DCC.

17. The RCDS (107) as claimed in claim 10, wherein, to generate the one or more rules, the instructions cause the processor (109) to: determine a count of each of the one or more probable root causes in total number of chunks corresponding to one or more error events currently stored in the RCDS (107), wherein the count indicates frequency of occurrence of each of the one or more probable root causes in each of the one or more chunks; identify confidence value of each of the one or more probable root causes based on the corresponding count, wherein the confidence value indicates ratio of number of times the one or more probable root cause have occurred in a predefined position in the total number of chunks and the count of the corresponding probable root cause; compare the confidence value and the corresponding count of each of the one or more probable root causes with the confidence threshold and the count threshold respectively; and correlate the one or more error events comprising a common probable root cause in a predefined manner to generate the one or more rules, wherein the count and the confidence value of the common probable root cause are greater than the count threshold and the confidence threshold respectively.

18. The RCDS (107) as claimed in claim 10, wherein the count threshold indicates a minimum number of occurrences of the one or more probable root causes in total number of chunks and the confidence threshold indicates a minimum ratio value of a confidence value of the one or more probable root causes. , Description:TECHNICAL FIELD The present subject matter is related, in general to root cause analysis system and more particularly, but not exclusively to a method and system for determining an optimized root cause for an error event in a cloud environment. BACKGROUND Cloud environment hosts network, storage, servers and other infrastructure elements. Currently, various industries are moving towards utilizing the cloud environment to meet their requirements, thus creating a high demand for the cloud environment. With high demand comes a greater responsibility of troubleshooting errors occurring in the cloud environment by performing root cause analysis. A root cause analysis system configured in the cloud computing environment may identify the fault/error or a root cause event causing the fault and indicates a source of the problem. To identify the fault or an error event in the cloud environment, the most important necessity would be one or more rules. The one or more rules are either created manually or generated automatically for the root cause analysis system. The time taken to manually create the one or more rules for the root cause analysis system is more due to which there may be significant delay in productizing the root cause analysis system. Further, manually created rules may be prone to numerous faults and the one or more rules may not be completely reliable. The existing techniques solve the above mentioned problem by generating the one or more rules automatically. The one or more rules generated automatically may be “if-then” type of rules. The one or more rules thus generated may be fed into the root cause analysis system to determine solution for the root cause events/error events occurring in the cloud environment. In this approach, the root cause analysis system matches the error events with the list of “if-then” rules such that, if the error events match with “if” part of the one or more rules, the “then” part of the rules provide the root cause. This kind of technique has high precision, but generation of the one or more rules may take substantial amount of time. Also, the process may not be completely automated but would require manual intervention to some extent. The rule based technique may prioritize generating the one or more rules automatically but does not provide enough attention towards coverage, thereby leaving the rule set incomplete. Few other existing techniques follow correlation based root cause analysis to identify the root cause of the error events in the cloud environment. These correlation based techniques may provide a high coverage i.e. most of the scenarios and possibilities related to the error events and the corresponding root causes may be covered. However, these correlation based techniques may achieve the coverage based on logical relationships between resources of the cloud environment and execution information of the resources. The execution information may consider only the resources having similar execution patterns for performing the correlation but not the resources having dissimilar execution patterns. Therefore, a significant amount of coverage may be missed out by not considering the dissimilar execution patterns because, in some scenarios, the resources having entirely dissimilar execution patterns may also be highly related. Further, the correlation based techniques prioritize achieving better coverage, thereby lagging in terms of precision. Also, the correlation based techniques may provide too many probable root causes for a certain error event instead of one optimized root cause. Therefore, detecting the optimized root cause for the error event may involve a lot of time and manual efforts as well. SUMMARY One or more shortcomings of the prior art are overcome and additional advantages are provided through the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure. Disclosed herein is a method of determining an optimized root cause for an error event in a cloud environment. The method comprises receiving, by a Root Cause Determining System (RCDS), information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment. Further, the RCDS generates a logical graph comprising plurality of logical nodes. Each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource. Furthermore, the RCDS determines a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. Upon determining the correlation weight and the data flow direction, the RCDS generates a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction. Further, the RCDS identifies one or more probable root causes of an error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window. The one or more anomaly nodes correspond to the logical node in which error event has occurred. Finally, the RCDS generates dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules. Further, the present disclosure includes a Root Cause Determining System (RCDS) for determining an optimized root cause for an error event in a cloud environment. The RCDS comprising a processor and a memory communicatively coupled to the processor. The memory stores the processor-executable instructions, which, on execution, causes the processor to receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment. Further, the processor generates a logical graph comprising plurality of logical nodes. Each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource. Furthermore, the processor determines a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. Upon determining the correlation weight and the data flow direction , the processor generates a Proactive Metric Graph(PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction . Further, the processor identifies one or more probable root causes of an error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window. The one or more anomaly nodes correspond to the logical node in which error event has occurred. Finally, the processor generates dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules. The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description. BRIEF DESCRIPTION OF THE ACCOMPANYING DIAGRAMS The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which: FIG.1 shows an exemplary architecture for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure; FIG.2A shows a detailed block diagram of a Root Cause Determining System (RCDS) for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure; FIG.2B shows an exemplary logical graph comprising logical nodes indicative of resource and a metric in accordance with some embodiments of the present disclosure; FIG.2C(i) and FIG.2C(ii) shows graphs indicating similar execution patterns of metrics in accordance with some embodiments of the present disclosure; FIG.2D(i) and FIG.2D(ii) shows graphs indicating dissimilar execution patterns of metrics in accordance with some embodiments of the present disclosure; FIG.2E shows an exemplary Proactive Metric Graph (PMG) in accordance with some embodiments of the present disclosure; FIG.2F shows an exemplary PMG indicating error node and anomaly nodes in accordance with some embodiments of the present disclosure; FIG.2G shows an exemplary PMG with updated correlation weights in accordance with some embodiments of the present disclosure; FIG.2H shows an exemplary sub-graph of the PMG indicating Direct Current Correlation in accordance with some embodiments of the present disclosure; FIG.3 shows a flowchart illustrating a method of determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure; and FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure. It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown. DETAILED DESCRIPTION In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments. While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure. The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method. Disclosed herein are a method and system for determining an optimized root cause for an error event in a cloud environment. A Root Cause Determining System (RCDS) may receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment. The one or more data sources are related to the cloud environment such as monitoring systems, topology extractors, cloud servers, databases and the like. Further, the RCDS generates a logical graph comprising plurality of logical nodes. Each of the plurality of logical nodes may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “Central Processing Unit (CPU)” and the metric is “Ready”, the logical node may be [CPU, ready]. Furthermore, the RCDS determines a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. In the present disclosure, the root cause detection may include determining correlation between metrics of the one or more resources having similar execution patterns and dissimilar execution patterns thereby providing optimized coverage. Upon determining the correlation weight and the data flow direction, the RCDS generates a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction. Further, the RCDS identifies one or more probable root causes of an error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG. The one or more anomaly nodes correspond to the logical node in which error event has occurred. The present disclosure provides a feature wherein not just the neighbouring nodes of the logical node in which the error event has occurred but logical nodes beyond the neighbouring nodes are also considered for detecting the root cause. The anomaly nodes are selected based on a predefined time window that covers the most recent root causes of an error event. Finally, the RCDS generates dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules. Therefore, the present disclosure reduces the number of probable root causes for each error event and deduces a single optimized root cause, thus reducing significant amount of time required for determining the root cause for an error event and increasing accuracy and reliability. In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense. FIG.1 shows an exemplary architecture for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure. The architecture 100 comprises one or more data sources, data source 1 1031 to data source n 103n (collectively referred to as one or more data sources 103), a Root Cause Determining System (RCDS) 107 and a rules verification system 115. The one or more data sources 103 are related to the cloud environment such as monitoring systems, topology extractors, cloud servers, databases and the like. The one or more data sources 103 communicate with the RCDS 107 through a communication network (not shown in the FIG.1). As an example, the communication network may be at least one of a wired communication network and a wireless communication network. The RCDS 107 comprises a processor 109, an Input/output (I/O) interface 111 and a memory 113. In an embodiment, the processor 109 may receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from the one or more data sources 103. As an example, if the resource is a Central Processing Unit (CPU), the one or more metrics related to the resource “CPU” includes idle, ready, usage percentage, memory consumed and the like. Upon receiving the information related to the one or more resources and the one or more metrics related to the one or more resources, the processor 109 may generate a logical graph. In some embodiments, the logical graph may include plurality of logical nodes. Each logical node may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “CPU” and the one or more metrics related to the resource “CPU” are idle, ready, usage percentage and memory consumed, the plurality of logical nodes corresponding to the resource “CPU” and the one or more metrics would be (CPU, usage), (CPU, ready), (CPU, usage_percentage) and (CPU, memory_consumed). In some embodiments, the processor 109 may restrict to type of resources and type of metrics related to the resources based on requirement. Further, the RCDS 107 may determine a correlation weight and a data flow direction between each of the plurality of logical nodes based on factors such as logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. In some embodiments, the correlation weight indicates level of correlation between the plurality of logical nodes. Upon determining the correlation weight and the data flow direction between plurality of logical nodes, the processor 109 may compare the correlation weight of each of the plurality of logical nodes with a dynamically configured correlation threshold. If the correlation weight between two logical nodes is greater than the dynamically configured threshold, the processor 109 may establish an edge between two logical nodes. Also, the edge is associated with an arrow head on one end of the edge which is indicative of the data flow direction between the two logical nodes. The completed graph thus generated by establishing the edges between the plurality of logical nodes may be referred to as a Proactive Metric Graph (PMG). In some embodiments, the PMG may act as a blueprint that indicates the necessary connections between the plurality of logical nodes along with the level of correlation and the data flow direction. Further, when an error event occurs in the cloud environment, the processor 109 may identify one or more anomaly nodes corresponding to the logical node in which the error event has occurred. In some embodiments, the one or more anomaly nodes are the logical nodes that may be subjected to one or more anomaly events due to the occurrence of an error event in the logical node. In some embodiments, the one or more anomaly nodes may be selected within a predefined time window. Further, the processor 109 may identify the one or more probable root causes of the error event based on the one or more anomaly nodes. Furthermore, the processor 109 may determine an optimized root cause of the error event from the one or more probable root causes by dynamically generating one or more rules corresponding to the error event. Each of the one or more rules thus generated may be verified by the processor 109 using one or more predefined techniques. In some embodiments, the RCDS 107 may delegate the verification of the one or more rules to a rules verification system 115 which is associated with the RCDS 107. FIG.2A shows a detailed block diagram of a Root Cause Determining System (RCDS) for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure. In some implementations, the Root Cause Determining System (RCDS) 107 may include data 203 and modules 205. As an example, the data 203 is stored in the memory 113 configured in the RCDS 107 as shown in the FIG.2A. In one embodiment, the data 203 may include input data 207, logical graph data 209, logical relationship data 211, cross-correlation data 213, dissimilar pattern correlation data 215, correlation weight data 217, Proactive Metric Graph (PMG) data 219, updated graph data 221, Direct Current Correlation (DCC) data 223, rules generating data 227, rules data 229 and other data 230. In the illustrated FIG.2A, modules 205 are described herein in detail. In some embodiments, the data 203 may be stored in the memory 113 in form of various data structures. Additionally, the data 203 can be organized using data models, such as relational or hierarchical data models. The other data 230 may store data, including temporary data and temporary files, generated by the modules 205 for performing the various functions of the RCDS 107. In some embodiments, the data 203 stored in the memory 113 may be processed by the modules 205 of the RCDS 107. The modules 205 may be stored within the memory 113. In an example, the modules 205 communicatively coupled to the processor 109 configured in the RCDS 107, may also be present outside the memory 113 as shown in FIG.2A and implemented as hardware. As used herein, the term modules refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. In an embodiment, the modules 205 may include, for example, a receiving module 231, a graph generating module 233, a probable root cause identifying module 235, rules generating module 237 and other modules 239. The other modules 239 may be used to perform various miscellaneous functionalities of the RCDS 107. It will be appreciated that such aforementioned modules 205 may be represented as a single module or a combination of different modules. In some embodiments, the receiving module 231 may receive information related to one or more resources of a cloud environment and one or more metrics related to each of the one or more resources from one or more data sources 103 of the cloud environment. The information related to the one or more resources and the one or more metrics may be stored as input data 207. As an example, if the resource is a Central Processing Unit (CPU), the one or more metrics related to the resource “CPU” includes idle, ready, usage percentage, memory consumed and the like. In some embodiments, the graph generating module 233 may generate a Proactive Metric Graph (PMG) based on the input data 207. To generate the PMG, the graph generating module 233 initially generates a logical graph that includes plurality of logical nodes. The logical graph including the plurality of logical nodes may be stored as the logical graph data 209. In some embodiments, each logical node may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “CPU” and the metric related to the resource “CPU” is idle, the logical node would be (CPU, idle). An exemplary logical graph is as shown in the FIG.2B. Similarly, the other exemplary logical nodes as shown in the FIG.2B are [CPU1, CPU_UsageHz], [CPU1, CPU_Total], [CPU1, CPU_Ready] and the like. Further, the graph generating module 233 may establish edges between the plurality of logical nodes. However, to establish the edges between the plurality of logical nodes, the graph generating module 233 may require a correlation weight and a data flow direction between each of the plurality of logical nodes. In some embodiments, the graph generating module 233 may determine the correlation weight and the data flow direction between the plurality of logical nodes based on factors such as logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. As an example, the logical relationship between each of the one or more resources may include, but not limited to, sibling relationship and subsumption relationship. In some embodiments, the sibling relationship is the logical relationship between two metrics of a single resource and the subsumption relationship is the logical relationship between a resource and a sub-resource of the resource. The graph generating module 233 may assign binary value to the sibling relationship of the plurality of logical nodes using which the correlation weight between the plurality of logical nodes may be determined. Similarly, the graph generating module 233 may assign binary value to the subsumption relationship between the plurality of logical nodes using which the correlation weight between the plurality of logical nodes may be determined. The binary values associated with the sibling relationship and the subsumption relationship of the plurality of logical nodes may be stored as the logical relationship data 211. Further, the graph generating module 233 may receive the execution information of the one or more metrics of each of the one or more resources from cloud monitoring tools. In some embodiments, the execution information may include, but not limited to, similar execution patterns and dissimilar execution patterns. The graph generating module 233 may perform cross-correlation between the one or more metrics of the one or more resources that are associated with similar execution patterns. In other words, the graph generating module 233 may perform cross-correlation between each of the plurality of logical nodes including the one or more metrics with similar execution patterns in pairs. Performing cross-correlation between the one or more metrics with similar execution patterns in pairs may provide a temporal deviation value and a cross-correlation weight between the one or more metrics. In some embodiments, the temporal deviation value may be used to decide the direction of the edge between the pair of the plurality of logical nodes. The graph generating module 233 may compare the cross-correlation weight with a predefined weight threshold value. If the cross-correlation weight is less than the predefined weight threshold value, the graph generating module 233 may not use the cross-correlation weight for determining overall correlation weight of the pair of the plurality of logical nodes corresponding to the one or more metrics for which the graph generating module 233 performed cross-correlation. If the cross-correlation weight is greater than the predefined weight threshold value, the graph generating module 233 may use the cross-correlation weight to determine the overall correlation weight of the pair of the plurality of logical nodes corresponding to the one or more metrics for which the graph generating module 233 performed cross-correlation. A value obtained by performing the cross-correlation is stored as the cross-correlation data 213. As an example, consider execution information of two metrics “CPU_util” and “CPU_memory-consumed” as shown in the FIG.2C(i) and FIG.2C(ii). In FIG.2C(i), X-axis 250a indicates “time” and Y-axis 250b indicates “CPU_util”. In FIG.2C(ii), X-axis 251a indicates “time” and Y-axis 251b indicates “CPU_memory-consumed”. Since, the two metrics “CPU_util” and “CPU_memory-consumed” have similar execution patterns, cross-correlation is performed. In some embodiments, the data flow direction between the plurality of logical nodes may be determined based on the execution information between the plurality of logical nodes. In the FIG.2C(i) and FIG.2C(ii), we observe that “CPU_util” is shifted a bit towards left by time “t”. Therefore, the graph generating module 233 may infer that, the data flow direction may be from “CPU_memory-consumed” towards “CPU_util”, since, “CPU_util” is being executed ahead in time compared to “CPU_memory-consumed”. Further, the graph generating module 233 may also determine the correlation between one or more metrics by comparing dissimilar execution patterns of the one or more metrics. However, the graph generating module 233 may not use cross-correlation technique for comparing the dissimilar execution patterns, since the cross-correlation technique may show less correlation value even though the one or more metrics are highly correlated, due to the dissimilar execution patterns. Consider the dissimilar execution patterns of two metrics “CPU_util” and “Port 80 status” as shown in the FIG.2D(i) and FIG.2D(ii). In FIG.2D(i), X-axis 252a indicates “time” and Y-axis 252b indicates “CPU_util”. In FIG.2D(ii), X-axis 253a indicates “time” and Y-axis 253b indicates “Port 80 status”. Execution pattern of the metric “CPU_util” in FIG.2D(i) is a continuous function whereas execution pattern of the metric “Port 80 status” is a step function. Therefore, in such cases where the correlation has to be performed between two dissimilar execution patterns, the graph generating module 233 may depend on a common sub-resource between the two metrics to determine the correlation. The dissimilar execution patterns such as the continuous function and the step function may be highly correlated when both the execution patterns include a sub-resource or processes running on resources are common for a maximum time. Therefore, the graph generating module 233 may associate the sub-resource information or information related to the processes running, of the two dissimilar execution patterns continuously for a certain time “T”. In the FIG.2D(i) and FIG.2D(ii), the process “Nginx” is being executed in both “CPU_util” and “Port 80 status”. Therefore, “Nginx” is a common process identified in both the dissimilar execution patterns. Similarly, the process “Apache”, is another common process identified in both the dissimilar execution patterns. Upon identifying the time for which the sub-resource is common or the time for which the processes running are common, the graph generating module 233 may use the Equation 1 as shown below to determine the correlation between the two metrics. Co = (T-t)/T ----------------------- Equation 1 In the above Equation 1, “Co” indicates correlation between the two metrics; “T” indicates the total time for which the graph generating module 233 compared the two dissimilar execution patterns; and “t” indicates the time interval when no common sub-resources existed during comparison of the dissimilar execution patterns of the two metrics. The correlation determined between the two metrics having dissimilar execution patterns may be stored as the dissimilar pattern correlation data 215. Further, the graph generating module 233 may determine the data flow direction between the pair of plurality of logical nodes for which the correlation has been performed using the above Equation 1, based on time. As an example, in the FIG.2D(i) and FIG.2D(ii), the process “Nginx” is being executed in both the metrics “CPU_util” and “Port_80 status”. Execution of the process “Nginx” started first in “CPU_util” and then after a short delay the process “Nginx” started in “Port_80 status”. Since, “CPU_util” is executing the process “Nginx” ahead in time when compared to “Port 80 status”, the graph generating module 233 may infer that, the data flow direction may be from “Port 80 status” towards “CPU_util”. The data flow direction or the direction from “Port 80 status” to “CPU_util” may indicate that, if an error occurs in “Port 80 status”, “CPU_util” can be a root cause of the error since the process “Nginx” is executed first in “CPU_util”. Further, the graph generating module 233 may assign a hop value of “1” to the plurality of logical nodes whose resources have a direct connection in the actual topology of the cloud environment. The hop value increases with increase in actual physical connectivity of the resources. As an example, hop value between a pair of resources or in other words pair of the plurality of logical nodes would be 3 if the pair of resources are 3 hops away in the actual topology. In some embodiments, the hop value is inversely proportional to the correlation between the pair of the plurality of logical nodes which means, lesser the hop value, greater the correlation and greater the hop value, lesser the correlation. Furthermore, the graph generating module 233 may determine the correlation weight between the pair of the plurality of logical nodes using the Equation 2 as shown below. Corr(i,j) = ?1*? + ?2*Co + ?3*Si + ?4*Su + ?5*H -------------------- Equation 2 In the above Equation 2, i and j indicate the pair of the plurality of logical nodes and Corr(i,j) indicates the correlation weight between the logical nodes i and j. ?1, ?2, ?3 and ?4 are configurable parameters to adjust weight of each of the factors; ? indicates the cross-correlation between the logical nodes i and j; Co indicates the correlation between dissimilar execution patterns; Si indicates the sibling relationship between the logical nodes i and j; Su indicates the subsumption relationship between the logical nodes i and j; and H indicates the hop value between the logical nodes i and j. The correlation weight of each of the plurality of logical nodes may be stored as correlation weight data 217. Upon determining the correlation weight between the pair of the plurality of logical nodes, the graph generating module 233 may compare the correlation weight with a dynamically configured correlation threshold. If the correlation weight is greater than the dynamically configured correlation threshold, the graph generating module 233 may establish an edge between the pair of the plurality of logical edges. Also, the edge is associated with an arrow head on one end of the edge which is indicative of the data flow direction between the pair of the plurality of logical nodes. Similarly, the graph generating module 233 may establish edges between the plurality of logical nodes whose correlation weight is greater than the dynamically configured correlation threshold, thereby generating the PMG. The PMG may be stored as the PMG data 219. An exemplary PMG may be as shown in the FIG.2E which indicates the plurality of logical nodes, the edges and the correlation weight between the plurality of logical nodes and the data flow direction between the plurality of logical nodes. If the correlation weight is less than the dynamically configured correlation threshold, the graph generating module 233 may not establish the edge between the pair of plurality of logical nodes. In some embodiments, the probable root cause identifying module 235 may identify the one or more probable root causes of an error event occurring in the cloud environment. In some embodiments, when an error event or anomaly events occur in the cloud environment, the RCDS 107 may map the error events and the anomaly events on the PMG. The error event may be an unwanted event in the cloud environment that should be rectified immediately before causing any further damage to the cloud environment. The anomaly event may be a slight deviation in behaviour of a metric from original behaviour that does not cause any severe damage to the cloud infrastructure. Initially, the probable root cause identifying module 235 may identify, in the PMG, one or more anomaly nodes corresponding to the logical node in which the error event has occurred. In some embodiments, the one or more anomaly nodes may be the plurality of logical nodes in the PMG associated with one or more anomaly events, that are executed before the execution of the logical node in which the error event has occurred. The probable root cause identifying module 235 may identify the one or more anomaly nodes within a predefined time window. In some embodiments, the one or more data sources 103 such as monitoring systems may identify the error events and the anomaly events and provide the information to the probable root cause identifying module 235, which will map the error event and the anomaly events to the corresponding logical nodes in the PMG. Upon identifying the one or more anomaly nodes in the predefined time window, the probable root cause identifying module 235 may update the correlation weight of each edge in sequence of edges corresponding to each of the one or more anomaly nodes temporarily. In some embodiments, the probable root cause identifying module 235 may perform the updation based on the Equation 3 as shown below. Wi' = 1/(4*H) + Wi ------------------------- Equation 3 In the above Equation 3, Wi' indicates the updated correlation weight of the edge i from the logical node where the error event has occurred towards the each of the one or more anomaly nodes; H indicates the hop distance/value between the logical node where the error event has occurred and each of the one or more anomaly nodes; and Wi indicates the initial weight of each edge prior to updation. As an example, consider the PMG as shown in the FIG.2F with numbers [in bold] indicating each edge corresponding to the plurality of logical nodes. In the FIG.2F, logical node where the error has occurred is [CPU1, Mem_shared] and the one or more anomaly nodes are [CPU1, CPU_usage%] and [CPU1, CPU_idle]. Table 1 indicates the updated correlation weight of each edge in the sequence of edges corresponding to each of the one or more anomaly nodes determined using the above Equation 3. Logical nodes representing the edge Existing correlation weight Hop distance Updated correlation weight 1 2.1 1 1/(4*1)+2.1 = 2.35 2 2.8 2 1/(4*2)+2.8 = 2.93 3 2.6 2 1/(4*2)+2.6 = 2.73 4 2.1 2 1/(4*2)+2.1 = 2.23 5 2.4 3 1/(4*3)+2.4 = 2.48 6 2.9 4 1/(4*4)+2.9 = 2.96 7 2.5 1 1/(4*1)+2.5 = 2.75 8 2.3 2 1/(4*2)+2.3 = 2.43 9 2.7 2 1/(4*2)+2.7 = 2.83 Table 1 Updated PMG indicating the updated correlation weight is stored as the updated graph data 221. The temporarily updated PMG including the logical node where the error event has occurred and each of the one or more anomaly nodes within the predefined time window along with the updated correlation weight calculated in the Table 1, is as shown in the FIG.2G. Upon obtaining the temporarily updated PMG, the probable root cause identifying module 235 may determine a Direct Current Correlation (DCC) between the plurality of logical nodes starting from the logical node in which the error event has occurred and moving away to the next logical node based on the sequence of edges until the DCC value becomes less than the dynamically configured CC threshold. For the plurality of logical nodes that are at a hop distance of 1 from the logical node in which the error event has occurred, the correlation weight is same as the original correlation weight of the edge between the plurality of logical nodes which is shown in the Equation 4. For the plurality of logical nodes that are at a hop distance greater than 1, the probable root cause identifying module 235 may determine the DCC from the logical node in which the error event has occurred by using the Equation 4 given below. DCC = (Diff /a) * W ------------------ Equation 4 In the above Equation 4, Diff is the difference between the updated correlation weight of previous logical node and a dynamically configured Current Correlation (CC) threshold; a indicates configurable parameter to adjust the Diff value according to requirement; and W indicates updated correlation weight of the edge connecting the current node with the previous node. DCC between the logical node in which the error event has occurred and each of the plurality of logical nodes may be stored as the DCC data 223. Upon obtaining the DCC, the probable root cause identifying module 235 may compare the DCC of each of the plurality of logical nodes in real-time with the dynamically configured CC threshold. The plurality of logical nodes having the DCC greater than the dynamically configured CC threshold may be identified as the one or more probable root causes of the error event. Each of the one or more probable root causes of the error event occurring in the logical node are arranged in a descending order according to the DCC to form a chunk. The probable root cause identifying module 235 may stop determining the DCC of the plurality of logical nodes when the DCC value of the plurality of logical nodes becomes lesser than the dynamically configured CC threshold. Consider the PMG as shown in the FIG.2G. The exemplary DCC values calculated for each of the plurality of logical nodes along the sequence of edges are as shown in the below Table 2 and pictorially indicated in the FIG.2H. Consider that path 1 and path 2 as indicated in the FIG.2H are the only two outgoing paths from the logical node in which the error has occurred. Therefore, the probable root cause identifying module 235 takes one path at a time starting from the logical node in which the error has occurred until the DCC becomes less than the dynamically configured CC threshold. The dynamically configured CC threshold is considered to be 2.0 for illustrating the example. Logical Node Pair Path Number DCC [CPU1, Mem_shared], [CPU1, Mem_remaining] Path 1 2.75 [CPU1, Mem_shared], [CPU1, CPU_usage%] Path 1 (2.75 – 2.0) / 0.55 * (2.43) = 3.31 [CPU1, Mem_shared], [CPU1, CPU_ready] Path 2 2.35 [CPU1, Mem_shared], [CPU1, CPU_idle] Path 2 (2.35 – 2.0) / 0.55 * (2.93) = 1.86 Table 2 In the above Table 2, upon determining the DCC for the logical node pair [CPU1, Mem_shared], [CPU1, CPU_usage%], there exists no other logical node beyond the logical node [CPU1, CPU_usage%] according to the FIG.2H. Therefore, the probable root cause identifying module 235 may stop determining further DCC along Path 1. However, along path 2, the logical node pair [CPU1, Mem_shared], [CPU1, CPU_idle] has the DCC value less than the dynamically configured CC threshold. Therefore, the probable root cause identifying module 235 may stop determining further DCC along Path 2. However, if there existed logical nodes beyond the logical node [CPU1, CPU_idle], the probable root cause identifying module 235 may not proceed further since the DCC value of current logical node is less than the dynamically configured CC threshold. The probable root cause determining module 235 may arrange the logical node pairs whose DCC is greater than or equal to the dynamically configured CC threshold in the descending order based on the DCC values to form a chunk as shown below. Error Event 1: [CPU1, Mem_shared] Chunk-1

1. [CPU1, Mem_shared], [CPU1, Mem_remaining]

2. [CPU1, Mem_shared], [CPU1, CPU_usage%]

3. [CPU1, Mem_shared], [CPU1, CPU_ready] The logical node pairs arranged in descending order in the chunk may be the one or more probable root causes of the error event that occurred in the cloud environment. The chunks comprising the one or more probable root causes are stored as the chunk data 225. Upon obtaining the chunk for the error event, the probable root cause identifying module 235 may revert the updated correlation weight corresponding to the plurality of logical nodes to the corresponding original correlation weights until a next error event occurs in the cloud environment. This will bring the current state of PMG from as shown in FIG.2G to the one shown in FIG2E. In some embodiments, the rules generating module 237 may generate one or more rules corresponding to the one or more error events. The one or more rules help in determining the optimized root cause of each of the one or more error events from the one or more probable root causes. Initially, the rules generating module 237 may determine a count of each of the one or more probable root causes in one or more chunks corresponding to one or more error events. The count indicates frequency of occurrence of each of the one or more probable root causes in each of the one or more chunks. Further, the rules generating module 237 may determine confidence value of each of the one or more probable root causes based on the corresponding count. The confidence value indicates ratio of number of times the one or more probable root causes have occurred in a predefined position in the one or more chunks and the count of the corresponding probable root cause. In some embodiments, the predefined position may be first position in the chunk since the first position in the chunk contains the probable root cause having the highest DCC compared to the other probable root causes in the chunk. The count and the confidence values are stored as the rule generating data 227. Furthermore, the rules generating module 237 may compare the confidence value and the corresponding count of each of the one or more probable root causes with a confidence threshold and a count threshold respectively. In some embodiments, the count threshold indicates a minimum number of occurrences of the one or more probable root causes in total number of chunks currently stored in the RCDS 107. Further, the confidence threshold indicates a minimum ratio value of a confidence value of the one or more probable root causes. If the count and the confidence value of the one or more probable root causes are equal to or greater than the count threshold and the confidence threshold respectively, the rules generating module 237 may correlate the error events comprising the common probable root cause in a predefined manner to generate the one or more rules. The predefined manner for correlating the one or more error events to generate the one or more rules is stored as the rules generating data 227. In some embodiments, the predefined manner may include correlating the error events having the common probable root cause by introducing a conjunction symbol between the error events, if the common probable root cause appears in the predefined position. As an example, the predefined position may be the first position. Further, the predefined manner may include correlating the error events having the common probable root cause by introducing a disjunction symbol between the error events, if the common probable root cause appears in any other position other than the predefined position. Based on the correlation, the rules generating module 237 may generate the one or more rules that determines the common probable root cause as the optimized root cause of the error event for which the common probable root cause appeared in the predefined position in the chunk. The one or more rules generated by the rules generating module 237 may be stored as the rules data 229. If the count and the confidence value are less than the count threshold and the confidence threshold respectively, then the rules generating system 237 may discard the common probable root cause. Consider 3 exemplary chunks for the error events as shown below. Chunk 1: ( {[CPU1, Mem_shared]}, {[CPU1, Mem_remaining], [CPU1, CPU_usage%], [CPU1, CPU_ready]} ) Chunk 2: ( {[CPU1, Mem_consumed]}, {[CPU1, Mem_shared], [CPU1, CPU_usageHz], [CPU1, CPU_usage%]} ) Chunk 3: ( {[CPU1, CPU_ready]}, {[CPU1, Mem_UsageHz], [CPU1, CPU_usage%], [CPU1, Mem_remaining]} ) In the above chunks, the probable root cause [CPU1, Mem_remaining] has appeared twice in chunk 1 and chunk 3. Therefore, count of the probable root cause [CPU1, Mem_remaining] is 2. The probable root cause [CPU1, Mem_remaining] has appeared once in the first position. Therefore, confidence value of the probable root cause [CPU1, Mem_remaining] is 1/2. Consider that the count threshold is 2 and the confidence threshold is 1/4. The count and the confidence value of the probable root cause [CPU1, Mem_remaining] are equal to the count threshold and greater than the confidence threshold respectively. Therefore, the rules generating system 237 may generate the rule for the error events [CPU1, Mem_shared] and the [CPU1, CPU_ready] as shown below: ( [CPU1, Mem_shared] ? [CPU1, CPU_ready]) ? Optimized root cause = [CPU1, Mem_remaining] Therefore, the optimized root cause of the error event [CPU1, Mem_shared] is [CPU1, Mem_remaining] Upon generating the one or more rules, the one or more rules may be verified by a rules verification system 115 associated with the RCDS 107 for identifying one or more faults in the one or more rules. As an example, the one or more faults include, but not limited to, correctness, redundancy, completeness and consistency. In an embodiment, a verification technique disclosed in the Indian Patent Application: 6303/CHE/2015 may be used by the rules verification system 115 to verify the one or more rules. Entire content of the Indian Patent Application: 6303/CHE/2015 is incorporated by reference herein. In an alternative embodiment, other verification techniques may also be used by the rules verification system 115 to verify the one or more rules. The one or more faults may also be manually corrected as illustrated in the Indian Patent Application: 6303/CHE/2015. The RCDS 107 may rectify the one or more faults, if any and updates the one or more rules dynamically. When an error event occurs in the cloud environment, the RCDS 107 may determine the root cause of the error event based on the one or more rules stored in the memory 113. If the one or more rules are not present in the memory 113 for a certain error event, the RCDS 107 may follow the method described above to generate the one or more rules and determine the optimized root cause for the error event. FIG.3 illustrates a flowchart showing a method of determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure. As illustrated in FIG.3, the method 300 includes one or more blocks illustrating a method of determining an optimized root cause for an error event in a cloud environment. The method 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types. The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 300. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 300 can be implemented in any suitable hardware, software, firmware, or combination thereof. At block 301, the method 300 may include receiving, by a processor 109 of the Root Cause Determining System (RCDS) 107, information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment. At block 303, the method 300 may include generating, by the processor 109, a logical graph comprising plurality of logical nodes. Each logical node may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “CPU” and the metric associate with CPU is idle, then the logical node would be (CPU, idle). At block 305, the method 300 may include determining, by the processor 109, a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. The correlation weight indicates level of correlation between the plurality of logical nodes. In some embodiments, the logical relationship may include, but not limited to, sibling relationship and subsumption relationship. Further, in some embodiments, the execution information of the one or more metrics of the one or more resources may include execution information with similar execution patterns and execution information with dissimilar execution patterns. Furthermore, the hop distance is inversely proportional to the level of correlation between the plurality of logical nodes. In some embodiments, the data flow direction may indicate direction in which the process is driven. In the representation of the data flow direction, if the logical node present at tail of the edge is where the error event has occurred, the logical node present at head of the edge indicated by an arrow head may be the probable root cause. At block 307, the method 300 may include generating, by the processor 109, a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction. The processor 109 may establish the edges only when the correlation weight between the plurality of logical nodes is greater than a dynamically configured correlation threshold. At block 309, the method 300 may include identifying, by the processor 109, one or more probable root causes of an error event occurring in the cloud environment. In some embodiments, the processor 109 may identify one or more anomaly nodes in the PMG within a predefined time window. In some embodiments, the one or more data sources 103 such as monitoring systems may identify error events and anomaly events and provide the information to the RCDS 107, which will map the error event and the anomaly events to the corresponding logical nodes in the PMG. The processor 109 may update the correlation weight of each edge in the sequence of edges corresponding to each of the one or more anomaly nodes temporarily. Further, the processor 109 may determine a Direct Current Correlation (DCC) between pairs of the logical node in which the error event has occurred and each of the plurality of logical nodes present along each of one or more outgoing paths, based on the updated correlation weight. In some embodiments, each of the one or more outgoing paths may include the sequence of edges starting from the logical node in which the error event has occurred. In some embodiments, the processor 109 may proceed in each of the one or more outgoing paths sequentially to determine the DCC until the DCC of at least one pair in each of the one or more outgoing paths becomes less than the dynamically configured Current Correlation (CC) threshold. In some embodiments, the processor 109 may also stop determining DCC when number of edges along a certain outgoing path have ended. Further, the processor 109 may select logical node pairs corresponding to each edge having the DCC greater than a dynamically configured CC threshold and form a chunk by arranging the logical node pairs in a descending order based on the DCC. The one or more logical node pairs arranged in the chunk may be the one or more probable root causes of the error event. At block 311, the method 300 may include generating, by the processor 109, one or more rules corresponding to the error event. In some embodiments, the processor 109 may determine a count of each of the one or more probable root causes in total number of chunks corresponding to one or more error events currently stored in the RCDS 107. Count indicates frequency of occurrence of each of the one or more probable root causes in each of the total number of chunks. Further, the processor 109 may identify a confidence value of each of the one or more probable root causes based on the corresponding count. The confidence value indicates ratio of number of times the one or more probable root causes have occurred in a predefined position in one or more chunks and the count of the corresponding probable root cause. The processor 109 correlates the one or more events comprising a common probable root cause in a predefined manner to generate the one or more rules, when the count and the confidence value of the one or more probable root causes is greater than a count threshold and a confidence threshold. The processor 109 may determine the optimized root cause of each of the one or more error events based on the one or more rules. FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure. In an embodiment, FIG.4 illustrates a block diagram of an exemplary computer system 400 for implementing embodiments consistent with the present invention. In an embodiment, the computer system 400 can be Root Cause Determining System (RCDS) 107 that is used determining an optimized root cause for an error event in a cloud environment. The computer system 400 may include a central processing unit (“CPU” or “processor”) 402. The processor 402 may include at least one data processor for executing program components for executing user or system-generated business processes. A user may include a person, a person using a device such as those included in this invention, or such a device itself. The processor 402 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc. The processor 402 may be disposed in communication with one or more input/output (I/O) devices (411 and 412) via I/O interface 401. The I/O interface 401 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like), etc. Using the I/O interface 401, computer system 400 may communicate with one or more I/O devices (411 and 412). In some embodiments, the processor 402 may be disposed in communication with a communication network 409 via a network interface 403. The network interface 403 may communicate with the communication network 409. The network interface 403 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 403 and the communication network 409, the computer system 400 may communicate with data source 1 4101 to data source n 410n (also referred to as one or more data sources 410). The communication network 409 can be implemented as one of the different types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 409 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 409 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. The one or more data sources 410 may include monitoring systems, topology extractors, cloud servers, databases and the like. In some embodiments, the processor 402 may be disposed in communication with a memory 405 (e.g., RAM, ROM, etc. not shown in FIG.4) via a storage interface 404. The storage interface 404 may connect to memory 405 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fibre channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc. The memory 405 may store a collection of program or database components, including, without limitation, a user interface 406, an operating system 407, a web browser 408 etc. In some embodiments, the computer system 400 may store user/application data, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase. The operating system 407 may facilitate resource management and operation of the computer system 400. Examples of operating systems include, without limitation, Apple Macintosh OS X, UNIX, Unix-like system distributions (e.g., Berkeley Software Distribution (BSD), FreeBSD, NetBSD, OpenBSD, etc.), Linux distributions (e.g., Red Hat, Ubuntu, Kubuntu, etc.), International Business Machines (IBM) OS/2, Microsoft Windows (XP, Vista/7/8, etc.), Apple iOS, Google Android, Blackberry Operating System (OS), or the like. The User interface 406 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 400, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical User Interfaces (GUIs) may be employed, including, without limitation, Apple Macintosh operating systems’ Aqua, IBM OS/2, Microsoft Windows (e.g., Aero, Metro, etc.), Unix X-Windows, web interface libraries (e.g., ActiveX, Java, Javascript, AJAX, HTML, Adobe Flash, etc.), or the like. In some embodiments, the computer system 400 may implement the web browser 408 stored program components. The web browser 408 may be a hypertext viewing application, such as Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, Apple Safari, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS) secure sockets layer (SSL), Transport Layer Security (TLS), etc. Web browsers may utilize facilities such as AJAX, DHTML, Adobe Flash, JavaScript, Java, Application Programming Interfaces (APIs), etc. In some embodiments, the computer system 400 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as Active Server Pages (ASP), ActiveX, American National Standards Institute (ANSI) C++/C#, Microsoft .NET, CGI scripts, Java, JavaScript, PERL, PHP, Python, WebObjects, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), Microsoft Exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 400 may implement a mail client stored program component. The mail client may be a mail viewing application, such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Mozilla Thunderbird, etc. Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, non-volatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media. Advantages of the embodiment of the present disclosure are illustrated herein. In an embodiment, the present disclosure provides a method and a system determining an optimized root cause for an error event in a cloud environment. The present disclosure combines rule-based and correlation-based techniques of root cause analysis for providing improved coverage in less amount of time comparatively. The present disclosure provides a feature wherein the root cause detection includes determining correlation between metrics of one or more resources having dissimilar execution patterns, thereby providing optimized coverage. The present disclosure provides a feature wherein one or more rules are dynamically generated using probable root cause chunks of one or more error events to provide a single optimized root cause for each error event. Therefore, the present disclosure reduces the number of probable root causes for each error event and deduces a single optimized root cause, thus reducing significant amount of time required for determining the root cause for an error event and increasing accuracy and reliability. The present disclosure provides a feature wherein not just the neighbouring nodes of the logical node in which the error event has occurred but adjacent nodes also are considered as anomaly nodes. The anomaly nodes are selected based on a predefined time window that covers the most recent root causes of an error event. A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention. When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself. The specification has described a method and a system determining an optimized root cause for an error event in a cloud environment. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that on-going technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open-ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims. Referral numerals Reference Number Description 100 Architecture 103 One or more data sources 107 Root Cause Determining System (RCDS) 109 Processor 111 I/O interface 113 Memory 203 Data 205 Modules 207 Input data 209 Logical graph data 211 Logical relationship data 213 Cross-correlation data 215 Dissimilar pattern correlation data 217 Correlation weight data 219 Proactive Metric Graph (PMG) data 221 Updated graph data 223 Direct Current Correlation (DCC) data 227 Rules generating data 229 Rules data 230 Other data 231 Receiving module 233 Graph generating module 235 Probable root cause identifying module 237 Rules generating module 239 Other modules 250a X-axis indicating time in FIG.2C(i) 250b Y-axis indicating CPU_util in FIG.2C(i) 251a X-axis indicating time in FIG.2C(ii) 251b Y-axis indicating CPU_memory consumed in FIG.2C(ii) 252a X-axis indicating time in FIG.2D(i) 252b Y-axis indicating CPU_util in FIG.2D(i) 253a X-axis indicating time in FIG.2D(ii) 253b Y-axis indicating Port 80 statues in FIG.2D(ii)

Claims:1. A method of determining an optimized root cause for an error event in a cloud environment, the method comprising:
receiving, by a Root Cause Determining System (RCDS) (107), information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment;
generating, by the RCDS (107), a logical graph comprising plurality of logical nodes, wherein each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource;
determining, by the RCDS (107), a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources;
generating, by the RCDS (107), a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction;
identifying, by the RCDS (107), one or more probable root causes of the error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window, wherein the one or more anomaly nodes correspond to the logical node in which error event has occurred; and
generating, by the RCDS (107), dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules.
2. The method as claimed in claim 1 further comprises verifying, by the RCDS (107), each of the one or more rules based on one or more predefined techniques.

3. The method as claimed in claim 1, wherein the execution information of the one or more resources comprises at least one of similar execution patterns and dissimilar execution patterns.

4. The method as claimed in claim 1, wherein the logical relationship between the one or more resources comprises at least one of sibling relationship and subsumption relationship, wherein the sibling relationship is the logical relationship between two metrics of a single resource and the subsumption relationship is the logical relationship between a resource and a sub-resource of the resource.

5. The method as claimed in claim 1, wherein generating the PMG comprises establishing the edges whose correlation weight is greater than a dynamically configured correlation threshold.

6. The method as claimed in claim 1, wherein identifying the one or more probable root causes comprises:
updating, by the RCDS (107), temporarily, the correlation weight of each edge in a sequence of edges corresponding to each of the one or more anomaly nodes;
determining, by the RCDS (107), based on the updated correlation weight, a Direct Current Correlation (DCC) between pairs of the logical node in which the error event has occurred and each of the plurality of logical nodes present along each of one or more outgoing paths until the DCC corresponding to at least one of the pairs becomes less than the dynamically configured Current Correlation (CC) threshold, wherein each of the one or more outgoing paths comprise the sequence of edges starting from the logical node in which the error event has occurred; and
identifying, by the RCDS (107), the pairs having the DCC greater than the dynamically configured CC threshold as the one or more probable root causes of the error event, wherein each of the one or more probable root causes of the error event form a chunk.
7. The method as claimed in claim 7, wherein each of the one or more probable root causes of the error event in the chunk are arranged in a descending order based on the DCC.

8. The method as claimed in claim 1, wherein generating the one or more rules comprises:
determining, by the RCDS (107), a count of each of the one or more probable root causes in total number of chunks currently stored in the RCDS (107) corresponding to one or more error events, wherein the count indicates frequency of occurrence of each of the one or more probable root causes in the total number of chunks;
identifying, by the RCDS (107), confidence value of each of the one or more probable root causes based on the corresponding count, wherein the confidence value indicates ratio of number of times the one or more probable root causes have occurred in a predefined position in the total number of chunks and the count of the corresponding probable root cause;
comparing, by the RCDS (107), the confidence value and the corresponding count of each of the one or more probable root causes with the confidence threshold and the count threshold respectively; and
correlating, by the RCDS (107), the one or more error events comprising a common probable root cause in a predefined manner to generate the one or more rules, wherein the count and the confidence value of the common probable root cause are greater than the count threshold and the confidence threshold respectively.
9. The method as claimed in claim 1, wherein the count threshold indicates a minimum number of occurrences of the one or more probable root causes in total number of chunks and the confidence threshold indicates a minimum ratio value of a confidence value of the one or more probable root causes.

10. A Root Cause Determining System (RCDS) (107) for determining an optimized root cause for an error event in a cloud environment, the RCDS (107) comprising:
a processor (109); and
a memory (113) communicatively coupled to the processor (109), wherein the memory (113) stores the processor-executable instructions, which, on execution, causes the processor (109) to:
receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment;
generate a logical graph comprising plurality of logical nodes, wherein each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource;
determine a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources;
generate a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction;
identify one or more probable root causes of the error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window, wherein the one or more anomaly nodes correspond to the logical node in which error event has occurred; and
generate dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules.
11. The RCDS (107) as claimed in claim 10, wherein the processor (109) is further configured to verify each of the one or more rules based on one or more predefined techniques.

12. The RCDS (107) as claimed in claim 10, wherein the execution information of the one or more resources comprises at least one of similar execution patterns and dissimilar execution patterns.

13. The RCDS (107) as claimed in claim 10, wherein the logical relationship between the one or more resources comprises at least one of sibling relationship and subsumption relationship, wherein the sibling relationship is the logical relationship between two metrics of a single resource and the subsumption relationship is the logical relationship between a resource and a sub-resource of the resource.

14. The RCDS (107) as claimed in claim 10, wherein the processor (109) generates the PMG by establishing the edges whose correlation weight is greater than a dynamically configured correlation threshold.

15. The RCDS (107) as claimed in claim 10, wherein, to identify the one or more probable root causes, the instructions cause the processor (109) to:
update temporarily, the correlation weight of each edge in a sequence of edges corresponding to each of the one or more anomaly nodes;
determine, based on the updated correlation weight, a Direct Current Correlation (DCC) between pairs of the logical node in which the error event has occurred and each of the plurality of logical nodes present along each of one or more outgoing paths until the DCC corresponding to at least one of the pairs becomes less than the dynamically configured Current Correlation (CC) threshold, wherein each of the one or more outgoing paths comprise the sequence of edges starting from the logical node in which the error event has occurred ; and
identify the pairs having the DCC greater than the dynamically configured CC threshold as the one or more probable root causes of the error event, wherein each of the one or more probable root causes of the error event form a chunk.
16. The RCDS (107) as claimed in claim 15, wherein the processor (109) arranges each of the one or more probable root causes of the error event in the chunk in a descending order based on the DCC.

17. The RCDS (107) as claimed in claim 10, wherein, to generate the one or more rules, the instructions cause the processor (109) to:
determine a count of each of the one or more probable root causes in total number of chunks corresponding to one or more error events currently stored in the RCDS (107), wherein the count indicates frequency of occurrence of each of the one or more probable root causes in each of the one or more chunks;
identify confidence value of each of the one or more probable root causes based on the corresponding count, wherein the confidence value indicates ratio of number of times the one or more probable root cause have occurred in a predefined position in the total number of chunks and the count of the corresponding probable root cause;
compare the confidence value and the corresponding count of each of the one or more probable root causes with the confidence threshold and the count threshold respectively; and
correlate the one or more error events comprising a common probable root cause in a predefined manner to generate the one or more rules, wherein the count and the confidence value of the common probable root cause are greater than the count threshold and the confidence threshold respectively.
18. The RCDS (107) as claimed in claim 10, wherein the count threshold indicates a minimum number of occurrences of the one or more probable root causes in total number of chunks and the confidence threshold indicates a minimum ratio value of a confidence value of the one or more probable root causes.
, Description:TECHNICAL FIELD

The present subject matter is related, in general to root cause analysis system and more particularly, but not exclusively to a method and system for determining an optimized root cause for an error event in a cloud environment.

BACKGROUND

Cloud environment hosts network, storage, servers and other infrastructure elements. Currently, various industries are moving towards utilizing the cloud environment to meet their requirements, thus creating a high demand for the cloud environment. With high demand comes a greater responsibility of troubleshooting errors occurring in the cloud environment by performing root cause analysis. A root cause analysis system configured in the cloud computing environment may identify the fault/error or a root cause event causing the fault and indicates a source of the problem. To identify the fault or an error event in the cloud environment, the most important necessity would be one or more rules. The one or more rules are either created manually or generated automatically for the root cause analysis system. The time taken to manually create the one or more rules for the root cause analysis system is more due to which there may be significant delay in productizing the root cause analysis system. Further, manually created rules may be prone to numerous faults and the one or more rules may not be completely reliable.
The existing techniques solve the above mentioned problem by generating the one or more rules automatically. The one or more rules generated automatically may be “if-then” type of rules. The one or more rules thus generated may be fed into the root cause analysis system to determine solution for the root cause events/error events occurring in the cloud environment. In this approach, the root cause analysis system matches the error events with the list of “if-then” rules such that, if the error events match with “if” part of the one or more rules, the “then” part of the rules provide the root cause. This kind of technique has high precision, but generation of the one or more rules may take substantial amount of time. Also, the process may not be completely automated but would require manual intervention to some extent. The rule based technique may prioritize generating the one or more rules automatically but does not provide enough attention towards coverage, thereby leaving the rule set incomplete. Few other existing techniques follow correlation based root cause analysis to identify the root cause of the error events in the cloud environment. These correlation based techniques may provide a high coverage i.e. most of the scenarios and possibilities related to the error events and the corresponding root causes may be covered. However, these correlation based techniques may achieve the coverage based on logical relationships between resources of the cloud environment and execution information of the resources. The execution information may consider only the resources having similar execution patterns for performing the correlation but not the resources having dissimilar execution patterns. Therefore, a significant amount of coverage may be missed out by not considering the dissimilar execution patterns because, in some scenarios, the resources having entirely dissimilar execution patterns may also be highly related. Further, the correlation based techniques prioritize achieving better coverage, thereby lagging in terms of precision. Also, the correlation based techniques may provide too many probable root causes for a certain error event instead of one optimized root cause.
Therefore, detecting the optimized root cause for the error event may involve a lot of time and manual efforts as well.

SUMMARY
One or more shortcomings of the prior art are overcome and additional advantages are provided through the present disclosure. Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.
Disclosed herein is a method of determining an optimized root cause for an error event in a cloud environment. The method comprises receiving, by a Root Cause Determining System (RCDS), information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment. Further, the RCDS generates a logical graph comprising plurality of logical nodes. Each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource. Furthermore, the RCDS determines a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. Upon determining the correlation weight and the data flow direction, the RCDS generates a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction. Further, the RCDS identifies one or more probable root causes of an error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window. The one or more anomaly nodes correspond to the logical node in which error event has occurred. Finally, the RCDS generates dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules.
Further, the present disclosure includes a Root Cause Determining System (RCDS) for determining an optimized root cause for an error event in a cloud environment. The RCDS comprising a processor and a memory communicatively coupled to the processor. The memory stores the processor-executable instructions, which, on execution, causes the processor to receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment. Further, the processor generates a logical graph comprising plurality of logical nodes. Each of the plurality of logical nodes is indicative of at least one resource and at least one metric corresponding to the at least one resource. Furthermore, the processor determines a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. Upon determining the correlation weight and the data flow direction , the processor generates a Proactive Metric Graph(PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction . Further, the processor identifies one or more probable root causes of an error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG in a predefined time window. The one or more anomaly nodes correspond to the logical node in which error event has occurred. Finally, the processor generates dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules.
The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.
BRIEF DESCRIPTION OF THE ACCOMPANYING DIAGRAMS
The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and/or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and with reference to the accompanying figures, in which:
FIG.1 shows an exemplary architecture for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure;
FIG.2A shows a detailed block diagram of a Root Cause Determining System (RCDS) for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure;
FIG.2B shows an exemplary logical graph comprising logical nodes indicative of resource and a metric in accordance with some embodiments of the present disclosure;
FIG.2C(i) and FIG.2C(ii) shows graphs indicating similar execution patterns of metrics in accordance with some embodiments of the present disclosure;
FIG.2D(i) and FIG.2D(ii) shows graphs indicating dissimilar execution patterns of metrics in accordance with some embodiments of the present disclosure;
FIG.2E shows an exemplary Proactive Metric Graph (PMG) in accordance with some embodiments of the present disclosure;
FIG.2F shows an exemplary PMG indicating error node and anomaly nodes in accordance with some embodiments of the present disclosure;
FIG.2G shows an exemplary PMG with updated correlation weights in accordance with some embodiments of the present disclosure;
FIG.2H shows an exemplary sub-graph of the PMG indicating Direct Current Correlation in accordance with some embodiments of the present disclosure;
FIG.3 shows a flowchart illustrating a method of determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure; and

FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether or not such computer or processor is explicitly shown.
DETAILED DESCRIPTION
In the present document, the word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or implementation of the present subject matter described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments.
While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.
The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.
Disclosed herein are a method and system for determining an optimized root cause for an error event in a cloud environment. A Root Cause Determining System (RCDS) may receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment. The one or more data sources are related to the cloud environment such as monitoring systems, topology extractors, cloud servers, databases and the like. Further, the RCDS generates a logical graph comprising plurality of logical nodes. Each of the plurality of logical nodes may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “Central Processing Unit (CPU)” and the metric is “Ready”, the logical node may be [CPU, ready]. Furthermore, the RCDS determines a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. In the present disclosure, the root cause detection may include determining correlation between metrics of the one or more resources having similar execution patterns and dissimilar execution patterns thereby providing optimized coverage. Upon determining the correlation weight and the data flow direction, the RCDS generates a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction.
Further, the RCDS identifies one or more probable root causes of an error event occurring in the cloud environment based on one or more anomaly nodes identified in the PMG. The one or more anomaly nodes correspond to the logical node in which error event has occurred. The present disclosure provides a feature wherein not just the neighbouring nodes of the logical node in which the error event has occurred but logical nodes beyond the neighbouring nodes are also considered for detecting the root cause. The anomaly nodes are selected based on a predefined time window that covers the most recent root causes of an error event. Finally, the RCDS generates dynamically, one or more rules corresponding to the error event based on a count threshold and a confidence threshold, thereby determining the optimized root cause of each of the one or more error events from the one or more probable root causes based on the one or more rules. Therefore, the present disclosure reduces the number of probable root causes for each error event and deduces a single optimized root cause, thus reducing significant amount of time required for determining the root cause for an error event and increasing accuracy and reliability.
In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

FIG.1 shows an exemplary architecture for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure.

The architecture 100 comprises one or more data sources, data source 1 1031 to data source n 103n (collectively referred to as one or more data sources 103), a Root Cause Determining System (RCDS) 107 and a rules verification system 115. The one or more data sources 103 are related to the cloud environment such as monitoring systems, topology extractors, cloud servers, databases and the like. The one or more data sources 103 communicate with the RCDS 107 through a communication network (not shown in the FIG.1). As an example, the communication network may be at least one of a wired communication network and a wireless communication network.
The RCDS 107 comprises a processor 109, an Input/output (I/O) interface 111 and a memory 113. In an embodiment, the processor 109 may receive information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from the one or more data sources 103. As an example, if the resource is a Central Processing Unit (CPU), the one or more metrics related to the resource “CPU” includes idle, ready, usage percentage, memory consumed and the like. Upon receiving the information related to the one or more resources and the one or more metrics related to the one or more resources, the processor 109 may generate a logical graph. In some embodiments, the logical graph may include plurality of logical nodes. Each logical node may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “CPU” and the one or more metrics related to the resource “CPU” are idle, ready, usage percentage and memory consumed, the plurality of logical nodes corresponding to the resource “CPU” and the one or more metrics would be (CPU, usage), (CPU, ready), (CPU, usage_percentage) and (CPU, memory_consumed). In some embodiments, the processor 109 may restrict to type of resources and type of metrics related to the resources based on requirement. Further, the RCDS 107 may determine a correlation weight and a data flow direction between each of the plurality of logical nodes based on factors such as logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources.
In some embodiments, the correlation weight indicates level of correlation between the plurality of logical nodes. Upon determining the correlation weight and the data flow direction between plurality of logical nodes, the processor 109 may compare the correlation weight of each of the plurality of logical nodes with a dynamically configured correlation threshold. If the correlation weight between two logical nodes is greater than the dynamically configured threshold, the processor 109 may establish an edge between two logical nodes. Also, the edge is associated with an arrow head on one end of the edge which is indicative of the data flow direction between the two logical nodes. The completed graph thus generated by establishing the edges between the plurality of logical nodes may be referred to as a Proactive Metric Graph (PMG). In some embodiments, the PMG may act as a blueprint that indicates the necessary connections between the plurality of logical nodes along with the level of correlation and the data flow direction. Further, when an error event occurs in the cloud environment, the processor 109 may identify one or more anomaly nodes corresponding to the logical node in which the error event has occurred. In some embodiments, the one or more anomaly nodes are the logical nodes that may be subjected to one or more anomaly events due to the occurrence of an error event in the logical node. In some embodiments, the one or more anomaly nodes may be selected within a predefined time window.
Further, the processor 109 may identify the one or more probable root causes of the error event based on the one or more anomaly nodes. Furthermore, the processor 109 may determine an optimized root cause of the error event from the one or more probable root causes by dynamically generating one or more rules corresponding to the error event. Each of the one or more rules thus generated may be verified by the processor 109 using one or more predefined techniques. In some embodiments, the RCDS 107 may delegate the verification of the one or more rules to a rules verification system 115 which is associated with the RCDS 107.
FIG.2A shows a detailed block diagram of a Root Cause Determining System (RCDS) for determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure.
In some implementations, the Root Cause Determining System (RCDS) 107 may include data 203 and modules 205. As an example, the data 203 is stored in the memory 113 configured in the RCDS 107 as shown in the FIG.2A. In one embodiment, the data 203 may include input data 207, logical graph data 209, logical relationship data 211, cross-correlation data 213, dissimilar pattern correlation data 215, correlation weight data 217, Proactive Metric Graph (PMG) data 219, updated graph data 221, Direct Current Correlation (DCC) data 223, rules generating data 227, rules data 229 and other data 230. In the illustrated FIG.2A, modules 205 are described herein in detail.

In some embodiments, the data 203 may be stored in the memory 113 in form of various data structures. Additionally, the data 203 can be organized using data models, such as relational or hierarchical data models. The other data 230 may store data, including temporary data and temporary files, generated by the modules 205 for performing the various functions of the RCDS 107.
In some embodiments, the data 203 stored in the memory 113 may be processed by the modules 205 of the RCDS 107. The modules 205 may be stored within the memory 113. In an example, the modules 205 communicatively coupled to the processor 109 configured in the RCDS 107, may also be present outside the memory 113 as shown in FIG.2A and implemented as hardware. As used herein, the term modules refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
In an embodiment, the modules 205 may include, for example, a receiving module 231, a graph generating module 233, a probable root cause identifying module 235, rules generating module 237 and other modules 239. The other modules 239 may be used to perform various miscellaneous functionalities of the RCDS 107. It will be appreciated that such aforementioned modules 205 may be represented as a single module or a combination of different modules.
In some embodiments, the receiving module 231 may receive information related to one or more resources of a cloud environment and one or more metrics related to each of the one or more resources from one or more data sources 103 of the cloud environment. The information related to the one or more resources and the one or more metrics may be stored as input data 207. As an example, if the resource is a Central Processing Unit (CPU), the one or more metrics related to the resource “CPU” includes idle, ready, usage percentage, memory consumed and the like.
In some embodiments, the graph generating module 233 may generate a Proactive Metric Graph (PMG) based on the input data 207. To generate the PMG, the graph generating module 233 initially generates a logical graph that includes plurality of logical nodes. The logical graph including the plurality of logical nodes may be stored as the logical graph data 209. In some embodiments, each logical node may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “CPU” and the metric related to the resource “CPU” is idle, the logical node would be (CPU, idle). An exemplary logical graph is as shown in the FIG.2B. Similarly, the other exemplary logical nodes as shown in the FIG.2B are [CPU1, CPU_UsageHz], [CPU1, CPU_Total], [CPU1, CPU_Ready] and the like. Further, the graph generating module 233 may establish edges between the plurality of logical nodes. However, to establish the edges between the plurality of logical nodes, the graph generating module 233 may require a correlation weight and a data flow direction between each of the plurality of logical nodes. In some embodiments, the graph generating module 233 may determine the correlation weight and the data flow direction between the plurality of logical nodes based on factors such as logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. As an example, the logical relationship between each of the one or more resources may include, but not limited to, sibling relationship and subsumption relationship. In some embodiments, the sibling relationship is the logical relationship between two metrics of a single resource and the subsumption relationship is the logical relationship between a resource and a sub-resource of the resource. The graph generating module 233 may assign binary value to the sibling relationship of the plurality of logical nodes using which the correlation weight between the plurality of logical nodes may be determined. Similarly, the graph generating module 233 may assign binary value to the subsumption relationship between the plurality of logical nodes using which the correlation weight between the plurality of logical nodes may be determined. The binary values associated with the sibling relationship and the subsumption relationship of the plurality of logical nodes may be stored as the logical relationship data 211.
Further, the graph generating module 233 may receive the execution information of the one or more metrics of each of the one or more resources from cloud monitoring tools. In some embodiments, the execution information may include, but not limited to, similar execution patterns and dissimilar execution patterns. The graph generating module 233 may perform cross-correlation between the one or more metrics of the one or more resources that are associated with similar execution patterns. In other words, the graph generating module 233 may perform cross-correlation between each of the plurality of logical nodes including the one or more metrics with similar execution patterns in pairs. Performing cross-correlation between the one or more metrics with similar execution patterns in pairs may provide a temporal deviation value and a cross-correlation weight between the one or more metrics. In some embodiments, the temporal deviation value may be used to decide the direction of the edge between the pair of the plurality of logical nodes. The graph generating module 233 may compare the cross-correlation weight with a predefined weight threshold value. If the cross-correlation weight is less than the predefined weight threshold value, the graph generating module 233 may not use the cross-correlation weight for determining overall correlation weight of the pair of the plurality of logical nodes corresponding to the one or more metrics for which the graph generating module 233 performed cross-correlation. If the cross-correlation weight is greater than the predefined weight threshold value, the graph generating module 233 may use the cross-correlation weight to determine the overall correlation weight of the pair of the plurality of logical nodes corresponding to the one or more metrics for which the graph generating module 233 performed cross-correlation. A value obtained by performing the cross-correlation is stored as the cross-correlation data 213. As an example, consider execution information of two metrics “CPU_util” and “CPU_memory-consumed” as shown in the FIG.2C(i) and FIG.2C(ii). In FIG.2C(i), X-axis 250a indicates “time” and Y-axis 250b indicates “CPU_util”. In FIG.2C(ii), X-axis 251a indicates “time” and Y-axis 251b indicates “CPU_memory-consumed”. Since, the two metrics “CPU_util” and “CPU_memory-consumed” have similar execution patterns, cross-correlation is performed. In some embodiments, the data flow direction between the plurality of logical nodes may be determined based on the execution information between the plurality of logical nodes. In the FIG.2C(i) and FIG.2C(ii), we observe that “CPU_util” is shifted a bit towards left by time “t”. Therefore, the graph generating module 233 may infer that, the data flow direction may be from “CPU_memory-consumed” towards “CPU_util”, since, “CPU_util” is being executed ahead in time compared to “CPU_memory-consumed”.
Further, the graph generating module 233 may also determine the correlation between one or more metrics by comparing dissimilar execution patterns of the one or more metrics. However, the graph generating module 233 may not use cross-correlation technique for comparing the dissimilar execution patterns, since the cross-correlation technique may show less correlation value even though the one or more metrics are highly correlated, due to the dissimilar execution patterns. Consider the dissimilar execution patterns of two metrics “CPU_util” and “Port 80 status” as shown in the FIG.2D(i) and FIG.2D(ii). In FIG.2D(i), X-axis 252a indicates “time” and Y-axis 252b indicates “CPU_util”. In FIG.2D(ii), X-axis 253a indicates “time” and Y-axis 253b indicates “Port 80 status”. Execution pattern of the metric “CPU_util” in FIG.2D(i) is a continuous function whereas execution pattern of the metric “Port 80 status” is a step function. Therefore, in such cases where the correlation has to be performed between two dissimilar execution patterns, the graph generating module 233 may depend on a common sub-resource between the two metrics to determine the correlation. The dissimilar execution patterns such as the continuous function and the step function may be highly correlated when both the execution patterns include a sub-resource or processes running on resources are common for a maximum time. Therefore, the graph generating module 233 may associate the sub-resource information or information related to the processes running, of the two dissimilar execution patterns continuously for a certain time “T”. In the FIG.2D(i) and FIG.2D(ii), the process “Nginx” is being executed in both “CPU_util” and “Port 80 status”. Therefore, “Nginx” is a common process identified in both the dissimilar execution patterns. Similarly, the process “Apache”, is another common process identified in both the dissimilar execution patterns. Upon identifying the time for which the sub-resource is common or the time for which the processes running are common, the graph generating module 233 may use the Equation 1 as shown below to determine the correlation between the two metrics.
Co = (T-t)/T ----------------------- Equation 1
In the above Equation 1,
“Co” indicates correlation between the two metrics;
“T” indicates the total time for which the graph generating module 233 compared the two dissimilar execution patterns; and
“t” indicates the time interval when no common sub-resources existed during comparison of the dissimilar execution patterns of the two metrics.
The correlation determined between the two metrics having dissimilar execution patterns may be stored as the dissimilar pattern correlation data 215.
Further, the graph generating module 233 may determine the data flow direction between the pair of plurality of logical nodes for which the correlation has been performed using the above Equation 1, based on time. As an example, in the FIG.2D(i) and FIG.2D(ii), the process “Nginx” is being executed in both the metrics “CPU_util” and “Port_80 status”. Execution of the process “Nginx” started first in “CPU_util” and then after a short delay the process “Nginx” started in “Port_80 status”. Since, “CPU_util” is executing the process “Nginx” ahead in time when compared to “Port 80 status”, the graph generating module 233 may infer that, the data flow direction may be from “Port 80 status” towards “CPU_util”. The data flow direction or the direction from “Port 80 status” to “CPU_util” may indicate that, if an error occurs in “Port 80 status”, “CPU_util” can be a root cause of the error since the process “Nginx” is executed first in “CPU_util”.
Further, the graph generating module 233 may assign a hop value of “1” to the plurality of logical nodes whose resources have a direct connection in the actual topology of the cloud environment. The hop value increases with increase in actual physical connectivity of the resources. As an example, hop value between a pair of resources or in other words pair of the plurality of logical nodes would be 3 if the pair of resources are 3 hops away in the actual topology. In some embodiments, the hop value is inversely proportional to the correlation between the pair of the plurality of logical nodes which means, lesser the hop value, greater the correlation and greater the hop value, lesser the correlation.
Furthermore, the graph generating module 233 may determine the correlation weight between the pair of the plurality of logical nodes using the Equation 2 as shown below.

Corr(i,j) = ?1*? + ?2*Co + ?3*Si + ?4*Su + ?5*H -------------------- Equation 2

In the above Equation 2, i and j indicate the pair of the plurality of logical nodes and Corr(i,j) indicates the correlation weight between the logical nodes i and j.

?1, ?2, ?3 and ?4 are configurable parameters to adjust weight of each of the factors;
? indicates the cross-correlation between the logical nodes i and j;
Co indicates the correlation between dissimilar execution patterns;
Si indicates the sibling relationship between the logical nodes i and j;
Su indicates the subsumption relationship between the logical nodes i and j; and
H indicates the hop value between the logical nodes i and j.

The correlation weight of each of the plurality of logical nodes may be stored as correlation weight data 217.

Upon determining the correlation weight between the pair of the plurality of logical nodes, the graph generating module 233 may compare the correlation weight with a dynamically configured correlation threshold. If the correlation weight is greater than the dynamically configured correlation threshold, the graph generating module 233 may establish an edge between the pair of the plurality of logical edges. Also, the edge is associated with an arrow head on one end of the edge which is indicative of the data flow direction between the pair of the plurality of logical nodes. Similarly, the graph generating module 233 may establish edges between the plurality of logical nodes whose correlation weight is greater than the dynamically configured correlation threshold, thereby generating the PMG. The PMG may be stored as the PMG data 219. An exemplary PMG may be as shown in the FIG.2E which indicates the plurality of logical nodes, the edges and the correlation weight between the plurality of logical nodes and the data flow direction between the plurality of logical nodes. If the correlation weight is less than the dynamically configured correlation threshold, the graph generating module 233 may not establish the edge between the pair of plurality of logical nodes.

In some embodiments, the probable root cause identifying module 235 may identify the one or more probable root causes of an error event occurring in the cloud environment. In some embodiments, when an error event or anomaly events occur in the cloud environment, the RCDS 107 may map the error events and the anomaly events on the PMG. The error event may be an unwanted event in the cloud environment that should be rectified immediately before causing any further damage to the cloud environment. The anomaly event may be a slight deviation in behaviour of a metric from original behaviour that does not cause any severe damage to the cloud infrastructure. Initially, the probable root cause identifying module 235 may identify, in the PMG, one or more anomaly nodes corresponding to the logical node in which the error event has occurred. In some embodiments, the one or more anomaly nodes may be the plurality of logical nodes in the PMG associated with one or more anomaly events, that are executed before the execution of the logical node in which the error event has occurred. The probable root cause identifying module 235 may identify the one or more anomaly nodes within a predefined time window. In some embodiments, the one or more data sources 103 such as monitoring systems may identify the error events and the anomaly events and provide the information to the probable root cause identifying module 235, which will map the error event and the anomaly events to the corresponding logical nodes in the PMG. Upon identifying the one or more anomaly nodes in the predefined time window, the probable root cause identifying module 235 may update the correlation weight of each edge in sequence of edges corresponding to each of the one or more anomaly nodes temporarily. In some embodiments, the probable root cause identifying module 235 may perform the updation based on the Equation 3 as shown below.

Wi' = 1/(4*H) + Wi ------------------------- Equation 3

In the above Equation 3,
Wi' indicates the updated correlation weight of the edge i from the logical node where the error event has occurred towards the each of the one or more anomaly nodes;
H indicates the hop distance/value between the logical node where the error event has occurred and each of the one or more anomaly nodes; and
Wi indicates the initial weight of each edge prior to updation.

As an example, consider the PMG as shown in the FIG.2F with numbers [in bold] indicating each edge corresponding to the plurality of logical nodes. In the FIG.2F, logical node where the error has occurred is [CPU1, Mem_shared] and the one or more anomaly nodes are [CPU1, CPU_usage%] and [CPU1, CPU_idle]. Table 1 indicates the updated correlation weight of each edge in the sequence of edges corresponding to each of the one or more anomaly nodes determined using the above Equation 3.

Logical nodes representing the edge Existing correlation weight Hop distance Updated correlation weight
1 2.1 1 1/(4*1)+2.1 = 2.35
2 2.8 2 1/(4*2)+2.8 = 2.93
3 2.6 2 1/(4*2)+2.6 = 2.73
4 2.1 2 1/(4*2)+2.1 = 2.23
5 2.4 3 1/(4*3)+2.4 = 2.48
6 2.9 4 1/(4*4)+2.9 = 2.96
7 2.5 1 1/(4*1)+2.5 = 2.75
8 2.3 2 1/(4*2)+2.3 = 2.43
9 2.7 2 1/(4*2)+2.7 = 2.83
Table 1
Updated PMG indicating the updated correlation weight is stored as the updated graph data 221.

The temporarily updated PMG including the logical node where the error event has occurred and each of the one or more anomaly nodes within the predefined time window along with the updated correlation weight calculated in the Table 1, is as shown in the FIG.2G.

Upon obtaining the temporarily updated PMG, the probable root cause identifying module 235 may determine a Direct Current Correlation (DCC) between the plurality of logical nodes starting from the logical node in which the error event has occurred and moving away to the next logical node based on the sequence of edges until the DCC value becomes less than the dynamically configured CC threshold. For the plurality of logical nodes that are at a hop distance of 1 from the logical node in which the error event has occurred, the correlation weight is same as the original correlation weight of the edge between the plurality of logical nodes which is shown in the Equation 4. For the plurality of logical nodes that are at a hop distance greater than 1, the probable root cause identifying module 235 may determine the DCC from the logical node in which the error event has occurred by using the Equation 4 given below.

DCC = (Diff /a) * W ------------------ Equation 4
In the above Equation 4,
Diff is the difference between the updated correlation weight of previous logical node and a dynamically configured Current Correlation (CC) threshold;
a indicates configurable parameter to adjust the Diff value according to requirement; and
W indicates updated correlation weight of the edge connecting the current node with the previous node.

DCC between the logical node in which the error event has occurred and each of the plurality of logical nodes may be stored as the DCC data 223. Upon obtaining the DCC, the probable root cause identifying module 235 may compare the DCC of each of the plurality of logical nodes in real-time with the dynamically configured CC threshold. The plurality of logical nodes having the DCC greater than the dynamically configured CC threshold may be identified as the one or more probable root causes of the error event. Each of the one or more probable root causes of the error event occurring in the logical node are arranged in a descending order according to the DCC to form a chunk. The probable root cause identifying module 235 may stop determining the DCC of the plurality of logical nodes when the DCC value of the plurality of logical nodes becomes lesser than the dynamically configured CC threshold.

Consider the PMG as shown in the FIG.2G. The exemplary DCC values calculated for each of the plurality of logical nodes along the sequence of edges are as shown in the below Table 2 and pictorially indicated in the FIG.2H. Consider that path 1 and path 2 as indicated in the FIG.2H are the only two outgoing paths from the logical node in which the error has occurred. Therefore, the probable root cause identifying module 235 takes one path at a time starting from the logical node in which the error has occurred until the DCC becomes less than the dynamically configured CC threshold. The dynamically configured CC threshold is considered to be 2.0 for illustrating the example.

Logical Node Pair Path Number DCC
[CPU1, Mem_shared], [CPU1, Mem_remaining] Path 1 2.75
[CPU1, Mem_shared], [CPU1, CPU_usage%] Path 1 (2.75 – 2.0) / 0.55 * (2.43) = 3.31
[CPU1, Mem_shared], [CPU1, CPU_ready] Path 2 2.35
[CPU1, Mem_shared], [CPU1, CPU_idle] Path 2 (2.35 – 2.0) / 0.55 * (2.93) = 1.86
Table 2
In the above Table 2, upon determining the DCC for the logical node pair [CPU1, Mem_shared], [CPU1, CPU_usage%], there exists no other logical node beyond the logical node [CPU1, CPU_usage%] according to the FIG.2H. Therefore, the probable root cause identifying module 235 may stop determining further DCC along Path 1. However, along path 2, the logical node pair [CPU1, Mem_shared], [CPU1, CPU_idle] has the DCC value less than the dynamically configured CC threshold. Therefore, the probable root cause identifying module 235 may stop determining further DCC along Path 2. However, if there existed logical nodes beyond the logical node [CPU1, CPU_idle], the probable root cause identifying module 235 may not proceed further since the DCC value of current logical node is less than the dynamically configured CC threshold. The probable root cause determining module 235 may arrange the logical node pairs whose DCC is greater than or equal to the dynamically configured CC threshold in the descending order based on the DCC values to form a chunk as shown below.
Error Event 1: [CPU1, Mem_shared]
Chunk-1
1. [CPU1, Mem_shared], [CPU1, Mem_remaining]
2. [CPU1, Mem_shared], [CPU1, CPU_usage%]
3. [CPU1, Mem_shared], [CPU1, CPU_ready]

The logical node pairs arranged in descending order in the chunk may be the one or more probable root causes of the error event that occurred in the cloud environment. The chunks comprising the one or more probable root causes are stored as the chunk data 225. Upon obtaining the chunk for the error event, the probable root cause identifying module 235 may revert the updated correlation weight corresponding to the plurality of logical nodes to the corresponding original correlation weights until a next error event occurs in the cloud environment. This will bring the current state of PMG from as shown in FIG.2G to the one shown in FIG2E.

In some embodiments, the rules generating module 237 may generate one or more rules corresponding to the one or more error events. The one or more rules help in determining the optimized root cause of each of the one or more error events from the one or more probable root causes.

Initially, the rules generating module 237 may determine a count of each of the one or more probable root causes in one or more chunks corresponding to one or more error events. The count indicates frequency of occurrence of each of the one or more probable root causes in each of the one or more chunks. Further, the rules generating module 237 may determine confidence value of each of the one or more probable root causes based on the corresponding count. The confidence value indicates ratio of number of times the one or more probable root causes have occurred in a predefined position in the one or more chunks and the count of the corresponding probable root cause. In some embodiments, the predefined position may be first position in the chunk since the first position in the chunk contains the probable root cause having the highest DCC compared to the other probable root causes in the chunk. The count and the confidence values are stored as the rule generating data 227. Furthermore, the rules generating module 237 may compare the confidence value and the corresponding count of each of the one or more probable root causes with a confidence threshold and a count threshold respectively.

In some embodiments, the count threshold indicates a minimum number of occurrences of the one or more probable root causes in total number of chunks currently stored in the RCDS 107. Further, the confidence threshold indicates a minimum ratio value of a confidence value of the one or more probable root causes. If the count and the confidence value of the one or more probable root causes are equal to or greater than the count threshold and the confidence threshold respectively, the rules generating module 237 may correlate the error events comprising the common probable root cause in a predefined manner to generate the one or more rules. The predefined manner for correlating the one or more error events to generate the one or more rules is stored as the rules generating data 227. In some embodiments, the predefined manner may include correlating the error events having the common probable root cause by introducing a conjunction symbol between the error events, if the common probable root cause appears in the predefined position. As an example, the predefined position may be the first position. Further, the predefined manner may include correlating the error events having the common probable root cause by introducing a disjunction symbol between the error events, if the common probable root cause appears in any other position other than the predefined position. Based on the correlation, the rules generating module 237 may generate the one or more rules that determines the common probable root cause as the optimized root cause of the error event for which the common probable root cause appeared in the predefined position in the chunk. The one or more rules generated by the rules generating module 237 may be stored as the rules data 229.

If the count and the confidence value are less than the count threshold and the confidence threshold respectively, then the rules generating system 237 may discard the common probable root cause.

Consider 3 exemplary chunks for the error events as shown below.

Chunk 1: ( {[CPU1, Mem_shared]}, {[CPU1, Mem_remaining], [CPU1, CPU_usage%], [CPU1, CPU_ready]} )

Chunk 2: ( {[CPU1, Mem_consumed]}, {[CPU1, Mem_shared], [CPU1, CPU_usageHz], [CPU1, CPU_usage%]} )

Chunk 3: ( {[CPU1, CPU_ready]}, {[CPU1, Mem_UsageHz], [CPU1, CPU_usage%], [CPU1, Mem_remaining]} )

In the above chunks, the probable root cause [CPU1, Mem_remaining] has appeared twice in chunk 1 and chunk 3. Therefore, count of the probable root cause [CPU1, Mem_remaining] is 2.

The probable root cause [CPU1, Mem_remaining] has appeared once in the first position. Therefore, confidence value of the probable root cause [CPU1, Mem_remaining] is 1/2.

Consider that the count threshold is 2 and the confidence threshold is 1/4. The count and the confidence value of the probable root cause [CPU1, Mem_remaining] are equal to the count threshold and greater than the confidence threshold respectively. Therefore, the rules generating system 237 may generate the rule for the error events [CPU1, Mem_shared] and the [CPU1, CPU_ready] as shown below:

( [CPU1, Mem_shared] ? [CPU1, CPU_ready]) ? Optimized root cause = [CPU1, Mem_remaining]

Therefore, the optimized root cause of the error event [CPU1, Mem_shared] is [CPU1, Mem_remaining]

Upon generating the one or more rules, the one or more rules may be verified by a rules verification system 115 associated with the RCDS 107 for identifying one or more faults in the one or more rules. As an example, the one or more faults include, but not limited to, correctness, redundancy, completeness and consistency. In an embodiment, a verification technique disclosed in the Indian Patent Application: 6303/CHE/2015 may be used by the rules verification system 115 to verify the one or more rules. Entire content of the Indian Patent Application: 6303/CHE/2015 is incorporated by reference herein. In an alternative embodiment, other verification techniques may also be used by the rules verification system 115 to verify the one or more rules. The one or more faults may also be manually corrected as illustrated in the Indian Patent Application: 6303/CHE/2015. The RCDS 107 may rectify the one or more faults, if any and updates the one or more rules dynamically.
When an error event occurs in the cloud environment, the RCDS 107 may determine the root cause of the error event based on the one or more rules stored in the memory 113. If the one or more rules are not present in the memory 113 for a certain error event, the RCDS 107 may follow the method described above to generate the one or more rules and determine the optimized root cause for the error event.
FIG.3 illustrates a flowchart showing a method of determining an optimized root cause for an error event in a cloud environment in accordance with some embodiments of the present disclosure.
As illustrated in FIG.3, the method 300 includes one or more blocks illustrating a method of determining an optimized root cause for an error event in a cloud environment. The method 300 may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types.

The order in which the method 300 is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method 300. Additionally, individual blocks may be deleted from the methods without departing from the spirit and scope of the subject matter described herein. Furthermore, the method 300 can be implemented in any suitable hardware, software, firmware, or combination thereof.

At block 301, the method 300 may include receiving, by a processor 109 of the Root Cause Determining System (RCDS) 107, information related to one or more resources of the cloud environment and one or more metrics related to each of the one or more resources from one or more data sources of the cloud environment.
At block 303, the method 300 may include generating, by the processor 109, a logical graph comprising plurality of logical nodes. Each logical node may be indicative of at least one resource and at least one metric corresponding to the at least one resource. As an example, if the resource is “CPU” and the metric associate with CPU is idle, then the logical node would be (CPU, idle).
At block 305, the method 300 may include determining, by the processor 109, a correlation weight and a data flow direction between each of the plurality of logical nodes based on logical relationship between each of the one or more resources, execution information of the one or more metrics of each of the one or more resources and hop distance between each of the one or more resources. The correlation weight indicates level of correlation between the plurality of logical nodes. In some embodiments, the logical relationship may include, but not limited to, sibling relationship and subsumption relationship. Further, in some embodiments, the execution information of the one or more metrics of the one or more resources may include execution information with similar execution patterns and execution information with dissimilar execution patterns. Furthermore, the hop distance is inversely proportional to the level of correlation between the plurality of logical nodes. In some embodiments, the data flow direction may indicate direction in which the process is driven. In the representation of the data flow direction, if the logical node present at tail of the edge is where the error event has occurred, the logical node present at head of the edge indicated by an arrow head may be the probable root cause.
At block 307, the method 300 may include generating, by the processor 109, a Proactive Metric Graph (PMG) by establishing edges between the plurality of logical nodes based on the correlation weight and the data flow direction. The processor 109 may establish the edges only when the correlation weight between the plurality of logical nodes is greater than a dynamically configured correlation threshold.
At block 309, the method 300 may include identifying, by the processor 109, one or more probable root causes of an error event occurring in the cloud environment. In some embodiments, the processor 109 may identify one or more anomaly nodes in the PMG within a predefined time window. In some embodiments, the one or more data sources 103 such as monitoring systems may identify error events and anomaly events and provide the information to the RCDS 107, which will map the error event and the anomaly events to the corresponding logical nodes in the PMG. The processor 109 may update the correlation weight of each edge in the sequence of edges corresponding to each of the one or more anomaly nodes temporarily. Further, the processor 109 may determine a Direct Current Correlation (DCC) between pairs of the logical node in which the error event has occurred and each of the plurality of logical nodes present along each of one or more outgoing paths, based on the updated correlation weight. In some embodiments, each of the one or more outgoing paths may include the sequence of edges starting from the logical node in which the error event has occurred. In some embodiments, the processor 109 may proceed in each of the one or more outgoing paths sequentially to determine the DCC until the DCC of at least one pair in each of the one or more outgoing paths becomes less than the dynamically configured Current Correlation (CC) threshold. In some embodiments, the processor 109 may also stop determining DCC when number of edges along a certain outgoing path have ended. Further, the processor 109 may select logical node pairs corresponding to each edge having the DCC greater than a dynamically configured CC threshold and form a chunk by arranging the logical node pairs in a descending order based on the DCC. The one or more logical node pairs arranged in the chunk may be the one or more probable root causes of the error event.
At block 311, the method 300 may include generating, by the processor 109, one or more rules corresponding to the error event. In some embodiments, the processor 109 may determine a count of each of the one or more probable root causes in total number of chunks corresponding to one or more error events currently stored in the RCDS 107. Count indicates frequency of occurrence of each of the one or more probable root causes in each of the total number of chunks. Further, the processor 109 may identify a confidence value of each of the one or more probable root causes based on the corresponding count. The confidence value indicates ratio of number of times the one or more probable root causes have occurred in a predefined position in one or more chunks and the count of the corresponding probable root cause. The processor 109 correlates the one or more events comprising a common probable root cause in a predefined manner to generate the one or more rules, when the count and the confidence value of the one or more probable root causes is greater than a count threshold and a confidence threshold. The processor 109 may determine the optimized root cause of each of the one or more error events based on the one or more rules.
FIG.4 is a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.
In an embodiment, FIG.4 illustrates a block diagram of an exemplary computer system 400 for implementing embodiments consistent with the present invention. In an embodiment, the computer system 400 can be Root Cause Determining System (RCDS) 107 that is used determining an optimized root cause for an error event in a cloud environment. The computer system 400 may include a central processing unit (“CPU” or “processor”) 402. The processor 402 may include at least one data processor for executing program components for executing user or system-generated business processes. A user may include a person, a person using a device such as those included in this invention, or such a device itself. The processor 402 may include specialized processing units such as integrated system (bus) controllers, memory management control units, floating point units, graphics processing units, digital signal processing units, etc.
The processor 402 may be disposed in communication with one or more input/output (I/O) devices (411 and 412) via I/O interface 401. The I/O interface 401 may employ communication protocols/methods such as, without limitation, audio, analog, digital, stereo, IEEE-1394, serial bus, Universal Serial Bus (USB), infrared, PS/2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE 802.n /b/g/n/x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE), WiMax, or the like), etc.
Using the I/O interface 401, computer system 400 may communicate with one or more I/O devices (411 and 412).
In some embodiments, the processor 402 may be disposed in communication with a communication network 409 via a network interface 403. The network interface 403 may communicate with the communication network 409. The network interface 403 may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10/100/1000 Base T), Transmission Control Protocol/Internet Protocol (TCP/IP), token ring, IEEE 802.11a/b/g/n/x, etc. Using the network interface 403 and the communication network 409, the computer system 400 may communicate with data source 1 4101 to data source n 410n (also referred to as one or more data sources 410). The communication network 409 can be implemented as one of the different types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The communication network 409 may either be a dedicated network or a shared network, which represents an association of the different types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol/Internet Protocol (TCP/IP), Wireless Application Protocol (WAP), etc., to communicate with each other. Further, the communication network 409 may include a variety of network devices, including routers, bridges, servers, computing devices, storage devices, etc. The one or more data sources 410 may include monitoring systems, topology extractors, cloud servers, databases and the like. In some embodiments, the processor 402 may be disposed in communication with a memory 405 (e.g., RAM, ROM, etc. not shown in FIG.4) via a storage interface 404. The storage interface 404 may connect to memory 405 including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fibre channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.
The memory 405 may store a collection of program or database components, including, without limitation, a user interface 406, an operating system 407, a web browser 408 etc. In some embodiments, the computer system 400 may store user/application data, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle or Sybase.
The operating system 407 may facilitate resource management and operation of the computer system 400. Examples of operating systems include, without limitation, Apple Macintosh OS X, UNIX, Unix-like system distributions (e.g., Berkeley Software Distribution (BSD), FreeBSD, NetBSD, OpenBSD, etc.), Linux distributions (e.g., Red Hat, Ubuntu, Kubuntu, etc.), International Business Machines (IBM) OS/2, Microsoft Windows (XP, Vista/7/8, etc.), Apple iOS, Google Android, Blackberry Operating System (OS), or the like. The User interface 406 may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, user interfaces may provide computer interaction interface elements on a display system operatively connected to the computer system 400, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, etc. Graphical User Interfaces (GUIs) may be employed, including, without limitation, Apple Macintosh operating systems’ Aqua, IBM OS/2, Microsoft Windows (e.g., Aero, Metro, etc.), Unix X-Windows, web interface libraries (e.g., ActiveX, Java, Javascript, AJAX, HTML, Adobe Flash, etc.), or the like.
In some embodiments, the computer system 400 may implement the web browser 408 stored program components. The web browser 408 may be a hypertext viewing application, such as Microsoft Internet Explorer, Google Chrome, Mozilla Firefox, Apple Safari, etc. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS) secure sockets layer (SSL), Transport Layer Security (TLS), etc. Web browsers may utilize facilities such as AJAX, DHTML, Adobe Flash, JavaScript, Java, Application Programming Interfaces (APIs), etc. In some embodiments, the computer system 400 may implement a mail server stored program component. The mail server may be an Internet mail server such as Microsoft Exchange, or the like. The mail server may utilize facilities such as Active Server Pages (ASP), ActiveX, American National Standards Institute (ANSI) C++/C#, Microsoft .NET, CGI scripts, Java, JavaScript, PERL, PHP, Python, WebObjects, etc. The mail server may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), Microsoft Exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system 400 may implement a mail client stored program component. The mail client may be a mail viewing application, such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Mozilla Thunderbird, etc.
Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, non-volatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.
Advantages of the embodiment of the present disclosure are illustrated herein.
In an embodiment, the present disclosure provides a method and a system determining an optimized root cause for an error event in a cloud environment. The present disclosure combines rule-based and correlation-based techniques of root cause analysis for providing improved coverage in less amount of time comparatively.
The present disclosure provides a feature wherein the root cause detection includes determining correlation between metrics of one or more resources having dissimilar execution patterns, thereby providing optimized coverage.
The present disclosure provides a feature wherein one or more rules are dynamically generated using probable root cause chunks of one or more error events to provide a single optimized root cause for each error event. Therefore, the present disclosure reduces the number of probable root causes for each error event and deduces a single optimized root cause, thus reducing significant amount of time required for determining the root cause for an error event and increasing accuracy and reliability.
The present disclosure provides a feature wherein not just the neighbouring nodes of the logical node in which the error event has occurred but adjacent nodes also are considered as anomaly nodes. The anomaly nodes are selected based on a predefined time window that covers the most recent root causes of an error event.
A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.
When a single device or article is described herein, it will be apparent that more than one device/article (whether or not they cooperate) may be used in place of a single device/article. Similarly, where more than one device or article is described herein (whether or not they cooperate), it will be apparent that a single device/article may be used in place of the more than one device or article or a different number of devices/articles may be used instead of the shown number of devices or programs. The functionality and/or the features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality/features. Thus, other embodiments of the invention need not include the device itself.
The specification has described a method and a system determining an optimized root cause for an error event in a cloud environment. The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that on-going technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words "comprising," "having," "containing," and "including," and other similar forms are intended to be equivalent in meaning and be open-ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

Referral numerals
Reference Number Description
100 Architecture
103 One or more data sources
107 Root Cause Determining System (RCDS)
109 Processor
111 I/O interface
113 Memory
203 Data
205 Modules
207 Input data
209 Logical graph data
211 Logical relationship data
213 Cross-correlation data
215 Dissimilar pattern correlation data
217 Correlation weight data
219 Proactive Metric Graph (PMG) data
221 Updated graph data
223 Direct Current Correlation (DCC) data
227 Rules generating data
229 Rules data
230 Other data
231 Receiving module
233 Graph generating module
235 Probable root cause identifying module
237 Rules generating module
239 Other modules
250a X-axis indicating time in FIG.2C(i)
250b Y-axis indicating CPU_util in FIG.2C(i)
251a X-axis indicating time in FIG.2C(ii)
251b Y-axis indicating CPU_memory consumed in FIG.2C(ii)
252a X-axis indicating time in FIG.2D(i)
252b Y-axis indicating CPU_util in FIG.2D(i)
253a X-axis indicating time in FIG.2D(ii)
253b Y-axis indicating Port 80 statues in FIG.2D(ii)