AI 助理
备案控制台
开发者社区 云存储 文章 正文

日志服务数据加工最佳实践: 多子键为数组的复杂JSON加工

2019-08-02 1189
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
对象存储 OSS，标准 - 本地冗余存储 20GB 3个月
推荐场景：
基于PAI-EAS挂载OSS部署AIGC服务 ossutil工具管理OSS
日志服务 SLS，月写入数据量 50GB 1个月
对象存储 OSS，恶意文件检测 1000次 1年
简介： 程序构建的日志经常会以一种统计性质的JSON格式写入, 通常其包含一个基础信息, 以及多个子健为数组的形式. 本篇如何使用日志服务数据加工处理多子键为数组的复杂JSON.

加工需求

统计类日志形式

程序构建的日志经常会以一种统计性质的JSON格式写入, 通常其包含一个基础信息, 以及多个子健为数组的形式. 例如一个服务器每隔1分钟写入一条日志, 包含当前信息状态, 以及相关服务器和客户端节点的统计状态信息.

样例:

__source__:  1.2.3.4
__topic__:  
content:{
     "service": "search_service",
     "overal_status": "yellow",
     "servers": [
         {
             "host": "1.2.3.4",
             "status": "green"
         },
         {
             "host": "1.2.3.5",
             "status": "green"
         }
     ],
     "clients": [
         {
             "host": "1.2.3.6",
             "status": "green"
         },
         {
             "host": "1.2.3.7",
             "status": "red"
         }
     ]
}

加工需求

1、对原始日志进行topic分裂，主题主要分为三个，分别是overall_type、client_status、server_status
2、对于不同的topic保存不同的信息

  • overall_type：保留server、client数量，overal_status颜色和service信息
  • client_status: 保留对应的host地址、status状态和service信息
  • server_status: 保留对应的host地址、status状态和service信息

期望输出的日志

期望样例中的一条日志会被分裂加工成5条日志:

__source__:  1.2.3.4
__topic__:  overall_type
client_count:  2
overal_status:  yellow
server_count:  2
service:  search_service


__source__:  1.2.3.4
__topic__:  client_status
host:  1.2.3.7
status:  red
service:  search_service


__source__:  1.2.3.4
__topic__:  client_status
host:  1.2.3.6
status:  green
service:  search_service


__source__:  1.2.3.4
__topic__:  server_status
host:  1.2.3.4
status:  green
service:  search_service


__source__:  1.2.3.4
__topic__:  server_status
host:  1.2.3.5
status:  green
service:  search_service

解决方案

初步处理

1、第一步将一条日志拆分成3条日志, 给主题赋予3个不同值, 在进行分裂，经过分裂后会分成除了topic不同，其他信息相同的三条日志。

e_set("__topic__", "server_status,client_status,overall_type")
e_split("__topic__")

处理后日志格式如下(在内存中)：

__source__:  1.2.3.4
__topic__:  server_status                    // 另外2条是client_status和overall_type, 其他一样
content:  {
    ...如前...
}

2、第二步为基于content的JSON内容在第一层展开, 并删除content字段:

e_json('content',depth=1)
e_drop_fields("content")

处理后的日志格式如下(在内存中):

__source__:  1.2.3.4
__topic__:  overall_type                          // 另外2条是client_status和overall_type, 其他一样
clients:  [{"host": "1.2.3.6", "status": "green"}, {"host": "1.2.3.7", "status": "red"}]
overal_status:  yellow
servers:  [{"host": "1.2.3.4", "status": "green"}, {"host": "1.2.3.5", "status": "green"}]
service:  search_service

处理overall_type日志

  1. 针对主题是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_type
server_count:  2
client_count:  2
  1. 丢弃相关字段:
e_if(e_search("__topic__==overall_type"), e_drop_fields("clients", "servers"))

处理server_status日志

  1. 针对主题是server_status的日志, 进行进一步分裂.
e_if(e_search("__topic__==server_status"), 
       e_compose(
                 e_split("servers"), 
                 e_json("servers", depth=1)
    ))

处理后的日志为2条如下(仅显示修改部分):

__topic__:  server_status
servers:  {"host": "1.2.3.4", "status": "green"}
host: 1.2.3.4
status: green

和

__topic__:  server_status
servers:  {"host": "1.2.3.5", "status": "green"}
host: 1.2.3.5
status: green
  1. 保留相关字段:
e_if(e_search("__topic__==overall_type"), e_drop_fields("servers"))

处理client_status日志

  1. 同理, 针对主题是client_status的日志, 进行进一步分裂, 在删除多余字段.
e_if(e_search("__topic__==client_status"), 
       e_compose(
                 e_split("clients"), 
                 e_json("clients", depth=1),
                 e_drop_fields("clients")
    ))

处理后的日志为2条如下(仅显示修改部分):

__topic__:  client_status
host: 1.2.3.6
status: green

和

__topic__:  clients
host: 1.2.3.7
status: red

综合

综上，LOG DSL规则是


# 总体分裂
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))
    ))

# 处理server_status日志
e_if(e_search("__topic__==server_status"), 
       e_compose(
                 e_split("servers"), 
                 e_json("servers", depth=1)
    ))
e_if(e_search("__topic__==overall_type"), e_drop_fields("servers"))


# 处理client_status日志
e_if(e_search("__topic__==client_status"), 
       e_compose(
                 e_split("clients"), 
                 e_json("clients", depth=1),
                 e_drop_fields("clients")
    ))

方案优化

一个边界问题

注意到以上方案对于content.servers和content.servers是空时的处理有一些问题,

假设原始日志是:

__source__:  1.2.3.4
__topic__:  
content:{
            "service": "search_service",
            "overal_status": "yellow",
            "servers": [ ],
            "clients": [ ]
}

会被分裂为3条日志, 其中主题是client_status和server_status的日志内容是空的.

__source__:  1.2.3.4
__topic__:  overall_type
client_count:  0
overal_status:  yellow
server_count:  0
service:  search_service


__source__:  1.2.3.4
__topic__:  client_status
service:  search_service
__source__:  1.2.3.4


__topic__:  server_status
host:  1.2.3.4
status:  green
service:  search_service

方案1

这里可以在初始分裂后, 处理server_status和client_status日志前分别判断并丢弃空的相关事件:

# 处理server_status: 空的丢弃(非空保留)
e_keep(op_and(e_search("__topic__==server_status"), json_select(v("servers"), "length([*])")))

# 处理client_status: 空的丢弃(非空保留)
e_keep(op_and(e_search("__topic__==client_status"), json_select(v("clients"), "length([*])")))

综合

综上，LOG DSL规则是


# 总体分裂
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))
    ))

# 新加: 预处理server_status: 空的丢弃(非空保留) 
e_keep(op_and(e_search("__topic__==server_status"), json_select(v("servers"), "length([*])")))

# 处理server_status日志
e_if(e_search("__topic__==server_status"), 
       e_compose(
                 e_split("servers"), 
                 e_json("servers", depth=1)
    ))
e_if(e_search("__topic__==overall_type"), e_drop_fields("servers"))


# 新加: 预处理client_status: 空的丢弃(非空保留) 
e_keep(op_and(e_search("__topic__==client_status"), json_select(v("clients"), "length([*])")))

# 处理client_status日志
e_if(e_search("__topic__==client_status"), 
       e_compose(
                 e_split("clients"), 
                 e_json("clients", depth=1),
                 e_drop_fields("clients")
    ))

方案2

在初始分裂时进行判断, 如果对应数据是空的就不分裂出更多事件:

# 初始主题
e_set("__topic__", "server_status")

# 如果content.servers非空, 则从server_status分裂出1条日志
e_if(json_select(v("content"), "length(servers[*])"),
     e_compse(
           e_set("__topic__", "server_status,overall_type"),
           e_split("__topic__")
     ))

# 如果content.clients非空, 则从overall_type再分裂出1条日志
e_if(op_and(e_search("__topic__==overall_type"), json_select(v("content"), "length(clients[*])")),
     e_compse(
           e_set("__topic__", "client_status,overall_type"),
           e_split("__topic__")
     ))

综合

综上，LOG DSL规则是


# 总体分裂
e_set("__topic__", "server_status")

# 如果content.servers非空, 则从server_status分裂出1条日志
e_if(json_select(v("content"), "length(servers[*])"),
     e_compse(
           e_set("__topic__", "server_status,overall_type"),
        e_split("__topic__")
     ))

# 如果content.clients非空, 则从server_status分裂出1条日志
e_if(op_and(e_search("__topic__==overall_type"), json_select(v("content"), "length(clients[*])")),
     e_compse(
           e_set("__topic__", "client_status,overall_type"),
        e_split("__topic__")
     ))

# 处理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))
    ))

# 处理server_status日志
e_if(e_search("__topic__==server_status"), 
       e_compose(
                 e_split("servers"), 
                 e_json("servers", depth=1)
    ))
e_if(e_search("__topic__==overall_type"), e_drop_fields("servers"))


# 处理client_status日志
e_if(e_search("__topic__==client_status"), 
       e_compose(
                 e_split("clients"), 
                 e_json("clients", depth=1),
                 e_drop_fields("clients")
    ))

比较

方案1会在分裂出日志后再删除, 逻辑上有些多余, 但规则简单易维护. 默认推荐.
方案2会在分裂前进行判断, 处理效率会高一些, 但规则略微冗余, 仅在特定场景(例如初始分裂可能导致大量额外事件产生)时推荐.

进一步参考

欢迎扫码加入官方钉钉群获得实时更新与阿里云工程师的及时直接的支持:
image

文章标签：
日志服务
关键词：
JSON数据
日志服务数据
日志服务最佳实践
JSON最佳实践
JSON数组
相关实践学习
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
【涂鸦即艺术】基于云应用开发平台CAP部署AI实时生图绘板
成喆
目录
相关文章
技术交流18179014480
|
1月前
|
JSON API 数据格式
淘宝拍立淘按图搜索API系列，json数据返回
淘宝拍立淘按图搜索API系列通过图像识别技术实现商品搜索功能，调用后返回的JSON数据包含商品标题、图片链接、价格、销量、相似度评分等核心字段，支持分页和详细商品信息展示。以下是该API接口返回的JSON数据示例及详细解析：
技术交流18179014480
447 136
技术交流18179014480
|
1月前
|
JSON 算法 API
Python采集淘宝商品评论API接口及JSON数据返回全程指南
Python采集淘宝商品评论API接口及JSON数据返回全程指南
技术交流18179014480
437 136
技术交流18179014480
|
1月前
|
JSON API 数据安全/隐私保护
Python采集淘宝拍立淘按图搜索API接口及JSON数据返回全流程指南
通过以上流程，可实现淘宝拍立淘按图搜索的完整调用链路，并获取结构化的JSON商品数据，支撑电商比价、智能推荐等业务场景。
技术交流18179014480
380 138
技术交流18179014480
|
2月前
|
JSON 缓存 自然语言处理
多语言实时数据微店商品详情API：技术实现与JSON数据解析指南
通过以上技术实现与解析指南，开发者可高效构建支持多语言的实时商品详情系统，满足全球化电商场景需求。
技术交流18179014480
213 0
阿里云云原生
|
2月前
|
SQL 人工智能 监控
SLS Copilot 实践：基于 SLS 灵活构建 LLM 应用的数据基础设施
本文将分享我们在构建 SLS SQL Copilot 过程中的工程实践，展示如何基于阿里云 SLS 打造一套完整的 LLM 应用数据基础设施。
阿里云云原生
650 53
阿里云云原生
|
2月前
|
数据采集 运维 监控
不重启、不重写、不停机：SLS 软删除如何实现真正的“无感数据急救”？
SLS 全新推出的「软删除」功能，以接近索引查询的性能，解决了数据应急删除与脏数据治理的痛点。2 分钟掌握这一数据管理神器。
阿里云云原生
234 28
凉凉心.
|
1月前
|
JSON 中间件 Java
【GoGin】（3）Gin的数据渲染和中间件的使用：数据渲染、返回JSON、浅.JSON()源码、中间件、Next()方法
我们在正常注册中间件时，会打断原有的运行流程，但是你可以在中间件函数内部添加Next()方法，这样可以让原有的运行流程继续执行，当原有的运行流程结束后再回来执行中间件内部的内容。​ c.Writer.WriteHeaderNow()还会写入文本流中。可以看到使用next后，正常执行流程中并没有获得到中间件设置的值。接口还提供了一个可以修改ContentType的方法。判断了传入的状态码是否符合正确的状态码，并返回。在内部封装时，只是标注了不同的render类型。再看一下其他返回的类型；
凉凉心.
157 3
凉凉心.
|
1月前
|
JSON Java Go
【GoGin】（2）数据解析和绑定：结构体分析，包括JSON解析、form解析、URL解析，区分绑定的Bind方法
bind或bindXXX函数（后文中我们统一都叫bind函数）的作用就是将，以方便后续业务逻辑的处理。
凉凉心.
264 3
技术交流18179014480
|
2月前
|
JSON API 数据安全/隐私保护
Python采集淘宝评论API接口及JSON数据返回全流程指南
Python采集淘宝评论API接口及JSON数据返回全流程指南
技术交流18179014480
1074 6
技术交流18179014480
|
2月前
|
JSON 自然语言处理 监控
淘宝关键词搜索与商品详情API接口（JSON数据返回）
通过商品ID（num_iid）获取商品全量信息，包括SKU规格、库存、促销活动、卖家信息、详情页HTML等。
技术交流18179014480
275 0

云存储

热门文章

最新文章

  • 1
    日志客户端（Logstash,Fluentd, Logtail）横评
  • 2
    《Kafka Stream》调研：一种轻量级流计算模式
  • 3
    10分钟精通Nginx访问日志分析统计
  • 4
    #云存储的成本到底省在哪儿# 终于搞明白，存储TCO原来是这样算的......
  • 5
    如何将DynamoDB的数据增量迁移到表格存储
  • 6
    表格存储数据模型和查询操作
  • 7
    时间序列数据的存储和计算 - 概述
  • 8
    时间序列数据的存储和计算 - 开源时序数据库解析（一）
  • 9
    MySQL执行计划解析
  • 10
    自建ELK vs 日志服务(SLS)全方位对比
  • 1
    Gin框架集成了本地、阿里云存储、腾讯云、七牛云文件存储方式，并留有继续拓展其他云存储能力，本文介绍多种文件存储使用和继续集成其他云存储方法指导
    59
  • 2
    阿里云 OSS MetaQuery 全面升级——新增内容和语义的检索能力，助力 AI 应用快速落地
    457
  • 3
    免费的ECS备份重磅上线！100GiB 免费额度，全地域覆盖！
    263
  • 4
    基于 Cloudflare Workers 构建高性能知识库镜像服务：反向代理与 HTML 动态重写实践
    441
  • 5
    金融保险行业客户配置OSS公共读引发数据泄漏风险
    204
  • 6
    Spring AOP切面编程颠覆传统！3大核心注解+5种通知类型，让业务代码纯净如初
    455
  • 7
    银行卡归属地及开户行查询API查询实战指南
    1145
  • 8
    信息一键收集：新闻查询API的核心功能和技术实现
    458
  • 9
    如何使用CDN加速访问OSS存储的图片资源？
    523
  • 10
    如何创建、修改和删除OSS加速器？
    202

    • 相关产品

  • 日志服务
    文档详情 产品详情

    • 相关课程

    更多
  • 基于MongoDB构建实时日志分析平台
  • 日志服务SLS 构建可观测体系实战
  • 日志服务 SLS 可观测数据分析平台介绍
  • 大数据知识图谱系列—基于ELK+Flink日志全观测最佳实践
  • 场景实践-基于阿里云Quick BI 对MOOC网站日志分析
  • JSON 自学手册图文教程

    • 相关电子书

    更多
  • PostgresChina2018_赖思超_PostgreSQL10_hash索引的WAL日志修改版final
  • Kubernetes下日志实时采集、存储与计算实践
  • 日志数据采集与分析对接
    • 下一篇
    oss云网关配置