Docs

Torch Log Service

Tracing service

Trace feature overview

Trace storage is a distributed tracing feature provided by Torch Log Service(TLS). Based on the native OpenTelemetry protocol and standards, trace storage supports access, storage, query, analysis, visualization of various trace data. It ensures full-link trace data observability. This topic introduces the features, limits, and access solutions of trace storage.

Features overview

In architectures or systems involving multiple service interactions such as cloud-native, microservices, and distributed systems, a request typically needs to be processed by multiple microservices, and a performance issue may involve multiple services and components. As distributed systems grow in scale and complexity, understanding the path of request and across-component flow becomes more challenging. Distributed tracing allows you to check the complete call chain and view of requests in the system. It can also be used to track the propagation path of abnormal signals and monitor the running process of the entire transaction. This helps developers know the performance metrics of each microservice, and quickly and timely locate and resolve issues.

Via trace storage, TLS provides distributed tracing capability based on the OpenTelemetry (OTel) standard protocol. It is suitable for scenarios like performance optimization, troubleshooting, microservices architecture monitoring, service call chain analysis, distributed transaction tracing, and security auditing. OTel offers cross-language standards that unify all observability data. Besides, OTel also provides SDKs in various languages based on the OTel standard. Therefore, it supports custom observability data collection. After trace data is successfully delivered to TLS, TLS promptly records complete request details and context information. These details and information will be stored in a standardized format on the server for subsequent query, analysis, and data visualization.

Currently, TLS provides the following capabilities via trace storage:

Collect and store various types of trace data.

Query and analyze real-time online trace data.

Related resources

Resources	Description
Log topic	When you create a trace instance, TLS automatically creates two log topics. The log topics include: tls_${trace instance name}-trace: stores raw trace data collected from tracing. tls_${trace instance name}-dependency: stores topology data extracted and aggregated from raw trace data. Tip Manually deleting log topics is not supported, but the configuration of tls_${trace instance name}-trace can be modified. By default, trace data in log topics can be stored for 30 days. You can modify based on your needs.
Index	By default, TLS configures index fields for trace topics. You can also add new field index based on the default settings. Preset index fields can not be modified or deleted. Otherwise, errors in trace instance or data query may occur.

Notice

Trace storage in TLS is free of service charges. However, when using trace storage, resources like log topic shards, data storage, and index storage, will be billed according to the standard pricing model. For detailed pricing information, see Billing items based on pay-by-feature mode.

To ensure data security, we recommend that you proceed with a VolcanoEngine IAM account when using trace storage. IAM sub-accounts must have permission policies for operating trace instances and writing data. For detailed instructions, see Examples of custom permission policy.

Limits

The number of trace instances you can create in each VolcanoEngine account depends on the remaining quota of log topics that can be created in the project to which the trace instance belongs.

Trace feature relies on the scheduling concurrency limits of SQL tasks. For details, see Limits.

The upload throughput and QPS for trace are aligned with the associated topic. If thresholds are exceeded, errors will occur.

When you query trace, the query QPS and data volume are aligned with the associated topic. If thresholds are exceeded, errors will occur.

The log topic name and index configuration of the dependency associated with the Trace instance cannot be modified.

When uploading spans, each span can not exceed 9 KiB. The maximum size per request is 4 MiB.

Access methods

TLS supports delivering trace data via native OpenTelemetry protocol. The recommended access methods are as follows.

Access method	Description	Reference
OpenTelemetry SDK	OTel provides SDKs in various languages based on the OTel standard API for collecting trace data. You can use the OTel SDK to write trace data directly to the log service. OTel supports both HTTPS protocol and gRPC method.	Write data via OpenTelemetry SDK

Tip

We recommend that you use open-source OTel standard protocol, and integrate with OpenTracing and OTel standards for quick TLS access and seamless connectivity with other open-source systems.

We recommend that all components and services in the system use the same trace storage access method to enable unified and comprehensive trace data collection and upload.

Last updated: 2026.07.27 14:20:21