Torch Log Service
Torch Log Service
Torch Log Service
Document
Product News
Product Overview
Product Billing
User Guide
TLS Agent
AgentLoop
Resource management
Host group
Data collection
LogCollector collection
Introduction to LogCollector
Installation and upgrade
Collect host logs
Collect container logs
LogCollector plugins
Manage LogCollector
general reference
Data import
Cloud product log collection
TOS log collection
DBW log collection
VPN Log collection
VKE log collection
CLB log collection
CloudTrail log collection
CFW log collection
NTA log collection
ALB log collection
APMPlus log collection
veFaaS log collection
VPC log collection
veImageX log collection
TrafficRoute DNS log collection
DDoS log collection
WAF log collection
DCDN log collection
Multi-cloud security platform log collection
APIG log collection
Machine learning task log collection
CR log collection
Volcano Ark application lab log collection
FileNAS log collection
LLM Application Firewall Service log collection
vePFS log collection
Cloud security center log collection
EFS log collection
Data storage
Query and analysis
Configure log indexes
Query log
Analyze logs
Query and analyze logs using third-party tools
Associate external data source for log query
SQL function
SQL syntax
Visualization
Query and analysis charts
Summaries of query and analysis charts
Create dashboard
Use dashboard
Add dashboard filters and variables
Use other systems to analyze logs
Log application
Log applications for product observability
Log applications for large models observability
Coding Agent log app
ModelProvider log app
No-coding Agent log app
Log applications for basic service monitoring
Data processing
Data transformation
Syntax and functions
Global operation function
expression function
Data processing best practices
general reference
Data write processor
Data consumer processor
Data consumption and shipping
Ship logs to TOS
Ship logs to Kafka
Ship logs to Splunk
Alarm
Alarm policy
Alarm notification content
Alarm notification content template
alarm notification channel
Tracing service
Monitor Log Service
API reference
Project management API
Topic management API
Shard management API
Index management API
Log management API
Host group management API
Collection configuration management API
Data import API
Data processor API
Data transformation API
Data backflow API
SQL analysis API
Alarm management API
Consumer group management API
Kafka protocol consumption API
Tag management API
Trace storage API
Account management API
SDK reference
Go SDK
Java SDK
Python SDK
iOS SDK
C++ SDK
CLI reference
Best practices
Data collection
Query and analysis
permission management
Consumption and delivery
Visualization
Alarm
FAQs
Billing and cost FAQ
Data collection FAQ
Data storage FAQ
Index configuration FAQ
Query and analysis FAQ
Scheduled SQL tasks FAQ
Alarm FAQ
- Documentation
Torch Log ServiceUser GuideData processingData transformationHow data transformation works
Copy page
Download PDFData transformation
How data transformation works
Copy pageDownload PDFHow data transformation works
The data transformation feature provided by TLS consumes log data from the source topic through consumer groups. The data transformation feature automatically compiles specified DSL statements, parses them into processing rules, and applies these rules to transform and process log data. Then the feature writes the processed log data to the specified log topic via the log writing API. This topic describes the scheduling principles of transformation tasks and the working principles of processing rules.
Scheduling principles
The data transformation feature uses coordinated consumer groups to stream log data from the source log topic. Each transformation task corresponds to a consumer group, which launches one or more consumers. Then these consumers process the consumed log data. Each consumer processes one or more shards from the source log topic, and the maximum number of consumers matches the number of readable and writable shards in the source log topic.
Processing rule principles
TLS supports writing processing rules using built-in functions provided by the TLS DSL. Each statement in a processing rule represents a processing step. The rule engine executes these steps in the order that the statements appear. For example, the following four statements define four steps in order.
f_set("user_type", "normal")
f_drop("content")
c_if(f_has("inner_user"), f_set("user_source", "inner"))
c_if(op_eq(v("user_city"), "chengdu"), e_output("target"))
Corresponding logic diagram:
Rule | Description |
Basic logic | TLS executes each statement defined in the rule sequentially and processes every function in the statements based on semantic order. Each function modifies the log event during execution and returns the processed event. For example, f_set("user_type", "normal") adds a field user_type with value normal to every event. The next function receives the event after the new user_type field has been added. |
Conditional judgment | The data transformation rules allow setting conditions for each step. Only events that meet these conditions will trigger the corresponding function execution. For example, in the statement c_if(f_has("inner_user"), f_set("user_source", "inner")), TLS first checks whether the field inner_user exists. If it does not exist, no action is taken. If it exists, a new field user_source will be added with the value set to inner. |
Output | If the specified condition is met, the data is output; if not, no action will be taken. If no other rule processes the event, it will be deleted afterwards. For example, c_if(op_eq(v("user_city"), "chengdu"), e_output("target")). If the value of user_city is chengdu, the event will be output to the log topic with the alias target. |
Last updated: 2026.04.16 15:32:45
All rights reserved © Beijing Volcano Engine Technology Co., Ltd2024
