このページの情報は古くなっている可能性があります。 最新の情報は 本家サイト でご確認ください。
Thanks for visiting this category strategy page on Tracing in GitLab. This category belongs to and is maintained by the APM group of the Monitor stage.
Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your Metrics usage, we'd especially love to hear your use case(s)
Tracing is a part of Application Performance Monitoring (APM) solution, and described as a way to measure an application while running. To enable tracing, code instrumentation is required. With it, it is possible to gain in-depth insight into the app across all layers by measuring the execution time of a user journey. Tracing information can be used to troubleshoot an application by measuring different metrics of Traces and Spans.
A trace is normally constructed out of multiple spans.
With the rise of microservices applications, it has become difficult to correlates traces and spans, as those are likely to be routed across distributed components. Distributed tracing is a method that correlates multiple Traces and Spans of a single transaction across different components. Making it easier to understand the path a transaction took through multiple services.
Gitlab integrates with Jaeger - an open-source, end-to-end distributed tracing system tool used for monitoring and troubleshooting microservices-based distributed systems. If you are using Jaeger it is possible to view its UI within Gitlab.
We're pursuing continued iteration on our initial MVP via the tracing to viable epic with a specific next step to enable deployment of Jaeger to your Kubernetes cluster with a push of a button.