The data transformation feature in Simple Log Service uses consumer groups to consume and process log data. You can orchestrate more than 200 built-in functions to create transformation rules. This document explains how data is scheduled during transformation and how the rules engine works.
Scheduling basics
The data transformation feature of Simple Log Service uses a consumer group to consume log data from the source Logstore as a stream. It processes each log using a transformation rule and then outputs the result.

Scheduling mechanism
For each transformation rule, the scheduler starts one or more running instances. Each instance acts as a consumer for one or more shards in the source Logstore. The scheduler determines the number of parallel instances based on their memory and CPU usage. The maximum number of instances is equal to the number of shards in the source Logstore.
Running instance
A running instance reads source logs from its assigned shards according to your configuration. It processes the data using the transformation rule and outputs the result to the destination Logstore. Transformation rules can use external resources to enrich log data. The instance uses the consumer group mechanism to save its consumption position in a shard. This ensures that if the instance stops unexpectedly, it can resume consumption from the last saved breakpoint.
Task stop
If you do not configure an end time for the task, the running instances continue to run by default, and the data transformation job does not stop.
If you configure an end time for the task, the running instances process all logs received up to that time. Then, the instances automatically exit and the data transformation job stops.
If a job stops for any reason and is restarted, it resumes consumption from the last saved position by default.
Rules engine basics: Basic operations
You can use the built-in functions provided by the SLS DSL to write transformation rules. Each function represents a transformation step, and the rules engine executes the functions in sequence.
e_set("log_type", "access_log")
e_drop_fields("__action")
e_if(e_search("ret: pass"), e_set("result", "pass"))
e_if(e_search("ret: unknown"), DROP)The following figure shows the logic.
Basic logic
Each event function in a rule is executed in sequence. Each function processes and modifies an event before passing the modified event to the next function.
For example,
e_set("log_type", "access_log")adds a field namedlog_typewith the value access_log to each event. The next function then receives the updated event, which now includes thelog_typefield.Conditional logic
Steps can have conditions. If an event does not meet a condition, it skips that step's operation.
For example, the function
e_if(e_search("ret: pass"), e_set("result", "pass"))first checks if theretfield contains pass. If the condition is not met, no action is taken. If the condition is met, the function sets the value of theresultfield to pass.Stop processing
If a step returns zero events, the event is considered deleted.
For example,
e_if(e_search("ret: unknown"), DROP)discards events where the value of theretfield is unknown. After an event is discarded, no subsequent operations are performed on it, and processing begins on the next event.
Rules engine basics: Output, copy, and split
The rules engine also supports copying, outputting, and splitting events.
e_coutput("archive_Logstore") )
e_split("log_type")
e_if(e_search("log_type: alert"), e_output("alert_Logstore") )
e_set("result", "pass")Assume the source log to be processed is as follows:
log_type: access,alert
content: admin login to database.The following figure shows the logic.
Output event
An output operation can be considered a special type of stop processing. For example, in Step 3, if an event has a
log_typefield with the value alert, thee_output("alert_Logstore")function is called. This function outputs the event to the specified destination and then deletes the event. Subsequent operations are not performed on this event.Copy and output event
The
e_coutputfunction copies the current event and outputs the copy. The original event continues to the next processing step. For example, in Step 1, all received events are copied and then output to thearchive_Logstoredestination.Split and parallel processing
In Step 2, if the
log_typefield contains the values access and alert,e_split("log_type")splits the event into two separate events based on the values in thelog_typefield. The two new events are identical except for the log_type field, which will have the value access in one event and alert in the other. Each new event then continues through the subsequent steps independently.After the split, each resulting event proceeds through the subsequent steps independently.