> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/home/observability/tracing-service/use-cases.md). # Use Cases Tracing Service ingests distributed traces from applications and services into a centralized platform for storage, search, visualization, and root-cause analysis. ## Scenario 1: Microservice request tracing ### Precondition An e-commerce platform is split into multiple services for checkout, payment, inventory, and shipping. Users report occasional slow checkout requests, but the failing service is unclear. ### Solution Tracing Service captures the full request path across all participating services. Engineers can inspect a single trace in Grafana, identify the slow span, and determine whether the delay came from the application, a database call, or an external dependency. ## Scenario 2: API latency analysis ### Precondition A SaaS provider exposes public APIs and needs to understand why some endpoints exceed latency targets during busy periods. ### Solution Tracing Service records spans for inbound requests and downstream calls. By comparing span durations, teams can separate network latency from application processing time and pinpoint the most expensive operations. ## Scenario 3: Error investigation across services ### Precondition A business workflow fails intermittently, but logs from individual services do not clearly show where the failure starts. ### Solution Tracing Service links related spans into a single trace so teams can follow the exact execution path of a failed request. Error status, events, and span attributes help isolate the failing component, triggering step, and root cause. ## Scenario 4: Dependency visibility ### Precondition A platform team needs better visibility into how internal services interact with databases, message queues, and third-party APIs. ### Solution Tracing Service shows server, client, producer, consumer, and internal spans in one flow. This helps teams understand service dependencies, spot slow external calls, and analyze retry patterns, timeout events, or queue delays. ## Scenario 5: Release validation ### Precondition A development team deploys frequent application changes and wants to verify that a new release does not introduce hidden latency or failure patterns. ### Solution Tracing Service allows the team to compare traces before and after deployment. Changes in span duration, error rate, or dependency behavior can be detected early before users are broadly affected. ## Scenario 6: OpenTelemetry standardization ### Precondition An organization wants to standardize observability across different languages and runtimes without building separate tracing stacks per team. ### Solution Tracing Service supports OpenTelemetry trace ingestion over `OTLP/HTTP` and `OTLP/gRPC`. Teams can instrument services with OpenTelemetry SDKs and export traces to one managed backend using consistent authentication and access patterns. ## Scenario 7: AI and LLM cost and latency transparency ### Precondition A team runs generative AI and LLM workflows and needs to understand where latency and operating cost accumulate across internal processing steps, without adding a separate AI observability tool. ### Solution Tracing Service uses the OpenTelemetry semantic conventions for generative AI (GenAI) to instrument each interaction and processing chain. Token consumption, prompts, and step costs are recorded as span attributes, the execution path is visualized in Grafana, and AI performance correlates directly with infrastructure signals in the same interface. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ionos.com/cloud/home/observability/tracing-service/use-cases.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.