华为云用户手册

场景9：字符串脱敏 若希望日志中的关键字符串不被暴露，可通过str_translate函数制定映射规则，对关键字符或字符串进行映射脱敏。 原始日志 { "content": "message level is info_"} 加工规则 e_set("data_translate", str_translate(v("content"),"aeiou","12345")) 加工结果 {"data_translate": "m2ss1g2 l2v2l 3s 3nf4_","content": "message level is info_"}

场景3：邮箱地址脱敏 日志中包含邮箱信息，可采用正则表达式，运用regex_replace函数脱敏。 原始日志 { "content":"email is username@example.com"} 加工规则 e_set( "email_encrypt", regex_replace( v("content"), r"[A-Za-z\d]+([-_.][A-Za-z\d]+)*(@([A-Za-z\d]+[-.])+[A-Za-z\d]{2,4})", replace=r"****\2", ),) 加工结果 {"content": "email is username@example.com","email_encrypt": "email is ****@example.com"}

场景8：订单号脱敏 对日志内容中的订单号做脱敏处理，同时不希望其他人能够解码，可运用MD5编码函数，对订单号进行编码。 原始日志 { "orderId": "20210101123456"} 加工规则 e_set("md5_orderId",md5_encoding(v("orderId"))) 加工结果 {"orderId": 20210101123456,"md5_orderId": "9c0ab8e4d9f4eb6fbd5c508bbca05951"}

场景二：使用e_set函数为日志空缺字段赋值 您可以使用e_set函数为日志空缺字段赋值。 场景1：原字段不存在或者为空时，为字段赋值。 e_set("result", "......value......", mode="fill") 示例如下所示： 原始日志 { "name":""} 加工规则 e_set("name", "Apache 2.0", mode="fill") 加工结果 {name:Apache 2.0} 场景2：为多个字段赋值。 e_set("k1", "v1", "k2", "v2") 示例如下所示： 原始日志 {"source":"192.168.0.1","topic":"","tag":"","id":7990,"content":"this is a log"} 加工规则 e_set("topic","app","tag","stu") 加工结果 {topic: appsource: 192.168.0.1tag: stuid: 7990content: this is a log} 父主题： 使用DSL加工函数清洗LTS日志数据

场景1：手机号脱敏 日志中包含不希望被暴露的手机号，可采用正则表达式，运用regex_replace函数脱敏。参考如下示例： 原始日志 { "iphone":"13900001234"} 加工规则 e_set( "sec_iphone", regex_replace(v("iphone"), r"(\d{0,3})\d{4}(\d{4})", replace=r"\1****\2"),) 加工结果 {"sec_iphone": "139****1234","iphone": 13900001234}

场景7：网址脱敏 对日志内容中的网址做脱敏处理，并且将脱敏的数据转成明文格式，可运用Base64编码解码函数，对网址进行转码。 原始日志 { "content":"https://www.huaweicloud.com/"} 加工规则 e_set("base64_url",base64_encoding(v("content"))) 加工结果 {"base64_url": "aHR0cHM6Ly93d3cuaHVhd2VpY2xvdWQuY29tLw==","content": "https://www.huaweicloud.com/"} 如果想对base64_url进行解码，可以使用base64_decoding(v("base64_url"))DSL语法规则。

使用e_search_dict_map函数进行数据富化 本案例介绍使用e_search_dict_map函数完成数据富化的方法。 原始日志 [{ "http_host": "example.com", "http_status": 200, "request_method": "GET"},{ "http_host": "example.org", "http_status": 201, "request_method": "POST"},{ "http_host": "example.net", "http_status": 404, "request_method": "GET"}] 加工需求 根据日志中的http_status字段的值的不同，为每条日志添加不同的type信息。 为http_status为2XX的日志，添加type字段，并将字段值设置为正常。 为http_status为3XX的日志，添加type字段，并将字段值设置为重定向。 为http_status为4XX的日志，添加type字段，并将字段值设置为错误。 加工规则 e_search_dict_map({"http_status:2??": "正常","http_status:3??": "重定向","http_status:4??": "错误"}, "http_status", "type") 加工结果 {"http_status": "正常","request_method": "GET","http_host": "example.com"}{"http_status": "正常","request_method": "POST","http_host": "example.org"}{"http_status": "错误","request_method": "GET","http_host": "example.net"}

使用e_dict_map函数进行数据富化 本案例介绍使用e_dict_map函数完成数据富化的方法。 原始日志 [{ "http_host": "example.com", "http_status": 300, "request_method": "GET"},{ "http_host": "example.org", "http_status": 200, "request_method": "POST"},{ "http_host": "example.net", "http_status": 400, "request_method": "GET"},{ "http_host": "huaweicloud.com", "http_status": 500, "request_method": "GET"}] 加工需求 将http_status字段中的请求状态码转化为文本格式，并添加到status_desc字段中。 加工规则 e_dict_map({"400": "请求错误", "500": "服务器错误", "300": "跳转", "200": "成功"}, "http_status", "status_desc") 在实际情况中，HTTP请求状态码不止以上4种，详情请参见HTTP请求状态码。当http_status字段的值为401、404时，需要更新字典覆盖，否则无法匹配。 加工结果 {"status_desc": "跳转","http_status": 300,"request_method": "GET","http_host": "example.com"}{"status_desc": "成功","http_status": 200,"request_method": "POST","http_host": "example.org"}{"status_desc": "请求错误","http_status": 400,"request_method": "GET","http_host": "example.net"}{"status_desc": "服务器错误","http_status": 500,"request_method": "GET","http_host": "huaweicloud.com"}

步骤一：配置监控数据存储路径 Zabbix会将监控数据保存在其所在的机器上，您可以根据如下步骤设置监控数据的存储路径。 登录Zabbix所在服务器。 打开zabbix_server.conf文件。 vim /etc/zabbix/zabbix_server.conf 在zabbix_server.conf文件中，设置数据存储路径。 ExportDir=/tmp/ 重启Zabbix服务，使配置生效。 systemctl restart zabbix-server 配置生效后，Zabbix会在/tmp目录下生产文件（文件名后缀为.ndjson），用于保存监控数据。

场景四：删除JSON对象值 日志中包含JSON对象时，您可以通过dct_delete函数删除JSON对象值。 例如，删除JSON对象中的键值对"k1":"v1"、"k2":"v2"。 原始日志 { "data": {"k1":"v1","k2":"v2", "k3": "v3"}} 加工规则 e_set("data", dct_delete(v("data"), "k1", "k2")) 加工结果 data:{"k3": "v3"}

背景信息 日志服务数据加工映射富化函数包括普通映射函数和搜索映射函数，两者区别如下所示： 普通映射函数使用文本完全匹配方式来映射。普通映射函数包括e_dict_map函数和e_table_map函数，两者区别在于e_dict_map函数接收的是dict类型的数据，e_table_map函数接收的是通过资源函数获取的table类型的数据。 例如：在nginx日志中，将特定的状态码转换为文本格式，可以使用普通映射函数e_dict_map。 状态码 文本 200 成功 300 跳转 400 请求错误 500 服务器错误 搜索映射函数的映射关键字是查询字符串，支持正则表达式匹配、完全匹配、模糊匹配等形式。搜索映射函数包括e_search_dict_map函数和e_search_table_map函数，两者区别在于e_search_dict_map函数接收的是dict类型的数据，而e_search_table_map函数接收的是通过资源函数获取的table类型的数据。 例如：在nginx日志中，将一定范围内的状态码转换为文本格式，可以使用搜索映射函数e_search_dict_map。 状态码 文本 2XX 成功 3XX 跳转 4XX 请求错误 5XX 服务器错误

场景三：更新JSON对象值 日志中包含JSON对象时，您可以通过dct_update函数更新JSON对象值。 例如，修改JSON对象中k1的值。 原始日志 {"data": {"k1": "k1","k2": "v2"}} 加工规则 e_set("data", dct_update(v("data"), {"k1": "new_k1"})) 加工结果 {"data": {"k1": "new_k1","k2": "v2"}}

场景五：解析值为JSON对象 您可以使用json_parse函数将字符串解析为JSON对象。 例如，data字段值为字符串，您可以将其转换为JSON对象。 原始日志 { "data": "pre{ \"k1\": \"v1\", \"k2\": \"v2\"}"} 加工规则 e_set("json_object", json_parse(op_slice(v("data"), 3, 28))) 加工结果 {"data": "pre{ \"k1\": \"v1\", \"k2\": \"v2\"}","json_object": {"k1": "v1","k2": "v2"}}

场景一：展开和提取JSON对象 日志中包含JSON对象时，您可以通过e_json函数展开和提取对象。 示例：指定字段名精确提取JSON对象值，例如展开data字段值中的第一层键值对。 原始日志 { "data": {"k1": "v1", "k2": {"k3": "v3", "k4": "v4"}}} 加工规则 e_json("data", depth=1) 加工结果 {"data": {"k1": "v1","k2": {"k3": "v3","k4": "v4"}},"k1": "v1","k2": {"k3": "v3","k4": "v4"}}

表格构建 不同表格构建方式对比参考如下： 表2 不同表格构建方式对比 构建方式 优点 缺点 从文本构建 直观、简单、方便。 如果内容较多，规则会相对冗长。不易于维护、扩展和复用。 从OBS资源构建 内容较多且不常修改时推荐使用，易于维护。 编写相对复杂。 从文本构建 e_table_map(tab_parse_csv("city,name,age\nshanghai,baixiao,10\ncity:nanjing,Maki,18"), "name",["city", "age"]) 从OBS资源构建 e_search_table_map(tab_parse_csv(res_obs_file("https://obs.xxx.myhuaweicloud.com","dsl-test-xx","data.csv")), "name",["city", "age"]) 其中data.csv是obs中的文件，值为： e_search_table_map(tab_parse_csv(res_obs_file("https://obs.xxx.myhuaweicloud.com","dsl-test-xx","data.csv")), "name",["city", "age"])

场景二：提取JSON对象值 日志中包含JSON对象时，您可以通过dct_get函数提取JSON对象值。 例如，提取JSON对象中的键值对"k1":"v1"，并将键名更改为key1。 原始日志 { "data": {"k1":"v1","k2":"v2"}} 加工规则 e_set("key1", dct_get(v("data"), "k1")) 加工结果 {"key1": "v1","data": {"k1": "v1","k2": "v2"}}

采集Web/移动端页面用户行为日志 关于Web/移动端页面用户行为日志可以分为两类： 页面与后台服务器交互日志：例如下单、登录、退出等。 页面无后台服务器交互日志：请求直接在前端处理，例如滚屏、关闭页面等。 使用匿名写入采集Web/移动端页面用户行为日志，详细请参见使用匿名写入采集日志。使用匿名写入采集日志功能仅支持华北-北京四、华东-上海一、华南-广州区域的白名单用户使用，如有需要，请提交工单，其他区域暂不支持申请开通。

采集服务器日志 服务器日志参考如下：以下示例日志仅供参考，请以实际日志为准。 Syslog日志 Aug 31 11:07:24 zhouqi-mac WeChat[9676]: setupHotkeyListenning event NSEvent: type=KeyDown loc=(0,703) time=115959.8 flags=0 win=0x0 winNum=7041 ctxt=0x0 chars="u" unmodchars="u" repeat=0 keyCode=32 应用程序Debug日志 __FILE__:build/release64/sls/shennong_worker/ShardDataIndexManager.cpp__LEVEL__:WARNING__LINE__:238__THREAD__:31502offset:816103453552saved_cursor:1469780553885742676seek count:62900seek data redolog:pangu://localcluster/redo_data/41/example/2016_08_30/250_1472555483user_cursor:1469780553885689973 Trace日志 [2013-07-13 10:28:12.772518] [DEBUG] [26064] __TRACE_ID__:661353951201 __item__:[Class:Function]_end__ request_id:1734117 user_id:124 context:..... 支持通过以下方法采集服务器日志： 将日志写到本地文件，通过创建采集任务写到指定日志流中。 Docker中产生的日志可以使用CCE接入LTS进行采集，详细请参考云容器引擎CCE应用日志接入LTS。 C#、Python、Java、PHP、C等日志可以使用SDK写入LTS，详细请参考SDK概述。

采集用户推广日志 商家一般通过以下方式推广新用户： 在注册网站时直接投放优惠券。 在扫描传单二维码、网页二维码或其他渠道的二维码，投放优惠券。 推广前先设置如下注册服务器地址，生成二维码（传单、网页）供用户注册扫描。用户通过扫码进行注册时，就可以得知用户是通过特定来源进入的，并记录日志。 http://example.com/login?source=10012&ref=kd4b 当服务端接受请求时，服务器输出如下日志： 2024-06-20 19:00:00 e41234ab342ef034,102345,5k4d,467890 支持通过以下方式采集用户推广日志： 应用程序输出日志到硬盘，通过ICAgent采集日志，详细请参考云主机E CS 文本日志接入LTS。 应用程序日志通过SDK写入LTS，详细请参考SDK概述。

采集服务端数据 支付宝和微信公众账号编程是典型的Web端模式，一般会有四种类型的日志，可以使用SDK上报日志的方式，详细请参考 云日志 服务支付宝小程序SDK、云日志服务微信小程序SDK。以下示例日志仅供参考，请以实际应用日志为准。 Nginx和Apache访问日志 Nginx和Apache访问日志用以监控、实时统计。 10.1.168.193 - - [01/Mar/2024:16:12:07 +0800] "GET /Send?AccessKeyId=8225105404 HTTP/1.1" 200 5 "-" "Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2" Nginx和Apache错误日志 2024/04/18 18:59:01 [error] 26671#0: *20949999 connect() to unix:/tmp/fastcgi.socket failed (111: Connection refused) while connecting to upstream, client: 10.101.1.1, server: , request: "POST /logstores/test_log HTTP/1.1", upstream: "fastcgi://unix:/tmp/fastcgi.socket:", host: "example.com" 应用层日志 应用层日志可以把事件产生的时间、地点、结果、参数等记录详细，扩展类字段一般放在最后。 {"labels":{"cccdasd":51,"platform":"wx"},"logs":[{"contents":[{"aaa":"13123","__client_time__":1728565099070}]}]} 应用层错误日志 {"errorCode":"LTS.403","errorMessage":" request header auth is empty"} 支持通过以下方法采集服务端数据： 将日志写到本地文件，通过创建日志采集任务写到指定日志流中。 Docker中产生的日志可以使用CCE接入LTS进行采集，详细请参考云容器引擎CCE应用日志接入LTS。 C#、Python、Java、PHP、C等日志可以使用SDK写入LTS，详细请参考SDK概述。

字典构建 不同字典构建方式对比参考如下： 表1 不同字典构建方式对比 构建方式 优点 缺点 直接构建 直观、简单、方便。 如果内容较多，规则会相对冗长。且静态不灵活。 从任务配置资源构建 内容较多且经常修改时推荐使用，易于维护。 不易于扩展和跨任务复用，不支持自动刷新。 从表格构建 高级场景下使用，维护机制更灵活。 需要构建和维护对应的表格，过程相对繁琐。 从字典函数构建 基于逻辑动态构建字典，特定场景下适用。 较为高级，不易于维护。 从其他表达式构建 从日志事件的字段中动态提取映射关系，特定场景下适用。 较为高级，不易于维护。 直接构建 e_dict_map({"400": "error", "200": "ok", "*": "other"}, "status", "message") 从任务高级配置构建 e_dict_map(res_local("http_code_map"), "status", "message") 其中http_code_map是任务高级配置项，值为： 从表格构建 使用tab_to_dict从表格构建。而表格的构建参见本文后面的表格构建。 e_dict_map(tab_to_dict(tab_parse_csv("status_code,status_info\n400,error\n200,ok\n*,other"), "status_code", "status_info"), "status", "message") 从字典函数构建 e_dict_map(dct_make("400", "error", "200", "ok", "*", "other"), "status", "message") 从其他表达式构建 e_dict_map(json_parse(v("http_code_map")), "status", "message") 此处从源日志的http_code_map字段中获取映射关系。

采集终端用户日志 端侧日志全面采集接入LTS，例如Web浏览器、IOS、安卓、百度小程序、微信小程序、钉钉小程序、快应用等多类端侧日志。LTS提供了多种移动端SDK，实现了缓存发送、异常重试、批量发送等稳定功能，用户快速集成即可全面采集移动端日志到LTS。 采集方案： 移动端：可以使用移动端iOS SDK，Android SDK接入。 ARM设备：ARM平台可以使用Native C交叉编译。 商家平台设备：X86平台设备可以用SDK、ARM平台可以使用Native C交叉编译。 支持通过以下方法采集终端用户日志： 将日志写到本地文件，通过创建日志采集任务写到指定日志流中。 Docker中产生的日志可以使用CCE接入LTS进行采集，详细请参考云容器引擎CCE应用日志接入LTS。 C#、Python、Java、PHP、C等可以使用SDK写入LTS，详细请参考SDK概述。

统一管理日志 在 云日志服务LTS 控制台创建日志组，详细操作请参考管理日志组。 在云日志服务LTS控制台为不同数据源产生的日志创建日志流，详细操作请参考管理日志流，以下示例日志仅供参考，请以实际应用日志为准。 wechat-server（用于存储微信服务器访问日志） wechat-app（用于存储微信服务器应用日志） wechat-error（用于存储错误日志） alipay-server alipay-app deliver-app（用于存储送货员App状态） deliver-error（用于存储错误日志） web-click（用于存储H5页面点击量的日志） server-access（用于存储服务端访问日志） server-app（用于存储服务器应用的日志） coupon（用于存储应用优惠券的日志） pay（用于存储支付日志） order（用于存储订单日志） 如需要对原始数据进行加工，可以通过创建日志加工任务，详细请参考DSL加工。DSL加工的功能在邀测中，仅支持华北-北京四、华东-上海一、华南-广州局点的内测用户使用，其他局点暂不支持。

多子键为数组的复杂JSON数据加工 程序构建的日志会以一种统计性质的JSON格式写入，通常包含一个基础信息以及多个子键为数组的数据形式。例如一个服务器每隔1分钟写入一条日志，包含当前信息状态，以及相关服务器和客户端节点的统计状态信息。 日志样例 { "content":{ "service": "search_service", "overal_status": "yellow", "servers": [ { "host": "192.0.2.1", "status": "green" }, { "host": "192.0.2.2", "status": "green" } ], "clients": [ { "host": "192.0.2.3", "status": "green" }, { "host": "192.0.2.4", "status": "red" } ]}} 加工需求 对原始日志进行topic分裂，分别是overall_type、client_status、server_status。 对不同的topic保存不同的信息。 overall_type：保留server、client数量、overall_status颜色和service信息。 client_status：保留host地址、status状态和service信息。 server_status：保留host地址、status状态和service信息。 解决方案：接下来分别介绍加工语法的使用方法，以下1-7的加工语法需要综合使用。 将一条日志拆分成三条日志，给主题赋予三个不同值再进行分裂，经过分裂后会分成除topic不同，其他信息相同的三条日志。 e_set("topic", "server_status,client_status,overall_type")e_split("topic") 处理后日志格式如下： topic: server_status // 另外2条是client_status和overall_type, 其他一样content: { ...如上...} 基于content的JSON内容在第一层展开，并删除content字段。 e_json('content',depth=1)e_drop_fields("content") 处理后的日志格式如下： topic: overall_type // 另外2条是client_status和overall_type, 其他一样clients: [{"host": "192.0.2.3", "status": "green"}, {"host": "192.0.2.4", "status": "red"}]overal_status: yellowservers: [{"host": "192.0.2.1", "status": "green"}, {"host": "192.0.2.2", "status": "green"}]service: search_service 对主题是overall_type的日志，统计client_count和server_count。 e_if(e_search("topic==overall_type"), e_compose( e_set("client_count", json_select(v("clients"), "length([*])", default=0)), e_set("server_count", json_select(v("servers"), "length([*])", default=0)) )) 处理后的日志为： topic: overall_typeserver_count: 2client_count: 2 丢弃相关字段： e_if(e_search("topic==overall_type"), e_drop_fields("clients", "servers")) 对主题是server_status的日志，进行进一步分裂。 e_if(e_search("topic==server_status"), e_split("servers"))e_if(e_search("topic==server_status"), e_json("servers", depth=1)) 处理后的第一条日志参考如下： topic: server_statusservers: {"host": "192.0.2.1", "status": "green"}host: 192.0.2.1status: green 处理后的第二条日志参考如下： topic: server_statusservers: {"host": "192.0.2.2", "status": "green"}host: 192.0.2.2status: green 保留相关字段： e_if(e_search("topic==server_status"), e_compose(e_drop_fields("servers"),e_drop_fields("clients"))) 对主题是client_status的日志进行进一步分裂，再删除多余字段。 e_if(e_search("topic==client_status"), e_split("clients"))e_if(e_search("topic==client_status"), e_json("clients", depth=1)) 处理后的第一条日志参考如下： topic: client_statushost: 192.0.2.3status: green 处理后的第二条日志参考如下： topic: clientshost: 192.0.2.4status: red 将以上语法综合后，参考如下： #总体分裂e_set("topic", "server_status,client_status,overall_type")e_split("topic")e_json('content',depth=1)e_drop_fields("content")# 处理overall_type日志e_if(e_search("topic==overall_type"), e_compose( e_set("client_count", json_select(v("clients"), "length([*])", default=0)), e_set("server_count", json_select(v("servers"), "length([*])", default=0)) ))e_if(e_search("topic==overall_type"), e_drop_fields("clients", "servers"))# 处理server_status日志e_if(e_search("topic==server_status"), e_split("servers"))e_if(e_search("topic==server_status"), e_json("servers", depth=1))e_if(e_search("topic==server_status"), e_compose(e_drop_fields("servers"),e_drop_fields("clients")))# 处理client_status日志e_if(e_search("topic==client_status"), e_split("clients"))e_if(e_search("topic==client_status"), e_json("clients", depth=1))e_if(e_search("topic==client_status"), e_compose(e_drop_fields("servers"),e_drop_fields("clients"))) 执行后输出日志如下： { "content":{ "service": "search_service", "overal_status": "yellow", "servers": [ { "host": "192.0.2.1", "status": "green" }, { "host": "192.0.2.2", "status": "green" } ], "clients": [ { "host": "192.0.2.3", "status": "green" }, { "host": "192.0.2.4", "status": "red" } ]}}

多层数组对象嵌套的复杂JSON数据加工 以一个复杂的保护多层数组嵌套的对象为示例，将users下的每个对象中的login_histories的每个登录信息都拆成一个登录事件。 原始日志 {"content":{ "users": [ { "name": "user1", "login_histories": [ { "date": "2019-10-10 0:0:0", "login_ip": "192.0.2.6" }, { "date": "2019-10-10 1:0:0", "login_ip": "192.0.2.6" }, { ...更多登录信息... } ] }, { "name": "user2", "login_histories": [ { "date": "2019-10-11 0:0:0", "login_ip": "192.0.2.7" }, { "date": "2019-10-11 1:0:0", "login_ip": "192.0.2.9" }, { ...更多登录信息... } ] }, { ....更多user.... } ]}} 期望分裂出的日志 name: user1date: 2019-10-11 1:0:0login_ip: 192.0.2.6name: user1date: 2019-10-11 0:0:0login_ip: 192.0.2.6name: user2date: 2019-10-11 0:0:0login_ip: 192.0.2.7name: user2date: 2019-10-11 1:0:0login_ip: 192.0.2.9 ....更多日志.... 解决方案 对content中的users进行分裂和展开操作。 e_split("content", jmes='users[*]', output='item')e_json("item",depth=1) 处理后返回的日志： content:{...如前...}item: {"name": "user1", "login_histories": [{"date": "2019-10-10 0:0:0", "login_ip": "192.0.2.6"}, {"date": "2019-10-10 1:0:0", "login_ip": "192.0.2.6"}]}login_histories: [{"date": "2019-10-10 0:0:0", "login_ip": "192.0.2.6"}, {"date": "2019-10-10 1:0:0", "login_ip": "192.0.2.6"}]name: user1content:{...如前...}item: {"name": "user2", "login_histories": [{"date": "2019-10-11 0:0:0", "login_ip": "192.0.2.7"}, {"date": "2019-10-11 1:0:0", "login_ip": "192.0.2.9"}]}login_histories: [{"date": "2019-10-11 0:0:0", "login_ip": "192.0.2.7"}, {"date": "2019-10-11 1:0:0", "login_ip": "192.0.2.9"}]name: user2 对login_histories先分裂再展开。 e_split("login_histories")e_json("login_histories", depth=1) 处理后返回的日志： content: {...如前...}date: 2019-10-11 0:0:0item: {"name": "user2", "login_histories": [{"date": "2019-10-11 0:0:0", "login_ip": "192.0.2.7"}, {"date": "2019-10-11 1:0:0", "login_ip": "192.0.2.9"}]}login_histories: {"date": "2019-10-11 0:0:0", "login_ip": "192.0.2.7"}login_ip: 192.0.2.7name: user2content: {...如前...}date: 2019-10-11 1:0:0item: {"name": "user2", "login_histories": [{"date": "2019-10-11 0:0:0", "login_ip": "192.0.2.7"}, {"date": "2019-10-11 1:0:0", "login_ip": "192.0.2.9"}]}login_histories: {"date": "2019-10-11 1:0:0", "login_ip": "192.0.2.9"}login_ip: 192.0.2.9name: user2content: {...如前...}date: 2019-10-10 1:0:0item: {"name": "user1", "login_histories": [{"date": "2019-10-10 0:0:0", "login_ip": "192.0.2.6"}, {"date": "2019-10-10 1:0:0", "login_ip": "192.0.2.6"}]}login_histories: {"date": "2019-10-10 1:0:0", "login_ip": "192.0.2.6"}login_ip: 192.0.2.6name: user1content: {...如前...}date: 2019-10-10 0:0:0item: {"name": "user1", "login_histories": [{"date": "2019-10-10 0:0:0", "login_ip": "192.0.2.6"}, {"date": "2019-10-10 1:0:0", "login_ip": "192.0.2.6"}]}login_histories: {"date": "2019-10-10 0:0:0", "login_ip": "192.0.2.6"}login_ip: 192.0.2.6name: user1 删除无关字段。 e_drop_fields("content", "item", "login_histories") 处理后返回的日志： {"date": "2019-10-10 0:0:0","name": "user1","login_ip": "192.0.2.6"}{"date": "2019-10-10 1:0:0","name": "user1","login_ip": "192.0.2.6"}{"date": "2019-10-11 0:0:0","name": "user2","login_ip": "192.0.2.7"}{"date": "2019-10-11 1:0:0","name": "user2","login_ip": "192.0.2.9"} 综上DSL规则参考如下： e_split("content", jmes='users[*]', output='item')e_json("item",depth=1)e_split("login_histories")e_json("login_histories", depth=1)e_drop_fields("content", "item", "login_histories") 总结：针对以上类似的需求，首先进行分裂，然后再做展开操作，最后删除无关信息。

应用场景 某个外卖平台型电商网站（包括用户、餐厅、配送员等），用户可以在网页、App、微信、支付宝等进行下单点菜，商家拿到订单后开始加工，并自动通知周围的快递员，最后由快递员将外卖送到用户手中。 在数据化运营的过程中，发现数据采集困难，例如： 多渠道：各种渠道数据分散，例如广告商、推广人员等。 多终端：网页版、公众账号、手机、浏览器（Web、移动端页面）等。 异构网：VPC、用户自建IDC，华为云ECS等。 多开发语言：核心系统Java、前端Nginx服务器、后台支付系统C++。 设备不同：商家有不同平台（X86、ARM）设备。 如果需要把散落在外部、内部的日志收集起来，可以通过LTS实现统一管理日志。 采集用户推广日志 采集服务端数据 采集终端用户日志 采集Web/移动端页面用户行为日志 采集服务器日志 采集不同网络环境下的日志数据

常用方案比较 字符串动态键值对提取分为关键字提取、值提取、关键字加工和值加工，常用方案为采用e_kv函数、e_kv_delimit函数和e_regex函数等。不同提取场景的三种方案如下： 方案 关键字提取 值提取 关键字加工 值加工 e_kv 使用特定正则表达式 支持默认的字符集、特定分隔符或者带(、)或（"）分隔 支持前后缀 支持文本escape e_kv_delimit 使用特定正则表达式 使用分隔符 支持前后缀 默认无 e_regex 组合自定义正则表达式和默认字符集过滤 完全自定义 自定义 自定义 大部分键值对的提取使用e_kv函数并配置特定参数就可以很好地满足，尤其是带括字符和反斜杠需要提取并转义时。其他复杂或高级的场景可以用e_regex函数来提取。部分特定场景下的键值对使用e_kv_delimit函数会更简单。

值提取 动态键值对之间以及关键字与值之间有明确标识，如a=b或a="cxxx"日志格式的，推荐用e_kv函数，示例如下。 原始日志 { "content":"k=\"helloworld\",the change world, k2=\"good\""} 加工规则 这种情况下使用e_kv函数，提取内容不包括the change world： e_kv("content")# e_regex函数写法e_regex("content",r"(\w+)=\"(\w+)",{r"\1": r"\2"}) 加工结果：提取后的日志为： {"k2": "good","k": "helloworld","content": "k=\"helloworld\",the change world, k2=\"good\""} 对带"的日志格式content:k1="v1=1"&k2=v2?k3=v3，推荐使用e_kv函数进行提取，例如： 原始日志 { "content":"k1=\"v1=1\"&k2=v2?k3=v3"} 加工规则 e_kv("content",sep="=", quote="'") 加工结果 处理后日志为： {"k1": "v1=1","k2": "v2","k3": "v3","content": "k1=\"v1=1\"&k2=v2?k3=v3"}

关键字加工 e_kv函数和e_kv_delimit函数都可以通过prefix="", suffix=""对关键字和值进行加工。 原始日志 { "content":"q=asd&a=1&b=2"} 加工规则(各语句分开执行，功能相同) e_kv("content", sep="=", quote='"', prefix="start_", suffix="_end")e_kv_delimit("content", pair_sep=r"&", kv_sep="=", prefix="start_", suffix="_end")e_regex("content",r"(\w+)=([a-zA-Z0-9]+)",{r"start_\1_end": r"\2"}) 加工结果 加工后的数据都是关键字加工形式，如下： {"start_b_end": 2,"start_a_end": 1,"start_q_end": "asd","content": "q=asd&a=1&b=2"} e_regex函数对关键字加工的能力更强，例如： 加工规则 e_regex("content",r"(\w+)=([a-zA-Z0-9]+)",{r"\1_\1": r"\2"}) 加工结果 加工后的数据都是关键字加工形式，如下： {"q_q": "asd","a_a": 1,"b_b": 2,"content": "q=asd&a=1&b=2"}

值加工 日志格式为k1:"v1\"abc"形式， 同时值加工的内容存在有双引号符号的情形，使用e_kv函数可正常进行提取。 原始日志 """这里的\只是普通的符号，不是转义符"""{ "content":"k1:\"v1\\\"abc\", k2:\"v2\", k3: \"v3\""} 加工规则： e_kv("content",sep=":", quote='"') 加工结果 提取后的日志为： {"k1": "v1\\","k2": "v2","k3": "v3","content": "k1:\"v1\\\"abc\", k2:\"v2\", k3: \"v3\""}