华为云用户手册

场景一：过滤LTS日志 您可以使用e_if函数与DROP参数、e_if_else函数与DROP参数过滤日志，也可以使用e_drop函数或e_keep函数过滤日志。 常用规则如下所示： e_keep(e_has(...))：满足条件时保留，不满足条件时丢弃。 e_drop(e_has(...) )：满足条件时丢弃，不满足条件时保留。 e_if_else(e_has("..."), KEEP, DROP)：满足条件时保留，不满足条件时丢弃。 e_if(e_not_has("..."), DROP)：满足条件时丢弃，不满足条件时保留。 示例如下所示： 原始日志 [{ //日志1"source": "192.168.0.1","client_ip": "192.168.0.2","receive_time": 1587214851,"topic": "app","class": "test_case","id": 7892,"content": "this is a log test"},{ //日志2"source": "192.168.0.1","class": "produce_case","id": 7890,"content": "this is a log test"}] 加工规则：丢弃没有topic字段和receive_time字段的日志。 e_if(e_not_has("topic"),e_drop())e_if(e_not_has("receive_time"),e_drop()) 加工结果 {source: 192.168.0.1client_ip: 192.168.0.2receive_time: 1587214851topic: app class: test_caseid: 7892content: this is a log test} 父主题： 使用DSL加工函数清洗LTS日志数据

场景八：数据转化微秒级标准 ISO8601 时间戳 部分场景需要日志服务的数据加工满足高精度时间戳的需求，当原始日志中存在标准 ISO8601时间格式的字段，您可以使用e_set字段操作函数，将其解析成微秒精度的日志时间。 原始日志 { "source": "1.2.3.4", "time": 1704983810, "topic": "test", "log_time":"2024-01-11 23:10:43.992847200"} 加工规则 e_set( "time", dt_parsetimestamp(v("log_time"), tz="Asia/Shanghai"), mode="overwrite",)e_set("tmp_ms", dt_prop(v("log_time"), "microsecond"))e_set( "time_ns_part", op_mul(ct_int(v("tmp_ms")), 1000),) 加工结果 {"time_ns_part": 992847000,"tmp_ms": 992847,"topic": "test","source": "1.2.3.4","time": 1704985843,"log_time": "2024-01-11 23:10:43.992847200"} 父主题： 使用DSL加工函数清洗LTS日志数据

背景信息 使用敏感数据包括手机号、银行卡号、邮箱、IP地址、AK、身份证号、网址、订单号、字符串等场景中，您需要为敏感数据进行脱敏操作。在日志服务数据加工服务中，常见的脱敏方法有正则表达式替换（关键函数regex_replace）、Base64转码（关键函数base64_encoding）、MD5编码（关键函数md5_encoding）、str_translate映射（关键函数str_translate）等。更多信息，请参见正则表达式函数和编码解码函数。

场景5：IP地址脱敏 日志中包含IP地址信息，可同时运用regex_replace函数，对IP地址进行正则捕获后而脱敏。 原始日志 { "content":"ip is 192.0.2.10"} 加工规则 e_set("ip_encrypt",regex_replace(v('content'), r"((25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9]{2}|[1-9]?[0-9])", replace=r"****")) 加工结果 {"content": "ip is 2.0.2.10","ip_encrypt": "ip is ****"}

场景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_"}

场景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语法规则。

场景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日志数据

场景2：银行卡信息脱敏 日志中包含银行卡或者信用卡信息，可采用正则表达式，运用regex_replace函数脱敏。 原始日志 { "content":"bank number is 491648411333978312 and credit card number is 4916484113339780"} 加工规则 e_set( "bank_number", regex_replace( v("content"), r"([1-9]{1})(\d{14}|\d{13}|\d{11})(\d{4})", replace=r"****\3" ),) 加工结果 {"bank_number": "bank number is ****8312 and credit card number is ****9780","content": "bank number is 491648411333978312 and credit card number is 4916484113339780"}

场景6：身份证脱敏 日志中包含身份证信息，可同时运用regex_replace函数，对身份证号进行正则捕获后而脱敏。 原始日志 content: Id card is 111222190002309999 加工规则 e_set( "id_encrypt", regex_replace(v("content"), r"\b\d{17}(\d|X)\b", replace=r"\1****")) 加工结果 {"id_encrypt": "Id card is 9****","content": "Id card is 111222190002309999"}

使用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），用于保存监控数据。

背景信息 日志服务数据加工映射富化函数包括普通映射函数和搜索映射函数，两者区别如下所示： 普通映射函数使用文本完全匹配方式来映射。普通映射函数包括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"}}

表格构建 不同表格构建方式对比参考如下： 表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"}}

场景一：展开和提取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"}}

场景四：删除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"}

采集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概述。

采集终端用户日志 端侧日志全面采集接入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概述。

字典构建 不同字典构建方式对比参考如下： 表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 控制台创建日志组，详细操作请参考管理日志组。 在云日志服务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" } ]}}