## 6 Multi-Service Dependency
### Summary  
As we can see, the discussed methods try to extract the dependencies between distributed services or components. Some of them use network-level data, which use sending/receiving patterns in a time period, packet header data like (e.g., IP, port, protocol), delay distribution of the traffic, cross-correlation of data, equality of the attributes (key-based correlation) and reference-based correlation. Others leverage application-level data such as application ID and process ID, monitored data (e.g., resource usage, TCP/UDP connection number), and temporal dependency between the execution of systems, which allow them to have a better understanding of the systems' behaviour and their dependencies.  
The existing approaches try to extract simple explicit dependencies (i.e., dependencies between services with their direct traffic between them). Latent dependencies (where the dependencies cannot be identified at first glance and need mathematical calculation to discover) and implicit dependencies (data dependencies between distributed services without access to their traffic or through their traffic with other services) have only been covered in a very limited sense. For example, [PERSON] et al. [68] extracted part of latent dependencies using cross-correlation, but their effort only considers linear dependencies for the services that communicate directly in terms of sending and receiving messages. In general, each existing method tries to discover only one part of the simple dependencies in the real service's traffic. Little attention has been paid to the selection of multiple and  
\begin{table}
\begin{tabular}{c c c} \hline Method & Specification & Remarks \\ \hline CSight [74] & Inferring communicating FSM models from the execution traces of the concurrent and distributed systems & It requires repeated executions of each single task in the log file \\ \hline NetCheck [75] & Ordering the distributed input trace sets, and employing a network model to specify deviation points in the ordered execution & It does not track causality in a systematic manner, the identified root cause and proposed repair may not be accurate \\ \hline [PERSON] et al. [76] & Discovering artifact-centric process models captured in the guard-stage-milestone notation, starting from raw logs & Needs an expert to specify artifacts as well as a single instance notion within each artifact \\ \hline CloudScout [77] & Identifies dependent service components & Sensitive to aberrant data measurements \\ \hline Dinv. [78] & Using static and dynamic program analyses to deduce relations between distributed systems variables which can imply the correctness of the developed systems & Focusing only on traces as one type data. It infers likely invariants since it is a dynamic and only considers a finite set of system behaviours \\ \hline \end{tabular}
\end{table}
Table 7: Different approaches of multi-service dependency from application level data.  
complex dependency functions that can identify latent dependencies or a combination of several dependencies. A major focus in existing service dependency discovery efforts has been on how to identify data-dependent services rather than incorporating their effects on the system's behaviour. In general, there remains a need for efficient and systematic approaches that can cover all types of data dependencies between services and their mutual impacts on each other.