## 7 Conclusions and Future Work  
DT is essential for increasing the visibility of complex interactions and dependencies within native cloud applications. By tracing the requests across microservices, containers, and dynamic environments, users can effectively monitor, manage, and troubleshoot their native cloud applications to ensure optimal performance and reliability. Despite the efforts, the adoption of this technology encounters several challenges, and one of the most crucial is the volume of data and the corresponding resource consumption needed to handle it. Sampling is a technique that alleviates the overhead in collecting, storing, and processing vast amounts of trace data. It reduces the volume of data by selectively capturing only a fraction of traces. This approach offers benefits such as decreased latency, reduced resource consumption, and improved scalability. However, sampling introduces challenges, particularly in maintaining representative samples and preserving the accuracy of analysis results. Striking a balance between sampling rate and data fidelity is crucial to ensure effective troubleshooting and performance analysis in distributed systems. Overall, DT sampling plays a vital role in managing the complexity of distributed environments while optimizing resource utilization and maintaining analytical efficacy. We explored several approaches for sampling that preserved traces with some specific properties. One such property was the type of trace that described the transaction similarity. Traces of the same type should normally have almost the same structure. The goal of such sampling was to preserve traces across all available types. Another property was the duration of the trace. This approach could or might not be combined with the information regarding the type. Trace durations were important as they described the transaction duration. Similar transactions had some typical/ average durations. Atypical durations indicated a transaction/microservice malfunction. The next important trace characteristic was its normality. Erroneous traces carried important information regarding problems. Hence, it was natural to try to keep all representatives while monitoring the performance of microservices. The flow of erroneous traces would show which microservices had degraded performance. Further, those traces were critical sources of information for troubleshooting application issues. We sampled only dominant/common errors at the troubleshooting stage, trying to remove the rare ones. This removed the noise and made explanations more confident. RCA could be performed by tracing traffic passing through a malfunctioning microservice. Rule-learning ML methods could help generate explicit rules that explain the problems and clarify the remediation process. We showed how rule-induction systems like RIPPER solved this problem and provided recommendations that system administrators could follow to accelerate the resolution process. We also showed that sampling could dramatically decrease the program execution time and provide more clear recommendations. However, as mentioned before, sampling degraded the statistics, and sometimes rare but important evidence could escape the analysis. Several limitations of our approach are crucial to consider. Acknowledging and addressing these limitations is vital for enhancing the robustness and applicability of the sampling strategy. Firstly, a significant limitation is the dependence of trace types on the root span. This approach overlooks the fact that a substantial volume of traces lack a root span, necessitating the utilization of the first span instead. Overall, this introduces potential inaccuracies in type definitions, as many traces may exhibit distinct structures not adequately captured by this method. Secondly, the procedure for calculating trace durations may be prone to misinterpretation due to the challenges associated with defining trace types, as previously discussed.