用户可以编写云函数 SCF 来处理 CLS 日志服务中采集到的日志，通过将采集到的日志作为参数传递来调用 SCF 云函数，函数代码可以对其进行数据加工处理、分析或将其转储到其他云产品。
CLS 触发器具有以下特点：
Push 模型
CLS 会监控指定的日志主题，在一定时间内聚合并调用相关函数，将事件数据推送给 SCF 函数。
异步调用
CLS 始终使用异步调用类型来调用函数，结果不会返回给调用方。有关调用类型的更多信息，请参阅 调用类型。
CLS 触发器属性
日志集：可配置连接的 CLS 日志集，仅支持选择同地域下的日志集。
日志主题：可配置连接的 CLS 日志主题，日志主题是管理配置日志服务触发器的最小单元。
最长等待时间：单次事件拉取的最长等待时间。
CLS 触发器消费及消息传递
CLS 后台的消费模块在消费到消息后，会根据最长等待时间、投递过程及消息体大小等信息，组合为事件结构并发起函数调用（异步调用）。相关限制说明如下：
最长等待时间
目前云函数后台的消费模块的范围在3 - 300s，避免时延过长才进行消费。例如，最长等待时间设置为60s，则消费模板会60s聚合一次日志数据投递至云函数。
异步调用的事件大小限制
128KB，详情请参见 限制说明。如果日志主题的消息较大，例如消息体在最长等待时间内通过后台组件压缩后依然达到128KB以上，由于异步调用的128KB限制，传递给云函数的事件结构中系统会依次截取通过 Gzip 压缩后达到128KB的消息体并投递，而不使用用户配置的最长等待时间的聚合。
投递过程
如果投递过程中发生错误且是不可重试的错误（例如 AccessDeniedException 或 ResourceNotFoundException），则 CLS 触发器会中断重试传输逻辑。
说明
在消息传递过程中，每次组合的时间聚合不一定相同，即每个事件结构内的消息个数在1 - 配置的最长等待时间之间。如果配置的最长等待时间过大，有可能出现事件结构内的聚合时间始终不会达到最大聚合时间的情况。
在云函数中获取到事件内容后，可选择循环处理的方式，确保每一条消息都得到处理，而不是假定每次传递的消息时间均是恒定的。
CLS 触发器的事件消息结构
在指定的 CLS 触发器接收到消息时，CLS 的后台消费者模块会消费消息，并将消息组装异步调用您的函数。为保证单次触发传递数据的效率，数据字段的值是 Base64 编码的 Gzip 文档。
{"clslogs": {"data": "ewogICAgIm1lc3NhZ2VUeXBlIjogIkRBVEFfTUVTU0FHRSIsCiAgICAib3duZXIiOiAiMTIzNDU2Nzg5MDEyIiwKICAgICJsb2dHcm91cCI6I..."}}
在解码和解压缩后，日志数据类似以下 JSON 体，以 CLS Logs 消息数据（已解码）为例：
{"topic_id": "xxxx-xx-xx-xx-yyyyyyyy","topic_name": "testname","records": [{"timestamp": "1605578090000000","content": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}, {"timestamp": "1605578090000000","content": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}]}
数据结构内容详细说明如下：
结构名 | 内容 |
topic_id | 日志主题的 ID |
topic_name | 日志主题的名称 |
timestamp | 日志生产时间，微秒级时间戳 |
content | 日志内容 |